應用級集群系統的設計

集群系統在企業 IT 應用中的部署越來越廣泛，基於某個具體業務的應用級集群服務系統也越來越得到重視，圍繞這個主題，本文簡要地探討了應用級集群一般性的設計思路，重點針對分層業務資源、業務資源監測器、負載均衡器和故障轉移管理器等四部分。

集群類型

按集群系統的應用範圍，大體可分為操作系統級集群和業務應用級集群。通常，操作系統級集群作為底層基礎集群架構為業務應用級集群提供操作系統級的集群服務；而業務應用級集群則作為操作系統級集群的子集群，部署在操作系統級集群之上，完成特定業務的集群服務。

操作系統級集群

Linux 下主要的幾個操作系統集群：

1. LSF：通過網路將多個異構的集群體系相聯繫，共享計算資源 ，而用戶則以透明的方式來訪問這些資源。
2. TurboCluster：是一個企業級軟體集群系統解決方案，支持異構的網路環境。有較強的可用性和可擴展性。
3. Linux Virtual Server：LVS 項目是國內章文嵩博士領導開發的 Linux 服務集群系統，它集合了集群技術和 Linux 操作系統內核實現了一個具有高伸縮性、高可靠性和高可管理性的集群解決方案，同時也為完成大訪問量、可靈活部署、高可用的企業級集群系統的開發提供了一個完美的架構。LSF、TurboCluster 和 LVS 三者類似，在體系中都部署了一個負責完成平衡訪問負載的主控制機，由它來根據環境數據決定負載均衡策略完成整個訪問請求的轉發，內部核心處理部分基本上是對外端客戶完全透明的。
4. MOSIX：與前三者對比有很大的不同，它沒有一個單獨的專用部件來完成訪問請求的負載均衡，所有的伺服器節點是都平等的和完全分佈的。
5. EDDIE：它由 HTTP 網關和特殊的 DNS 伺服器組成，共同構成了一個分散式的 WEB 服務集群。

操作系統集群具備的基本特點：

• 提供強大的計算處理能力
• 提供高可用性的應用
• 提供可伸縮的軟體硬體部署
• 提供對系統資源強大全面的調度與管理

業務應用級集群

業務應用級集群在繼承操作系統級集群特性的基礎上，重點集中在自身所支持的業務特性，也有自身的特點。

業務應用級集群基於具體的業務規則，它將關注焦點放在框架內運行的各個業務資源，以及資源內部或資源之間的業務數據流，結合事先定製的業務策略，進而做出符合業務的管理操作。

業務應用級集群對資源的管理與調度範圍相對有限，局限於框架內部的組件；而對於框架之外的組件無能為力，須藉助於底層的操作系統級集群的功能進行間接的管理。

業務應用級集群運行在操作系統集群之上作為其子部分，要接受操作系統集群的監管。

本文中討論的內容就是基於 LVS 體系架構的業務應用級集群的開發。它提供針對對象生命周期的管理、差錯檢測、自我修復和自我遷移等功能。以下的章節介紹業務應用集群軟體框架 BRMF（Business Resource Management Framework，業務資源管理框架）的設計。

集群業務資源的設計

分析大多數的業務系統，我們都可以將其業務資源分為兩類：形成業務特徵的邏輯業務資源和最終執行業務服務運行的物理業務資源。對於這兩類資源，往往又以“部分”從屬於“整體”的樹形層次結構來展現，物理業務資源從屬於邏輯業務資源，“從屬”的關係決定了二者已具有功能上的一致性。其中，劃分粒度的最細單位為 BRU（Business Resource Unit，業務資源單元）；若干的 BRU 可以組成 BRG（Business Resource Group，業務資源組），每一個 BRG 就代表了一個完整的業務處理服務過程；若干個 BRG 可以組成一個 BRC（Business Resource Container，業務資源容器），形成一個服務節點。其中，BRU 屬於物理業務資源，BRG 和 BRC 屬於邏輯業務資源。

BRMF 框架採用嚴格的分層管理機制，至上而下來看，當前業務資源層只能對下一層的業務資源進行管理；至下而上來看，當前層業務資源層只能接受上一層的管理。總之，只能在相鄰的上下兩層之間產生管理與被管理的關係，不允許縱向跨層管理，例如 BRC 不能對 BRU 直接進行管理；類似的，也不允許橫向上的平層管理，即處於同一層次的業務資源不能相互管理，它們之間是平行且獨立的關係，例如從屬於 BRC_A 的 BRG_A 不能對從屬於 BRC_B 的 BR_B 直接進行管理。如果 BRC 需要對 BRU 實施管理操作，BRC 就必?通過 BRU 所屬的 BRG 進行管理指令的下達；對於 BRU 的回饋信息也只能層層上報，即 BRC 只能通過 BRG 才能了解相關的 BRU 的信息。如 表 1 所示為 BRMF 框架中業務資源部署結構。

BRU 表示處理業務服務的最細節過程，它是業務服務的直接載體，它與真實的業務之間表現為兩種映射關係：

1. 一對一關係，即一個 BRU 映射一個業務功能，它能獨立的表示某個完整業務生命周期。這種關係下的 BRU 一般只能處理簡單的業務服務。
2. 多對一關係，這種關係下單一 BRU 只代表業務過程的一個片段，多個 BRU 之間相互依存，並協同處理某個複雜度較高的業務。

通過 BRU，我們可以看到真實的業務規則實施和業務數據流。每一個 BRU 都只從屬某一個 BRG，接受 BRG 的管理。

BRG 實現了某個完整的業務生命周期。BRG 由若干 BRU 組合的方式來表現，這種方式更多的是體現出實際業務的邏輯性上，它是若干 BRU 業務邏輯集合的反映，與完整的真實業務功能呈現一對一的關係。BRG 的集合粒度可根據軟硬體技術因素和業務規則等因素進行集合或拆分，可分為兩種：

1. 一般而言，簡單的 BRG 體現出了 BRU 與業務之間的一對一關係，即一個 BRG 只集合了一個 BRU，此 BRG 負責處理某個較簡單的業務；稍微複雜的 BRG 集合了若干（大於 1）個 BRU 協調處理較複雜的業務服務；
2. 特殊情況下，若干 BRG 可以再次被集合形成一個體積更大功能含蓋範圍更廣層次更高的 BRG，以便於表示更加複雜的業務。不過這種情況增加了業務資源的管理複雜度，特別是在發生故障需要做遷移操作時，所以不建議採用。為了在不影響業務服務的前提下，避免這種情況的發生，可考慮重新選擇業務資源的粒度進行劃分。

在 BRG 的屬性中，包括了對 BRU 組成的業務鏈的定義，從起始輸入點，中間過程處理點，到最終輸出點。

從邏輯上引入 BRG 的概念，還有一個更重要的原因，就是為了劃定出在集群應用系統中故障管理情況下最小的邏輯遷移單元，因此，BRG 還需要具有集群特性 ---- BRG 中所有的 BRU 必?作為一個完整的實體存在，任何一個 BRU 運行失敗都代表所屬的整個 BRG 運行的失敗。在故障轉移發生的情況下，BRG 只能做整體性操作，包括重啟和遷移等。每一個 BRG 都只從屬某一個 BRC，接受 BRC 的管理。

BRC 表示物理上的服務節點，一個 BRC 對外提供若干完整的業務服務過程，若干個 BRC 便形成了更加全面綜合的業務服務體系，或者一個提供冗餘特性的業務服務體系。BRC 接收負載均衡器轉發的客戶端訪問請求，每個 BRC 都有各自的內部 IP 地址。

在集群系統當中，一般都提供資源的冗餘配置，如將兩個相同的 BRG 部署在不同的 BRC 上，為實現均衡的負載和故障的平滑處理，以提高服務響應度和保證服務可用性。

可以觀察到 BRC、BRG 和 BRU 三者之間存在一種“整體－部分”的樹形層次結構。在業務操作方面，為了使這種具有明顯樹形特點的對象組合擁有操作簡易性和一致性，可以用“複合模式（composite design pattern）”來設計展現三者之間的層次關係。這種設計下，樹形複合體內部的各個元素對象都擁有共同的介面。當調用元素對象的某個介面時，自動遞歸地遍歷以當前元素為起始根節點的以下的所有節點元素，在遍歷的同時對每個經歷的元素對象調用相同的介面，達到“一令齊動”的效果。具體講，就是只需要操作 BRC 即可完成對 BRC 中所有 BRG 的相同操作，操作 BRG 即可完成對 BRG 中所有 BRU 的相同操作。

				   // 根據業務資源展現出的形態，採用 composite 模式作為開發實現  public interface IElement {       // 基本屬性      public void setName ( String name );       public String getName ( );       public void setId ( int id );       public int getId ( );       // 業務數據      public void setData ( Object data );       public Object getData ( );       // 結構管理，實現樹形的結構      public void addChildElement ( IElement child );       public boolean contains ( IElement child );       public void removeChildElement ( int index );       public void removeChildElement ( IElement child );       public void removeChildrenAll ( );       public void enable();       public void disable();       public IElement getChildElement ( int index );       public int getChildCount();       public int getIndexOfChild ( IElement child);       public IElement[] getChildElements ( );       public IElement getParentElement ( );       public void setLeaf ( boolean leaf );       // 如果返回為 true 則表示此業務資源為 BRU，返回 false 則有可能為 BRG 或 BRC       public boolean isLeaf ( );    }      // 定義業務操作介面  public interface IOperation {       // 讓 parentElement 業務資源及其以下的所有業務資源執行業務服務 business_1       public boolean doBusiness_1 ( IElement parentElement );       public boolean doBusiness_2 ( IElement parentElement );       public boolean checkDetailsOfBusiness ( IElement parentElement, Map details );   }     public interface IBR extends IElement, IOperation { }     public class AbstractBR implements IBR {       ....       public boolean doBusiness_1 ( IElement parentElement ) {           // TODO: 實現 parentElement 真實的業務操作          ........           // 實現 parentElement 節點下所有節點的 doBusiness_1 業務的遞歸操作          for ( int i=0; i<parentElement.getChildCount(); i++) {               IElement childElement = parentElement.getChildElement ( i ) ;               childElement.doBusiness_1 ( childElement );           }       }   }     // 完成 BRC 自身的服務后，將服務命令傳遞給 BRG   public class BRC extends AbstractBR { ...... }     // 完成 BRG 自身的服務后，將服務命令傳遞給 BRU   public class BRG extends AbstractBR { ...... }     // 負責完成通過 BRC 和 BRG 下達的服務命令，它是服務處理最核心最主要的執行者  public class BRU extends AbstractBR { ...... }     // 測試代碼  public class Test {       .....       public void fun ( ) {           AbstractBR BR = new BRG ( );           // BR 完成 business_1 業務 :           // 最終由此業務資源組中的業務資源單元來完成相關的業務實現          BR.doBusiness_1 ( BR );       }   }