專利名稱：一種基于Spread分布式應用系統(tǒng)的熱加載方法
技術領域：
本發(fā)明涉及分布式應用系統(tǒng)技術領域，具體涉及一種基于spread消息總線的分布式應用系統(tǒng)的熱加載技術。
背景技術：
分布式應用系統(tǒng)，是目前在企業(yè)級應用中普遍采用的一種軟件系統(tǒng)架構，應用系統(tǒng)按功能被切分成多個模塊，部署在若干獨立的計算機上，模塊之間通過某種消息機制進行信息交互，協(xié)同完成工作。spread，是一套開源工具包，可以作為一個分布式應用系統(tǒng)的消息總線，提供高可靠性、高性能、支持異構環(huán)境的分布式分組消息傳遞，詳見http: //www. spread, cxtr/。在一個典型的環(huán)境中，通常每臺服務器上運行一個spread server，各服務器上的應用本地連接server,發(fā)送消息到指定組,而這臺服務器上的spread server會傳遞消息給其他訂閱該組消息的應用。由于spread作為消息總線所體現(xiàn)的突出優(yōu)勢，因此,基于spread的分布式應用系統(tǒng)是目前廣泛采用的一種分布式應用系統(tǒng)架構。典型的一類分布式應用系統(tǒng)如圖1所示，就是將各接口模塊和內部處理(非接口)模塊分離，通過spread消息總線的分組傳遞實現(xiàn)模塊之間的數(shù)據(jù)交互。由于這種架構具有高度的靈活性且模塊劃分明晰，因此對于那些接口眾多、業(yè)務邏輯變化較快的應用系統(tǒng)來說特別適用。這類應用有一個特點接口模塊相對穩(wěn)定，內部業(yè)務處理(非接口)模塊由于業(yè)務上“隨需而變”的要求，升級比較頻繁。傳統(tǒng)的內部處理模塊程序升級是先停止原模塊進程，然后啟動新模塊進程，這種升級方式必然導致應用的中斷，對于那些有7*24小時嚴格要求的企業(yè)級應用來說是無法容忍的。

發(fā)明內容
本發(fā)明所要解決的技術問題是為基于spread消息總線的分布式應用系統(tǒng)，提供一種新的內部處理(非接口)模塊的程序熱加載方法，用于實現(xiàn)不中斷業(yè)務應用的程序升級。本發(fā)明解決上述技術問題的技術方案如下一種基于spread分布式應用系統(tǒng)的熱加載方法，包括以下步驟步驟1:部署常駐在內存的升級消息監(jiān)聽模塊，并將其連接至指定的Spread消息組；步驟2 :啟動新版本模塊,將新版本模塊連接到一個新的Spread消息組,并讓新版本模塊與原版本模塊并運行；步驟3 :啟動升級消息發(fā)布模塊，發(fā)送原版本模塊的升級消息至升級消息監(jiān)聽模塊；步驟4 :升級消息監(jiān)聽模塊接收到原版本模塊的升級消息后，將原版本模塊對應的Spread消息組名切換成新版本模塊對應的Spread消息組名，并將切換結果反饋給升級消息發(fā)布模塊；步驟5 :升級消息發(fā)布模塊收到所有反饋結果后，提示升級成功，并退出運行；步驟6 :在確保原版本模塊將Spread消息組切換前收到的所有消息處理完成后，停止原版本模塊的運行,完成熱加載過程。在上述技術方案的基礎上，本發(fā)明還可以做如下改進。進一步，所述步驟3具體包括啟動升級消息發(fā)布模塊，讀取原版本模塊信息，將原版本模塊信息組成原版本模塊的升級消息，并發(fā)送至升級消息監(jiān)聽模塊。進一步，所述原版本模塊信息包括原版本模塊連接的Spread消息組在共享內存中的索引名和新版本模塊連接的Spread消息組名。進一步，所述方法中各模塊間通信的數(shù)據(jù)保存在共享內存或共享物理存儲機制中，且所述共享物理機制包括數(shù)據(jù)庫和文件。進一步，執(zhí)行所述步驟4后，還包括向原版本模塊發(fā)送消息時，會根據(jù)共享內存中更新的原版本模塊連接Spread消息組名，將消息由spread消息總線轉發(fā)到新版本模塊。進一步，所述步驟5中升級消息發(fā)布模塊將收到的反饋結果打印到控制臺上。本發(fā)明只針對分布式系統(tǒng)內部處理模塊，即非接口模塊，因為其基本原理是通過切換模塊間通信的spread消息組來完成進程切換，而接口模塊與外部系統(tǒng)的通信協(xié)議是不確定的，因此本發(fā)明不適用于接口模塊。在上述技術方案中，本發(fā)明中涉及的各模塊相當于應用進程。本發(fā)明的有益效果是主要有以下幾個方面的特點一、本發(fā)明適用的分布式應用系統(tǒng)，其模塊(進程)間的通信全部是通過spread消息總線完成，且模塊(進程)間通信的數(shù)據(jù)(包括通信使用的消息組名)會在共享內存(其他共享物理存儲亦可，如數(shù)據(jù)庫、文件等)中保存，以便新老模塊(進程)之間、模塊(進程)與升級監(jiān)聽進程之間可以共享數(shù)據(jù)。二、本發(fā)明通過引入模塊升級發(fā)布/監(jiān)聽進程，并配合共享內存技術的應用，達到了在分布式系統(tǒng)中將內部處理模塊升級消息發(fā)布到消息總線、通知其他模塊(進程)對升級模塊接收消息組進行切換的目的，實現(xiàn)了內部處理模塊在不中斷業(yè)務情況下的加載。三、本發(fā)明技術方案基于spread消息總線架構，其模塊(進程)間的通信全部是通過spread消息總線完成,具有跨平臺、跨語言的特性,各業(yè)務模塊可以部署在windows、unix、Iinux操作系統(tǒng)上，在可以用不同編程語目開發(fā)，如C語目、JAVA語目、Python語目
坐寸ο四、本發(fā)明不同于傳統(tǒng)的先停止原進程、再啟動新進程的加載方式，其加載方式是在不停止原進程的情況下，先啟動新進程，再通過一套升級消息發(fā)布/監(jiān)聽進程完成升級消息發(fā)布及升級模塊(進程)連接spread消息組切換，確保新老進程在并運行期間無縫完成功能切換，最后再停止原進程。


圖1為基于spread消息總線的分布式系統(tǒng)不意圖；圖2為本發(fā)明實施例中的分布式應用系統(tǒng)示意圖；圖3為本發(fā)明實施例中熱加載方法的流程示意圖4為本發(fā)明實施例在熱加載前的系統(tǒng)示意圖；圖5為本發(fā)明實施例中熱加載中的系統(tǒng)示意圖；圖6為本發(fā)明實施例中熱加載后的系統(tǒng)示意圖。
具體實施例方式以下結合附圖對本發(fā)明的原理和特征進行描述，所舉實例只用于解釋本發(fā)明，并非用于限定本發(fā)明的范圍。如圖2所示，本實施例中以一個簡單的分布式系統(tǒng)作為應用場景，若要在具有更多模塊的復雜分布式系統(tǒng)中應用，其方法的操作是相同的，只不過要部署更多的升級消息監(jiān)聽模塊。本實施例中，分布式系統(tǒng)分為兩個獨立模塊(進程)，即一個接口模塊(進程)IF, 一個業(yè)務處理模塊(進程)P，兩個模塊之間的通信由spread消息總線完成，IF連接到消息組G_IF_RCV, P連接到消息組G_P_RCV，分別用于接收各自的spread消息。如圖3所示，本實施例中的熱加載方法即是將業(yè)務處理模塊進程從P升級到PI，具體步驟為步驟1:如圖4所示，在接口模塊(進程)IF所在服務器的相同用戶下，部署常駐內存的升級消息監(jiān)聽進程Upd_Listener,連接到消息組G_UPD_SEND,用于接收模塊升級消
肩、O這里，步驟I是在第一次使用此方法時操作，今后按此方法做熱加載可直接從步驟2開始。步驟2 :在待升級模塊(即原版本模塊)P所在服務器的相同用戶下，啟動新業(yè)務處理模塊(即新版本模塊)P1，連接到新的Spread消息組G_P_RCV_1，與原版本模塊(進程)P并運行，但此時Pl并不參與系統(tǒng)業(yè)務處理，因為接口模塊(進程)IF還未收到升級通知，不會將消息發(fā)送到Pl連接的消息組G_P_RCV_1。步驟3 :啟動升級消息發(fā)布進程Upd_PubIisher,讀取待升級模塊信息,包括升級進程連接的消息組在共享內存中的索引名、新進程連接的消息組名(確保新組名唯一，不與已定義組名沖突)，組成模塊升級消息包，發(fā)送到消息組G_UPD_SEND，并連接到G_UPD_RCV消息組，接收反饋結果。這里，先將待升級模塊信息配置成升級發(fā)布配置文件(可參加下述的樣例)，進行熱加載時再從相應配置文件中讀取升級消息。步驟4 :升級消息監(jiān)聽進程Upd_Listener —旦接收到模塊升級消息,依據(jù)消息數(shù)據(jù)內容，對共享內存中升級模塊(進程)所連接的消息組名進行切換，并將結果通過spread返回給升級消息發(fā)布進程UpcLPublisher ;接口模塊(進程)IF后續(xù)向業(yè)務處理模塊發(fā)送消息時，會根據(jù)共享內存中更新的升級模塊連接的新消息組名，將請求發(fā)送到新的spread消息組G_P_RCV_1中，從而由spread將請求轉發(fā)到新版本模塊(進程)P1,此時新版本模塊(進程)Pl就真正參與到系統(tǒng)業(yè)務處理中。如圖5所示，為加載過程中的系統(tǒng)狀態(tài)，IF發(fā)送消息到P的虛線和IF發(fā)送消息到Pl實線反映了這個切換過程。步驟5 :升級消息發(fā)布進程UpcLPublisher從G_UPD_RCV消息組陸續(xù)收到各升級消息監(jiān)聽進程反饋的結果，并將結果打印到控制臺上，當收到預期數(shù)目的成功返回后，升級消息發(fā)布進程會提示升級成功，并退出。步驟6 :等待一定時間(確保原模塊進程將消息組切換前收到的所有請求完成處理，可通過日志記錄確認)后，停止原模塊(進程)P，如圖6所示，為加載完畢后的系統(tǒng)狀態(tài)，這標志一次完整的業(yè)務處理模塊程序熱加載過程結束。本實施例很好地解決了這種基于spread消息總線的分布式應用系統(tǒng)的內部處理模塊(非接口模塊)的熱加載問題，其實現(xiàn)需要將各步驟的技術方案編制成相應的程序，程序樣例主要有升級發(fā)布配置文件樣例、升級消息發(fā)布程序UpcLPublisher關鍵流程樣例和升級消息監(jiān)聽程序Upd_Listener關鍵流程樣例,如下所述一、升級發(fā)布配置文件樣例。#升級進程連接的消息組名在共享內存中的索引名Upd_Group_Key=l#新進程連接的消息組名Upd_Group_New=G_P_RCV_l#與升級進程有交互的進程個數(shù)(此例中只有I個接口模塊進程，因此配置為I)Upd_Count=l二、升級消息發(fā)布程序Upd_Publisher關鍵流程樣例。
//從UpdatePiiblish.1ni升級發(fā)布配置文件中讀取信息GetProfiIeString ("Upd-Group-Key", updGroupKey, “UpdatePublish.
9 \
ini );
GetProf i IeString (lfUpd-Group-New11, updGroupNew, “UpdatePubI i sh.mi );
GetProf i IeStr ing ("Upd-Count11, updCount, “UpdatePublish.1ni” );//初始化消息總線，并加入消息組G—UPD—RCV,用來接收升級消息進程返回的結果消息initMQ O;
JoinMsgGroupC “G_UPD_RCV” );
//構造模塊升級消息包
strcpy(groupSwitchNotifydata. updGroupKey, updGroupKey);strcpy(groupSwitchNotifydata. updGroupNew, updGroupNew);
//發(fā)送模塊升級消息至G-UPD-SEND
sendToMQC “G—UPD—SEND” , groupSwitchNotifydata); //阻塞監(jiān)聽消息組G_UPD_RCV，將收到的消息打印到控制臺，并判斷升級反饋個數(shù)while(l) {
int ret ■ rcvFroniMQ (&iRevDataLength, RevData); if ( 0 == ret) {
pr intf ( “-------\n , RevData);
if(isSuccessfulResult(groupSwitchNotifyRsp *)RevData))iCorrectResuIt-count++;
//判斷升級成功返回數(shù)目是否與預期一致，一致則退出If (ICorrectResult-count == Upd-Count)
break;

}
}
printf ( “升級完畢！ \n” );三、升級消息監(jiān)聽程序Upd_Listener關鍵流程樣例。
//初始化消息總線，加入G-UPD-SEND組 initMQO;
joinMsgGroup( “G_UPD_SEND” );
"在G-UPD-SEND組上阻塞監(jiān)聽升級發(fā)布消息 whi Ie (I) {
int ret = rcvFromMQ (ftiRevDataLength, RevData);
if (0 == ret) {
meaicpy (GroupSwi tchNot if y, RevDa ta，GROUPSWITCHNOTIFY-LEN); //獲取共享內存地址 UpdateShmAddr = getShmO ;
//將共享內存中的升級消息組進行切換*/ strcpy (updateShmAddr ->GroupKey [GroupSwitchNotify. updGroupKe
y],
GroupSwitchNot ify. updGroupNew);
//切換成功后，返回結果到G_UPD_RCV
sendToMQ (nG-UPD-RCVn, sizeof(ProgUpdateResp), (char
*) &resp);
}
}以上所述僅為本發(fā)明的較佳實施例，并不用以限制本發(fā)明，凡在本發(fā)明的精神和原則之內，所作的任何修改、等同替換、改進等，均應包含在本發(fā)明的保護范圍之內。
權利要求
1.一種基于spread分布式應用系統(tǒng)的熱加載方法,其特征在于,包括 步驟1:部署常駐在內存的升級消息監(jiān)聽模塊，并將其連接至指定的Spread消息組； 步驟2 :啟動新版本模塊,將新版本模塊連接到一個新的Spread消息組,并讓新版本模塊與原版本模塊并運行； 步驟3 :啟動升級消息發(fā)布模塊，發(fā)送原版本模塊的升級消息至升級消息監(jiān)聽模塊； 步驟4 :升級消息監(jiān)聽模塊接收到升級消息后，將原版本模塊對應的Spread消息組名切換成新版本模塊對應的Spread消息組名，并將切換結果反饋給升級消息發(fā)布模塊； 步驟5 :升級消息發(fā)布模塊收到所有反饋結果后，提示升級成功，并退出運行； 步驟6 :在確保原版本模塊將Spread消息組切換前收到的所有消息處理完成后，停止原版本模塊的運行，完成熱加載過程。
2.根據(jù)權利要求1所述的熱加載方法，其特征在于，所述步驟3具體包括啟動升級消息發(fā)布模塊，讀取原版本模塊信息，將原版本模塊信息組成原版本模塊的升級消息，并發(fā)送至升級消息監(jiān)聽模塊。
3.根據(jù)權利要求2所述的熱加載方法，其特征在于，所述原版本模塊信息包括原版本模塊連接的Spread消息組在共享內存中的索引名和新版本模塊連接的Spread消息組名。
4.根據(jù)權利要求1所述的熱加載方法，其特征在于，所述方法中各模塊間通信的數(shù)據(jù)保存在共享內存或共享物理存儲機制中，且所述共享物理機制包括數(shù)據(jù)庫和文件。
5.根據(jù)權利要求1所述的熱加載方法，其特征在于，執(zhí)行所述步驟4后，還包括向原版本模塊發(fā)送消息時，會根據(jù)共享內存中更新的原版本模塊連接Spread消息組名，將消息由spread消息總線轉發(fā)到新版本模塊。
6.根據(jù)權利要求1所述的熱加載方法，其特征在于，所述步驟5中升級消息發(fā)布模塊將收到的反饋結果打印到控制臺上。
全文摘要
本發(fā)明涉及一種基于Spread分布式應用系統(tǒng)的熱加載方法，包括步驟1，部署常駐內存的升級消息監(jiān)聽模塊；步驟2，啟動新版本模塊，與原版本模塊并運行；步驟3，啟動升級消息發(fā)布模塊，發(fā)送新版本模塊的升級消息；步驟4升級消息監(jiān)聽模塊接收到升級消息后，對共享內存中原版本模塊所連接的消息組名進行切換，并將結果返回給升級消息發(fā)布進程；步驟5，升級消息發(fā)布模塊收到所有發(fā)布成功結果返回后，提示升級成功，并退出；步驟6原版本模塊將消息組切換前收到的所有消息處理完成后，停止原版本模塊運行。本發(fā)明提供了一個統(tǒng)一的穩(wěn)定的熱加載方式，使得模塊升級不再受時間的限制，實現(xiàn)在不中斷業(yè)務的情況下完成程序加載。
文檔編號G06F9/445GK103064711SQ20121058139
公開日2013年4月24日 申請日期2012年12月27日 優(yōu)先權日2012年12月27日
發(fā)明者陳明, 謝宗周, 郭子慧 申請人:北京思特奇信息技術股份有限公司