Java Service Request Broker 簡(jiǎn)介
Java Service Request Broker(JSRB)是一個(gè) Java/C/C++ 的開(kāi)源項(xiàng)目
Project URL http://jsrb.sourceforge.net
項(xiàng)目目標(biāo)按照優(yōu)先順序依次是:
1 高效,透明的通訊框架,屏蔽本地/遠(yuǎn)程網(wǎng)絡(luò)架構(gòu)的復(fù)雜性(高效來(lái)源于基于poll/epoll的NIO通訊框架,透明來(lái)源于多個(gè)JSRB Server之間的動(dòng)態(tài)級(jí)聯(lián)機(jī)制).
2 高效率,穩(wěn)定的服務(wù)請(qǐng)求處理機(jī)制(高效來(lái)源于服務(wù)端為C語(yǔ)言實(shí)現(xiàn),穩(wěn)定來(lái)源于對(duì)服務(wù)進(jìn)程的不間斷監(jiān)控和自動(dòng)重啟動(dòng)機(jī)制)
3 分布式事務(wù)處理能力(JSRB 作為分布式事務(wù)管理器,初步實(shí)現(xiàn)了DTP XA協(xié)議,還在開(kāi)發(fā)過(guò)程中).
4 客戶端語(yǔ)言中立(語(yǔ)言無(wú)關(guān)通訊協(xié)議,客戶端提供Java或C API庫(kù)).
JSRB 大致架構(gòu)如下:
JSRB SERVICE 特性/訪問(wèn)方式
1 SERVICE 無(wú)狀態(tài),通過(guò)二進(jìn)制數(shù)據(jù)傳遞輸入輸出數(shù)據(jù)
2 運(yùn)行時(shí),可以有多個(gè)SERVICE實(shí)現(xiàn)進(jìn)程, JSRB會(huì)平衡調(diào)度這些進(jìn)程.
SERVICE支持同步/異步兩種訪問(wèn)方式:
SERVICE之間也支持forward和嵌套調(diào)用兩種方式
同步訪問(wèn)SERVICE:
Response Data = JsrbConection.syncCall("SERVICE NAME",Request Data);
當(dāng)客戶端從syncCall中返回時(shí),它已經(jīng)獲得SERVICE的返回?cái)?shù)據(jù)
異步訪問(wèn)SERVICE
long key = JsrbConnection.asyncCall("SERVICE",Request Data);
...
Response Data = JsrbConnection.fetchReply(key);
客戶端可以提交服務(wù)請(qǐng)求后,過(guò)一段時(shí)間再去嘗試獲取數(shù)據(jù), 便衣客戶端同時(shí)提交多個(gè)服務(wù)請(qǐng)求,增加并發(fā)性.
SERVICE FORWARD
客戶端訪問(wèn)SVC1, SVC1完成后將該請(qǐng)求forward到SVC2, SVC2完成后直接返回客戶端數(shù)據(jù).
SERVICE的嵌套調(diào)用
SVC1 調(diào)用SVC2 并獲得SVC2的返回?cái)?shù)據(jù).
一般問(wèn)題:
1 為什么會(huì)選擇用Java 實(shí)現(xiàn)Service Request Broker
答: Java跟C語(yǔ)言相比, 代碼執(zhí)行速度其實(shí)并不慢. 我們一般感覺(jué)J2EE 應(yīng)用慢,主要是由于IO(特別是socket和JDBC)慢造成的.
Java 在多線程編程, 開(kāi)發(fā)的方便性方面比C/C++強(qiáng).
JSRB在實(shí)現(xiàn)過(guò)程中,自行定義和實(shí)現(xiàn)了一套NIO框架, 增加了對(duì)于Linux epoll(Edge Triggered Mode)的支持, 同時(shí)為了實(shí)現(xiàn)與C進(jìn)程的高效通訊,自行實(shí)現(xiàn)了Sysv IPC和創(chuàng)建子進(jìn)程方面的Native代碼.
2 為什么要用C實(shí)現(xiàn)業(yè)務(wù)代碼,作為Service的實(shí)現(xiàn)語(yǔ)言.
從企業(yè)端的應(yīng)用來(lái)看, 企業(yè)應(yīng)用必定要跟數(shù)據(jù)庫(kù)打交道, 實(shí)際上C語(yǔ)言訪問(wèn)數(shù)據(jù)庫(kù)要比Java訪問(wèn)數(shù)據(jù)庫(kù)快1到兩個(gè)數(shù)量級(jí). 甚至可以說(shuō), J2EE應(yīng)用響應(yīng)的大部分的延遲時(shí)間都耗費(fèi)在JDBC上.
從大型項(xiàng)目的實(shí)施經(jīng)驗(yàn)來(lái)看, 將這部分代碼放在C進(jìn)程中, 盡管要多付出通訊方面的代價(jià),總體還是要比純Java的方案快得多.
3 為什么分布式事務(wù)的優(yōu)先級(jí)最低
從大型項(xiàng)目的實(shí)施經(jīng)驗(yàn)來(lái)看, 分布式事務(wù)由于運(yùn)行代價(jià)過(guò)高, 業(yè)務(wù)系統(tǒng)中用到的概率很小(基本上直接用數(shù)據(jù)庫(kù)的事務(wù)). 對(duì)于CICS/TUXEDO應(yīng)用而言,首先還是將CICS/TUXEDO 作為一個(gè)高效/穩(wěn)定的通訊和服務(wù)請(qǐng)求處理排隊(duì)框架來(lái)用.
如果真要有分布式的交易的需求,一般采用流水對(duì)帳+沖正處理方式解決.
4 為什么選擇無(wú)狀態(tài)方式實(shí)現(xiàn)SERVICE
無(wú)狀態(tài)是提高并發(fā)效率, 實(shí)現(xiàn)透明故障遷移的最佳方式. Server端資源有限,為并發(fā)的成千上萬(wàn)個(gè)用戶同時(shí)維護(hù)狀態(tài)是非常困難的,這樣也會(huì)造成集群實(shí)現(xiàn)的困難.
由于Client端是有狀態(tài)的,所以這在實(shí)現(xiàn)上其實(shí)問(wèn)題不大.
今后得空還會(huì)慢慢寫更多文檔介紹JSRB的一些組件的實(shí)現(xiàn)方式和特性.