EDA 和 SOA 的融合以及實踐

申請免費試用、咨詢電話：400-8352-114

EDA 和 SOA

SOA 簡介

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

可以從兩個方面來理解 EDA：

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

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

簡單地說， 面向服務(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

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

SOA 的局限性

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

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

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

什么是事件（Event）？

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

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

Event-Driven SOA

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

下面我就其中的幾點具體展開討論一下：

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

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

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

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

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

互聯(lián)互通

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

無論通訊的方式如何，最好做到自動化

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

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

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

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

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

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

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

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

設(shè)計考慮

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

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

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

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

開始采用 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）集成進來，利用業(yè)務(wù)過程建模工具和 BPEL 可以創(chuàng)建不同的應(yīng)用行為，而無需修改軟件

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

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

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

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

服務(wù)編制（Orchestration）

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

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

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

EDA 的實現(xiàn)途徑

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

簡單事件處理 (Simple Event Processing)

流事件處理 (Stream Event Processing)

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

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

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

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

嚴(yán)格意義上來說，事件和消息是不同的概念。消息代表非直接交互時簡短的信息，而事件往往代表狀態(tài)的顯著變化?？梢园咽录醋飨⒌淖宇?，因為后者還包括包含數(shù)據(jù)的消息等。而且，在實際應(yīng)用中，一個消息中往往同時包含事件和數(shù)據(jù)的內(nèi)容。比如系統(tǒng)接收客戶的訂單后，它會發(fā)布一條消息：其中既包括事件（新增客戶訂單），又包括新訂單的具體數(shù)據(jù)。

基礎(chǔ)組件

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

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

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

消息中間件

監(jiān)控體系

異常處理的討論

配置和規(guī)則引擎

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

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

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

結(jié)束語

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