綜述
阿里巴巴集團有國內最大規模的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等爲代表的輕量級的應用服務器上。然而，隨着互聯網應用多樣性的不斷髮展，分佈式系統規模的不斷增大，尤其是移動互聯網時代的到來，目前的主流服務器可能都無法滿足未來日益變化需求，因此我們還正在探索下一代應用服務器的路上。
系列文章：
《 中間件技術及雙十一實踐之中間件總體介紹 》 http://jm-blog.aliapp.com/?p=3359
《 中間件技術及雙十一實踐之軟負載篇 》 http://jm-blog.aliapp.com/?p=3450
《 中間件技術及雙十一實踐·服務框架篇 》 http://jm-blog.aliapp.com/?p=3462
《 中間件技術及雙十一實踐·EagleEye篇 》 http://jm-blog.aliapp.com/?p=3465
《中間件技術及雙十一實踐·消息中間件篇》http://jm-blog.aliapp.com/?p=3483
《中間件技術及雙十一實踐·應用服務器篇》http://jm-blog.aliapp.com/?p=3495
如果覺得內容還行，請分享給更多的人...