實(shí)時(shí)SOA從消息總線(xiàn)開(kāi)始

SOA組件的最佳組合

實(shí)時(shí)應用程序需要面向服務(wù)的基礎組件的最佳組合。SOA系統有三種基礎組件：消息總線(xiàn)、信息轉換/處理引擎和數據存儲庫（見(jiàn)圖1）。一般來(lái)說(shuō)，這些組件會(huì )集成到企業(yè)服務(wù)總線(xiàn)中（ESB），并使用J2EE應用程序服務(wù)器。

圖1

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

為什么消息性能很重要？

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

表1

為實(shí)時(shí)SOA選擇消息中間件

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

1. 架構
消息中間件有四種基本架構：星型拓撲（hub-and-spoke）架構、集群拓撲架構、聯(lián)合架構和對等架構（peer-to-peer）。（見(jiàn)圖2）

圖2

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

表2

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