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