EDA 和 SOA 的融合以及實(shí)踐

申請(qǐng)免費(fèi)試用、咨詢電話：400-8352-114

EDA 和 SOA

SOA 簡(jiǎn)介

事件驅(qū)動(dòng)架構(gòu) (Event-Driven Architecture，EDA) 簡(jiǎn)介

可以從兩個(gè)方面來理解 EDA：

EDA 是一種側(cè)重于以生成/消費(fèi)為基礎(chǔ)的異步通信的架構(gòu)模式。這主要對(duì)照于傳統(tǒng)的基于線程的同步系統(tǒng)。

EDA 是一種以事件 (event)為核心，提供事件產(chǎn)生，路由，消費(fèi)已經(jīng)結(jié)果回調(diào)等機(jī)制的架構(gòu)模式。

簡(jiǎn)單地說， 面向服務(wù)架構(gòu) (Service-Oriented Architecture, SOA) 是一種 IT 架構(gòu)策略，其基于面向服務(wù)的概念之上。自從 2002 開始為大家熟知以來，SOA 已經(jīng)逐漸地成為業(yè)界的標(biāo)準(zhǔn)，也得到了廣泛的應(yīng)用。

SOA != Web Service

因?yàn)?SOA 經(jīng)常和 Web Service 相提并論，所以導(dǎo)致大家一直有一個(gè)誤區(qū)，認(rèn)為這兩者是等同的，其實(shí)不然。雖然兩者有很多的關(guān)聯(lián)，但它們是截然不同的兩個(gè)概念，或者說考慮問題的角度不同。雖然 SOA 最初的流行離不開 Web Service 的貢獻(xiàn)，但如今 SOA 早已超越了 Web Service 的范疇，變成一個(gè)獨(dú)立的設(shè)計(jì)理念。

SOA 的局限性

SOA 主要從系統(tǒng)解構(gòu)的角度入手，它側(cè)重于將整個(gè)應(yīng)用分解為一系列獨(dú)立的服務(wù)，并指定各種標(biāo)準(zhǔn)和基礎(chǔ)設(shè)施來使得這些服務(wù)易于重用，能夠很容易地被各種平臺(tái)上的應(yīng)用來使用。但是在服務(wù)實(shí)際業(yè)務(wù)時(shí)出現(xiàn)了一些問題，因?yàn)?SOA 更多地是關(guān)注靜態(tài)的信息，所以不能很好地與動(dòng)態(tài)業(yè)務(wù)匹配。比如 SOA 不能很好地回答類似下面的一些問題：

比如在一個(gè)證券公司，有很完善的交易系統(tǒng)、后臺(tái)系統(tǒng)、賬務(wù)系統(tǒng)和頭寸管理系統(tǒng)等，當(dāng)一個(gè)客戶的下單在交易所執(zhí)行后，所有的這些系統(tǒng)都應(yīng)該得到通知，并做出相應(yīng)的處理。這里面其實(shí)包含了幾個(gè)問題：誰來負(fù)責(zé)觸發(fā)這樣一個(gè)事件，各個(gè)系統(tǒng)如何得到通知？如何保證各個(gè)系統(tǒng)行動(dòng)的一致性？ SOA 架構(gòu)由于其關(guān)注點(diǎn)的限制，并不能很好地解決上述問題，而這些問題往往又是實(shí)際系統(tǒng)非常需要的特性。因此，EDA 與 SOA 的集成引起了人們的注意。

通過引入面向事件的機(jī)制，使得系統(tǒng)具備了感知和快速響應(yīng)業(yè)務(wù)事件的能力。其實(shí)不管是 SOA 還是 EDA 都不是什么新技術(shù)，無非是在一些舊的概念上添加了一些新元素。

什么是事件（Event）？

事件就是狀態(tài)的顯著變化，比如說前面提到的客戶下單被執(zhí)行。從來源來分，事件可以分為系統(tǒng)內(nèi)部事件和外部事件。從類型來分，可以分為業(yè)務(wù)事件和系統(tǒng)事件。

其實(shí)你可以從 SOA 或 EDA 的身上很容易看到以前的技術(shù) ( 比如 CORBA 或者 DCOM) 的影子。任何系統(tǒng)都可以簡(jiǎn)化為組件 / 服務(wù)加上通道 (channel，解決通訊的問題 )，如果說 SOA 關(guān)注于組件和服務(wù)的話，那么 EDA 更多地關(guān)注通道。

Event-Driven SOA

我們一般將 SOA 和 EDA 的集成體稱之為事件驅(qū)動(dòng)的面向服務(wù)架構(gòu) (Event-Driven SOA)，可以將其理解為 SOA 的一種衍生。SOA 和 EDA 的交互主要體現(xiàn)在以下幾個(gè)方面：

將事件處理的能力引入到 SOA

一個(gè)事件的產(chǎn)生可以觸發(fā)一個(gè)或多個(gè)服務(wù)被調(diào)用，這樣就把這些靜態(tài)的功能動(dòng)態(tài)地串聯(lián)起來。

服務(wù)本身也可以產(chǎn)生事件

服務(wù)除了完成特定的功能外，也可以根據(jù)自身需要產(chǎn)生某個(gè)事件。

有人將 EDA 和 SOA 的關(guān)系與人體做了一個(gè)形象的比喻，如果把 SOA 比作手和腳的話，那 EDA 就像人的眼睛和耳朵。當(dāng)眼睛發(fā)現(xiàn)一只獅子正朝你奔來時(shí)，一個(gè)消息被發(fā)送到大腦，然后大腦向你的手腳發(fā)出指令：趕快跑。

Event-Driven SOA 架構(gòu)的特點(diǎn)

當(dāng)然，任何一種架構(gòu)模式都有其適用的場(chǎng)景，Event-Driven SOA 自然也不例外。

首先，它適用于異步的環(huán)境。如果你的系統(tǒng)對(duì)實(shí)時(shí)性要求比較高，請(qǐng)不要使用該架構(gòu)。

第二，如果你的系統(tǒng)需要面對(duì)復(fù)雜的異構(gòu)環(huán)境——跨平臺(tái) / 跨語言，那么面向服務(wù)的架構(gòu)能夠很好地應(yīng)對(duì)。

第三，將系統(tǒng)功能分解為適當(dāng)粒度并且重用性高的一個(gè)個(gè)服務(wù)，可以顯著地提高 IT 系統(tǒng)的適應(yīng)性和效率，進(jìn)而提高投資回報(bào)率 (ROI)。

第四，引入事件處理的能力以后，每個(gè)服務(wù)都是由不同的事件驅(qū)動(dòng)，這樣當(dāng)某個(gè)事件發(fā)生后，系統(tǒng)的不同服務(wù)就能夠自動(dòng)地進(jìn)行觸發(fā)。這對(duì)那些有更高自動(dòng)化要求的系統(tǒng)來說非常適合。

第五，與面向過程的系統(tǒng)中客戶端必須輪詢更改請(qǐng)求 ( 通過 API 調(diào)用 ) 不同，事件驅(qū)動(dòng)架構(gòu)允許系統(tǒng)和組件在事件發(fā)生時(shí)實(shí)時(shí)動(dòng)態(tài)地做出響應(yīng)。事件驅(qū)動(dòng)架構(gòu)通過引入長(zhǎng)時(shí)間運(yùn)行的處理功能來彌補(bǔ) SOA 的不足。這一點(diǎn)對(duì)于金融系統(tǒng)來說尤其重要，比如說一次股票買賣從客戶下單到最終交割會(huì)經(jīng)歷幾天的生命周期。

最后，Event-Driven SOA 使得增加事件的 consumer 和 producer 非常容易，這樣就使得增加系統(tǒng)吞吐量也變得很簡(jiǎn)單，系統(tǒng)的彈性非常好，非常適合那些業(yè)務(wù)量持續(xù)增加的系統(tǒng)。在這方面，有一個(gè) EDA 的變體 SEDA（Staged Event-Driven Architecture）將這方面的設(shè)計(jì)發(fā)揮到了極致，詳細(xì)的介紹請(qǐng)參考正文后的參考資料。

Event-Driven SOA 在金融系統(tǒng)的應(yīng)用

金融系統(tǒng)的實(shí)際需求

在當(dāng)今社會(huì)，市場(chǎng)變化莫測(cè)，商機(jī)稍縱即逝，企業(yè)需要有極強(qiáng)的靈活性和應(yīng)變能力，金融行業(yè)尤其如此，特別是在中國(guó)這樣一個(gè)金融行業(yè)處于快速發(fā)展的市場(chǎng)里。企業(yè)要求 IT 系統(tǒng)能夠快速地對(duì)業(yè)務(wù)需求做出應(yīng)對(duì)，否則就會(huì)喪失先發(fā)優(yōu)勢(shì)。這有點(diǎn)類似于現(xiàn)代戰(zhàn)爭(zhēng)條件下，各國(guó)都要求部隊(duì)具備快速反應(yīng)能力，這種能力主要體現(xiàn)在 IT 部門能夠通過快速開發(fā)或者重用 / 整合現(xiàn)有資源來達(dá)到快速響應(yīng)業(yè)務(wù)需求。還有，金融行業(yè)業(yè)務(wù)越來越龐大復(fù)雜，所涉及的第三方系統(tǒng)或者遺留系統(tǒng)非常多，這就要求 IT 系統(tǒng)有很強(qiáng)的整合能力及對(duì)異構(gòu)環(huán)境的適應(yīng)能力。最后，由于金融行業(yè)的發(fā)展日新月異，特定金融業(yè)務(wù)都會(huì)在其初期發(fā)展后迎來一個(gè)快速膨脹期，業(yè)務(wù)量和業(yè)務(wù)類型會(huì)急劇增加，這也要求 IT 系統(tǒng)有很好的可擴(kuò)展性。

對(duì)照前面提到的 Event-Driven SOA 的特點(diǎn)，我們可以很直觀地發(fā)現(xiàn)該架構(gòu)可以很好地滿足金融系統(tǒng)的實(shí)際需求。當(dāng)然，金融系統(tǒng)也是包羅萬象，特點(diǎn)各不一樣，這里可能更偏重于金融行業(yè)的交易系統(tǒng)。

為什么選擇 Event-Driven SOA ——適用性討論

除了上面提到的這些大的因素之外，我們還可以深入到具體系統(tǒng)的內(nèi)部，從一些微觀層面來考慮 Event-Driven SOA 是否仍然能夠符合我們的要求。下圖是一個(gè)證券公司股票交易系統(tǒng)的簡(jiǎn)圖：

圖 1. 證券公司股票交易系統(tǒng)概略圖

從上圖我們可以看出，整個(gè)應(yīng)用被分為很多子系統(tǒng)，各個(gè)子系統(tǒng)之間存在著大量的信息交互。而且大部分應(yīng)用輸入都需要經(jīng)歷一個(gè)比較長(zhǎng)的生命周期，比如說一個(gè)客戶訂單輸入到系統(tǒng)后，會(huì)先后經(jīng)歷前臺(tái)系統(tǒng) (Front Office)，中臺(tái)系統(tǒng) (Middle Office) 以及后臺(tái)系統(tǒng) (Back Office)，而且每個(gè)系統(tǒng)內(nèi)部又包括很多服務(wù)組件。除了系統(tǒng)層面的跨度外， 這個(gè)生命周期也體現(xiàn)在時(shí)間長(zhǎng)度上。而且，如今所有的金融系統(tǒng)都追求 STP (Straight Through Processing) 的能力，主張盡可能少的人工干預(yù)，這樣所有的服務(wù)組件都需要具備自觸發(fā)的能力。

Event-Driven SOA 架構(gòu)設(shè)計(jì)

架構(gòu)師在著手每次的架構(gòu)設(shè)計(jì)時(shí)，其實(shí)都是在提出并回答一系列的問題，把這些問題都回答了，架構(gòu)設(shè)計(jì)也就出來了。比如我們每次肯定都會(huì)問：系統(tǒng)的最終用戶是誰，他們會(huì)如何來使用該系統(tǒng)，他們的核心訴求是什么。當(dāng)然，不是所有的問題都能有一個(gè)圓滿的答案，更多的時(shí)候其實(shí)是一個(gè)取舍的過程。比如說系統(tǒng)的關(guān)鍵指標(biāo)我們很難一下子全部滿足，就需要結(jié)合具體的業(yè)務(wù)需求和人力物力以及時(shí)間的具體情況來做取舍。下表就列出了一些我在做 Event-Driven SOA 架構(gòu)設(shè)計(jì)時(shí)認(rèn)為比較關(guān)鍵的問題（在遵循一般架構(gòu)設(shè)計(jì)的原則的基礎(chǔ)之上），看看你是否也有同感。

表一：Event-Driven SOA 架構(gòu)設(shè)計(jì)時(shí)的幾個(gè)關(guān)鍵考慮

下面我就其中的幾點(diǎn)具體展開討論一下：

業(yè)務(wù)為先

任何的技術(shù)或者架構(gòu)思想都是由具體的業(yè)務(wù)需求驅(qū)動(dòng)的，比如 SOA 的出現(xiàn)是由于人們打破豎井應(yīng)用 (application silos) 并追求功能重用的強(qiáng)烈需求，而 EDA 的出現(xiàn)也迎合了業(yè)務(wù)流程化、自動(dòng)化的趨勢(shì)。所以，任何的架構(gòu)設(shè)計(jì)都要服從于自身業(yè)務(wù)的具體需求，沒有最好的架構(gòu)設(shè)計(jì)，只有最合適的。

在 SOA 實(shí)踐中，尤其強(qiáng)調(diào)業(yè)務(wù)為先的原則，因?yàn)槲覀儽仨毾冗M(jìn)行業(yè)務(wù)流程的整合重組，然后才是 IT 系統(tǒng)的服務(wù)化。業(yè)務(wù)流程本身的問題還是需要從業(yè)務(wù)本身去解決，再好的技術(shù)也解決不了業(yè)務(wù)的問題。試想一下，如果一個(gè)企業(yè)各個(gè)部門之間各自為戰(zhàn)，缺乏協(xié)作和溝通，那么可能開發(fā)出一個(gè)好的面向服務(wù)的 IT 系統(tǒng)嗎？

除了業(yè)務(wù)部門的努力外，IT 部門在做任何架構(gòu)設(shè)計(jì)的決定前，必須確保理解清楚了業(yè)務(wù)部門的具體需求。所以說，項(xiàng)目前期 IT 部門和業(yè)務(wù)部門之間的協(xié)作和交流非常重要。

這里很容易有一個(gè)誤區(qū)，尤其是對(duì)那些經(jīng)驗(yàn)豐富的架構(gòu)師。他們往往擁有豐富的 IT 經(jīng)驗(yàn)和業(yè)務(wù)知識(shí)，自認(rèn)為已經(jīng)非常了解業(yè)務(wù)部門的需求，甚至有些時(shí)候都能夠指導(dǎo)業(yè)務(wù)部門如何去改進(jìn)。在這種自負(fù)的情緒中，他們覺得可以先把所謂先進(jìn)的 IT 系統(tǒng)開發(fā)出來，然后再去推廣，他們認(rèn)為用戶肯定會(huì)欣然接受這些系統(tǒng)，因?yàn)樗麄兇碇冗M(jìn)的理念，但往往事與愿違。姑且不去深究究竟孰對(duì)孰錯(cuò)，退一萬步講，一個(gè)沒有充分聽取用戶意見，沒有用戶參與的系統(tǒng)能夠那么容易得到用戶的認(rèn)可嗎？即便你是對(duì)的。

互聯(lián)互通

在 Event-Driven SOA 的實(shí)施過程中，有幾個(gè)關(guān)鍵指標(biāo)：服務(wù)的分類和創(chuàng)建，事件的定義和管理，服務(wù)的互聯(lián)互通，業(yè)務(wù)流程的理解和 IT 實(shí)現(xiàn)等。那我們應(yīng)該更加關(guān)注哪個(gè)指標(biāo)呢？因?yàn)槲覀兺茈y一下子兼顧所有的指標(biāo)。個(gè)人認(rèn)為這其中最重要的就是服務(wù)的互通互聯(lián)。當(dāng)然這里所講的互通互聯(lián)并沒有那么簡(jiǎn)單，并不是僅僅建立起通訊的通道就可以，它包括以下幾個(gè)方面的內(nèi)容：

無論通訊的方式如何，最好做到自動(dòng)化

實(shí)現(xiàn)通訊的方式有很多種：同步調(diào)用，異步消息，Socket 甚至是文件，無論采用哪種，最好做到自動(dòng)化的實(shí)現(xiàn)。任何人工的干預(yù)都容易引起錯(cuò)誤和延遲。

通訊的雙方之間需要定義清晰的接口，有共同的異常應(yīng)對(duì)機(jī)制

特別是當(dāng)通訊的雙方是由不同的開發(fā)團(tuán)隊(duì)來完成，一定要在開始階段就定義清楚接口，并在隨后的開發(fā)過程中嚴(yán)格遵守，同時(shí)保持實(shí)時(shí)的溝通。這里面需要強(qiáng)調(diào)的一點(diǎn)就是異常的應(yīng)對(duì)機(jī)制，要讓雙方都充分理解可能面對(duì)的異常情況及應(yīng)對(duì)措施。

基礎(chǔ)數(shù)據(jù)的共享

在金融系統(tǒng)中，會(huì)用到大量的基礎(chǔ)數(shù)據(jù)（一般稱之為 Reference Data），這些數(shù)據(jù)在各個(gè)系統(tǒng)都會(huì)用到。但事實(shí)上情況往往并不如此，經(jīng)常是各個(gè)系統(tǒng)各自為戰(zhàn)，不用或者是使用不同的數(shù)據(jù)源，導(dǎo)致在通訊過程中的識(shí)別歧義。

做到以上這些，技術(shù)上并不困難，更重要的是項(xiàng)目之間的協(xié)作和執(zhí)行力強(qiáng)的領(lǐng)導(dǎo)團(tuán)隊(duì)。

結(jié)合到實(shí)際的例子，比如美國(guó)三軍聯(lián)合作戰(zhàn)系統(tǒng)，其核心就是其“數(shù)據(jù)鏈”系統(tǒng)，它使得戰(zhàn)場(chǎng)上的指揮中心、作戰(zhàn)部隊(duì)和武器平臺(tái)能夠?qū)崟r(shí)交換數(shù)據(jù)，達(dá)到精確協(xié)作的目的。從下面這段描述我們就能感受到這種高效無縫協(xié)作的威力：

“在 7 年之后的海灣戰(zhàn)爭(zhēng)中，初級(jí)的“數(shù)據(jù)鏈”就已顯威戰(zhàn)場(chǎng)。以美軍攔截導(dǎo)彈作戰(zhàn)為例，就可以看到“數(shù)據(jù)鏈”的作用。伊軍的“飛毛腿”導(dǎo)彈一發(fā)射，12 秒鐘之后，位于太平洋上空的美國(guó)防支援計(jì)劃（DSP）的導(dǎo)彈預(yù)警衛(wèi)星就發(fā)現(xiàn)了“飛毛腿”，并迅速測(cè)出它的航行軌道及預(yù)定著陸地區(qū)，報(bào)警信息及有關(guān)數(shù)據(jù)迅速傳遞到位于澳大利亞的美國(guó)航天司令部的一個(gè)數(shù)據(jù)處理中心，數(shù)據(jù)中心的巨型計(jì)算機(jī)緊急處理這些數(shù)據(jù)之后，得到對(duì)“飛毛腿”導(dǎo)彈進(jìn)行有效攔截的參數(shù)，然后航天司令部將這些參數(shù)通過衛(wèi)星傳給位于沙特阿拉伯的“愛國(guó)者”防空導(dǎo)彈指揮中心。防空導(dǎo)彈指揮中心立刻將數(shù)據(jù)裝填到“愛國(guó)者”導(dǎo)彈上并發(fā)射，整個(gè)過程只需要 3 分鐘左右的時(shí)間，而“飛毛腿”至少要飛行 4 ～ 5 分鐘才能到達(dá)預(yù)定目標(biāo)的上空，這就為攔截導(dǎo)彈創(chuàng)造了條件。…”

設(shè)計(jì)考慮

在明確了以上這些設(shè)計(jì)原則外， 我們需要一步步考慮整個(gè)架構(gòu)的實(shí)現(xiàn)途徑。首先面臨的就是一些基礎(chǔ)架構(gòu)的選擇。

基礎(chǔ)架構(gòu)的選擇

在這里我們需要回答一系列的問題：自己開發(fā)還是購(gòu)買？開源的還是商業(yè)的？選擇什么 Web Service 的基礎(chǔ)平臺(tái)？選擇什么樣的消息中間件（Message Oriented Middleware, MOM）？是否采用企業(yè)服務(wù)總線（Enterprise Service Bus, ESB）？

這其中討論的最多的就是是否以及如何使用 ESB。個(gè)人觀點(diǎn)，ESB 是有價(jià)值的，僅當(dāng)系統(tǒng)確實(shí)需要 ESB 的功能時(shí)。Accenture 首席技術(shù)官 Don Rippert 在他的一次早期訪談中提到發(fā)揮 SOA 的全部潛力大致需要以下 4 個(gè)步驟：

開始采用 SOA 架構(gòu)，使用 XML 等標(biāo)準(zhǔn)的方式來使用應(yīng)用程序接口

捕獲一些業(yè)務(wù)過程，并將它們轉(zhuǎn)化為 Web 服務(wù)

引入并全面使用企業(yè)服務(wù)總線

將業(yè)務(wù)過程執(zhí)行語言（Business Process Execution Language, BPEL）集成進(jìn)來，利用業(yè)務(wù)過程建模工具和 BPEL 可以創(chuàng)建不同的應(yīng)用行為，而無需修改軟件

為什么將 ESB 的使用放在第三個(gè)步驟呢，那我們需要從 ESB 的定義入手，來了解 ESB 究竟帶給我們些什么。ESB 應(yīng)該被理解為模式而不是產(chǎn)品，它應(yīng)該至少具備以下這些功能：

服務(wù)的虛擬化，支持虛擬化通訊參與方之間的服務(wù)交互并對(duì)其進(jìn)行管理。意思就是服務(wù)只需要關(guān)注完成自己的功能，不需要關(guān)心哪個(gè)服務(wù)調(diào)用它以及它需要調(diào)用哪個(gè)服務(wù)。

服務(wù)的轉(zhuǎn)化、包裝以及橋接

消息的傳遞、過濾以及路由

服務(wù)編制（Orchestration）

還記得前面將 EDA/SOA 和人體進(jìn)行類比的例子嗎？如果按照該思路，ESB 就可以看作是人體的中樞神經(jīng)系統(tǒng)。其接受眼睛傳入的“獅子來了”的信息，整體加工后成為協(xié)調(diào)的運(yùn)動(dòng)性傳出，手腳也就開始動(dòng)作了。

從上面的定義可以看出，ESB 更多地關(guān)注應(yīng)用流程方面的信息，將業(yè)務(wù)流程剝離出來并將其交由 ESB 來統(tǒng)一管理。因此，有一個(gè)非常簡(jiǎn)單的標(biāo)準(zhǔn)來判斷是否需要采用企業(yè)服務(wù)總線：就是看你的應(yīng)用本身是否有很復(fù)雜的業(yè)務(wù)流程，而且可能這些流程會(huì)經(jīng)常發(fā)生變化。依據(jù)這條標(biāo)準(zhǔn)，我覺得很多應(yīng)用一開始都沒有復(fù)雜到需要立即采用企業(yè)服務(wù)總線，比如說一個(gè)股票的后臺(tái)管理系統(tǒng)，其業(yè)務(wù)流程相對(duì)來說比較簡(jiǎn)單固定，就沒有必要引入企業(yè)服務(wù)總線這樣重量級(jí)的解決方案。

當(dāng)然，ESB 中分解流程信息的思想我們還是可以借鑒的，只不過我們可以用更簡(jiǎn)單的方法來實(shí)現(xiàn)。

EDA 的實(shí)現(xiàn)途徑

在 EDA 中，按照事件簡(jiǎn)易程度的不同，事件處理模型可以分為以下三種：

簡(jiǎn)單事件處理 (Simple Event Processing)

流事件處理 (Stream Event Processing)

復(fù)雜事件處理 (Complex Event Processing, CEP)

在一個(gè)成熟的事件驅(qū)動(dòng)架構(gòu)中，這三種往往會(huì)混合在一起使用。目前，很多公司都推出了支持 CEP 功能的產(chǎn)品。但是在實(shí)際應(yīng)用過程中，我們還是需要秉承由簡(jiǎn)入繁的原則。能用簡(jiǎn)單的事件處理解決問題，就沒必要使用復(fù)雜的。

實(shí)現(xiàn)事件驅(qū)動(dòng)架構(gòu)最簡(jiǎn)單、直觀的方式就是使用消息。在 JMS 的體系架構(gòu)里，我們很容易來實(shí)現(xiàn)事件驅(qū)動(dòng)的一些基礎(chǔ)元素：事件的生產(chǎn)者、消費(fèi)者和通道。下圖為在發(fā)布 / 訂閱模式下，消息發(fā)布者、訂閱者以及消息通道和主題之間的交互。

圖 2. 一個(gè)發(fā)布者、多個(gè)訂閱者、事件通道和主題之間的交互

嚴(yán)格意義上來說，事件和消息是不同的概念。消息代表非直接交互時(shí)簡(jiǎn)短的信息，而事件往往代表狀態(tài)的顯著變化。可以把事件看作消息的子類，因?yàn)楹笳哌€包括包含數(shù)據(jù)的消息等。而且，在實(shí)際應(yīng)用中，一個(gè)消息中往往同時(shí)包含事件和數(shù)據(jù)的內(nèi)容。比如系統(tǒng)接收客戶的訂單后，它會(huì)發(fā)布一條消息：其中既包括事件（新增客戶訂單），又包括新訂單的具體數(shù)據(jù)。

基礎(chǔ)組件

在確定了系統(tǒng)的架構(gòu)后，我們需要著手來實(shí)現(xiàn)它。經(jīng)過這么多年的實(shí)踐，人們也總結(jié)出一些基礎(chǔ)的組件，這些組件對(duì)于事件驅(qū)動(dòng)的面向服務(wù)架構(gòu)來說是必不可少的，或者說經(jīng)常被使用到的。

Web 服務(wù)基礎(chǔ)架構(gòu) （XML，SOAP，WSDL，UDDI 和 Quality of services）

企業(yè)服務(wù)總線（針對(duì)復(fù)雜應(yīng)用）

消息中間件

監(jiān)控體系

異常處理的討論

配置和規(guī)則引擎

其中第一、二項(xiàng)大家討論得最多，第三項(xiàng)也經(jīng)常被提及。作為消息運(yùn)轉(zhuǎn)的基礎(chǔ)，消息中間件（Message-Oriented Middleware，MOM）必須做到安全、可靠和快捷。市面上有很多很成熟的產(chǎn)品，比如 WebSphere MQ，Apache ActiveMQ 等。而且還有些針對(duì)特定行業(yè)的特色化產(chǎn)品，比如 WebSphere MQ Low Latency Messaging 是一款專門針對(duì)金融行業(yè)的中間件，用來滿足高吞吐量、低延遲的業(yè)務(wù)需求。

而后三項(xiàng)討論的并不多，但這些對(duì)于我們的應(yīng)用來說又都是非常關(guān)鍵的。我會(huì)在后續(xù)的文章中逐一進(jìn)行介紹。

圖 3. 各個(gè)子系統(tǒng)和基礎(chǔ)組件之間的協(xié)作

結(jié)束語

采用某個(gè)概念非常簡(jiǎn)單，我們實(shí)際需要的是如何結(jié)合自身項(xiàng)目的實(shí)際需求，真正地利用這些概念背后那些好的思想。利用這些智慧結(jié)晶來解決面臨的問題，這就需要大家多從實(shí)際出發(fā)來思考問題。很多時(shí)候，過多的概念只會(huì)讓你更加混淆，我們真正需要記住的不是這些名詞，而是這些名詞背后的思想——這些在軟件架構(gòu)中一直被傳承的東西。