本發(fā)明涉及一種分布式通信中間件技術，尤其是涉及一種可在規(guī)模較大的多臺主機上，多個應有程序中使用服務名進行相互通信的應用于靜態(tài)集群上的分布式通信系統(tǒng)及方法。

背景技術：

在傳統(tǒng)的信息系統(tǒng)中，隨著信息化的深入，信息系統(tǒng)的規(guī)模在不斷的擴大。例如，面向交通行業(yè)的軟件，因為線路的不斷建設、信息化的深入、互聯(lián)互通的需求等原因，系統(tǒng)規(guī)模不斷擴大，需要相互通信的主機規(guī)模甚至達到了千臺級別。為了解決大規(guī)模集群的通信問題，產(chǎn)生了分布式消息隊列技術。但是分布式消息隊列技術的實現(xiàn)大部分是面向互聯(lián)網(wǎng)行業(yè)的開源實現(xiàn)，應用于傳統(tǒng)行業(yè)軟件會有功能、性能、運維、授權協(xié)議等一系列問題。

隨著業(yè)務的發(fā)展，系統(tǒng)規(guī)模不斷擴大，呈現(xiàn)出分布式與集群等特點。系統(tǒng)中一部分業(yè)務模塊需要使用多臺主機組成一個集群才能完成業(yè)務。另一部分業(yè)務模塊需要分布在多臺主機上，甚至多地多臺主機上進行工作，主機既需要相互通信，又不能因為局部、或者大部分出問題而影響其他部分。在這樣的技術需求背景下，如果繼續(xù)使用傳統(tǒng)的客戶端、服務端通信模型進行軟件開發(fā)，設計、開發(fā)、維護的難度都非常巨大。

技術實現(xiàn)要素：

本發(fā)明的發(fā)明目的是為了克服現(xiàn)有技術中的現(xiàn)有業(yè)務需求下分布在一定規(guī)模主機上的多個應用程序無法進行高性能通信的不足，提供了一種可在規(guī)模較大的多臺主機上，多個應用進程中使用服務名進行相互通信的用于靜態(tài)集群上的分布式通信系統(tǒng)及方法。

為了實現(xiàn)上述目的，本發(fā)明采用以下技術方案：

一種應用于靜態(tài)集群上的分布式通信系統(tǒng)，在包括N臺主機，m個應用服務進程的靜態(tài)集群上，服務于該靜態(tài)集群的分布式通信系統(tǒng)包括設于每臺主機上的天使服務進程，極速配置庫和m個天使客戶端庫；每個應用服務進程均調對應的用天使客戶端庫，天使服務進程和各個應用服務進程均與極速配置庫連接，天使服務進程分別與各個應用服務進程連接，N≥1，m≥2；

極速配置庫中設有應用服務進程信息表與天使服務進程信息表；

應用服務進程信息表由4個字段構成，4個字段分別為應用服務進程服務名，應用服務進程編號，應用服務進程對應的天使服務進程編號和應用服務進程在線狀態(tài)；其中，應用服務進程服務名是應用服務進程信息表的主鍵；應用服務進程在線狀態(tài)字段是動態(tài)字段，應用服務進程根據(jù)應用服務進程與天使服務進程之間的連接狀態(tài)進行更新，其它字段均為靜態(tài)字段；

天使服務進程信息表由5個字段構成，5個字段分別為天使服務進程地址信息，天使服務進程編號，天使服務進程附屬應用服務進程起始編號，天使服務進程附屬應用服務進程個數(shù)和天使服務進程在線狀態(tài)；天使服務進程地址信息是天使服務進程信息表的主鍵，天使服務進程為動態(tài)字段，天使服務進程在線狀態(tài)根據(jù)本地天使服務進程與其它天使服務進程之間的連接狀態(tài)進行更新，同時更新的包括天使服務進程附屬的應用服務進程在線狀態(tài)。

本發(fā)明解決了分布在一定規(guī)模主機上的多個應用程序進行高性能相互通信的問題，提供了一種在規(guī)模較大的多臺主機上，多個應有程序可以使用服務名進行相互通信中間件系統(tǒng)。本發(fā)明使用簡單，對用戶友好。

在一個應用服務進程需要與多個應用服務進程進行通信的時候，如果使用客戶端、服務端模型，應用服務進程需要管理多個連接，操作復雜，且隨著需要相互通信的應用服務進程數(shù)量的增多，開發(fā)復雜度快速上升；如果整個集群中這種需要相互通信的應用服務進程數(shù)量特別多，將消耗比較多的系統(tǒng)資源。

相對于客戶端、服務端通信模型，本發(fā)明可以按照服務名進行通信。

現(xiàn)有的開源消息技術基本只支持三臺主機以上的集群；開源消息隊列技術在集群中N/2+1臺機器出現(xiàn)網(wǎng)絡故障或者主機故障時便不能進行通信；開源消息隊列技術在集群規(guī)模越來越大的時候，通信效率呈現(xiàn)下降；開源消息隊列技術在集群出現(xiàn)分裂時，處于少數(shù)的主機不能使用消息隊列；開源消息隊列面臨遵守開源協(xié)議的問題，需要面對動態(tài)集群技術，實現(xiàn)復雜度高、效率低，

相對于開源消息隊列技術，本發(fā)明可以適應一臺、兩臺到多臺主機的集群，在集群規(guī)模變大時，通信效率保持穩(wěn)定；少數(shù)的主機之間依舊可以通信；本發(fā)明面對靜態(tài)集群環(huán)境，實現(xiàn)簡單，效率高。

一種應用于靜態(tài)集群上的分布式通信系統(tǒng)的方法，包括關系表的插入過程：關系表為應用服務進程信息表或天使服務進程信息表；

步驟1：從要插入行的行內(nèi)容中取出主鍵內(nèi)容；

步驟2：對主鍵進行哈希計算，得到哈希值；

步驟3：在哈希區(qū)尋找與哈希值對應節(jié)點的位置，如果該節(jié)點沒有被使用，轉入步驟4，如果該節(jié)點已經(jīng)被使用，轉入步驟6；

步驟4：在節(jié)點內(nèi)寫入節(jié)點信息，節(jié)點信息包括主鍵、行號和下個節(jié)點偏移；其中，行號為關系表的表頭中的待插入行號，表頭包括行數(shù)目；

步驟5：將行內(nèi)容寫入待插入行號的行，待插入行號加1；

步驟6：按照節(jié)點信息中下一個節(jié)點偏移信息，依次尋找下一個節(jié)點，直到下一個節(jié)點偏移為-1，將-1改為拉鏈區(qū)可用節(jié)點偏移，在拉鏈區(qū)可用偏移的位置上，寫入節(jié)點信息，將拉鏈區(qū)可用偏移號加1；

步驟7：將行內(nèi)容寫入待插入行號的行，待插入行號加1；

其中，哈希計算包括如下步驟：

步驟1：采用公用的哈希算法對主鍵進行哈希，得到一個整數(shù)；

步驟2：將整數(shù)對行數(shù)目取余，得到一個哈希值。

作為優(yōu)選，還包括查詢的過程：

步驟1：對查詢主鍵進行哈希計算，得到哈希值；

步驟2：在哈希區(qū)尋找與哈希值對應節(jié)點的位置，比較節(jié)點的主鍵內(nèi)容與查詢主鍵內(nèi)容是否相同，相同時取節(jié)點中記錄的行號信息；不相同時，取下一個節(jié)點的偏移；

步驟3：按照下一個節(jié)點的偏移，依次比較節(jié)點的主鍵與查詢主鍵是否相同，直到找到相同的節(jié)點，取該節(jié)點中記錄的行號信息；

步驟4：如果沒有找到行號信息，查詢失??；

其中，哈希計算包括如下步驟：

步驟1：采用公用的哈希算法對主鍵進行哈希，得到一個整數(shù)；

步驟2：將整數(shù)對行數(shù)目取余，得到一個哈希值。

作為優(yōu)選，還包括在線狀態(tài)同步觸發(fā)步驟：

步驟1：取當前系統(tǒng)時間，將當前系統(tǒng)時間減去上一次的系統(tǒng)時間，得到時間差；

若時間差＞1秒，轉入步驟2；

若時間差≤1秒，則睡眠100毫秒，循環(huán)執(zhí)行步驟1；

步驟2：檢測事件觸發(fā)標志是否為1，或者是否到了同步周期；如果是，轉入步驟3；否則，繼續(xù)執(zhí)行步驟2；

步驟3：將事件觸發(fā)標志修改為0，執(zhí)行在線狀態(tài)同步過程；

步驟4：將上一次系統(tǒng)時間賦值為獲取的當前系統(tǒng)時間，將周期時間賦值為當前系統(tǒng)時間加周期值，繼續(xù)執(zhí)行步驟1。

作為優(yōu)選，還包括在線狀態(tài)同步過程：

步驟1：天使服務進程從極速配置庫中讀取附屬于自己的應用服務進程的在線狀態(tài)；

步驟2：天使服務進程將附屬于自己的應用服務進程的在線狀態(tài)進行壓縮，構成一個在線狀態(tài)更新包；

步驟3：向其他的所有主機的天使服務進程發(fā)送自己附屬的應用服務進程的在線狀態(tài)更新包；

步驟4：接收到在線狀態(tài)更新包的天使服務進程，解壓縮在線狀態(tài)更新包，修改本地的極速配置庫。

作為優(yōu)選，還包括應用服務進程登錄過程：

步驟1：在主機i上，應用服務進程j在天使服務進程i上登錄，應用服務進程j調用天使客戶端庫的登錄接口，傳入自己的服務名jX；i＝1，2，…，N；j＝1，2，…，m；

步驟2：天使服務進程i接到應用服務進程j登錄請求，按照服務名j查詢查詢本地極速配置庫；

如果查到極速配置庫里面存在該服務的配置，返回應用服務進程j的編號及登錄成功的信息，修改極速配置庫內(nèi)應用服務進程j的登錄狀態(tài)為已經(jīng)登錄，轉入步驟3；

如果沒有查到極速配置庫里面存在該服務的配置，返回-1及登錄失敗的信息；

步驟3：天使服務進程i將應用服務進程j的已登錄狀態(tài)廣播發(fā)送給天使服務進程2到N；

天使服務進程2至天使服務進程N收到應用服務進程j的已登錄狀態(tài)，分別轉入步驟4；

步驟4：天使服務進程2至天使服務進程N將應用服務進程j的已登錄狀態(tài)寫入本地極速配置庫。

作為優(yōu)選，還包括應用服務進程之間通信過程：

應用服務進程j向應用服務進程k發(fā)送一個消息；k＝1，2，…，m；k≠j；

步驟1：應用服務進程j通過本地極速配置庫，按照應用服務進程k的服務名，查詢應用服務進程k的編號與在線狀態(tài)；若查詢到應用服務進程的編號且應用服務進程的在線狀態(tài)為在線，轉入步驟2；反之，返回失敗信息，通信結束；

步驟2：應用服務進程j構建消息包，向天使服務進程i發(fā)送該消息包；

步驟3：天使服務進程i收到該消息包，按照該消息包包頭內(nèi)容，查詢極速配置庫，查出應該轉發(fā)的目標天使進程N，并查詢目標天使進程N的在線狀態(tài)；

步驟4：天使服務進程i將消息包發(fā)送給天使服務進程N；

步驟5：天使服務進程N收到該消息包，按照該消息包包頭內(nèi)容，查詢極速配置庫，查出應用服務進程k；

步驟6：天使服務進程N將消息包發(fā)送給應用服務進程k。

因此，本發(fā)明具有如下有益效果：可以適應一臺、兩臺到多臺主機的集群，在集群規(guī)模變大時，通信效率保持穩(wěn)定；在靜態(tài)集群出現(xiàn)故障時，即使故障范圍涉及了大部分主機，少數(shù)沒被涉及的主機之間依舊可以通信；本發(fā)明面對靜態(tài)集群環(huán)境，實現(xiàn)簡單，效率高。

附圖說明

圖1為本發(fā)明的一種結構示意圖；

圖2為本發(fā)明的極速配置庫的一種結構圖；

圖3為本發(fā)明的極速配置庫的表頭的一種結構圖；

圖4本發(fā)明的極速配置庫中表的索引結構與索引方法的一種示意圖；

圖5本發(fā)明的極速配置庫中表數(shù)據(jù)的一種分布方式圖；

圖6為本發(fā)明的對等輻射網(wǎng)絡的一種結構圖；

圖7為本發(fā)明的應用服務進程在線狀態(tài)的一種周期同步過程圖；

圖8本分明的在網(wǎng)絡分裂狀況下的一種可靠性分析圖；

圖9為本發(fā)明的天使客戶端庫接口的一種圖。

圖中：主機2、天使服務進程21、極速配置庫22、應用服務進程23、天使客戶端庫24。

具體實施方式

下面結合附圖和具體實施方式對本發(fā)明做進一步的描述。

如圖1所示的實施例是一種應用于靜態(tài)集群上的分布式通信系統(tǒng)，在包括N臺主機2，20個應用服務進程23的靜態(tài)集群上，服務于該靜態(tài)集群的分布式通信系統(tǒng)包括設于每臺主機上的天使服務進程21，極速配置庫22和20個天使客戶端庫24；20個應用服務進程分別調用20個天使客戶端庫，天使服務進程和各個應用服務進程均調用極速配置庫，天使服務進程分別與各個應用服務進程連接；

如圖2所示，極速配置庫中設有應用服務進程信息表與天使服務進程信息表；

應用服務進程信息表由4個字段構成，4個字段分別為應用服務進程服務名，應用服務進程編號，應用服務進程對應的天使服務進程編號和應用服務進程在線狀態(tài)；其中，應用服務進程服務名是應用服務進程信息表的主鍵；應用服務進程在線狀態(tài)字段是動態(tài)字段，會根據(jù)應用服務進程與天使服務進程之間的連接狀態(tài)進行更新；

其它字段均為靜態(tài)字段；靜態(tài)字段在一個靜態(tài)集群確定的時候就已經(jīng)確定，不會在運行期動態(tài)變化。應用服務進程服務名可以按照服務名進行快速查詢。應用服務進程的編號使用連續(xù)數(shù)字順序編號，對應應用服務進程在應用服務進程信息表中的行號，且將同一臺主機上的應用服務進程連續(xù)編號。只有應用服務進程在線狀態(tài)是根據(jù)實際情況動態(tài)更新的字段。

天使服務進程信息表由5個字段構成，5個字段分別為天使服務進程地址信息，天使服務進程編號，天使服務進程附屬應用服務進程起始編號，天使服務進程附屬應用服務進程個數(shù)和天使服務進程在線狀態(tài)；天使服務進程地址信息是天使服務進程信息表的主鍵，可以按照地址快速查詢。天使服務進程編號使用連續(xù)數(shù)字順序編號，對應天使服務進程信息表的行號。天使服務進程地址信息是主鍵，

天使服務進程附屬的應用服務進程是與天使服務進程在同一臺主機上，使用天使客戶端庫直接連接在天使服務進程上的應用服務進程。天使服務進程為動態(tài)字段，天使服務進程在線狀態(tài)，是根據(jù)本地天使服務進程與其他天使服務進程之間的連接狀態(tài)進行更新的，同時更新的包括天使服務進程附屬的應用服務進程在線狀態(tài)。

兩張表中的在線狀態(tài)字段是動態(tài)變化的，但是變化不頻繁，表中使用一個字節(jié)表示在線狀態(tài)，同時使用0表示在線，其他任何值均表示離線，所以變化字段無需加鎖，整個極速配置庫變可以使用無鎖設計。極速配置庫使用共享內(nèi)存進行實現(xiàn)，且使用無鎖設計，根據(jù)上述特點，極速配置庫可以提供內(nèi)存級別的訪問速度。

如圖3、圖5所示，還包括關系表的插入過程：

步驟1：從要插入行的行內(nèi)容中取出主鍵內(nèi)容；

步驟2：對主鍵進行哈希計算，得到哈希值；

步驟3：在哈希區(qū)尋找與哈希值對應節(jié)點的位置，如果該節(jié)點沒有被使用，轉入步驟4，如果該節(jié)點已經(jīng)被使用，轉入步驟6；

步驟4：在節(jié)點內(nèi)寫入節(jié)點信息，節(jié)點信息包括主鍵、行號和下個節(jié)點偏移；其中，行號為關系表的表頭中的待插入行號，表頭包括行數(shù)目；

步驟5：將行內(nèi)容寫入待插入行號的行，待插入行號加1；

步驟6：按照節(jié)點信息中下一個節(jié)點偏移信息，依次尋找下一個節(jié)點，直到下一個節(jié)點偏移為-1，將-1改為拉鏈區(qū)可用節(jié)點偏移，在拉鏈區(qū)可用偏移的位置上，寫入節(jié)點信息，將拉鏈區(qū)可用偏移號加1；

步驟7：將行內(nèi)容寫入待插入行號的行，待插入行號加1；

其中，哈希計算包括如下步驟：

步驟1：采用公用的哈希算法對主鍵進行哈希，得到一個整數(shù)；

步驟2：將整數(shù)對行數(shù)目取余，得到一個哈希值。

如圖4、圖5所示，還包括查詢的過程：

步驟1：對查詢主鍵進行哈希計算，得到哈希值；

步驟2：在哈希區(qū)尋找與哈希值對應節(jié)點的位置，比較節(jié)點的主鍵內(nèi)容與查詢主鍵內(nèi)容是否相同，相同時取節(jié)點中記錄的行號信息；不相同時，取下一個節(jié)點的偏移；

步驟3：按照下一個節(jié)點的偏移，依次比較節(jié)點的主鍵與查詢主鍵是否相同，直到找到相同的節(jié)點，取該節(jié)點中記錄的行號信息；

步驟4：如果沒有找到行號信息，查詢失??；

其中，哈希計算包括如下步驟：

步驟1：采用公用的哈希算法對主鍵進行哈希，得到一個整數(shù)；

步驟2：將整數(shù)對行數(shù)目取余，得到一個哈希值。

如圖6所示，分布在集群中每一臺機器上的天使服務進程均連接其他所有主機上的天使服務進程，構成一個每一臺主機上都對等的輻射形狀的網(wǎng)絡結構。第1天使服務進程在連接第2天使服務進程至第N天使服務進程的同時，接收第2天使服務進程至第N天使服務進程的連接。

對等輻射網(wǎng)絡上每一個天使服務進程管理的連接數(shù)目都是2*(N-1)；任意兩臺主機都使用天使服務進程直接連接；任意兩個分布在不同主機上的應用服務進程之間的通信都是使用兩個主機之間的天使服務進程進行轉發(fā)通信。在對等輻射網(wǎng)絡的網(wǎng)絡結構上，沒有任何一個天使服務進程節(jié)點會成為性能瓶頸，也沒有一個天使服務進程會成為主要節(jié)點，而影響不相關的應用服務進程之間的通信。由于本地進程間通信的與網(wǎng)絡通信的速度相比是非?？焖俚模员镜靥焓狗者M程也不會成為應用服務進程通信的瓶頸，因為更先到達瓶頸的是網(wǎng)絡通信速度。如果達到網(wǎng)絡通信的速度瓶頸，即使使用客戶端、服務端的傳統(tǒng)通信模式也不能提高速度。

在線狀態(tài)同步觸發(fā)方式分為兩種：

周期觸發(fā)在線狀態(tài)同步；

事件觸發(fā)在線狀態(tài)同步。周期觸發(fā)的在線狀態(tài)同步，是為防止異常情況的出現(xiàn)，一種可以從任何出錯情況下自修復策略。不管出現(xiàn)任何沒有預料到的異常，只要經(jīng)過一個周期，系統(tǒng)就可以從錯誤中恢復，回到正?？蛇\行狀態(tài)。每隔一個周期執(zhí)行一次，周期可配置，最短周期一秒。事件觸發(fā)的在線狀態(tài)同步，是在應用服務進程調用登錄接口、調用登出接口、異常退出三種情況下，修改在事件觸發(fā)標志為1(注意，不是直接觸發(fā)在線狀態(tài)同步)。兩種觸發(fā)方式結合在一起，得到下述在線狀態(tài)同步觸發(fā)步驟。

如圖7所示，還包括在線狀態(tài)同步觸發(fā)步驟：

步驟1：取當前系統(tǒng)時間，將當前系統(tǒng)時間減去上一次的系統(tǒng)時間，得到時間差；

若時間差＞1秒，轉入步驟2；

若時間差≤1秒，則睡眠100毫秒，循環(huán)執(zhí)行步驟1；

步驟2：檢測事件觸發(fā)標志是否為1，或者是否到了同步周期；如果是，轉入步驟3；否則，繼續(xù)執(zhí)行步驟2；

步驟3：將事件觸發(fā)標志修改為0，執(zhí)行在線狀態(tài)同步過程；

步驟4：將上一次系統(tǒng)時間賦值為獲取的當前系統(tǒng)時間，將周期時間賦值為當前系統(tǒng)時間加周期值，繼續(xù)執(zhí)行步驟1。

可以看出，事件觸發(fā)方式是合并進周期觸發(fā)方式中進行處理的，發(fā)生事件觸發(fā)的時候，僅修改事件觸發(fā)標志。這樣做的好處是，在發(fā)生應用服務進程調用登錄接口等事件的時候，最多1秒之后，應用服務進程的在線狀態(tài)將被同步，保持了系統(tǒng)的靈敏性。而且避免了如果某些應用服務進程發(fā)生異?；蚱渌闆r引起的頻繁的登錄、登出調用，導致在線狀態(tài)同步太頻繁，從而沖擊整個系統(tǒng)。因為無論如何頻繁的發(fā)生觸發(fā)事件，在線狀態(tài)同步過程最多每秒觸發(fā)一次。

還包括在線狀態(tài)同步過程：

步驟1：天使服務進程從極速配置庫中讀取附屬于自己的應用服務進程的在線狀態(tài)；

步驟2：天使服務進程將附屬于自己的應用服務進程的在線狀態(tài)進行壓縮，構成一個在線狀態(tài)更新包；

步驟3：向其他的所有主機的天使服務進程發(fā)送自己附屬的應用服務進程的在線狀態(tài)更新包；

步驟4：接收到在線狀態(tài)更新包的天使服務進程，解壓縮在線狀態(tài)更新包，修改本地的極速配置庫。

壓縮的方法如下：因為靜態(tài)集群的特點，附屬于同一個天使服務進程的多個應用服務進程在編號上是連續(xù)的，可以使用一個字符數(shù)組表示在線狀態(tài)，按照順序字符數(shù)組每一個字節(jié)的每一位對應一個應用服務進程的在線狀態(tài)。由于極速配置庫中已經(jīng)有天使服務進程對應的應用服務進程的起始編號與個數(shù)，所以不需要傳輸額外的其他信息，既可以進行解壓縮。例如天使服務進程1附屬5個應用服務進程，一個字節(jié)有8個比特位，使用一個字節(jié)就可以表示5個應用服務進程的在線狀態(tài)。使用上述壓縮方法，可以使用極少的字節(jié)，表示更多的信息。

使用本發(fā)明的應用服務進程在線狀態(tài)的同步方法，在一個1000臺主機，每臺主機上80個應用服務進程的靜態(tài)集群上，采用10秒為一個周期。在系統(tǒng)穩(wěn)定運行期間，每一臺主機上為保持應用服務進程在線狀態(tài)同步所耗用的網(wǎng)絡帶寬是1000個字節(jié)/秒(計算方法(80/8*1000)/10)，按照帶寬為百兆的系統(tǒng)計算，損耗的資源只有不足萬分之一。即使在系統(tǒng)徹底動蕩期間，所耗用的最大帶寬也只有10000字節(jié)/秒，按照百兆系統(tǒng)計算也不足千分之一，況且這種情況幾乎不會出現(xiàn)。所以使用這種同步方法，對于資源的損耗非常小，同步的速度穩(wěn)定，且具有自修復能力，可以從錯誤中恢復。

還包括應用服務進程登錄過程：

步驟1：在主機i上，應用服務進程j在天使服務進程i上登錄，應用服務進程j調用天使客戶端庫的登錄接口，傳入自己的服務名jX；i＝1，2，…，N；j＝1，2，…，m；

步驟2：天使服務進程i接到應用服務進程j登錄請求，按照服務名j查詢查詢本地極速配置庫；

如果查到極速配置庫里面存在該服務的配置，返回應用服務進程j的編號及登錄成功的信息，修改極速配置庫內(nèi)應用服務進程j的登錄狀態(tài)為已經(jīng)登錄，轉入步驟3；

如果沒有查到極速配置庫里面存在該服務的配置，返回-1及登錄失敗的信息；

步驟3：天使服務進程i將應用服務進程j的已登錄狀態(tài)廣播發(fā)送給天使服務進程2到N；

天使服務進程2至天使服務進程N收到應用服務進程j的已登錄狀態(tài)，分別轉入步驟4；

步驟4：天使服務進程2至天使服務進程N將應用服務進程j的已登錄狀態(tài)寫入本地極速配置庫。

還包括應用服務進程之間通信過程：

應用服務進程j向應用服務進程k發(fā)送一個消息；k＝1，2，…，m；k≠j；

步驟1：應用服務進程j通過本地極速配置庫，按照應用服務進程k的服務名，查詢應用服務進程k的編號與在線狀態(tài)；若查詢到應用服務進程的編號且應用服務進程的在線狀態(tài)為在線，轉入步驟2；反之，返回失敗信息，通信結束；

步驟2：應用服務進程j構建消息包，向天使服務進程i發(fā)送該消息包；

步驟3：天使服務進程i收到該消息包，按照該消息包包頭內(nèi)容，查詢極速配置庫，查出應該轉發(fā)的目標天使進程N，并查詢目標天使進程N的在線狀態(tài)；

步驟4：天使服務進程i將消息包發(fā)送給天使服務進程N；

步驟5：天使服務進程N收到該消息包，按照該消息包包頭內(nèi)容，查詢極速配置庫，查出應用服務進程k；

步驟6：天使服務進程N將消息包發(fā)送給應用服務進程k。

如圖8所示，因為網(wǎng)絡故障，導致進群分裂，分裂為2臺與3臺兩個部分，在這種情況下，本通信中間件依舊可以使用。

當出現(xiàn)如圖8所示的分裂的時候，如果使用開源消息隊列技術，下面一半主機數(shù)目為2，將不能進行通信，上面主機數(shù)目為3，可以進行通信。如果上半部分再出現(xiàn)一臺主機故障，上半部分也不能進行通信。

設左上方的應用服務進程為X，右上方的應用服務進程為Y，左下方的應用服務進程為F，右下方的應用服務進程為G；

本發(fā)明不存在這個問題，應用服務進程X與應用服務進程Y之間可以進行通信，應用服務進程F與應用服務進程G也可以進行通信。應用服務進程X與應用服務進程F不能進行通信的原因是因為網(wǎng)絡或硬件故障，在物理上不具有連通性，與通信中間件無關，通信中間件提供了最大可能的可靠性。本例只是列舉其中一種故障情況下本通信中間件的可靠性，其他類似的狀況與故障不再一一列舉。

如圖9所示，天使客戶端庫提供了服務登錄、登出、消息發(fā)送，消息接收回調四個接口，且只有四個接口，向應用服務進程提供了簡單的使用方式。

應理解，本實施例僅用于說明本發(fā)明而不用于限制本發(fā)明的范圍。此外應理解，在閱讀了本發(fā)明講授的內(nèi)容之后，本領域技術人員可以對本發(fā)明作各種改動或修改，這些等價形式同樣落于本申請所附權利要求書所限定的范圍。