JSRB設計思想－無狀態的,粗粒度的SERVICE
出于提高性能和負載均衡實現的考慮，JSRB 采取了無狀態的，粗粒度的SERVICE請求和響應機制。
該思想與有狀態的ORB(如CORBA或EJB Container)的設計思想截然相反.本文將詳述原因.
JSRB定位與想要解決的問題
JSRB定位于傳統的SERVICE REQUEST BROKER地位,就是原始意義上的中間件的位置: 負責將大量客戶端(N千或N萬)的請求,排隊到幾十或幾百個的請求處理進程(線程)中,最優化的使用系統資源,從而達到吞吐量最大化的目的.
從這個角度來看, EJB Container和CORBA ORB是標準的中間件. Java Web Container由于內建了線程池,也算是中間件(前端協議HTTP,后端協議是JDBC).
無狀態vs有狀態,遠程調用的選擇.
有狀態要求服務器在遠程調用之間保存對應客戶端的Session數據,這種設計思想會簡化程序代碼,有助于將分布式的程序寫得更
像非分布式程序.
但是在某些情況下,這種設計會帶來嚴重的性能問題.在金融的在線交易系統中,業務系統需要處理十萬至千萬級別的用戶信息(例如網銀系統),而中間件服務器較為合適的session池數量不過萬.要在中間件服務器的JVM內存中處理如此巨量的數據,肯定會將系統撐爆; 而如果存儲大部分數據到硬盤(鈍化技術)來應對,則就會面臨IO性能還不如 RDBMS 的窘境. RDBMS 在目前階段始終是最快速的數據存儲方案.
當業務系統面臨大數據量的問題時,需要采用應用相關的解決方案(數據分區,存儲過程等等)解決.將問題推給應用服務器固然方便,但是卻會帶來系統的性能和可擴展性的問題.遠程調用的代價本來就很大,不必要讓ORB再承擔session數據的重擔了.與之相反,無狀態的遠程調用在可擴展性和負載均衡方面的實現要簡單得多,也沒有session遷移的問題.
SERVICE的粒度問題
SERVICE遠程調用的粒度需要粗一點,在保證SERVICE可重用的前提下,應該盡量減少SERVICE的調用次數, 因為SERVICE的調用開銷非常大(一般的遠程調用都是以毫秒記,而普通方法的執行時間是以微秒或納秒為單位的).
有狀態SERVICE的一個副作用就是容易出現過細粒度的設計(同時由于Stub/Skeleton的生成很方便,這種設計就更加容易出現了),導致交互次數過多,會嚴重降低業務系統的性能.
這方面一個鮮明的對比是大型機的智能終端和telnet協議.智能終端只有等到用戶填充完一個表單并確認發送后,才會將請求數據發送到主機,并且自行解釋和顯示主機返回的數據(非常像Broswer/HTTP), 而telnet協議則將每個按鍵事件發送到主機,主機處理保存有所有的session數據. 主機可以毫不費勁的處理N萬個并發的客戶端,而UNIX主機在連接了幾千個telnet客戶端后,自身的正常運行都會出問題了.
順便說一句, 類似的, 從個人項目經歷來看, 由于 Hibernate 隱藏JDBC調用很成功,查詢或更新數據庫非常方便, 程序員就很容易濫用; 有可能導致程序從邏輯上來看毫無問題, 但是運行起來卻出現性能低下, 并且這種性能問題還很難改正(性能低下是由于數據庫查詢過多引起的,要調整的代碼遍布整個項目).
其它
- 本文的一些思想來源于MidWay(midway.sourceforge.net)和個人的項目經驗,僅為一家之言.
- 大型項目(企業級)和小項目(部門級)的區別主要就在于,大項目在各個階段都要將非功能性的要求(性能,容錯,恢復,分布式,響應時間,事務等等)放在設計/實現/測試首要考慮的位置,而小項目則幾乎無需考慮這樣的問題.
- 本文和JSRB主要集中在真正的中間層( Service/Object Request Broker/EJB Container).