应用服务器——系统运行的托管员
综述
阿里巴巴集团有国内最大规模的Java系统，几万台的应用服务器规模也空前庞大，目前主要使用的应用服务器有Tomcat，JBoss和Jetty三种。阿里巴巴自从2004年开始转向Java技术平台后，先后经历了从WebLogic到Jboss和Tomcat迁移。到了2008年，随着更为轻量级的Tomcat和Jetty容器的迅速发展，越来越多的应用系统开始尝试使用Tomcat或Jetty作为底层应用服务器。2013年上半年，阿里巴巴集团中间件成立了独立的应用服务器团队，主要面向整个集团进行应用服务器相关的工作，目前在公司内部主推Tomcat服务器。
本文将从中间件团队在2013年双十一大促前针对应用服务器上进行的工作展开，重点讲解Tomcat监控诊断工具，以及Pandora隔离技术两方面内容。更多关于应用服务器的内容，可以到中间件团队博客（ http://jm.taobao.org ）上查看。
6.1、Tomcat监控管理工具
Tomcat Monitor模块是一个Tomcat的监控和诊断模块，提供了一些基本的工具，可以对Tomcat的连接池、线程、内存、类加载以及JVM相关等进行监控和诊断。Tomcat Monitor的出现，解决了广大开发人员无法快速定位线上问题的尴尬问题，同时也帮助开发人员能够通过简单且统一的命令行工具来排查问题、查看程序运行时状态，而不需要使用各种包括jmap、jstat和BTrace等工具。
Tomcat Monitor模块集成于Tomcat服务器内部，能够对线程、连接池、内存和类加载等方面进行详细且实时的监控与诊断。
- 进行连接池的监控和管理
图6-1-查看Tomcat连接基本状态
- 检测出当前Tomcat服务器中那些慢连接
图6-2-检测慢连接
- 线程死锁检测
图6-3-线程死锁检测
可以看出，线程 pool-1-thread-1 和 pool-1-thread-2 发生死锁.下面两行清晰描述了死锁原因：
thread-2 阻塞在被 thread-1 锁住的对象 java.lang.String@114a3c6 上,
thread-1 阻塞在被 thread-2 锁住的对象 java.lang.String@c4cee 上,
两个线程互相等待, 导致死锁.
输出结果还显示了发生死锁的线程堆栈, 以便开发人员进一步排查发生死锁的原因.
- 诊断出CPU占用高的线程
显示最近一段时间 cpu% 持续过高的线程列表, 及其最近一次统计的 cpu%. 
- 在碰到烦人的ClassNotFoundException或是NoClassDefFoundError这些异常的时候，可以定位类的加载情况
图6-6-检测类加载情况
针对应用服务器的监控和诊断，后续的发展规划是在目前Tomcat Monitor的基础上，集成其他诸如 HouseMD 这样优秀的Java监控与诊断工具，使得不同的工具能够以一种统一方式给开发人员使用。同时，还会和公司内部已经成熟的监控报警系统打通，作为数据提供方来帮助更深入的监控应用的运行情况。
6.2、隔离容器Pandora
Pandora，中文名潘多拉，是阿里中间件团队打造的，基于HSF隔离技术构建的全新一代隔离容器。从解决二方包依赖冲突出发，致力于统一管理通用的二方包，包括方便的二方包升级管理，监控和管理，建立统一的二方包扩展编程方式等。基于Pandora容器基础上进行改造而来的Pandora-Framework，是一个类OSGi的模块化运行框架。它的产出，使得OSGi这个一直以来隐藏在应用服务器和IDE工具中的神秘技术，第一次在生产环境中走入了我们的前台应用系统。2013年9月在共享业务交易流程系统上线以来，目前将逐步应用于整个阿里交易流程系统，构建了交易系统的模块化运行环境。
功能介绍
- 隔离解决三方包依赖冲突问题。针对三方包的依赖冲突问题，比如：log4j，httpclient，通常我们在开发过程中，常常碰到不同的二方包依赖了不同版本的三方包。面对这种情况，我们都是使用 Maven 工具强行将这些三方包指定到一个版本。但是，针对那些兼容性不好的三方包，这存在很大的风险。
- 提供了一套完整的二方包大规模快速升级机制提供方便的二方包大规模升级方式，用户只需要将自己的包及依赖的包按照隔离容器的规范放到隔离容器里面，就可以达到升级的效果。不需要业务方做任何事情。Pandora 容器已经和 Freedom（新版发布系统）打通，在原有应用发布流程上，添加了 Pandora 发布流程，发布的时候，可以很方便的选择需要使用那个版本的 Pandora 容器，哪个版本
- 运行期开关和 Stableswitch（Stableswitch 是中间件团队开发的，嵌入在应用内部，当服务器压力比较大时，会通过开关功能来关闭一些不太重要的功能点）开关有区别，Stableswitch 开关是业务逻辑开关，面向的对象是应用，也就是应用里面的开关。而 Pandora 容器面向的是二方包的开关。运行期可以对所有应用里面使用的二方包做调配，是一个轻量级的方案。另外，相对于订阅 diamond 数据方式实现的开关，这个粒度更细，可以针对每一个单机进行调控。
- 监控管理Pandora 容器提供方便的命令行模式，二方包提供者只需要简单的实现 Pandora 的接口，就可以实现自己的命令行命令了。比如：可以实现一个功能，在运行期查看所有使用该二方包的应用的运行期数据，方便跟踪及排查问题。
6.3、应用服务器双11准备与优化
这里重点讲解下Pandora容器针对交易系统在双十一之前进行的模块化改造。谈到模块化，相信很多读者都会在第一时间联想到OSGi。没错，OSGi（JSR 291）是Open Services Gateway initiative的缩写，为系统的模块化开发定义了一个基础规范和架构模型。迄今为止，在一些著名的IDE产品（Eclipse是第一个也是目前最成熟的OSGi实践者）和应用服务器厂商（IBM、BEA、Oracle）中都已经采用了OSGi来创建“微内核与插件”的软件架构，这样一来，这些IDE和容器就可以被更好的模块化，并且可以在运行时被动态装配。
显然，模块化和动态化，是OSGi最显著的两大特性。模块化，尤其是他的隔离机制，基本得到了大家的认可，但是针对动态化这个特性，是公认的OSGi中最具争议的地方。
- 从实用性角度来讲，目前我们其实对于热部署，动态替换等并没有太强烈的需求，开发人员通常都能够接受应用重启。
- 从复杂性角度来讲，想要做到平滑热替换，尤其是对于那些运行期有状态的bundle而言，实现动态化相当复杂。
- 从可行性角度来讲，实现动态化，需要改变开发人员和运维人员的开发与运维习惯，在推广上面临极大的挑战。
- 废弃OSGi，实现应用系统模块化
因此，Panodrar容器废弃了OSGi框架，只是引入了OSGi隔离机制的思想，自己重新实现了ClassLoader的隔离，形成了一个全新的轻量级的隔离容器。如图6-7所示。 
图6-7-Pandora体系结构
下面重点从Bundle和类加载两方面来讲解下Pandora针对业务模块化的改造。
- Bundle — 最小的业务单元
首先引入了Bundle的概念，使得业务系统内部逻辑能够按照bundle为单元进行组织。同时提供了Maven插件用于bundle的生成，使得一个标准的Maven Web工程能够按照子工程为单位进行无缝迁移。
- 类加载 — 隔离的核心
类加载机制是模块化隔离的核心。根据业务系统模块化的需要，我们需要设计一种既要使bundle具有严格的私密性，又要使bundle和主应用以及bundle之间具有灵活的互通性，因此重新设计了类加载机制。大体的类加载可以分为以下三步：
第一步：尝试从import中加载。
Pandora在加载bundle的类的时候，首先会判断当前类是否需要从其他bundle中获取一些共享类。
第二步：尝试从bundle自己类路径下进行类加载。
Bundle的私有性需求已经规定了，每个bundle都应该有能力和外部业务系统环境隔离开来，因此一些三方包的加载，bundle自身目录下的都会优先于业务系统环境。
第三步：尝试从外部三方容器中加载。
如果bundle声明了需要从外部三方容器的biz classloader中来加载这个类，那么会尝试从这个biz classloader中去加载。
小结
总的来说，Pandora的这次改造，伴随着阿里交易系统第三次大规模的改造升级过程，不仅满足了业务模块化改造的需求，同时也使得Pandora容器在原有解决二方包问题的基础上，新增解决业务系统模块化改造需求的能力。传统IT公司的出现与发展远早于互联网，因此，很多早期的应用服务器，包括WebLogic和WebSphere在内，更多都是为大型的单机的系统设计，尤其是从运维角度来说，都已经无法满足互联网时代大规模分布式系统。越来越多的互联网应用转移到了以Tomcat、Jboss和Jetty等为代表的轻量级的应用服务器上。然而，随着互联网应用多样性的不断发展，分布式系统规模的不断增大，尤其是移动互联网时代的到来，目前的主流服务器可能都无法满足未来日益变化需求，因此我们还正在探索下一代应用服务器的路上。