阿里中間件技術：應用服務器篇

2016-04-20  架構說  19 閱讀

應用服務器——系統運行的託管員

綜述

阿里巴巴集團有國內最大規模的Java系統，幾萬臺的應用服務器規模也空前龐大，目前主要使用的應用服務器有Tomcat，JBoss和Jetty三種。阿里巴巴自從2004年開始轉向Java技術平臺後，前後經歷了從WebLogic到Jboss和Tomcat遷移。到了2008年，隨着更爲輕量級的Tomcat和Jetty容器的迅速發展，愈來愈多的應用系統開始嘗試使用Tomcat或Jetty做爲底層應用服務器。2013年上半年，阿里巴巴集團中間件成立了獨立的應用服務器團隊，主要面向整個集團進行應用服務器相關的工做，目前在公司內部主推Tomcat服務器。

本文將從中間件團隊在2013年雙十一大促前針對應用服務器上進行的工做展開，重點講解Tomcat監控診斷工具，以及Pandora隔離技術兩方面內容。

6.一、Tomcat監控管理工具

Tomcat Monitor模塊是一個Tomcat的監控和診斷模塊，提供了一些基本的工具，能夠對Tomcat的鏈接池、線程、內存、類加載以及JVM相關等進行監控和診斷。Tomcat Monitor的出現，解決了廣大開發人員沒法快速定位線上問題的尷尬問題，同時也幫助開發人員可以經過簡單且統一的命令行工具來排查問題、查看程序運行時狀態，而不須要使用各類包括jmap、jstat和BTrace等工具。

Tomcat Monitor模塊集成於Tomcat服務器內部，可以對線程、鏈接池、內存和類加載等方面進行詳細且實時的監控與診斷。

• 進行鏈接池的監控和管理

圖6-1-查看Tomcat鏈接基本狀態
圖6-1-查看Tomcat鏈接基本狀態

• 檢測出當前Tomcat服務器中那些慢鏈接

圖6-2-檢測慢鏈接
圖6-2-檢測慢鏈接

• 線程死鎖檢測
  圖6-3-線程死鎖檢測
  圖6-3-線程死鎖檢測

能夠看出，線程 pool-1-thread-1 和 pool-1-thread-2 發生死鎖.下面兩行清晰描述了死鎖緣由：

圖6-4-死鎖緣由

thread-2 阻塞在被 thread-1 鎖住的對象 java.lang.String@114a3c6 上,
thread-1 阻塞在被 thread-2 鎖住的對象 java.lang.String@c4cee 上,

兩個線程互相等待, 致使死鎖.
輸出結果還顯示了發生死鎖的線程堆棧, 以便開發人員進一步排查發生死鎖的緣由.

• 診斷出CPU佔用高的線程
  顯示最近一段時間 cpu% 持續太高的線程列表, 及其最近一次統計的 cpu%.

在碰到煩人的ClassNotFoundException或是NoClassDefFoundError這些異常的時候，能夠定位類的加載狀況
圖6-6-檢測類加載狀況
圖6-6-檢測類加載狀況

針對應用服務器的監控和診斷，後續的發展規劃是在目前Tomcat Monitor的基礎上，集成其餘諸如HouseMD這樣優秀的Java監控與診斷工具，使得不一樣的工具可以以一種統一方式給開發人員使用。同時，還會和公司內部已經成熟的監控報警系統打通，做爲數據提供方來幫助更深刻的監控應用的運行狀況。

6.二、隔離容器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.三、應用服務器雙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體系結構
  圖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.taobao.org/2014/03/07/3495/