系統架構設計筆記(39)—— 簡單分佈式系統設計

網絡極大地擴展了計算機的應用範圍,同時,由於升級到更強的服務器的費用常常遠遠高於購買多臺檔次稍低的機器,更何況雖然計算機有了長足的發展,可是單臺計算機的功能仍然十分有限,利用聯網的計算機協同工作,共同完成複雜的工作成爲相對成本較低的選擇,而且可以完成單臺計算機所無法完成的任務。分佈式系統使得這一目標成爲可能。

但網絡本質上並不可靠,特別是遠程通信,分佈式系統會帶來了併發和同步的問題。

分佈式系統可以由兩種完全不同的方式來進行協同和合作。

(1)基於實例

第一種是基於實例的協作。這種方式所有的實例都處理自己範圍內的數據,這些對象實例的地位是相同的,當一個對象實例必須要處理不屬於它自己範圍的數據時,它必須和數據歸宿的對象實例通信,請求另外一個對象實例進行處理。請求對象實例可以啓動對象 、 調用遠程對象的方法,以及停止運行遠程實例。

基於實例的協作具有良好的靈活性,但由於實例之間的緊密聯繫複雜的交互模型,使得開發成本提高,而且,由於實例必須能夠通過網絡找到,所以通信協議必須包括實例的生存週期管理,這使得基於實例的協作大多隻限於統一的網絡,對於複雜的跨平臺的系統就難以應付。所以基於實例的協作適用於比較小範圍內網絡情況良好的環境中,這種環境常常被稱爲近連接。

這種情況下對對象的生存週期管理所帶來不尋常的網絡流量是可以容忍的。使用基於實例的協作常常使用被稱爲 “ 代理 ” 的方法,某個對象實例需要調用遠程對象時,它可以只和代理打交道,由代理完成和遠程對象實例的通信工作:創建遠程對象,提交請求 、 得到結果,然後把結果提交給調用的對象實例。這樣,這個對象實例甚至可以不知道自己使用了遠程對象。當遠程對象被替換掉(升級)時,對本地代碼也沒有什麼需要修改的地方。

(2)基於服務

另外一種方式是基於服務的協作,該方法試圖解決基於實例的協作的困難。它只提供遠程對象的接口,用戶可以調用這些方法,卻無法遠程創建和銷燬遠程對象實例。這樣減少了交互,簡化了編程,而且使得跨平臺協作成爲可能。

同樣由於只提供接口,這種協作方式使得對象間的會話狀態難以確定,而且通信的數據類型也將有所限制,基本上很難使用自定義的類型。基於服務的協作適用於跨平臺的網絡,網絡響應較慢的情況,這種環境常稱爲遠連接,這時,簡化交互性更爲重要,而頻繁的網絡交換數據會帶來難以容忍的延時。

基於服務的協作往往採用分層次的結構,高層次的應用依賴於低層次的對象,而低層次對象實例的實現細節則沒有必要暴露給高層次對象,這種安排使得高層次的實現不受低層次如何實現的影響,同時,當低層次服務修改時,高層次的服務也不應該受到影響。

設計者在進行設計時,通常會傾向於比較細緻的設計,對象往往提供了大量的操作和方法,響應許多不同的消息,以增加達到系統的靈活性 、 可維護性等。這在單個系統中沒有什麼問題,當考慮分佈式系統的設計時,這種細緻的設計所帶來對對象方法的大量調用會比較嚴重地影響性能,所以在分佈式系統中,傾向於使用大粒度的設計方式,往往在一個方法中包含了許多參數,每個方法基本上代表了一個獨立的功能。當然這樣的設計使得參數的傳遞變得複雜,當需要修改參數時,需要對比較大範圍的一段過程代碼進行修改,而不是像小粒度設計一樣,只需要修改少量的代碼。

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章