zyskm用夢想丈量人生,用奔跑丈量激情

          分布式模式之Broker模式

          轉(zhuǎn)發(fā) http://blog.chinaunix.net/uid-23093301-id-90459.html 問題來源: 創(chuàng)建一個游戲系統(tǒng),其將運行在互聯(lián)網(wǎng)的環(huán)境中。客戶端通過WWW服務或特定的客戶端軟件連接到游戲服務器,隨著流量的增加,系統(tǒng)不斷的膨脹,最終后臺數(shù)據(jù)、業(yè)務邏輯被分布式的部署。然而相比中心化的系統(tǒng),復雜度被無可避免的增大了,該如何降低各個組件之間的耦合度。 挑戰(zhàn): 需要保證可伸縮性、可維護性、可更新性,需要將服務劃分為各個相對獨立的組件,組件被分布式的部署,它們之間通過進程間通信方式實現(xiàn)交互。服務的增加、刪除、改變都應該被支持。理想情況,以開發(fā)者的角度看,集中化的系統(tǒng)和分布式的系統(tǒng)在中心邏輯上沒有什么不同。為實現(xiàn)這個目標: l 可以遠程的訪問服務,而對于訪問者,服務的位置應該是透明的。 l 提供服務的組件可以增加、刪除、改變,而且這些在運行期同樣應該被支持。 l 訪問服務的客戶端不應該關心服務的實現(xiàn)細節(jié)。 解決方案: 引入一個Broker組件,解耦客戶端和服務端。服務端注冊自己到Broker,通過暴露接口的方式允許客戶端接入服務。客戶端是通過Broker發(fā)送請求的,Broker轉(zhuǎn)發(fā)請求道服務端,并將請求的結(jié)果或異常回發(fā)給客戶端。通過使用Broker模式,應用可以通過發(fā)送消息訪問遠程的服務。 這一架構(gòu)模式允許動態(tài)的改變、添加、刪除服務端,從客戶端的角度,這些都是透明的。 結(jié)構(gòu): Broker模式定義了6中類:Client,Server,Client_Proxy,Server_Proxy,Broker,Bridge。 Server: l 責任:處理特定領域的問題,實現(xiàn)服務的細節(jié),注冊自己到Broker,處理請求并返回結(jié)果或異常。 l 協(xié)作類:Server_Proxy,Broker Client: Client是需要訪問遠程服務的應用程序,為此,Client發(fā)送請求到Broker,并從Broker上接收響應或異常。Client和Server只是邏輯上相關而已,實際上Client并不知道Server的確切位置。 l 責任:1. 實現(xiàn)用戶端功能,2. 發(fā)送請求到Broker,3. 接收相應和異常。 l 協(xié)作類:Broker,Client_Proxy Broker: Broker可以被看成消息轉(zhuǎn)發(fā)器。Broker也負責一些控制和管理操作。它能夠定位服務端的位置,若發(fā)生異常,能夠?qū)惓2东@傳給Client。Broker需要提供注冊服務的接口給Server。如果請求來自其他的Broker,本地的Broker需要轉(zhuǎn)發(fā)請求并最終將結(jié)果或異常回應給相應的遠程Broker。Broker提供的服務和name service非常相像(如DNS、LDAP)。 l 責任:1. 注冊服務。2. 提供服務API。3. 轉(zhuǎn)發(fā)消息。4. 容錯處理。5. 與其他Broker的交互。6。 定位服務。 l 協(xié)作類:Client_Proxy,Server_Proxy,Bridge Client_Proxy: 連系Client和Broker,這一層保證了通訊的透明性,使Client調(diào)用遠程服務就像調(diào)用本地的服務一樣。 l 責任:1. 封裝特定的系統(tǒng)調(diào)用。2. 封裝通訊的參數(shù)、控制信息等。 l 協(xié)作類:Client,Broker。 Server_Proxy: Server_proxy是與Client_Proxy相對應的,它接受請求,解包消息,解析出參數(shù)并調(diào)用服務的實現(xiàn)接口。 l 責任:1. 封裝特定的系統(tǒng)調(diào)用。2. 封裝通訊的參數(shù)、控制信息等。3. 調(diào)用server的服務接口。 l 協(xié)作類:Server,Broker。 Bridge: Bridge用來連接各個Broker,一般這個組件是可選的。當系統(tǒng)是發(fā)雜的網(wǎng)絡組成時,有可能需要這一角色。 l 責任:1. 封裝特定的網(wǎng)絡特性。2. 傳遞Broker之間的通訊。 l 協(xié)作類:Broker。 應用場景一: 直接通訊方式。Client和Server相互理解他們之間的通訊協(xié)議。Broker主要完成Client和Server之間的握手。之后所有的消息、異常都是由Client與Server直接交互。(想象DNS)。簡單對象交互如圖: 應用場景二: l Broker啟動,完成自身的初始化,之后進入事件循環(huán),等待消息到來。 l Server啟動,首先執(zhí)行自身的初始化,然后注冊自己到Broker。 l Broker接收Server的注冊請求,將其加入到可使用服務的列表,并回應Ack給Server。 l Server接收Ack,進入事件監(jiān)聽循環(huán),等待消息到來。 l Client調(diào)用遠程服務對象的方法,Client_Proxy封裝消息請其發(fā)送給Broker。 l Broker查詢可使用的Server,將請求轉(zhuǎn)發(fā)給Server。 l Server_Proxy解析消息,分離出參數(shù)和控制信息,并調(diào)用特定的Server實現(xiàn)接口。Server處理完的結(jié)果通過Server_proxy封裝成消息轉(zhuǎn)發(fā)到Server。 l Broker將相應消息轉(zhuǎn)發(fā)給正確的Client_Proxy,Client受到響應繼續(xù)其他邏輯。 簡單對象交互如圖: 應用場景三: l Broker A接收到請求,交由Server處理,但是發(fā)現(xiàn)該Server位于其他的網(wǎng)絡節(jié)點。 l Broker A將請求轉(zhuǎn)發(fā)給Bridge A,Bridge A將請求進行必要的格式化,傳送給Bridge B。 l Bridge B將請求進行必要的格式化,轉(zhuǎn)化成Broker B可以理解的格式,并轉(zhuǎn)發(fā)給Broker B。Broker B執(zhí)行場景二中的過程,處理的結(jié)果按如上逆序返回。 簡單對象交互如圖: 部署示意圖: 總結(jié): u 優(yōu)點: 1. 服務的位置透明性。 2. 組件的可變性及擴展性。由于Server是注冊到Broker上的,所以Server可以動態(tài)的增加、刪除、改變。 3. Broker之間可交互。 4. 可重用性。 5. 由于組件的耦合度較小,調(diào)試和測試的工作也是可控的。 u 缺點: 1. 效率;增加了一層Broker的消息轉(zhuǎn)發(fā),效率有所降低。 2. 容錯能力必須要特別考慮。 3. 調(diào)試和測試的工作加大。

          posted on 2015-10-26 10:32 zyskm 閱讀(258) 評論(0)  編輯  收藏


          只有注冊用戶登錄后才能發(fā)表評論。


          網(wǎng)站導航:
           
          主站蜘蛛池模板: 隆子县| 山东省| 吐鲁番市| 堆龙德庆县| 祁连县| 临汾市| 扎兰屯市| 游戏| 宜宾市| 西盟| 凯里市| 西林县| 微山县| 区。| 永州市| 陈巴尔虎旗| 台南县| 谷城县| 永和县| 平原县| 堆龙德庆县| 义乌市| 巫山县| 榆中县| 揭东县| 香港 | 连城县| 洛扎县| 望谟县| 武安市| 大足县| 江达县| 道真| 银川市| 饶河县| 景德镇市| 吉林省| 萨迦县| 阿巴嘎旗| 无为县| 盐源县|