本文根據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