實時SOA從消息總線開始

SOA組件的最佳組合

實時應(yīng)用程序需要面向服務(wù)的基礎(chǔ)組件的最佳組合。SOA系統(tǒng)有三種基礎(chǔ)組件：消息總線、信息轉(zhuǎn)換/處理引擎和數(shù)據(jù)存儲庫（見圖1）。一般來說，這些組件會集成到企業(yè)服務(wù)總線中（ESB），并使用J2EE應(yīng)用程序服務(wù)器。

圖1

而在這些基礎(chǔ)組件中，消息總線是最重要的，因為它是所有其它組件交互的中介。
低性能的SOA系統(tǒng)或許會使用HTTP協(xié)議作為“消息總線”實現(xiàn)各組件間的消息交換。這種方案只適用于非實時應(yīng)用程序。HTTP協(xié)議缺乏可靠性、帶寬有限、延遲大，并且在系統(tǒng)暫時無法使用時不能提供緩沖或消息隊列以延時遞交。
解決方案是采用高性能的消息中間件，比如RTI Data-Distribution Service、IBM WebSphere MQ、TIBCO或SonicMQ等。這些中間件平臺在開發(fā)時充分考慮了可擴展性和表現(xiàn)性能。而且，它們?yōu)椴煌膽?yīng)用方案采用不同的優(yōu)化架構(gòu)。

為什么消息性能很重要？

這是計算機實時超越人類實時的需求與期望。若系統(tǒng)中存在人類這一環(huán)節(jié)，實時即指信息可以在一秒到幾秒反應(yīng)時間內(nèi)隨時可取；而在計算機到計算機環(huán)境中，卻必須以毫秒甚至微秒級別的速度處理信息。
計算機實時對消息基礎(chǔ)設(shè)施的要求更為嚴(yán)格：每個處理組件和存儲組件每秒都會收到幾十萬的消息或事件，延遲不能超過微秒級別，最差不能超過毫秒級別。這意味著消息中間件必須可以在系統(tǒng)范圍內(nèi)每秒傳送幾百萬的消息。
消息總線的負(fù)載能力也必須滿足基礎(chǔ)硬件設(shè)施的負(fù)載要求，并且不能在基礎(chǔ)硬件設(shè)施的限制（中央處理器速度、核心、速度和網(wǎng)絡(luò)帶寬）外再有其它限制。隨著中央處理器和網(wǎng)絡(luò)速度的提升，那些可以因硬件升級而提升性能的系統(tǒng)將獲得更大的競爭優(yōu)勢。比如，在一個自動交易系統(tǒng)中，決定性因素并不是判定交易所用的絕對時間，而是要在競爭交易發(fā)生前做出判定并執(zhí)行。
關(guān)于計算機實時，SOA系統(tǒng)的最后一個問題是，它們的“反向性能負(fù)載效應(yīng)曲線”，也就是系統(tǒng)在高負(fù)載下運作時的及時響應(yīng)能力非常重要。一般的效應(yīng)曲線，比如人類實時系統(tǒng)，由于負(fù)載的加重而使性能有所下降是可以接受的。這是因為人類的期望與耐性是隨情況改變的，比如，人們明白在度假高峰期預(yù)定機票必須忍受較長的等待時間。而對計算機實時系統(tǒng)的要求卻與此相反。高負(fù)載時期正是“最關(guān)鍵業(yè)務(wù)”發(fā)生的時期，也是需要系統(tǒng)表現(xiàn)最佳性能的關(guān)鍵時期。比如，業(yè)務(wù)繁忙時必須更快地處理交易判定。
人類實時系統(tǒng)與計算機度實時系統(tǒng)的區(qū)別在表1中做了概要說明。

表1

為實時SOA選擇消息中間件

消息中間件是實時SOA系統(tǒng)的實現(xiàn)關(guān)鍵。雖然如此，仍然有許多問題需要考慮。如何為實時SOA系統(tǒng)選擇最佳的消息中間件呢？可以從架構(gòu)、服務(wù)質(zhì)量（QoS）控制與過濾器、性能提升技術(shù)、實時判定機制和度量指標(biāo)五個方面考慮。

1. 架構(gòu)
消息中間件有四種基本架構(gòu)：星型拓?fù)洌╤ub-and-spoke）架構(gòu)、集群拓?fù)浼軜?gòu)、聯(lián)合架構(gòu)和對等架構(gòu)（peer-to-peer）。（見圖2）

圖2

星型拓?fù)浼軜?gòu)用一個服務(wù)器作為消息交換的路由，實現(xiàn)包含所有消息隊列的消息“服務(wù)”。
集群拓?fù)浼軜?gòu)使用一組服務(wù)器，分別處理不同種類的消息（比如消息隊列或主題所有權(quán)）。每條消息通過一個服務(wù)器，但不是所有消息都用同一個服務(wù)器。
聯(lián)合架構(gòu)也使用一組服務(wù)器，但這組服務(wù)器是作為“資源庫”使用。比如，消息隊列可以出現(xiàn)在多個服務(wù)器中。消息可能只經(jīng)過一個服務(wù)器代理，也可能經(jīng)過多個服務(wù)器代理。
對等架構(gòu)不在傳輸路徑中使用任何代理。消息直接從發(fā)送方傳向接收方。
各種架構(gòu)都有其優(yōu)缺點。星型拓?fù)湫腿菀坠芾?，便于操作，但表現(xiàn)性能、容錯率和可擴展性比較差。集群架構(gòu)可擴展性比星型架構(gòu)好，但容錯性同樣較差，并且只能在網(wǎng)格范圍內(nèi)為附近的客戶端提供較好的表現(xiàn)性能。聯(lián)合架構(gòu)的擴展性更好一些，但其延遲更大，因為每條消息都要經(jīng)過至少兩個服務(wù)器的代理。對等架構(gòu)提供了最好的可擴展性、表現(xiàn)性能，最低的延遲和最高的容錯率，但實現(xiàn)起來很困難，并且對業(yè)務(wù)的支持有限。
隨著需求越來越具實時性，對性能、可預(yù)見性和平衡的要求越來越傾向于對等架構(gòu)。這就是為什么像IP語音通信和IP視頻傳播（比如Skype）之類的需求網(wǎng)絡(luò)會采用對等的設(shè)計方案
服務(wù)質(zhì)量控制與過濾器
服務(wù)質(zhì)量控制是以低延遲、高處理能力提供及時數(shù)據(jù)的關(guān)鍵。中央處理器、內(nèi)存和網(wǎng)絡(luò)帶寬資源必須在所有通信過程中共享。然而，并不是所有的通信都需要相同的帶寬或有相同的緊急性和重要性。如果沒有服務(wù)質(zhì)量控制，應(yīng)用程序就無法分辨不同的信息類別和反應(yīng)需求。這會導(dǎo)致中間件不能靈活地做出判定，對信息進行優(yōu)化處理或滿足應(yīng)用需求。
比如，使用TCP協(xié)議（傳輸控制協(xié)議）的傳統(tǒng)網(wǎng)絡(luò)環(huán)境中，一個小而緊急的警告消息可能在TCP連接中被排在一個較大的文件傳輸后面。因為TCP無視消息源，并穩(wěn)定有序地傳輸每一個字節(jié)。這個警告消息只有在傳完整個文件之后才能被成功接收到。可以假想在廣域網(wǎng)（WAN）中轉(zhuǎn)播直播節(jié)目的情況。網(wǎng)絡(luò)阻塞可能會造成圖像丟失；由于沒有服務(wù)質(zhì)量控制，中間件就會繼續(xù)查找丟失的圖像，而不是選擇傳送最新的圖像。這樣就不只是丟失幾張圖片的問題，極有可能圖像會凍結(jié)，直到成功取得丟失的圖像。所以，即使硬件可以提供不錯的表現(xiàn)性能，系統(tǒng)的整體性能仍然大打折扣。
為實現(xiàn)計算機速度的實時性能，消息中間件必須至少滿足以下服務(wù)質(zhì)量控制要求：穩(wěn)定性、緩沖計算、流量控制、生命周期、歷史記錄和傳輸優(yōu)先級。（見表2）

表2

過濾功能是系統(tǒng)擴展性與表現(xiàn)性能的關(guān)鍵。支持過濾的中間件可以只為各組件傳送最重要的內(nèi)容，這可以節(jié)省大量網(wǎng)絡(luò)帶寬和CPU資源，使系統(tǒng)可以處理更多的信息。比如，事件處理引擎可能會查找關(guān)系到某些計算機或網(wǎng)絡(luò)單元，或者屬于某種協(xié)議的網(wǎng)絡(luò)活動。中間件并不會將所有網(wǎng)絡(luò)事件都傳送到引擎，并讓引擎過濾掉不相關(guān)數(shù)據(jù)，而是先進行過濾處理，然后再發(fā)送相關(guān)數(shù)據(jù)，這樣可為事件處理引擎節(jié)省網(wǎng)絡(luò)帶寬與CPU資源。
主要有兩種過濾器：一種是基于時間的，另一種是基于內(nèi)容的?；跁r間的過濾器會限制信息頻率，比如每秒最多允許發(fā)送10次更新信息?；跁r間的過濾器對應(yīng)用程序非常有用，例如以人為本的儀表板，只需要獲得走向與概要信息即可。