第5章分佈式系統模式 Broker（代理程序）

許多複雜的軟件系統運行在多個處理器或分佈式計算機上。將軟件分佈在多臺計算機上的緣由有多種，例如：

• 分佈式系統能夠利用多個 CPU 或一羣低成本計算機的計算能力。
• 某個軟件可能僅在特定計算機上可用。
• 出於安全考慮，軟件的各部分可能必須運行在不一樣的網段上。
• 一些服務多是由業務合做夥伴提供的，而且只能經過 Internet 進行訪問。

可是，實現分佈式系統是不容易的，由於您必須處理諸如併發性、跨平臺鏈接和不可靠網絡鏈接之類的問題。

影響因素

在構建分佈式系統時，必須協調下列影響因素：

• 雖 然分佈式系統具備許多優勢，可是它們每每也會使軟件系統變得很複雜。運行在同一網絡上的進程或計算機之間存在物理的和邏輯的邊界。要使運行在不一樣進程或計 算機上的對象跨越這些邊界相互通訊，您必須處理諸如通訊、編碼和安全之類的問題。若是您將這些實現細節與應用程序代碼混合在一塊兒，則通訊基礎結構中的簡單 更改就會致使大量的代碼更改。
• 在開發完成以後，一般須要分佈系統。例如，可能將軟件分佈在多臺服務器上以提升處理能力。您不會但願在生命週期中如此晚的階段更改應用程序代碼。
• 跨進程通訊的細節多是至關乏味的。您必須處理 TCP/IP 套接字、封送和拆收、序列化、超時和許多其餘難題。所以，有必要讓一個特殊的工做組致力於處理基礎結構，以便讓應用程序開發人員沒必要了解遠程通訊。
• 要維護可以在部署時將組件移動到不一樣位置這一靈活性，您必須避免對具體組件的位置進行硬編碼。

解決方案

使用 Broker 模式能夠隱藏遠程服務調用的實現細節，方法是將這些細節封裝到一個與業務組件自身不一樣的層 [Buschmann96]。

這個層爲客戶端提供一個接口，使客戶端能夠像調用任何本地接口同樣調用方法。可是，客戶端接口內的方法會觸發要對遠程對象執行的服務。這對客戶端是透明的， 由於遠程服務對象實現了相同的接口。該模式將啓動遠程服務調用的業務組件看成"客戶端"，而將響應遠程服務調用的組件看成"服務器"。

圖 1 顯示沒有進行任何分佈的簡單示例的靜態結構。客戶端直接調用服務器上的 performFunctionA 方法。僅當服務器對象與客戶端對象駐留在同一臺計算機上時，才能發生這種狀況。

圖 1:沒有實現分佈的結構

圖 2 顯示實現分佈後的靜態結構。

圖 2:實現分佈後的結構

ServiceInterface 是一個必需的抽象，對於在服務器端沒必要公開實現細節的狀況下將由服務器提供的服務來講，這樣的抽象能夠經過提供有關該服務的和約而使分佈成爲可能。在實現 分佈時，將添加客戶端和服務器代理，以處理經過網絡將方法調用及其參數發送到服務器，而後將響應發回客戶端的全部傳送工做。代理將完成全部數據封送和拆 收、安全控制、傳輸通道配置和任何其餘附加工做。客戶端只需調用客戶端代理的 performFunctionA 方法，就像它是本地調用同樣，這是由於客戶端代理實際上實現的是 ServerInterface。對客戶端進行的代碼更改將是最低限度的，所以您能夠開發整個業務域模型，而沒必要知道系統是不是分佈式的。對遠程服務調用的實現方式的任何更改都將被限制在代理類之內，而且不會對域模型產生任何影響。圖 3 顯示這些組件之間的一種交互方案。

圖 3:實現分佈後的行爲

服務器查找

Broker 解 決方案所針對的是前面所述的大多數問題。可是，由於客戶端代理直接與服務器代理進行通訊，因此客戶端必須可以在編譯時找到服務器的位置。這意味着，您不能 在運行時將服務器更改或移動到不一樣位置。要克服這一限制，須要避免公開服務器的確切位置。而應當將新組件（即代理程序組件）部署在一個衆所周知的位置，然 後向客戶端公開該位置。此後，代理程序組件負責爲客戶端查找服務器。代理程序組件還會實現一個用於添加和刪除服務器組件的儲存庫，這樣就有可能在運行時添 加、刪除或交換服務器組件。圖 4 顯示包含代理程序組件的靜態結構。

這種類型的功能一般稱爲"名稱服務"。查找遠程對象是企業計算中的一項常見要求。所以，許多平臺實現了名稱服務，例如，Microsoft 使用 Active Directory® 目錄服務。

圖 4:具備服務器查找功能的代理程序結構

代 理程序駐留在一個不該該頻繁更改的、衆所周知的位置。已被激活而且準備接收請求的任何服務器都將向代理程序註冊本身，以便下一次客戶端向代理程序請求這種 類型的服務器時，代理程序可以使用它。這還可能提升系統的性能和可用性，由於它使您能夠擁有多個同時運行並服務於多個客戶端的、徹底相同的服務器組件。這 種機制有時稱爲負載平衡。圖 5 顯示了一個這些組件之間的交互方案示例。

圖 5:具備服務器查找功能的代理程序行爲

代理程序做爲中介

在 前面的方案中，代理程序僅負責爲客戶端查找服務器。這種方案中，客戶端從代理程序得到服務器的位置，而後在不涉及代理程序的狀況下直接與服務器進行通訊。 可是，在某些狀況下，咱們並不但願客戶端與服務器之間進行直接通訊。例如，因爲安全緣由，您可能但願將全部服務器放在位於防火牆後面的公司專用網絡中，並 且只容許代理程序訪問它們。這種狀況下，您必須讓代理程序轉發服務器和客戶端這兩者之間的全部請求和響應，而不是讓它們直接相互通訊。圖 6 顯示將此模型修訂後的靜態結構。

圖 6:用做中介的代理程序的結構

圖 7 顯示用做客戶端和服務器之間的信使的代理程序的交互圖。此示例還說明了客戶端和服務器之間的通訊能夠是異步的（注意 sendRequest 調用上的開放箭頭）。

也 存在這樣的狀況：客戶端必須對同一服務器進行一系列方法調用，才能完成一個持續時間長並且複雜的業務事務。在這樣的狀況中，服務器必須在先後客戶端調用之 間保持狀態不變。而後，代理程序必須確保客戶端在基本會話內所進行的全部服務器調用都會被路由到徹底相同的服務器組件。

圖 7:用做中介的代理程序的行爲

Broker 模式具備 Layered Application 模式的許多優勢和缺點。

優勢

Broker 具備下列優勢：

• 隔離。經過將全部與通訊有關的代碼分離到它本身的層中，從而使其與應用程序隔離。您能夠決定在沒必要更改任何應用程序代碼的狀況下以分佈方式運行應用程序，或者在一臺計算機上運行所有應用程序。
• 簡單。將複雜的通訊邏輯封裝到單獨的層中，可使問題變得更簡單。爲代理程序編寫代碼的工程師沒必要關心沒法預知的用戶要求和業務邏輯，而應用程序開發人員也沒必要關心多播協議和 TCP/IP 路由。
• 靈活。經過將多個函數封裝在一個層中，能夠容許您以不一樣的實現來交換該層。例如，您能夠從 DCOM 切換到 .NET Remoting，再切換到標準 Web Service，而不用更改應用程序代碼。

缺點

惋惜的是，抽象層能夠損害性能。基本規則是，擁有的信息越多，就能夠優化得越好。使用單獨的代理程序層可能隱藏有關應用程序如何使用較低層的細節，這可能又 會阻止較低層執行特定的優化操做。例如，使用 TCP/IP 時，路由協議不知道正在路由的是什麼數據包。所以，很難決定包含視頻流的數據包（例如）應該具備比包含垃圾郵件的數據包更高的路由優先級。

安全考慮事項

包含敏感業務數據的服務器組件一般位於公司的專用網絡中，並受到防火牆的保護。而代理程序位於外圍網絡（也稱爲非管制區 (DMZ) 或屏蔽子網）中，外圍網絡是做爲公司專用網絡與外部公用網絡之間的中性區域而插入的小型網絡。只容許從外圍網絡訪問服務器組件，而不容許從外部公用網絡訪 問這些組件。這一額外的網絡層阻止了外部用戶直接訪問服務器。