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