应用容器云:接过Java EE的枪


 2016-12-26 16:09:08       801


blob.png

转载本文需注明出处:EAII企业架构创新研究院(微信号:eaworld),违者必究。如需加入微信群参与微课堂、架构设计与讨论直播请直接回复此公众号:“加群 姓名 公司 职位 微信号”。


老实说,今天的观点如果放在一年前,我不大敢讲,会比较有争议。最近看到有人也提出类似观点,所以我也整理了一下,拿出来分享。相信争议还是会有,希望能与大家共同探讨,也能进一步完善我的想法。


开始之前,首先需要明确下什么是Java EE,我直接引用了官方说明,不做翻译。



这里面有几组关键词,第一组是Platform、API and runtime,说明Java EE是远比Java语言范畴广泛的东西,今天所谈的Java EE的问题,基本上也和Java语言无关;第二组是large-scale、multi-tiered、scalable、distributed,这是Java EE的主攻方向,今天谈的问题主要也出在这里;第三组是modular components running on an applciation server,说明了Java EE的实现形态是应用服务器和一组运行在应用服务器上的组件。


下面看下Java EE的技术标准




Java EE由一系列技术标准组成,这里面有我们熟悉的用于定位和访问资源的JNDI、用于描述Web Service的WSDL、用于安全方面的JAAS、用于消息传递的JMS等等。这里不展开讲,后面会看到这些Java EE技术标准,或者说是Java EE的API和“子系统”,在应用容器云里,会以基础服务的形式体呈现。


下一页是Java EE的一组实现,其实就是一系列应用服务器




这个图来自IBM的竞争分析资料,稍微有一点美化自家产品WebSphere的味道,不过总体来说还算客观。

WebSphere确实在技术上最完整的实现了Java EE标准,在架构上可以支持最大的系统规模,就像图中所示,hundreds of servers,虽然很少见到上百个节点的WebSphere集群,但是WebSphere在架构设计上确实考虑到了这么大的规模。

既然WebSphere这么强,那我们就来打开看下WebSphere。

首先看下WebSphere的架构图,可以看到,Java EE的API作为一系列子系统运行在WebSphere中。



再看一下WebSphere的概念图



WebSphere的主要概念有

1.  Application Server:即一个应用服务器实例

2.  Node:一个操作系统实例,里面可以运行多个Application Server

3.  System:可以认为是一个物理机,通过虚拟化,上面可以运行多个操作系统实例,即多个Node

4.  Cell:一组执行相似任务的Node,作为一个管理域统一管理

这样的概念层次可以支持大规模的应用服务器集群,考虑的确实比同类产品要全面。

接下来看一下WebSphere如何管理large-scale multi-tiered系统。



只需要通过管理节点上传你的应用EAR,WebSphere就会帮你把应用部署到集群中所有Application Server实例上,可以在单一入口管理整个集群,还可以帮你管理前端的Web Server和后端的数据库。

看起来很美好,不是吗?然而事实上不是这样。

我们来看一下Java EE,或者说Java EE的技术实现 —— 应用服务器的四大问题。

第一个问题,资源隔离



应用服务器实例运行在单一JVM上面,而JVM无法隔离CPU、内存、IO等资源,所以一个应用有问题、或者是应用的某个模块有问题,都会造成应用服务器上的所有应用无法正常运行,有时候还会影响同一操作系统上的其他应用服务器。所以现状往往是,一个操作系统内只运行一个应用服务器,一个应用服务器上只运行一个应用,失去了应用服务器作为基础架构和资源池的意义。

第二个问题,依赖管理



应用服务器一般只能管理三层或者四层系统,对图中这种分布式系统无能为力,还记得最开始讲的Java EE的主攻方向里有distributed系统吗?实际上好像不是这么回事,或者说现在的分布式系统比起当年已经出现了根本性的变化。

第三个问题,与应用紧耦合



如图所示,应用服务器实际上已经变成了应用的一部分,而不是应用的基础设施。

第四个问题,CI/CD不友好



Java EE应用服务器过于庞大,很难纳入CI/CD流程。为什么要把应用服务器纳入CI/CD流程呢?前面说了,应用服务器实际上是应用的一部分,如果不纳入CI/CD流程,就会经常出现“在我这里能用,在你那里就不能用了”等看似琐碎、却影响很大的问题。

CI/CD都做不好,那怎么做DevOps呢!

这里可能有同学会说,可以用Tomcat、Jetty或者Spring Boot嘛。是这样,不过这些已经不是Java EE应用服务器了,使用嵌入式应用服务器是个很好的选择,但是这个时候,应用服务器就完全不具备large-scale、multi-tiered、scalable、distributed系统的管理能力了,后面可以看到,这些能力将由应用容器云提供。

上述这些Java EE意图解决却没有解决好的问题,应用容器云都可以很好的解决,所以才有了本次分享的题目:应用容器云,接过Java EE的枪。


使用容器技术配合微服务模式,Java EE的那些“子系统”以进程的方式运行在容器之中,可以做到很好的资源隔离并根据负载进行扩展。应用容器云标配的服务注册能力,可以比Java EE更好的解决当今分布式系统的依赖问题,应用容器和运行环境的耦合性很低,应用容器镜像高内聚而且体积适中,可以很容易的纳入CI/CD流程,Java EE的四大问题迎刃而解。

对比Java EE,应用容器镜像就像是更广义的“WAR”或者“EAR”,如果运行Java应用,镜像里可以包含应用本身、嵌入式应用服务器和应用在操作系统层面的各种依赖。


应用容器云就像是更广义的Java EE Platform,或者说是更广义的“应用服务器”,可以为各种语言和类型的应用提供Runtime并很好的将它们管理起来。

Java EE的“子系统”



在应用容器云中以基础服务的形式提供。



这些基础服务提供和Java EE API相似的能力,并且可以做的更好。

普元的数字化企业云平台正在紧张的开发之中,在此我对我司的产品和应用容器云这一产品形态做个展望。



应用容器云将完成Java EE未竟的事业。

最后我们来看一下Gartner的一个说法。


和我们的感受一样,与基于虚拟化的云平台,主要由运维人员参与的状况完全不同,这一波基于容器的云平台热潮由开发者推动,我个人也非常希望更多的开发者能够参与到这次变革之中。

谢谢大家。

关于作者:

宋潇男

EAII-企业架构创新研究院 专家委员

现任普元云计算架构师,曾在华为负责云计算产品与解决方案的规划和管理工作。曾负责国家电网第一代云资源管理平台以及中国银联基于OpenStack的金融云的技术方案、架构设计和技术原型工作。



关于EAII

EAII(Enterprise Architecture Innovation Institute)企业架构创新研究院,致力于软件架构创新与实践,加速企业数字化转型。

eaworld项目(微信号:eaworld,长按二维码关注)


eaworld是EAII的官方微信账号。


相关阅读: