3.布式系統的關鍵技術
3.1面向對象技術Object-Oriented
客戶/ 服務器模式，是典型的分布式計算模型。在此模式下，客戶端建立連接到服務器，通過相互約定的協議通訊，以達到交換信息的目的。SoftEngine 核心的通訊通道封裝了這些復雜的底層細節。通過多層的封裝技術，將底層對象與應用對象完全隔離。SoftEngine 只在組件區域為應用提供了一些抽象類作為"軟總線"的接口。如下圖所示:
圖表 2 Abstract class is the interface of Soft-Bus.
Application Objects : 應用對象 System Objects: 系統對象
Infrastructure Objects: 底層對象 Abstract Class: 抽象類
設計一個可重用的面向對象軟件不是簡單的事，一個分布式的重用系統更是困難的事。在SoftEngine 的基礎之上卻很容做到。因為其本身的體系結構是對象化設計的，也是可重用的 。
在組件區域內，開發人員只需關注應用的業務，繼承接口抽象類，實現所定義的業務流程，通過發布實例化的應用對象，構造應用系統。這種面向對象的開發模式，對程序員來講是非常簡單，非常有效的，也可從繁重的體力勞動（編碼）中解脫出來，更多的精力用于設計工作。
組件區域中的應用對象，是可被重用。按照一定的發布方式，可以在不同的SoftEngine 系統中再次利用�？杀恢赜眯圆辉偃Q于編碼的質量，而在于如何設計出好的應用業務邏輯流程。關于這一點，我們將在后續的流水線式設計模式中討論。
3.2任務驅動Task-Driven
在SoftEngine 內部采用的是任務驅動。在這里所提到的任務驅動概念，不完全相同于一些專業任務驅動論文，更接近事件驅動(Event-Driven) 。也就是說，所有的對象在沒有任務時，處于空閑狀態；直到有任務（事件）到達，對象的運行模式才會轉變為激活狀態。
在不同的對象間，傳遞任務是合作(collaborate) 的唯一方式。合作模式有兩種:
·完全獨立的模式(Individual)
·松散耦合模式(Loosely Coupled)
下面圖示了其中的不同： 
圖表 3 Individual and loosely coupled collaboration
·對象A 和對象B 有次序地處理同一個任務，對象B 必須等待對象A 的處理結果。對象A 和對象B 的合作關系稱為：松散藕合模式 。
·對象B 和對象C 分別處理不同的任務。這種關系稱為：完全獨立的模式。也就是說，對象C 需要的任務，不總是來自于對象B ，它們之間沒有必要的關聯。
在完全獨立模式，對象C 由于功能相對獨立，無須等待想關數據，所以效率比較高，具有很高的實時性。但存在功能相對集中，適應性比較差，被可重用的可能性也相對減少的不足。松散耦合模式，為完成任務，將處理步驟/ 功能細分為不同的對象。使對象A 和B 的功能相對專一，適應性增強，可重用性也增加了。同時更據不同的功能效率可以方便的作負載均衡(Load balancing)調整。但是任務的多次投遞，以及相對的耦合關系，也降低了局部的處理性能。就如下圖所顯示的兩者的性能比較：
圖表 4 Performance of collaboration
在實際應用開發中，如果選擇完全獨立的模式 或 松散耦合模式，取決于在設計階段如何定義應用的業務流程。這將在后續章節: 流水線式設計模式中再次闡述 。
每個被傳送中的任務，都具有自己的生存周期(Live cycle)，從產生到被丟棄。如下圖生存周期圖：
圖表 5 Live-cycle of task
Created : 被產生 Forward: 正向傳送
Backward: 回送 Pending: 懸掛
Timeout: 超時 Operating:處理
Droped:被丟棄
一個任務由某個功能對象產生，并傳送(forward)到下一個目的對象，在那里將被處理之后，這個任務會被丟棄，或被返回(backward)到源對象。這是一個常規的任務生存周期，但如果在任務傳遞途中，發生如目標對象不可到達等阻礙，該任務將會被懸掛(pending) 。直到繼續傳送或超時(timeout)被丟棄。任務在傳遞中的安全問題，將會在后續的數據安全主題中討論。
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) ，任何主機。
·通過配置，對象可以動態地加載/ 卸載。整個分布系統，始終處于動態調整狀態。
·虛擬對象讓本地對象忽視真實的遠地對象的物理位置。
·開發與分布過程完全分離。在對象開發過程中，無需過多的考慮系統級的問題。 
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 應用開發平臺，提供一些好的體系結構，改善我們的開發環境。
在后續文章( 應用篇) 中，將陸續結合幾個實際中的案例，如：如何構建最快、最靈活、最穩定的無線數字增值服 務 ( 短信SMS, 彩信MMS ) 平臺，以及相關的組件等，描述其分布式、組件化的體系，及具體的解決方案。進一步談討，實際應用的可操作性。
注:
·在文章中所提及的一些觀點，只是本人在開發中的經驗所得。
·文章中所涉及的分布式技術，也可在SoftEngine 中得到證實 。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
