小談應用伺服器的未來發展

　　InfoQ中國站發表了一篇衛濱張兄的文章“Java應用伺服器前途堪憂”。仔細看進去，Eberhard Wolff的演示稿寫的很好，有針對性的分析了目前應用伺服器當前的狀態和存在的一些問題，提出微服務和持久交付會對應用伺服器市場產生衝擊，這個技術趨勢我非常贊同，但是演示稿的確有標題黨和片面下結論之嫌。接下來我就從應用伺服器的歷史發展，需求由來和網際網路浪潮對其促進變化談談個人的觀點，在一些地方輔以技術說明。

　　早期一些計算機教科書裡寫軟體可以分為兩大類，科學計算和業務管理，我認為是很有道理的，這種分類很好的匹配了現代計算機體系的兩大主要部件：CPU和記憶體，一個負責計算，另一個負責存放狀態資料。向後推導，進一步產生面向函式和麵向物件的程式語言；軟體體系架構選擇聚焦在海量資料併發訪問，還是選擇企業應用系統事務為先。在設計一個軟體之前，仔細想想這個軟體是給什麼人用，同時有多少人用，它的需求或者說要完成什麼功能，對事務的要求高麼，中間環境需要人為干預麼，要積累多少業務資料，使用者怎麼使用最方便。這些問題一旦有了答案，軟體的架構基本上就呼之欲出了。

　　軟體的發展離不開和同期硬體能力的匹配，原先CPU是單個，需要分時分配給不同任務使用，記憶體更是寶貴的資源。在這種環境限制下，再加上專心做一件事的天性使然，程式設計師在編寫程式時，會非常自然的按照時序來書寫程式，所以在當代程式設計師的開發基因中，本能的排斥各種加鎖，各種干擾程式正常流程的操作。就和我們去銀行辦業務，你會抱怨別的顧客插隊打岔，櫃員中途離開，或者你被要求到外面先填單子等一樣。我們的軟體框架及容器為了讓開發者更快捷的程式設計，從各種非業務技術難點中解脫出來，會充分利用語言能力和編譯/部署手段。

　　上世紀90年代網際網路開始普及，分散式計算技術開始迅速發展，過去針對單機編寫的應用程式需要移植部署在網際網路上。但無論是科學計算還是業務管理應用軟體，適應網際網路都是一個“緩慢”的過程。在經典的企業軟體設計書籍裡，比如 Martin Flowler 的“企業應用架構模式”裡建議慎重使用分佈物件，Rod Johnson的經典“J2EE development without EJB”更是通篇對早期遠端EJB進行鞭撻，而如今網際網路應用中完全貫徹SOA思想，幾乎全部的介面都是無狀態的分散式設計方案，目前Spring社群也在主推 MicroServices 分佈協作。是不是感到困惑？是大師們偏頗還是當前的架構出了問題？其實站在各自目標應用立場上，放在當時的技術背景下，都是對的。絕大多數的企業應用都不需要分佈，或者說在單一領域根操作時應避免分佈；而網際網路網站面向海量使用者，需要成千上萬的機器來保障服務，天生需要分佈。

　　那麼對JavaEE中的代表EJB規範，究竟該怎麼評點呢？不能以單純好壞論之，我的觀點是EJB承擔了太多的責任。1.執行緒安全的物件。前面說過容器試圖解脫程式設計師，開發EJB物件，是不需要考慮併發的，反而要限制你不能建立執行緒(3.1之前)。同時非共享成員變數也帶來狀態的安全，這個重要知識點並沒有在程式設計師中深入人心；2.AOP模式的實現，可以做到讓開發者聚焦業務邏輯，事務，安全等上下文資訊通過容器隱式傳遞；3.分散式物件實現。遠端EJB設計沒有太大問題，關鍵缺憾是基於Corba相關協議和技術過時。另外對非同步式支援不足，無論是非同步介面還是MDB的定義，規範定義都不到位。4.還有Timer，StatefulSessionBean等內容，早期甚至還有EntityBean。

　　剖析EJB，其實就是在分析應用伺服器，它們都面臨同樣的問題：太過於龐大，開發者在經驗不足時很難全面把握，從而產生厭惡感。我們知道所謂規範是多個軟體大廠商妥協的產物，有太多的非實用主義摻雜在裡面。但還是由市場驅動的，是知識經驗的凝聚。過去這幾年中，除了其他語言方案，就是Java自己內部，各種技術框架就層出不窮。但我們看到無論是Spring還是OSGi，目前都不得不適應JavaEE很多子規範，比如Servlet, JPA等等。因為這些規範更好更全面的揭示了軟體開發的內在原則。

　　Servlet是Java適配HTTP協議而設計的規範，簡單好用，關鍵之處在於，其中的基礎介面揭示了面向網路程式設計最重要的內容：包含訊息內容的Request/Response，傳遞上下文的Context，狀態傳遞的Session，攔截邏輯的Filter，各種Listener接收事件，當然還有軟體執行點Servlet，和諧而穩定的構造出一個框架。同樣的，JPA是Java適配關聯式資料庫和SQL查詢而設計的規範，它試圖把持久介質上的關係圖譜對映到記憶體中，使得開發人員即便面對很複雜的關係資料表格和業務邏輯，也能找到線索來理清紛繁頭緒。大多數優良的JavaEE規範都是按照這個邏輯思路設計的，所以我建議涉足企業應用開發的程式設計師，都應該全面系統的學習JavaEE知識，相信會收益非淺。

　　技術和工具，只有最合適自己的才是最好的，而應用伺服器在過去就承載了太多的技術期望。傳統的軟體採購中，中介軟體是其中金額很小的一塊，但不光要承擔應用容器載體職責，還有軟體開發，架構設計，部署，監控，升級，安全之種種。面對這麼多技術內容，非IT基礎架構的企業是不可能，也沒有能力能夠全部玩轉的。他們希望有一個方案，軟體供應商可以通過培訓讓他們的技術員工能掌握部署，管理運維和部分開發定製，系統的整體一致和元件標準化是他們考量的一個重要因素。軟體是由程式設計師開發的，其中的價值和知識凝聚在程式碼，文件，圖示中，甚至更多在程式設計師的頭腦裡。最好的軟體精華部分，就和一本好書，一支好曲子，一座百年大橋的主要設計方案一樣，是由一個人或者少數人組成的團隊掌控者。但軟體是需要傳播的，使用軟體的企業也希望用的東西透明公開，可以不去了解細節，但不願意毫無知情權。這個也是開源運動成功的關鍵所在。就和我們去吃慶豐包子，透明的玻璃窗後能看到包子的整個製作流程，其實客戶並不關心這個包子如何做，只是這種公開透明讓人產生信任，從而願意花錢買包子而節省自己的時間。應用伺服器就是幫助企業使用者來節省時間，遮蔽複雜度，減少技術理解鴻溝的產品。

　　現在是網際網路時代，別的不說，人人看得見一種鮮明對比：網際網路的如日中天和企業軟體廠商的不景氣。網際網路公司有軟體平臺和自己的盈利模式，它們需要構建自己的技術平臺來滿足自己的業務需求，開發人力是最寶貴的資源。它們可以投入大量的人力物力來打磨每一個技術細節，不為別的，就為了更好的滿足自己需求。但問題是，對於非技術企業來說，它們的方案適合麼？有同樣的技術能力保障麼？能獲得後續的商業支援麼？為什麼說開源好，有標準好，就是因為絕大多數軟體專案，即使做的再好，圍繞其工作的人都是有限的，那麼開放的標準的技術會有更多的人書寫部落格，製作文件，貢獻程式碼，測試功能效能，不斷打磨使之成熟。越來越多的網際網路企業也看到這一點，尤其一些國外的網際網路巨頭，對開源做出了巨大的貢獻。對一般企業來說，建議選擇開源技術，並且選擇軟體產商來獲得專業服務支援。

　　還有一個變革是Linux作為基礎伺服器和雲端計算的普及。Linux是開源而成熟的作業系統，如今已成為整個網際網路的基礎之一，越來越多工程師掌握了Linux知識和可以對其進行定製裁剪。軟體應用最終要找一個載體，在原來Windows如日中天的微軟時代，Java虛擬機器作為一個可以跨越作業系統的平臺，是最好的選擇。如今Linux也可以做到以程式為單位，作業系統為容器，加上資源隔離，微服務等技術方式，一個和應用伺服器競爭的方案產生了。我個人非常看好這個趨勢，尤其認為改良後的PAAS是應用伺服器的發展方向，因為可以更和諧的滿足開發和部署業務程式的需要。但這有一個過程，還有面對一開始就提出的問題，是什麼業務場景，客戶IT應用水平等因素都需要考量。在國內，多數企業還是以windows平臺為主，那麼微服務這個技術推行還需以時日，即便在網際網路等企業中，同樣也有企業應用如財務系統，HR系統等需求，這些應用還是由JavaEE的子規範技術開發占主導地位。

　　所以軟體應用架構沒有銀彈，必須根據業務的特點和自身的技術實力來選擇最好的技術方案。