文章轉(zhuǎn)載自http://blog.chinaunix.net/uid-23093301-id-90459.html
分布式模式之Broker模式
問題來源：創(chuàng)建一個(gè)游戲系統(tǒng)，其將運(yùn)行在互聯(lián)網(wǎng)的環(huán)境中伐谈。客戶端通過WWW
服務(wù)或特定的客戶端軟件連接到游戲服務(wù)器赂蕴，隨著流量的增加，系統(tǒng)不斷的膨脹舶胀，最終后臺(tái)數(shù)據(jù)概说、業(yè)務(wù)邏輯被分布式的部署。然而相比中心化的系統(tǒng)嚣伐，復(fù)雜度被無可避免的增大了糖赔，該如何降低各個(gè)組件之間的耦合度。
挑戰(zhàn)：需要保證可伸縮性轩端、可維護(hù)性放典、可更新性，需要將服務(wù)劃分為各個(gè)相對(duì)獨(dú)立的組件基茵，組件被分布式的部署奋构，它們之間通過進(jìn)程間通信方式實(shí)現(xiàn)交互。服務(wù)的增加耿导、刪除声怔、改變都應(yīng)該被支持。理想情況舱呻，以開發(fā)者的角度看，集中化的系統(tǒng)和分布式的系統(tǒng)在中心邏輯上沒有什么不同悠汽。為實(shí)現(xiàn)這個(gè)目標(biāo)：
l 可以遠(yuǎn)程的訪問服務(wù)箱吕，而對(duì)于訪問者柿冲，服務(wù)的位置應(yīng)該是透明的。
l 提供服務(wù)的組件可以增加假抄、刪除、改變宿饱，而且這些在運(yùn)行期同樣應(yīng)該被支持熏瞄。
l 訪問服務(wù)的客戶端不應(yīng)該關(guān)心服務(wù)的實(shí)現(xiàn)細(xì)節(jié)谬以。
解決方案：引入一個(gè)Broker組件强饮，解耦客戶端和服務(wù)端为黎。服務(wù)端注冊自己到Broker邮丰，通過暴露接口的方式允許客戶端接入服務(wù)行您。客戶端是通過Broker發(fā)送請求的娃循，Broker轉(zhuǎn)發(fā)請求道服務(wù)端斗蒋，并將請求的結(jié)果或異嘲聘回發(fā)給客戶端骤星。通過使用Broker模式，應(yīng)用可以通過發(fā)送消息訪問遠(yuǎn)程的服務(wù)洞难。
這一架構(gòu)模式允許動(dòng)態(tài)的改變揭朝、添加、刪除服務(wù)端潭袱，從客戶端的角度，這些都是透明的编丘。
結(jié)構(gòu)：Broker模式定義了6中類：Client彤悔，Server，Client_Proxy晕窑，Server_Proxy，Broker敞斋，Bridge疾牲。
Server：l 責(zé)任：處理特定領(lǐng)域的問題，實(shí)現(xiàn)服務(wù)的細(xì)節(jié)说敏，注冊自己到Broker
鸥跟，處理請求并返回結(jié)果或異常。
l 協(xié)作類：Server_Proxy
医咨，
Broker
Client：
Client是需要訪問遠(yuǎn)程服務(wù)的應(yīng)用程序，為此干茉，
Client
發(fā)送請求到
Broker
很泊，并從
Broker
上接收響應(yīng)或異常。
Client
和
Server
只是邏輯上相關(guān)而已委造，實(shí)際上
Client
并不知道
Server
的確切位置戳鹅。
l 責(zé)任：1.
實(shí)現(xiàn)用戶端功能昏兆，
發(fā)送請求到
Broker
，
接收相應(yīng)和異常隶债。
l 協(xié)作類：Broker
跑筝，
Client_Proxy
Broker：
Broker可以被看成消息轉(zhuǎn)發(fā)器。
Broker
也負(fù)責(zé)一些控制和管理操作赞警。它能夠定位服務(wù)端的位置虏两，若發(fā)生異常，能夠?qū)惓２东@傳給
Client
。
Broker
需要提供注冊服務(wù)的接口給
Server
搁廓。如果請求來自其他的
Broker
，本地的
Broker
需要轉(zhuǎn)發(fā)請求并最終將結(jié)果或異瞅。回應(yīng)給相應(yīng)的遠(yuǎn)程
Broker
粱年。
Broker
提供的服務(wù)和
name service
非常相像（如
DNS
、
LDAP
）完箩。
l 責(zé)任：1.
注冊服務(wù)。
提供服務(wù)
API
阻逮。
轉(zhuǎn)發(fā)消息秩彤。
容錯(cuò)處理。
與其他
Broker
的交互瓜富。
6
降盹。 定位服務(wù)。
l 協(xié)作類：Client_Proxy,Server_Proxy,Bridge
Client_Proxy：
連系Client
和
Broker
仅胞，這一層保證了通訊的透明性剑辫，使
Client
調(diào)用遠(yuǎn)程服務(wù)就像調(diào)用本地的服務(wù)一樣。
l 責(zé)任：1.
封裝特定的系統(tǒng)調(diào)用妹蔽。
封裝通訊的參數(shù)胳岂、控制信息等。
l 協(xié)作類：Client,Broker
乳丰。
Server_Proxy：
Server_proxy是與
Client_Proxy
相對(duì)應(yīng)的，它接受請求汞斧，解包消息什燕，解析出參數(shù)并調(diào)用服務(wù)的實(shí)現(xiàn)接口。
l 責(zé)任：1.
封裝特定的系統(tǒng)調(diào)用庙睡。
封裝通訊的參數(shù)、控制信息等统台。
調(diào)用
server
的服務(wù)接口暂刘。
l 協(xié)作類：Server,Broker
。
Bridge：
Bridge用來連接各個(gè)
Broker
募寨，一般這個(gè)組件是可選的森缠。當(dāng)系統(tǒng)是發(fā)雜的網(wǎng)絡(luò)組成時(shí)，有可能需要這一角色列肢。
l 責(zé)任：1.
封裝特定的網(wǎng)絡(luò)特性宾茂。
傳遞
Broker
之間的通訊。
l 協(xié)作類：Broker
欧聘。
應(yīng)用場景一：直接通訊方式端盆。Client
和
Server
相互理解他們之間的通訊協(xié)議。
Broker
主要完成
Client
和
Server
之間的握手焕妙。之后所有的消息焚鹊、異常都是由
Client
與
Server
直接交互。（想象
DNS
）末患。簡單對(duì)象交互如圖：
l Broker啟動(dòng)阻塑，完成自身的初始化果复，之后進(jìn)入事件循環(huán)，等待消息到來走搁。
l Server啟動(dòng)，首先執(zhí)行自身的初始化忌栅，然后注冊自己到
Broker
曲稼。
l Broker接收
Server
的注冊請求，將其加入到可使用服務(wù)的列表瑞驱，并回應(yīng)
Ack
給
Server
窄坦。
l Server接收
Ack
，進(jìn)入事件監(jiān)聽循環(huán)彤侍，等待消息到來逆趋。
l Client調(diào)用遠(yuǎn)程服務(wù)對(duì)象的方法，
Client_Proxy
封裝消息請其發(fā)送給
Broker
父泳。
l Broker查詢可使用的
Server
惠窄，將請求轉(zhuǎn)發(fā)給
Server
。
l Server_Proxy解析消息杆融，分離出參數(shù)和控制信息脾歇，并調(diào)用特定的
Server
實(shí)現(xiàn)接口。
Server
處理完的結(jié)果通過
Server_proxy
封裝成消息轉(zhuǎn)發(fā)到
Server
藕各。
l Broker將相應(yīng)消息轉(zhuǎn)發(fā)給正確的
Client_Proxy
激况，
Client
受到響應(yīng)繼續(xù)其他邏輯膘魄。
簡單對(duì)象交互如圖：
l Broker A接收到請求竭讳，交由Server處理绢慢，但是發(fā)現(xiàn)該Server位于其他的網(wǎng)絡(luò)節(jié)點(diǎn)。
l Broker A將請求轉(zhuǎn)發(fā)給Bridge A胰舆，Bridge A將請求進(jìn)行必要的格式化思瘟，傳送給Bridge B。
l Bridge B將請求進(jìn)行必要的格式化滨攻，轉(zhuǎn)化成Broker B可以理解的格式，并轉(zhuǎn)發(fā)給Broker B女嘲。Broker B執(zhí)行場景二中的過程诞帐，處理的結(jié)果按如上逆序返回。
簡單對(duì)象交互如圖：
**總結(jié)：
u 優(yōu)點(diǎn)：1. 服務(wù)的位置透明性。
- 組件的可變性及擴(kuò)展性菇晃。由于Server是注冊到Broker上的蚓挤，所以Server可以動(dòng)態(tài)的增加、刪除灿意、改變缤剧。
- Broker之間可交互。
- 可重用性荒辕。
- 由于組件的耦合度較小，調(diào)試和測試的工作也是可控的大溜。
u 缺點(diǎn):
- 效率估脆；增加了一層Broker的消息轉(zhuǎn)發(fā)疙赠，效率有所降低。
- 容錯(cuò)能力必須要特別考慮圃阳。
- 調(diào)試和測試的工作加大。
**
