第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 調用上的開放箭頭）。

也 存在這樣的情況：客戶端必須對同一服務器進行一系列方法調用，才能完成一個持續時間長而且復雜的業務事務。在這樣的情況中，服務器必須在前后客戶端調用之 間保持狀態不變。然后，代理程序必須確?？蛻舳嗽诨緯拑人M行的所有服務器調用都會被路由到完全相同的服務器組件。

圖 7:用作中介的代理程序的行為

Broker 模式具有 Layered application 模式的許多優點和缺點。

優點

Broker 具有下列優點：

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

缺點

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

安全考慮事項

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