問題來源：

創(chuàng)建一個游戲系統(tǒng)，其將運行在互聯(lián)網(wǎng)的環(huán)境中。客戶端通過WWW服務(wù)或特定的客戶端軟件連接到游戲服務(wù)器，隨著流量的增加，系統(tǒng)不斷的膨脹，最終后臺數(shù)據(jù)、業(yè)務(wù)邏輯被分布式的部署。然而相比中心化的系統(tǒng)，復(fù)雜度被無可避免的增大了，該如何降低各個組件之間的耦合度。

挑戰(zhàn)：

需要保證可伸縮性、可維護性、可更新性，需要將服務(wù)劃分為各個相對獨立的組件，組件被分布式的部署，它們之間通過進程間通信方式實現(xiàn)交互。服務(wù)的增加、刪除、改變都應(yīng)該被支持。理想情況，以開發(fā)者的角度看，集中化的系統(tǒng)和分布式的系統(tǒng)在中心邏輯上沒有什么不同。為實現(xiàn)這個目標(biāo)：

l 可以遠程的訪問服務(wù)，而對于訪問者，服務(wù)的位置應(yīng)該是透明的。

l 提供服務(wù)的組件可以增加、刪除、改變，而且這些在運行期同樣應(yīng)該被支持。

l 訪問服務(wù)的客戶端不應(yīng)該關(guān)心服務(wù)的實現(xiàn)細節(jié)。

解決方案：

引入一個Broker組件，解耦客戶端和服務(wù)端。服務(wù)端注冊自己到Broker，通過暴露接口的方式允許客戶端接入服務(wù)。客戶端是通過Broker發(fā)送請求的，Broker轉(zhuǎn)發(fā)請求道服務(wù)端，并將請求的結(jié)果或異常回發(fā)給客戶端。通過使用Broker模式，應(yīng)用可以通過發(fā)送消息訪問遠程的服務(wù)。

這一架構(gòu)模式允許動態(tài)的改變、添加、刪除服務(wù)端，從客戶端的角度，這些都是透明的。

結(jié)構(gòu)：

Broker模式定義了6中類：Client，Server，Client_Proxy，Server_Proxy，Broker，Bridge。

Server：

l 責(zé)任：處理特定領(lǐng)域的問題，實現(xiàn)服務(wù)的細節(jié)，注冊自己到Broker，處理請求并返回結(jié)果或異常。

l 協(xié)作類：Server_Proxy，Broker

Client：

Client是需要訪問遠程服務(wù)的應(yīng)用程序，為此，Client發(fā)送請求到Broker，并從Broker上接收響應(yīng)或異常。Client和Server只是邏輯上相關(guān)而已，實際上Client并不知道Server的確切位置。

l 責(zé)任：1. 實現(xiàn)用戶端功能，2. 發(fā)送請求到Broker，3. 接收相應(yīng)和異常。

l 協(xié)作類：Broker，Client_Proxy

Broker：

Broker可以被看成消息轉(zhuǎn)發(fā)器。Broker也負責(zé)一些控制和管理操作。它能夠定位服務(wù)端的位置，若發(fā)生異常，能夠?qū)惓２东@傳給Client。Broker需要提供注冊服務(wù)的接口給Server。如果請求來自其他的Broker，本地的Broker需要轉(zhuǎn)發(fā)請求并最終將結(jié)果或異常回應(yīng)給相應(yīng)的遠程Broker。Broker提供的服務(wù)和name service非常相像（如DNS、LDAP）。

l 責(zé)任：1. 注冊服務(wù)。2. 提供服務(wù)API。3. 轉(zhuǎn)發(fā)消息。4. 容錯處理。5. 與其他Broker的交互。6。 定位服務(wù)。

l 協(xié)作類：Client_Proxy,Server_Proxy,Bridge

Client_Proxy：

連系Client和Broker，這一層保證了通訊的透明性，使Client調(diào)用遠程服務(wù)就像調(diào)用本地的服務(wù)一樣。

l 責(zé)任：1. 封裝特定的系統(tǒng)調(diào)用。2. 封裝通訊的參數(shù)、控制信息等。

l 協(xié)作類：Client,Broker。

Server_Proxy：

Server_proxy是與Client_Proxy相對應(yīng)的，它接受請求，解包消息，解析出參數(shù)并調(diào)用服務(wù)的實現(xiàn)接口。

l 責(zé)任：1. 封裝特定的系統(tǒng)調(diào)用。2. 封裝通訊的參數(shù)、控制信息等。3. 調(diào)用server的服務(wù)接口。

l 協(xié)作類：Server,Broker。

Bridge：

Bridge用來連接各個Broker，一般這個組件是可選的。當(dāng)系統(tǒng)是發(fā)雜的網(wǎng)絡(luò)組成時，有可能需要這一角色。

l 責(zé)任：1. 封裝特定的網(wǎng)絡(luò)特性。2. 傳遞Broker之間的通訊。

l 協(xié)作類：Broker。

應(yīng)用場景一：

直接通訊方式。Client和Server相互理解他們之間的通訊協(xié)議。Broker主要完成Client和Server之間的握手。之后所有的消息、異常都是由Client與Server直接交互。（想象DNS）。簡單對象交互如圖：

應(yīng)用場景二：

l Broker啟動，完成自身的初始化，之后進入事件循環(huán)，等待消息到來。

l Server啟動，首先執(zhí)行自身的初始化，然后注冊自己到Broker。

l Broker接收Server的注冊請求，將其加入到可使用服務(wù)的列表，并回應(yīng)Ack給Server。

l Server接收Ack，進入事件監(jiān)聽循環(huán)，等待消息到來。

l Client調(diào)用遠程服務(wù)對象的方法，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將相應(yīng)消息轉(zhuǎn)發(fā)給正確的Client_Proxy，Client受到響應(yīng)繼續(xù)其他邏輯。

簡單對象交互如圖：

應(yīng)用場景三：

l Broker A接收到請求，交由Server處理，但是發(fā)現(xiàn)該Server位于其他的網(wǎng)絡(luò)節(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)點：

服務(wù)的位置透明性。

組件的可變性及擴展性。由于Server是注冊到Broker上的，所以Server可以動態(tài)的增加、刪除、改變。

Broker之間可交互。

可重用性。

由于組件的耦合度較小，調(diào)試和測試的工作也是可控的。

u 缺點:

效率；增加了一層Broker的消息轉(zhuǎn)發(fā)，效率有所降低。

容錯能力必須要特別考慮。

調(diào)試和測試的工作加大。

總結(jié)

以上是生活随笔為你收集整理的分布式模式之Broker模式的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。