【阿里在线技术峰会】魏鹏：基于Java容器的多应用部署技术实践

本文首先向大家介绍阿里Java容器的发展历程，整个Java容器从开始到现在经历了哪些阶段，接着给大家分享目前Java容器的基础架构，最后与大家探讨经过这样的改变之后，它能够完成的一些高阶的特性，比如合并部署和多版本部署等对于我们的效率提升有明显的帮助的技术。

直播视频：点此进入

PDF下载：点此进入

以下为整理内容：

 

阿里Java容器的发展历程

阿里巴巴在开始阶段，就像普通的网站一样，通过前端的http的流量进来完成数据库的查询、调用，然后把数据反馈回去。当网站变得很大的时候，不能再像过去一样，只是通过单个系统就能够完成多个业务功能，我们需要把系统做拆分，服务化就是必由之路，Java容器诞生于服务框架的编写过程中，随着阶段不断的向前演进，陆续接入了很多其它的中间件，整个过程升级非常便利，直接替换部署的目录即可完成升级。阿里系发展迅猛，我们也将面临一些挑战，比如网站的链路越来越长，调用错综复杂，怎样通过应用容器的部署方式的改变使我们的性能提升，这是容器需要考虑的问题。

 

容器架构

Java容器的标准架构如图所示，在应用容器Tomcat基础上，我们抽象出一套Java容器，可以理解为在Tomcat中的一个固定子系统，在这个子系统中，我们会切割出两块内容，一是容器，一是插件，服务框架、消息组件、配置组件等都是按照标准的方式接入进去，都被封闭在自己的类加载器中，不会和应用之间产生冲突，这样就使得各个中间件的发展不会受制于其它中间件版本的选择。同时，容器会提供这些插件标准的部署方式、生命周期和事件体系，使得中间件的起停能够被我们所控制，这些中间件能够知道应用的上下线的一些过程，使得整个中间件和应用的关系变得更加自然。任何的插件都可以轻松的接入到整个容器体系中，把这些能力带给应用。

 

合并部署

横轴代表规模，纵轴代表部署复杂度，部署复杂度其实是人为造成的，用户可能把公司内部的应用割裂成多个，每个需要完成不同的工作，这种逻辑应用数量的上升必然会造成部署复杂度会变得很高。当应用变得复杂后，公司的业务提升了，就会引入服务的概念，我们需要把不同的业务进行拆分，机器数量就会相应变多，应用数也会增加。用户依然去访问页面，但可能穿过很多系统，这就需要远程调用，远程调用把两个系统进行连接去满足用户的请求，这样的结构确定后，它的规模会不断的向上攀升，会变得更加复杂，用户请求会随着网站规模的不断扩大，导致用户的请求离实际的数据源越来越远，远程调用在任何一个点都是不可靠的，用户在这个过程中承担的失败的概率会越来越高，访问的速率会越来越慢。

那么，怎样改变这个状况呢？我们可以在部署时利用Java容器把不同的应用部署在一起，是否会有效果呢？

确定优化路径

我们的核心链路是确定的，不论你的网站多大，真正用户去访问的系统的某一个功能是非常火热的，在核心链路中热点也是已知的，最关键的是我们的流量入口是固定的，从流量入口下手，优化核心链路中的热点线路。

核心链路上强相关的多应用部署

左侧是传统的样方式，前台应用、服务应用A和服务应用B都是通过远程调用来连接的。多应用部署的方式就是把这些在开发带是不同隔离的应用在部署时放在同一个JVM去做，放在一起后就把整个系统的远程调用转化成本地调用，这个过程就是服务框架能够根据Java容器提供的信息完成调用方式的转变，把不同的强关联的应用部署在同一个Java容器里，使得整个流程更加的顺畅。

远程调用转本地调用

容器提供给服务框架当前部署的应用信息，调用时“查表”，当进行调用时，首先看调用的服务在本地是否有另外一个应用提供，如果有则不进行网络调用，直接把对应参数进行转移完成本地调用；如果没有，就从远端随机选一个地址发起远程调用。本地调用需要进行“深拷贝”。

“深拷贝”

我们需要将我们去请求一个应用的参数转化成另外一个类加载器能消化的数据，同时要把反馈回的数据消化成本加载器能够理解的数据，这个过程称为深拷贝。

深拷贝的性能对比可以看出，深拷贝的耗时平均只有Hessian的15%，并且没有统计网络开销。面对越来越大的数据结构，深拷贝的优势会愈加明显。

合并部署的效果

越来越多的访问数据来自于无线，可以看出QPS提升超过50%，数据越大提升越发明显。合并部署后性能衰减不是很明显，趋势非常柔性。

实际情况来看，Rt下降了50%，毛刺基本消失，链路更加平稳。

合并部署带来了什么

合并部署技术降低了成本，使相同的机器提供更大的数车，不需要增加机器。成本的降低也就意味着性能的提升，RT下降明显。

 

多版本部署

发布的本质即重启，那么，能不能不重启就发布呢？运用多版本部署方式能够避免用户进行重启。将两个版本的应用都部署到容器中后，对外提供服务的链接是不断的，对外提供的HTTP流量、TomCat流量是不变的，远程服务框架、消息处理也是不变的，当外界给予切流命令的时候，就把对应的旧版本的处理逻辑向新有版本进行跃迁，就完成对应版本的发布了，整个过程是非常流畅、柔性的。

事件体系

如果高维度的组件不去释放掉对应的应用和扩展，对应的应用资源就没有办法释放，同一个应用的多个版本都在一个机器上运行着，此时我们通过事件体系来解决这个问题。

通过响应事件来释放资源，事件类型有：应用部署事件、应用退部署事件、流量关闭事件、流量开启事件。

容器不仅提供了多应用的部署能力，同时把事件做了一定的统一的抽象，事件能够直达所有的中间件，所有的中间件都会去响应容器发布的事件，我们会告诉所有中间件，某个应用上线了或者下线了，流量开始进入或者切出应用，这些事件的发送，使得中间件可以从容的响应所有的变更。

多租户JVM

Java容器能够做到类型隔离，却做不到资源隔离，我们需要完成对应的资源的隔离，CPU、内存、I/O带宽等都需要隔离。怎么办呢？

阿里特有的多租户JVM，支持多租户部署的AliJDK，包含多租户API，创造一个独立的容器，在这个容器里面的资源是隔离的，在这个隔离的区域纵使出现内存泄漏，也不会影响到另外一个区域，在这个区域运作的CPU的消耗也不会影响到另一区域对应的执行逻辑，这就完成多版本部署里的资源隔离需要使用的技术。

依靠Tenant做到资源隔离。

Context对应Webapp Tenant中创建Context 销毁Context时销毁Tenant

多版本部署带来了什么

发布速度非常快：实现了全量发布，自由切流。 秒级回滚：旧版本暂时不下线，极速回滚。

总结与展望

多应用部署是我们在应用部署方式和思考维度的改变。 通过合并部署把链路上强相关的应用进行部署后，使得性能有所提升。 多版本部署与发布提速。 模块化应用的支持。 高密度部署。
Java集合容器面试题 TreeSet 要求存放的对象所属的类必须实现 Comparable 接口，该接口提供了比较元素的 compareTo()方法，当插入元素时会回调该方法比较元素的大小。TreeMap 要求存放的键值对映射的键必须实现 Comparable 接口从而根据键对元素进 行排 序。
为什么 java 容器推荐使用 ExitOnOutOfMemoryError 而非 HeapDumpOnOutOfMemoryError ? 好久没写文章了, 今天之所以突然心血来潮, 是因为昨天出现了这样一个情况: 我们公司的某个手机APP后端的用户(customer)微服务出现内存泄露, 导致OutOfMemoryError, 但是