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

iteye發表於2014-05-22

  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的子規範技術開發占主導地位。

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

相關文章