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

  1. 云栖社区>
  2. 博客>
  3. 正文

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

稀奇古怪 2017-05-11 14:57:23 浏览1040
展开阅读全文

本文根据DCOS联盟第4期线上分享整理而成

 

讲师介绍20161220101033473.jpg

宋潇男

普元云计算架构师

 

 

  • 曾任职华为,负责云计算产品与解决方案的规划与管理,十年以上分布式系统和中间件技术经验,熟悉HPC、同格计算、云计算实战。

 

主题大纲:

1、回顾Java EE的发展

2、揭示Java EE的根本性缺陷

3、从Java EE的角度看应用容器云

4、对未来的展望

 

大家好,首先自我介绍一下。

 

20161220101043964.jpg

 

我来自普元软件,对Unix和云计算技术比较熟悉,而所在公司的传统业务是中间件,在这个背景下,我对眼下的容器热有着一些不同的看法,今天与大家分享。

 

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

 

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

 

20161220101054911.jpg

 

这里面有几组关键词,第一组是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的技术标准:

 

20161220101115905.jpg

 

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

 

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

 

20161220101129843.jpg

 

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

 

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

 

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

 

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

 

20161220101147752.jpg

 

再看一下WebSphere的概念图:

 

20161220101157688.jpg

 

WebSphere的主要概念有:

  • Application Server:即一个应用服务器实例;

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

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

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

 

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

 

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

 

20161220101212218.jpg

 

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

 

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

 

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

 

  • 第一个问题,资源隔离。

 

20161220101232147.jpg

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

 

  • 第二个问题,依赖管理。

 

20161220101250304.jpg

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

 

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

 

20161220101304282.jpg

 

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

 

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

 

20161220101319182.jpg

 

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的枪》。

 

20161220101421244.jpg

 

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

 

20161220101441928.jpg

 

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

 

20161220101451287.jpg

 

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

 

20161220101502596.jpg

 

Java EE的“子系统”,在应用容器云中以基础服务的形式提供。

 

20161220101521442.jpg

 

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

 

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

 

20161220101544644.jpg

 

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

 

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

 

20161220101555771.jpg

 

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

 

Q&A

 

Q1: 配合容器技术,Java EE的一些问题可以迎刃而解。我请问一下,贵公司的大数据相关应用(主要也都是Java相关),怎么与容器技术结合?

A1:我们确实没有Hadoop这类大数据产品,我们的数据类产品主要做的是数据治理。和容器的结合,主要是做元数据的管理。还有就是我们的容器云基于k8s,k8s现在的有状态业务能力还比较弱,还要等待一两个版本进行完善。

 

Q2:WAS是很重的J2EE容器,那么容器化必然会考虑他的启动时长限制,一般用这类云的都是并发较高的互联网应用,关于动态扩展到实际对外提供服务的时间间隔区你们怎么控制的呢?另外关于底层类加载的优化一般通过什么手段达到目标呢?

A2:容器化后我们这边基本上都是嵌入式应用服务器了,当然,IBM那边肯定会推荐WebSphere的Liberty版本。但是即使是嵌入式应用服务器,启动时间也还是有点慢,前段时间我正在做这个优化,应用稍微大一点,最快也要个十几秒,确实离理想状态还有点远。类加载这块,我感觉能做的优化不多,懒加载肯定不行。降低优化级别的话,虽然启动快了,但是运行时性能会下降。

原文发布时间为:2016-12-20

本文来自云栖社区合作伙伴DBAplus

网友评论

登录后评论
0/500
评论
稀奇古怪
+ 关注