作者：郭洪鋒
本文敘述了分布式實時系統中基礎服務應用概念，對其持久性實現做了詳細的分析。
1、基礎服務應用在分布式實時系統中的角色
在許多企業系統中，一般由內部核心局域網系統和以該核心系統為中心的外部廣域網客戶服務系統（例如Web系統）組成。核心局域網系統負責企業內部數據和事務的處理，同時也為外部系統提供企業可用的共享數據。因此，核心局域網系統的持久性、高可靠性和高可用性對於整個企業系統至關重要。
企業的核心局域網系統為一個分布式的企業應用系統，一般具有實時性的要求。比如電力行業的能量管理系統，作為電力企業的核心應用系統，是一個真正的分布式實時系統，要求系統具有實時反映電力系統狀態變化和不間斷可靠運行的能力。而在這個分布式應用系統中，基礎服務應用的設計又決定了系統的整體性能。
基礎服務應用是整個企業核心分布式系統運行的基礎平台。它為整個分布式應用系統提供分布式對象管理和提供各類服務的能力，為系統中的各類上層應用提供對象及內容查詢、實時資源共享、對象生命周期維護、對象引用分布化等服務。
2、基礎服務應用構架
基礎服務應用運行於企業系統中的所有節點，類似CORBA系統中的ORB，但是基礎服務應用作為一個單獨的應用，不僅提供對象定位服務，並且提供各類實時分布式系統所需的基礎服務。這樣設計的原因不僅基於高速局域網的固有特點，並且主要強化系統的不間斷運行的實時性和分布式特點。就基於高速局域網的企業系統而言，基於基礎服務應用的系統比之基於類似CORBA的系統更容易提供持久性服務（包括故障自動排除能力）、高可靠性和高可用性服務。
基礎服務應用的簡化構架如下圖所示：
圖1： 基礎服務應用的簡化構架
外部接口API層設計成對上層應用提供服務的標准接口集合。通過這些接口，上層應用可以以本地的方式訪問整個分布式實時系統中的分布式對象，可以引用、注冊或更新或注銷自己的對象引用等。事務處理層負責響應上層應用，以提供各類服務。它可以通過本地對象數據庫維護層操作本地記錄的系統內的所有分布式對象。分布式管理層則維護系統的分布式實時特征，提供持久性服務、可靠性服務。整個系統內的所有節點均通過分布式管理層達到分布式對象的全局統一性。
基於基礎服務應用系統中的任何一個節點的故障均不會影響整個分布式實時系統的整體運行。即不發生故障時，節點是分布式實時系統中一個不可分割的運行實體，而節點發生故障時，節點要平滑的脫離分布式實時系統，並且不會對系統的實時性、分布式和提供的各類服務產生異常的影響，其中不僅自動在分布式系統中注銷該節點，並且與該節點有關的所有對象將自動注銷或狀態轉移為非正常狀態如凍結、丟失或不可用狀態。
3、基礎服務應用服務持久性服務的實現
基礎服務應用的分布式管理層負責統一所有系統節點的分布式對象引用。並提供整個系統基礎服務應用的服務持久性。所有的基礎服務應用運行級別是不一樣的，其中一個運行級別最高的是系統中的主基礎服務應用，將作為其他基礎服務應用的對象應用的統一源，分布式管理層維護基礎服務應用的運行級別，實時統一系統內的分布式對象引用。
3.1分布式管理層狀態轉化圖
分布式管理層狀態轉化圖如下圖所示：
圖2：分布式管理層狀態轉化圖
該圖實際上只是表達了基礎服務應用開始啟動時的狀態轉化圖。運行過程中其狀態圖會變得更復雜。在基礎服務應用開始啟動時，首先查詢系統內有無主服務應用存在，由於基於地域有限的局域網系統，主基礎服務應用啟動後會啟動一個以廣播和多播形式的心跳消息驅動器。基礎服務應用開始啟動後可以很快收到這些消息，然後建立與主基礎服務應用的一條可靠的信道。這時由於基礎服務應用內部的分布式數據庫不能反映實時狀態，所以需要復制主基礎服務應用的分布式數據庫。復制過程中，基礎服務應用將調用主基礎服務應用的分布式管理層內部的復制服務方法，逐步的將所有的實時的數據復制到本地。在基礎服務應用獲得實時數據後，轉入正常狀態，並通知事務處理層本地的基礎服務應用可以提供服務，之後激活外部接口API層。如果啟動的基礎服務應用具有更高的運行級別，則在統一實時數據後，會重新建立分布式管理層之間的信道。
3.2 分布式管理層實現持久性服務
由於企業系統基於高速局域網，系統性能、調度管理、內存管理、數據統一的通信瓶頸和速度已經不是影響應用服務持久性的關鍵問題。依據企業系統具有操作復雜頻繁，系統更新頻率高等特點，同時在開發系統過程中也認識到，影響服務持久性的因素主要是節點故障。
基礎服務應用在分布式處理上，節點狀態變化至關重要，節點狀態變化可以有如下幾類：
一個新的節點加入分布式實時系統，該節點的服務級別小於運行的主基礎服務應用。
一個新的節點加入分布式實時系統，但該節點的服務級別大於運行的主基礎服務應用。
一個節點離開分布式實時系統，該節點中的基礎服務應用不是主基礎服務應用。
一個節點離開分布式實時系統，但該節點中的基礎服務應用是主基礎服務應用。
一個運行的節點加入分布式實時系統，該節點的服務級別小於運行的主基礎服務應用。
一個運行的節點加入分布式實時系統，但該節點的服務級別大於運行的主基礎服務應用。
第一類中，新節點中的基礎服務應用是圖2狀態圖中右邊狀態圖的反映，對於整個系統不會有狀態的影響。
第二類中，新節點中的基礎服務應用是圖2狀態圖中左邊狀態圖的反映，這時會重新建立所有節點的基礎服務應用中分布式管理層之間的信道，在新節點獲得實時數據後，將切斷與目前與主基礎服務應用的應用。各個基礎服務應用分布式管理層的主服務應用決策模塊將根據節點的運行級別計算出主基礎服務應用，然後重新與主基礎服務應用建立信道。這個過程由於不影響實時數據的內容，所以是一個平滑的過程，對於上層應用是透明的。
第三、四類的情況要復雜一些，因為一個節點退出，該節點提供的對象將不再能提供服務。在第三類情況下，主基礎服務應用首先收到一個信道切斷通知，然後將改變該節點的對象引用的狀態，一方面啟動通知服務，通知使用該對象引用的各個上層應用，另一方面也把該事件傳遞給其它節點的基礎服務應用。第四類情況下，隨著主基礎服務應用心跳信息的丟失，分布式管理層自動觸發主服務應用決策模塊，啟動一個新的主基礎服務應用。然後啟動節點丟失的各個動作。可以看出，這兩類情況不會出現實時數據的沖突問題，也基本上是一個平滑的過程。
第五、六類的情況是兩種嚴重的故障。一個運行的節點加入分布式實時系統，意味這系統內瞬間出現兩個可能存在差異的實時數據庫，因為這時有兩個主基礎服務應用。產生這種情況的原因可能是一個節點的網絡出現短暫故障或長久故障而後網絡恢復的結果。也有可能一個系統中連接兩個交換機的集連線或路由出現故障，一段時間後又恢復的結果。這種故障下，需要統一實時數據庫。統一的過程不是將兩個數據庫合並的過程，因為它們提供的實時服務可能有沖突。統一的方法依據對象的屬性而分別處理，一般對象分為獨立對象和冗余對象兩類。獨立對象由僅一個節點提供，例如節點對象。冗余對象由至少兩個應用提供，這些對象作為主備冗余角色存在於系統內。對於獨立對象類，完全可以合並。而冗余對象則要根據分隔的兩個系統的狀態決定如何處理，如果冗余對象只存在於一個分隔的系統中，則可以合並，而如果分隔的系統中均存在冗余對象且被引用，則系統將注銷該對象和對象引用，通知用戶應用重新創建該對象和引用對象。此種情況下的主基礎服務應用狀態圖如下所示：
圖3 多個主基礎服務應用沖突時運行狀態圖
主基礎服務應用首先進入凍結狀態，此時通知上層的用戶應用該狀態的變化。分布式管理層的主服務應用決策模塊將根據運行級別快速決定出一個主基礎服務應用，主基礎服務應用接收另一個實時對象庫的內容，根據對象的屬性分別作出處理，以統一對象數據庫。解除凍結狀態中，激活API層，以一個reset事件通知對象的創建者應用和對象引用的應用。另一個實時對象數據庫的主基礎服務應用將建立與主基礎服務應用的信道，統一數據庫後，轉入一般基礎服務應用運行狀態。
在判斷節點故障中，有一個重要的參數，即節點丟失超時時間timeout。該值的大小要根據系統的具體環境決定。如果該值太小，則在信道中那些屬於正常范圍的數據包丟失和瞬時故障均可能被判斷成節點丟失，會頻繁引起系統抖動。而如果該值太大，則節點丟失後，會在較長的時間內無法判斷節點是否丟失，影響系統的實時要求。因此，該值可以設置為一個略大於瞬時故障周期的值。瞬時故障周期值依賴於操作系統和網絡設備的網絡恢復timeout、主基礎服務應用的心跳周期、實時性的具體要求等。
4 結束語
基礎服務應用在企業分布式系統統中可以為用戶提供實時的分布式對象引用，實時的向用戶應用通知系統的實時軟件或硬件故障，以便使得用戶應用作出及時的故障處理和報警工作。它的持久性體現了軟故障自動處理和硬件故障及時通知用戶應用和提醒用戶及時處理的實時特征，同時也提供了用戶應用自動故障恢復的機制。可以說，基礎服務應用為企業的核心實時系統提供了一個較好的運行方案
