面向對象分布式開發系統理論篇(下)

面向對象分布式開發系統理論篇(下) 

來自：天極論壇 作者：陳立峰 [2004/03/15] 

3.3 分布式對象Distributed Object 
　　在上文提到，SoftEngine 由不同種類的對象構造，在發布實施角度上看，可分為三種: 本地(Local)對象，遠地(Remote) 對象，虛擬(Virtual) 對象 。 

圖表 6 Local, Remote and Virtual Object 
　　在上圖中: 
　　本地對象Local Object : 指分布在同一個SoftEngine 獨體系統中的對象，互稱為本地對象。如：在系統I 中的對象A 和B 互為本地對象 。 
　　遠地對象Remote Object : 指分布在不同SoftEngine 系統中的對象（同一個群體系統）。 如: 對象A 和C ，以及B 和C 互為遠地對象。對于系統II 中的C ，系統I 中的A 和B 屬于遠地對象的 。 
　　虛擬對象Virtual Object : 不同于本地和遠地對象，虛擬對象不屬于真實的對象，而是一個虛設的類型。真正的操作不在虛擬對象本身，只是遠地對象在本地的映射。如：虛擬對象A，是A 在系統II 中的映射。對象C 向A發送的任務，會轉送到遠地對象A ，而C 不知道，也沒有必要知道。同理，如果對象B 需要發送任務到C ，在系統I 中可定義C 的虛擬對象 。 
　　本地和遠地對象是相互的關系。而虛擬對象只是一種映射，用于關聯本地和遠地對象，起到分布和負載均衡的作用。三者之間的關系在開發中無須關心，只有在系統部署中，通過配置發布環境來確定或改變。以下圖為例，介紹負載均衡: 

圖表 7 A load balance system 
　　在一個分布的系統中，有兩個獨立的運行系 統 I 和II 。其中有相同的對象A1, A2, A3, A4 被分別發布，他們所被加載的類是相同的，只是被定義的發布名稱不同。如果再定義一個虛擬對象A 同時映射到A1 – A4 ，同時配置不同的策略，如負載均衡的循環法(Round-Robin) ，或冗余法(Hi-Available)。發送到A 的任務，會按照不同的策略分發到A1-A4 上。 
　　在應用對象開發測試完成后，部署的策略，包括：系統配置、對象配置、對象發布等信息，被定義在每個獨體系統的配置文件中。通過這些配置文件，將會動態地構建出一個分布的網狀系統，可以完成特定的應用功能。所以如此構成的分布式系統具備以下的體點： 
　　整個分布式系統由各種對象，以動態組件的方式構造。 
　　對象可以存在于任何網絡(LAN/WAN) ，任何主機。 
　　通過配置，對象可以動態地加載/ 卸載。整個分布系統，始終處于動態調整狀態。 
　　虛擬對象讓本地對象忽視真實的遠地對象的物理位置。 
　　開發與分布過程完全分離。在對象開發過程中，無需過多的考慮系統級的問題。

 

圖表 8 A distributed system 
　　3.4 數據安全Data-Safety 
　　應用系統所需的數據信息，在以任務的方式送入SoftEngine 系統內部后，任務將會被高效地傳輸在每個獨體系統內部，或群體系統的網絡中。因此，如何保證任務的安全到達，是一個關鍵的問題。在SoftEngine 里，解決這個問題的技術稱為：數據安全。其中包括四個部分 ： 
　　安全的任務池Safety Task Pool 
　　任務懸掛Pending 
　　降速傳遞Slowdown 
　　流量控制Flow control 
　　以下圖為例描述: 

圖表 9 Data-Safety 
　　Forward Task: 發送任務
　　Backward Task: 回送任務
　　Undeliverable Task: 無法發送任務
　　Panding Task:懸掛任務
　　Task Channel:任務通道
　　Pending Pool: 懸掛緩沖池 
　�。�安全的任務池Safety Task Pool 
　　在SoftEngine 的內核，大部份對象都有自己的任務池與任務通道連接。類似于文件系統的內存緩沖，任務池對于提高系統性能有非常重要的作用。同時為了保證數據的安全不丟失，任務池需要良好的設計，包括: 過載保護(overload protection) ，硬盤緩沖等安全機制，確保無論對象運行狀態如何，任務都不會丟失。也就是說，當一個任務被成功地送入目的對象的任務池，這意味著：任務是安全的。所以任務池保證了靜態任務的安全性。 
　�。�任務懸掛Pending 
　　在一些特殊情況下，任務無法立即發送到目的對象（如上圖對象A 發送任務到對象C ）。無法發送的任務將會被懸掛在一個特殊的任務池中 – 懸掛緩沖池。通過懸掛緩沖池，SoftEngine 系統會記住有那些任務因為那些目的對象而被懸掛，等待目的對象恢復后重發，或則任務超過了規定的生存周期，被丟棄。 
　�。�降速傳遞Slowdown 
　　在常規狀態下，對象A 會以最快的速度向對象B 發送任務。但如果此時，對象B 處于無效狀態，或任務量過載，那么第一個無法發送的任務將會被懸掛，同時發送源對象的發送速度也會被系統自動控制，減緩發送的頻率。稱之為: 降速傳遞。 
　　降速傳遞機制可以在巨大的任務流中，有效地保護系統失去控制，尤其當某個任務流中的對象發生了意外。舉個例子: 
　　對象A,B,C 合作完成一項任務，對象A 會產生大量的任務，經過對象B ，發送到C 。如下圖: 

圖表 10 One Sample 

　　假設，對象C 由于某種原因停止了工作，在沒有降速傳遞機制的情況下：對象B 也會由于大量的任務沒有發送，而很快“爆掉”。對象A 也會跟著失控。此時堆積在A,B,C 中間的任務將無法處理。另外，系統的CPU 、Memory 開銷可以會受到影響。采用了降速傳遞機制，對象B 的處理和發送任務的工作在一定程度上得到控制，對象A 也是如此。整個工作流的處理速度會自動減慢。直至對象C 恢復正常的工作狀態。 
　　所以當系統發生無法估計的問題時，降速傳遞可以有效地起到穩定系統的作用，避免大量數據因事故而丟失。 
　�。�流量控制Flow Control 
　　在分布式系統中，任務將會通過任務通道、通訊通道在內存、網絡上傳輸。保證傳輸線路上的數據安全也是非常重要了。流量控制機制是一個常見的技術用于解決傳輸雙方的穩定及數據的安全問題。這里不做過多的介紹。

3.5 流水線式設計模式Pipelining Design Model
　　“流水線式”經常在討論CPU 技術時被談及。在CPU 設計中，非流水線式設計模式的問題在于:每個單元指令必須在另一個指令開始前完成。這樣會有很多的空閑時間片，沒有效率。而流水線式的最基本思路在于充分利用CPU 內部空閑的組件，以至于可以同時處理多了單元指令，減少空閑時間片。也就是說，單元指令之間無須等待。非常明顯，這個技術可以極大程度地提高硬件效率。
　　在SoftEngine 內借用了這種思路，將任務代替了指令，將功能對象代替了硬件組件。流水線式設計所運用的基本理論：將大的任務劃分成一系列可交迭的、較小的任務，同時被一些功能對象分布處理。所以，在SoftEngine 基礎上，應用的設計人員，需要分析應用的處理流程，在設計階段劃分大任務，提高應用系統的性能。SoftEngine 可以有效地支持這種先進的設計模式 。
　　舉個例子，在普通的開發設計( 非流水線式設計) 中，假設一個任務需要4 個步驟完整，
　　　第一步：保存數據到磁盤，耗時100ms
　　　第二步：從磁盤中讀取歷史信息，耗時20ms
　　　第三步：從內存中讀取配置信息，耗時5ms
　　　第四步：結果計算，并返回結果，耗時10ms
　　見下圖：

圖表 11 Non-pipelining mode
　　整個流程的處理時間需要135ms ，請求的返回時間也是135ms 。不難看出，第一步雖然耗時最多，但屬于工作流的關鍵步驟，后續步驟也不等待其運行結果。而且在這個工作流中，每步操作，都需要等待上一步的操作（在同一時刻，只能有一個步驟在工作），所以135ms 不是最優化的結果。
　　通過流水線式設計模式，可以進步優化。首先，將這個任務，劃分為三個小任務分別由四個對象處理，所以設計了5 個對象 ：
　　對象A ：劃分大任務為三個小任務，同時分發。作為任務開始。
　　對象B ：保存數據到磁盤，耗時100ms
　　對象C ：從磁盤中讀取歷史信息，耗時20ms
　　對象D ：從內存中讀取配置信息，耗時5ms
　　對象E ：等待任務2 和3 的結果，計算后返回，耗時10ms
　　見下圖:

圖表 12 Pipelining mode
　　雖然每個步驟單位處理的時間并沒有減少。但對象B 的費時操作，被安排在主要流程之外，所以沒有影響整個處理時間。對象C 和D 的處理被安排在同一時刻發生。對象E 等待C 和D 的結果。所以只要工作流程為：
　　(A) -> (C, D) -> (E)
　　步考慮任務傳遞時間耦合時間，及A 的分發時間，總的響應時間為:
　　max( C, D ) + E = max( 20, 5 ) + 10 = 30ms 。
　　所以，流水線式設計模式的優勢，顯而易見。同時也改進了以往開發流程。
　　4. 分布式系統對開發流程的改進
　　以上介紹了分布式開發系統的關鍵概念及技術。利用這些技術，不但可以提高系統的性能，也可以改進以往開發的環境和步驟。開發步驟包括以下5 步:
　　設計Design: 改變以往從頭設計的做法，主要精力集中在應用的業務流程、工作流程、任務流程的設計。不斷優化流程，是應用系統成功與否的關鍵。
　　定義Define: 流程確定之后，就可以從中定義出各種功能對象，服務對象，任務對象，并加以描述。此過程需要將定義的對象放入確定的流程中，模擬其使用性、有效性等 。
　　實現Realization:開始實現定義好的的各種對象。并進行單元白盒測試，保證每個對象自身的穩定。在實現過程中會發現與定義中相矛盾的地方，此時需要與設計人員探討修改。
　　部署Deployment: 實現了每個對象之后，就可以對系統按照設計的流程進行部署。整個過程，都是通過配置文件進行系統調整。所以只要對象具有較強的獨立性，并且保證每個對象已達到錯誤最小化，就可以保證在聯合測試中，不會有過多的修改工作。但部署中，會根據實際境況對原先的流程進行調整，以達到最佳效果。
　　運 行 Running: 開發的最后一步，就是進入運行狀態。

圖表 13 Development process
　　與傳統開發流程相比，每個階段的劃分都更明確，這樣有利于不同角色的劃分和分工。尤其在部署階段，原始設計人員可以使用編碼完成的組件對象，直接介入系統的構建中。另外一個優勢在于：整個開發周期變短。由于無需從頭設計，按照一定的模式定義對象，程序的統一結構化，這些都是傳統軟件開發所無法比擬的。尤其充分的白盒測試，使聯合測試的成功率提高，時間節省了許多 。
　　5. 小結
　　本文，以SoftEngine 為例，簡潔地介紹了，以面向對象方式，解決分布式或傳統應用系統開發所需的關鍵技術。希望能為非Web 應用開發平臺，提供一些好的體系結構，改善我們的開發環境。