本文根据DCOS联盟第4期线上分享整理而成
宋潇男
普元云计算架构师
曾任职华为，负责云计算产品与解决方案的规划与管理，十年以上分布式系统和中间件技术经验，熟悉HPC、同格计算、云计算实战。
主题大纲：
1、回顾Java EE的发展
2、揭示Java EE的根本性缺陷
3、从Java EE的角度看应用容器云
4、对未来的展望
大家好，首先自我介绍一下。
我来自普元软件，对Unix和云计算技术比较熟悉，而所在公司的传统业务是中间件，在这个背景下，我对眼下的容器热有着一些不同的看法，今天与大家分享。
老实说，今天的观点如果放在一年前，我不大敢讲，会比较有争议。最近看到有人也提出类似观点，所以我也整理了一下，拿出来分享。相信争议还是会有，希望能与大家共同探讨，也能进一步完善我的想法。
开始之前，首先需要明确下什么是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的技术实现 —— 应用服务器的四大问题。
第一个问题，资源隔离。
应用服务器实例运行在单一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的一个说法：
和我们的感受一样，与基于虚拟化的云平台，主要由运维人员参与的状况完全不同，这一波基于容器的云平台热潮由开发者推动，我个人也非常希望更多的开发者能够参与到这次变革之中。谢谢大家！
Q1： 配合容器技术，Java EE的一些问题可以迎刃而解。我请问一下，贵公司的大数据相关应用（主要也都是Java相关），怎么与容器技术结合？
A1：我们确实没有Hadoop这类大数据产品，我们的数据类产品主要做的是数据治理。和容器的结合，主要是做元数据的管理。还有就是我们的容器云基于k8s，k8s现在的有状态业务能力还比较弱，还要等待一两个版本进行完善。
Q2：WAS是很重的J2EE容器，那么容器化必然会考虑他的启动时长限制，一般用这类云的都是并发较高的互联网应用，关于动态扩展到实际对外提供服务的时间间隔区你们怎么控制的呢？另外关于底层类加载的优化一般通过什么手段达到目标呢？
A2：容器化后我们这边基本上都是嵌入式应用服务器了，当然，IBM那边肯定会推荐WebSphere的Liberty版本。但是即使是嵌入式应用服务器，启动时间也还是有点慢，前段时间我正在做这个优化，应用稍微大一点，最快也要个十几秒，确实离理想状态还有点远。类加载这块，我感觉能做的优化不多，懒加载肯定不行。降低优化级别的话，虽然启动快了，但是运行时性能会下降。
原文发布时间为：2016-12-20
本文来自云栖社区合作伙伴DBAplus
