922
應用容器雲：接過Java EE的槍
本文根據DCOS聯盟第4期線上分享整理而成
講師介紹
宋瀟男
普元雲計算架構師
-
曾任職華為，負責雲計算產品與解決方案的規劃與管理，十年以上分布式係統和中間件技術經驗，熟悉HPC、同格計算、雲計算實戰。
主題大綱：
1、回顧Java EE的發展
2、揭示Java EE的根本性缺陷
3、從Java EE的角度看應用容器雲
4、對未來的展望
大家好，首先自我介紹一下。
我來自普元軟件，對Unix和雲計算技術比較熟悉，而所在公司的傳統業務是中間件，在這個背景下，我對眼下的容器熱有著一些不同的看法，今天與大家分享。
老實說，今天的觀點如果放在一年前，我不大敢講，會比較有爭議。最近看到有人也提出類似觀點，所以我也整理了一下，拿出來分享。相信爭議還是會有，希望能與大家共同探討，也能進一步完善我的想法。
開始之前，首先需要明確下什麼是Java EE，我直接引用了官方說明，不做翻譯。
這裏麵有幾組關鍵詞，第一組是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的技術標準：
Java EE由一係列技術標準組成，這裏麵有我們熟悉的用於定位和訪問資源的JNDI、用於描述Web Service的WSDL、用於安全方麵的JAAS、用於消息傳遞的JMS等等。這裏不展開講，後麵會看到這些Java EE技術標準，或者說是Java EE的API和“子係統”，在應用容器雲裏，會以基礎服務的形式體呈現。
下一頁是Java EE的一組實現，其實就是一係列應用服務器。
這個圖來自IBM的競爭分析資料，稍微有一點美化自家產品WebSphere的味道，不過總體來說還算客觀。
WebSphere確實在技術上最完整的實現了Java EE標準，在架構上可以支持最大的係統規模，就像圖中所示，hundreds of servers，雖然很少見到上百個節點的WebSphere集群，但是WebSphere在架構設計上確實考慮到了這麼大的規模。
既然WebSphere這麼強，那我們就來打開看下WebSphere。
首先看下WebSphere的架構圖，可以看到，Java EE的API作為一係列子係統運行在WebSphere中。
再看一下WebSphere的概念圖：
WebSphere的主要概念有：
-
Application Server：即一個應用服務器實例；
-
Node：一個操作係統實例，裏麵可以運行多個Application Server；
-
System：可以認為是一個物理機，通過虛擬化，上麵可以運行多個操作係統實例，即多個Node；
-
Cell：一組執行相似任務的Node，作為一個管理域統一管理。
這樣的概念層次可以支持大規模的應用服務器集群，考慮的確實比同類產品要全麵。
接下來看一下WebSphere如何管理large-scale multi-tiered係統。
隻需要通過管理節點上傳你的應用EAR，WebSphere就會幫你把應用部署到集群中所有Application Server實例上，可以在單一入口管理整個集群，還可以幫你管理前端的Web Server和後端的數據庫。
看起來很美好，不是嗎？然而，事實上不是這樣。
現在我們來看一下Java EE，或者說Java EE的技術實現 —— 應用服務器的四大問題。
-
第一個問題，資源隔離。
應用服務器實例運行在單一JVM上麵，而JVM無法隔離CPU、內存、IO等資源，所以一個應用有問題、或者是應用的某個模塊有問題，都會造成應用服務器上的所有應用無法正常運行，有時候還會影響同一操作係統上的其他應用服務器。所以現狀往往是，一個操作係統內隻運行一個應用服務器，一個應用服務器上隻運行一個應用，失去了應用服務器作為基礎架構和資源池的意義
-
第二個問題，依賴管理。
應用服務器一般隻能管理三層或者四層係統，對圖中這種分布式係統無能為力，還記得最開始講的Java EE的主攻方向裏有distributed係統嗎？實際上好像不是這麼回事，或者說現在的分布式係統比起當年已經出現了根本性的變化。
-
第三個問題，與應用緊耦合。
如圖所示，應用服務器實際上已經變成了應用的一部分，而不是應用的基礎設施。
-
第四個問題，CI/CD不友好。
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的槍》。
使用容器技術配合微服務模式，Java EE的那些“子係統”以進程的方式運行在容器之中，可以做到很好地資源隔離並根據負載進行擴展。應用容器雲標配的服務注冊能力，可以比Java EE更好地解決當今分布式係統的依賴問題，應用容器和運行環境的耦合性很低，應用容器鏡像高內聚而且體積適中，可以很容易的納入CI/CD流程，Java EE的四大問題迎刃而解。
對比Java EE，應用容器鏡像就像是更廣義的“WAR”或者“EAR”，如果運行Java應用，鏡像裏可以包含應用本身、嵌入式應用服務器和應用在操作係統層麵的各種依賴。
應用容器雲就像是更廣義的Java EE Platform，或者說是更廣義的“應用服務器”，可以為各種語言和類型的應用提供Runtime並很好的將它們管理起來。
Java EE的“子係統”，在應用容器雲中以基礎服務的形式提供。
這些基礎服務提供和Java EE API相似的能力，並且可以做得更好。
普元的數字化企業雲平台正在緊張的開發之中，在此我對我司的產品和應用容器雲這一產品形態做個展望。
應用容器雲將完成Java EE未竟的事業。
最後我們來看一下Gartner的一個說法：
和我們的感受一樣，與基於虛擬化的雲平台，主要由運維人員參與的狀況完全不同，這一波基於容器的雲平台熱潮由開發者推動，我個人也非常希望更多的開發者能夠參與到這次變革之中。謝謝大家！
Q&A
Q1： 配合容器技術，Java EE的一些問題可以迎刃而解。我請問一下，貴公司的大數據相關應用（主要也都是Java相關），怎麼與容器技術結合？
A1：我們確實沒有Hadoop這類大數據產品，我們的數據類產品主要做的是數據治理。和容器的結合，主要是做元數據的管理。還有就是我們的容器雲基於k8s，k8s現在的有狀態業務能力還比較弱，還要等待一兩個版本進行完善。
Q2：WAS是很重的J2EE容器，那麼容器化必然會考慮他的啟動時長限製，一般用這類雲的都是並發較高的互聯網應用，關於動態擴展到實際對外提供服務的時間間隔區你們怎麼控製的呢？另外關於底層類加載的優化一般通過什麼手段達到目標呢？
A2：容器化後我們這邊基本上都是嵌入式應用服務器了，當然，IBM那邊肯定會推薦WebSphere的Liberty版本。但是即使是嵌入式應用服務器，啟動時間也還是有點慢，前段時間我正在做這個優化，應用稍微大一點，最快也要個十幾秒，確實離理想狀態還有點遠。類加載這塊，我感覺能做的優化不多，懶加載肯定不行。降低優化級別的話，雖然啟動快了，但是運行時性能會下降。
原文發布時間為：2016-12-20
本文來自雲棲社區合作夥伴DBAplus
最後更新：2017-05-11 15:01:11