应用容器云：接过Java EE的枪
主要大纲： 一、回顾Java EE的发展
二、揭露Java EE的根本性缺陷
三、从Java EE的角度看应用容器云
四、对未来的展望
老实说，今天的观点如果放在一年前，我不大敢讲，会比较有争议。最近看到有人也提出类似观点，所以我也整理了一下，拿出来分享。相信争议还是会有，希望能与大家共同探讨，也能进一步完善我的想法。
一、回顾Java EE的发展
开始之前，首先需要明确下什么是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的主要概念有：
- Application Server：即一个应用服务器实例
- Node：一个操作系统实例，里面可以运行多个Application Server
- System：可以认为是一个物理机，通过虚拟化，上面可以运行多个操作系统实例，即多个Node
- Cell：一组执行相似任务的Node，作为一个管理域统一管理
这样的概念层次可以支持大规模的应用服务器集群，考虑的确实比同类产品要全面。
接下来看一下WebSphere如何管理large-scale multi-tiered系统。
只需要通过管理节点上传你的应用EAR，WebSphere就会帮你把应用部署到集群中所有Application Server实例上，可以在单一入口管理整个集群，还可以帮你管理前端的Web Server和后端的数据库。
看起来很美好，不是吗？然而事实上不是这样。
二、揭露Java EE的根本性缺陷
我们来看一下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的那些“子系统”以进程的方式运行在容器之中，可以做到很好的资源隔离并根据负载进行扩展。应用容器云标配的服务注册能力，可以比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的金融云的技术方案、架构设计和技术原型工作。
