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