專利名稱：消息處理方法
技術領域：
本發(fā)明涉及計算機技術領域，特別涉及一種消息分發(fā)及性能調(diào)優(yōu)技術中的消息處
理方法。
背景技術：
在大訪問量、高并發(fā)的大型網(wǎng)站中，Web服務器的線程消耗是非常嚴重的，線程資 源十分保貴，如何提高線程利用率、提高請求的響應能力常常是網(wǎng)站性能優(yōu)化的關鍵點。但 在系統(tǒng)中又常常會有一些高并發(fā)、高耗時、低實時性的操作，這些操作的結(jié)果對于網(wǎng)站用戶 來說并不需要及時反饋，但是如果網(wǎng)頁等待這些同步操作返回，則對線程占用和響應都有 嚴重的影響，減少服務的吞吐量。這樣，如何分流這些消息，進行異步處理就變得重要了。異 步調(diào)用框架就提供了一個通用的模型來處理這樣的調(diào)用。現(xiàn)有方案一使用線程池對耗時操作進行異步處理。把一個需要執(zhí)行的操作交給 線程池，線程池自己負責線程的創(chuàng)建、分配和銷毀。通過使用線程池可以對高消耗的操作進 行優(yōu)化，從而提高系統(tǒng)的處理能力和吞吐量。其缺陷是線程池仍然是消耗本機線程，在高 并發(fā)的情況下對CPU和內(nèi)存消耗非常嚴重，雖然可以通過修改配置提高線程數(shù)，但是對本 機資源的消耗是無法有效解決的?，F(xiàn)有方案二 使用消息隊列(MSMQ)異步處理高消耗的操作。通過使用消息隊列可 以把待處理的消息路由到本機或者別的機器上的另外一個進程進行處理。這種方式提供更 好的資源擴展，通過把消息路由到別的機器進行處理，可以降低對本機資源的消耗，同時消 息隊列所提供的異步和離線機制可以更好的提高主程序的響應能力。消息隊列的離線機制 也有效保障了消息傳遞的可靠性。其缺陷是消息隊列本身沒有合適的可編程機制，支持針 對不同的消息處理應用相對應的插件進行處理的機制，以及針對不同消息的按需的靈活路 由，需要在此基礎上進行擴展。

發(fā)明內(nèi)容
(一)要解決的技術問題本發(fā)明要解決的技術問題是如何提供一個通用的框架，對消息進行分流和異步 處理，并且使服務端能夠支持針對不同的消息動態(tài)地選擇相應的插件分別進行處理。( 二 )技術方案為解決上述技術問題，本發(fā)明提供了一種消息處理方法，其特征在于，包括以下步 驟Sl 客戶端把要進行異步處理或離線處理的消息路由到對應的服務端；S2 服務端接收所述消息，然后分析其中的消息來源參數(shù)，生成可在反轉(zhuǎn)控制IOC 容器中提取的關系名稱；S3 通過所述關系名稱從所述IOC容器中提取與消息對應的消息處理器；S4 在各自的消息處理器中實現(xiàn)對消息的處理。
其中，步驟Sl具體包括Sll 客戶端把要進行異步處理或離線處理的消息寫入微軟消息隊列MSMQ ；S12 =Windows操作系統(tǒng)根據(jù)服務端提供的服務地址，把消息自動路由到服務端。其中，步驟Sl中消息隊列的寫入操作應用Windows通信基礎WCF來處理。其中，步驟S2中生成可在反轉(zhuǎn)控制IOC容器中提取的關系名稱具體方式為根據(jù) 事先在IOC容器中注冊的消息來源參數(shù)與消息處理器的對應關系提取關系名稱。其中，在步驟S2中，通過所述服務端提供的消息服務接口接收所述消息。其中，消息接口中的參數(shù)包括消息標識和消息來源標識，所述消息來源標識包 括客戶端標識、服務標識及服務的版本ID。其中，在步驟S2中，所述消息處理器通過統(tǒng)一的接口被調(diào)用。其中，在步驟S4中，對消息的處理包括對外部服務的調(diào)用、對數(shù)據(jù)庫的操作以及 進行日志記錄。(三)有益效果本發(fā)明通過綜合應用MSMQ、WCF、IOC容器和巧妙的接口設計，我們開發(fā)出了一個 可以支持異步處理消息、具有自動選擇插件進行消息處理功能的通用的異步調(diào)用方法。通 過應用此方法可以把消息的處理路由給別的進程或者別的服務器進行處理，能夠指定不同 的服務地址和部署更多的服務器進行處理，從而可以支持大量的消息處理任務，進而大大 地優(yōu)化網(wǎng)站或服務的性能，提高該網(wǎng)站或服務的吞吐量和降低響應時間，更有效地利用服 務器資源。


圖1是本發(fā)明的一種消息處理方法流程圖；圖2是實現(xiàn)本發(fā)明的消息處理方法的客戶端服務端框架結(jié)構圖；圖3是本發(fā)明實施例的消息處理時序圖。
具體實施例方式為使本發(fā)明的目的、內(nèi)容、和優(yōu)點更加清楚，下面將結(jié)合附圖對本發(fā)明實施方式作 進一步地詳細描述。本發(fā)明的整體思路是設計一個分布式調(diào)用框架，分為客戶端調(diào)用和服務端處理。如圖1所示，本發(fā)明的步驟包括步驟S 1，客戶端把要進行異步或離線處理的消息寫入MSMQ (Microsoft Message Queue，微軟消息隊列)，Windows操作系統(tǒng)根據(jù)服務端提供的服務地址，把消息自動路由到 服務端。步驟S2，服務端接收來自于消息隊列的消息，然后分析其中的消息來源參數(shù)，生成 可在IOCdnversion of Control，反轉(zhuǎn)控制)容器中提取的關系名稱。步驟S3，服務端通過所述關系名稱從所述IOC容器中提取與消息對應的消息處理
ο步驟S4,在各自的消息處理器中實現(xiàn)對消息的處理，包括對外部服務的調(diào)用，數(shù)據(jù) 庫的操作，日志記錄等。
其中，消息隊列的寫入和提取，以及服務端的并發(fā)控制等相關網(wǎng)絡問題通過應用 微軟的 WCF (Windows CommunicationFoundation，Windows 通信基礎)技術進行統(tǒng)一處理。圖2示出了實現(xiàn)本發(fā)明方法的框架結(jié)構示意圖，圖中示出了客戶端1和客戶端2 分別通過各自的消息來源參數(shù)source和消息標識identity來調(diào)用服務，具體通過source 中的serviceName在分組中獲取要調(diào)用服務的地址address，調(diào)用服務采用上述的WCF技術 將各自的消息放入消息隊列中。服務端獲取消息隊列后，根據(jù)消息來源參數(shù)和消息標識從 IOC容器中選擇正確的處理器來處理消息。具體步驟結(jié)合時序圖進行描述。如圖3所示，為消息處理時序圖。 上述步驟Sl具體包括步驟S 11，客戶端通過WCF把需要處理的消息寫入本地的消息隊列MSMQ。因為應 用了微軟的WCF，客戶端把消息寫入隊列，服務端獲取隊列中的消息均被表現(xiàn)為對服務接口 的調(diào)用和服務接口的實現(xiàn)處理。所以這里所謂的把消息寫入消息隊列，實際上是對服務端 提供的一個消息服務接口進行調(diào)用。本實施例中，消息服務接口 IServicelnvoker定義如 下表1所示表1服務端提供的服務接口定義
權利要求
一種消息處理方法，其特征在于，包括以下步驟S1客戶端把要進行異步處理或離線處理的消息路由到對應的服務端；S2服務端接收所述消息，然后分析其中的消息來源參數(shù)，生成可在反轉(zhuǎn)控制IOC容器中提取的關系名稱；S3通過所述關系名稱從所述IOC容器中提取與消息對應的消息處理器；S4在各自的消息處理器中實現(xiàn)對消息的處理。
2.如權利要求1所述的消息處理方法，其特征在于，步驟Sl具體包括Sll 客戶端把要進行異步處理或離線處理的消息寫入微軟消息隊列MSMQ ；S12:Wind0WS操作系統(tǒng)根據(jù)服務端提供的服務地址，把消息自動路由到服務端。
3.如權利要求2所述的消息處理方法，其特征在于，步驟Sl中消息隊列的寫入操作應 用Windows通信基礎WCF來處理。
4.如權利要求1所述的消息處理方法，其特征在于，步驟S2中生成可在反轉(zhuǎn)控制IOC 容器中提取的關系名稱具體方式為根據(jù)事先在IOC容器中注冊的消息來源參數(shù)與消息處 理器的對應關系提取關系名稱。
5.如權利要求1 4中任一項所述的消息處理方法，其特征在于，在步驟S2中，通過所 述服務端提供的消息服務接口接收所述消息。
6.如權利要求5所述的消息處理方法，其特征在于，消息接口中的參數(shù)包括消息標識 和消息來源標識，所述消息來源標識包括客戶端標識、服務標識及服務的版本ID。
7.如權利要求1 4中任一項所述的消息處理方法，其特征在于，在步驟S2中，所述消 息處理器通過統(tǒng)一的接口被調(diào)用。
8.如權利要求1 4中任一項所述的消息處理方法，其特征在于，在步驟S4中，對消息 的處理包括對外部服務的調(diào)用、對數(shù)據(jù)庫的操作以及進行日志記錄。
全文摘要
本發(fā)明公開了一種消息處理方法，包括以下步驟S1、客戶端把要進行異步處理或離線處理的消息路由到對應的服務端；S2、服務端接收所述消息，然后分析其中的消息來源參數(shù)，生成可在控制反轉(zhuǎn)IOC容器中提取的關系名稱；S3、通過所述關系名稱從所述IOC容器中提取與消息對應的消息處理器；S4、在各自的消息處理器中實現(xiàn)對消息的處理。本發(fā)明提供了一個通用的框架，對消息進行分流和異步處理，并且使服務端能夠支持針對不同的消息動態(tài)地選擇相應的插件分別進行處理。
文檔編號H04L29/06GK101964763SQ20101050391
公開日2011年2月2日 申請日期2010年9月30日 優(yōu)先權日2010年9月30日
發(fā)明者陳俊彪 申請人:北京神州泰岳軟件股份有限公司