模式設計概述:代理者模式

分佈式系統模式

分佈式相關的模式設計有大概三種模式,分佈式系統與集中式系統相比需要完全不同的軟件。管道和過濾器模式,微核和代理者模式。

代理者模式

代理者模式體系結構的強制條件是

  1. 組件應該能夠訪問其他組件遠程、地點透明的服務調用提供的服務
  2. 需要在運行期間交換、添加或移動組件
  3. 該體系結構應該向用戶隱藏特定系統和特定實現的細節

引入代理者組件可較好地做到客戶機和服務機的隔離。服務器向代理者註冊自己並使其服務通過方法接口能爲客戶機所使用。客戶機通過代理者發送請求訪問服務器功能。代理者的任務包括定位合適的服務器,將請求轉發到服務器並向客戶機回送結果和異常。通過使用代理者模式,應用程序能夠簡單地通過向合適的對象發送消息調用訪問分佈式服務,而不是把重點放在低級進程間通信。另外,代理者體系結構很靈活,在這種模式下允許對對象動態改變、添加、刪除和重定位。代理者模式降低了開發分佈式應用程序的複雜性,因爲分佈性對開發者來說變得透明瞭。通過引入對象模型達到這個目標,在這個模型下分佈式服務被封裝在對象中。代理者系統提供了兩種核心技術集成的途徑:分佈技術和對象技術。它也將對象模型從單一應用程序擴展到由運行咋異構機器上的並可以用不同編程語言來編寫的獨立組件組成的分佈式應用程序。

本地代理者:代理者直接把請求傳送到服務器,如果服務器當前未激活,代理者將其激活。所有來自服務執行的應答和異常由代理者轉發到請求的客戶機。如果指定的服務器由另一個代理者代理,則本地代理者將尋找一條到遠程代理者的路徑並使用該路徑轉發請求。代理者允許對客戶機隱藏具體的實現細節,例如用來在客戶機和代理者之間傳送消息的進程間通信截止、存儲體的創建與刪除和參數與結果的列集。

服務器端代理者:與本地代理者類似,區別在於它們是負責接收請求、解開來到的消息、散集參數、調用恰當的服務等。

代理者的設計對象:

在這裏插入圖片描述

啓動階段

  1. 在系統的初始化階段代理者啓動,代理者進入其事件循環並等待消息的到來。
  2. 用戶或其他實體啓動了一個服務器應用程序。首先,服務器執行其初始化代碼。初始化完成後,服務器向代理者註冊自己。
  3. 代理者收到來自服務器的新來的註冊請求。從消息中提取出必須信息並將其存儲到一個或多個倉庫中。這些倉庫用來定位並激活服務器。返回一個確認。
  4. 從代理者收到確認後,服務器進入其主循環等待新來的客戶機請求。
ServerBrokerinitlalite啓動並初始化register_service註冊服務更新數據acknowledgmententer_main_loop進入事件循環ServerBroker

當一個客戶機向本地服務器發送請求時的行爲。在這個場景中,主要描述了一個同步調用,在這個調用中,客戶機處於阻塞狀態直到得到了服務器的迴應。代理者也可能支持異步調用,允許客戶機不必等待迴應而進一步執行任務。

  1. 啓動客戶機應用程序。在程序執行期間,客戶機調用遠程服務器對象的方法。
  2. 客戶機端代理將所有參數和其他相關信息打包成一條消息並將該消息發送到本地代理者。
  3. 代理者在倉庫中查找到所要求的服務器的地址。由於服務器是本地可用的,代理者將消息轉發到相應的服務器端代理。遠程情況下,見下面的場景。
  4. 服務器端代理打開所有參數和其他信息,如期望調用的方法。服務器端代理調用適當的服務器。
  5. 服務器執行完畢後,服務器將結果返回到服務器端代理,它將其打包成帶有其他相關信息的消息並傳遞給代理者。
  6. 代理者將回應轉發到客戶機端代理。
  7. 客戶機端代理收到迴應,打開結果並返回客戶機應用程序。客戶機進程繼續其計算。
ClientClientSideProxyBrokerServersSideProxyServercall_service調用服務send_request發送請求pack_data封裝數據forward_request發送請求到Brokerfind_server尋找servercall_service調用服務unpack_data解析數據run_service調用服務響應結果unpack_data包裝數據forward_response返回數據find_client尋找返回的客戶端返回數據unpack_data解析數據返回客戶端最終數據ClientClientSideProxyBrokerServersSideProxyServer

通過橋接組件不同代理者進行交互。

  1. 代理者A收到新來的請求。它通過在倉庫中查找定位負責執行特定服務的服務器。由於對應的服務器在另一個網絡節點處可用的,因此,該代理者發送請求到遠程代理者。
  2. 消息從代理者A發送到網橋A。這個組件負責將該消息從由代理者A定義的協議轉換成網絡特定的但可以被參與的兩個網橋所理解的公共協議。消息轉換後,網橋A將消息發送到網橋B。
  3. 網橋B將新來的請求從網絡特定格式映射到代理者B特定的格式。
  4. 當請求達到時,代理者B執行所有必須的行動,正如該場景中的第一步中所描述。
BrokerABridgeABridgeBBrokerB接收到forward_request請求find_server尋找serverforward_message傳遞數據pack_data封裝數據transmit_message傳遞數據unpack_date解析數據forward_request轉發請求find_server尋找服務器BrokerABridgeABridgeBBrokerB

代理者模式的優點:

  1. 定位透明性,由於代理者負責定位服務器通過使用了唯一的標識符,所以客戶機就不需要知道服務器的位置。
  2. 組件的可變性和可擴展性。如果服務器發生改變而其接口保持不變,這將對客戶機沒有功能上的影響。
  3. 代理者系統的可移植性。代理者系統通過使用諸如API、代理和網橋這樣的間接層,來對客戶機和服務器隱藏操作系統和網絡系統。
  4. 不同代理者系統之間的互操作性。如果不同代理者系統理解消息交互的公共協議,那麼它們就可以互操作。
  5. 可重用性。創建新的客戶機應用程序時,可以基於現有系統來建造應用程序的功能。

代理者模式的不足:

  1. 效率受限。使用代理者模式的應用程序通常比組件分部是靜態和已知的應用程序要慢。直接依賴於用來在進程間通信的具體機制的系統在性能上也高於代理者體系結構,因爲代理者引入了間接層使之具有可移植性、靈活性和可變更性。
  2. 容錯性較差。與非分佈式軟件系統相比,代理者系統提供的容錯性較低。假設一個服務器或代理者在程序執行期間失效,那麼所有依賴於該服務器或該代理者的應用程序將不能成功地繼續進行。

總結

本文大部分內容都是摘抄自<<面向模式的軟件體系結構卷1模式系統>>一書,該模式的設計內容比較有利於軟件架構設計故留所記錄。

發佈了143 篇原創文章 · 獲贊 61 · 訪問量 6萬+
發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章