EDA 和 SOA
SOA 簡介
事件驅動架構 (Event-Driven Architecture，EDA) 簡介
可以從兩個方面來理解 EDA：
- EDA 是一種側重于以生成/消費為基礎的異步通信的架構模式。這主要對照于傳統的基于線程的同步系統。
- EDA 是一種以事件 (event)為核心，提供事件產生，路由，消費已經結果回調等機制的架構模式。
簡單地說， 面向服務架構 (Service-Oriented Architecture, SOA) 是一種 IT 架構策略，其基于面向服務的概念之上。自從 2002 開始為大家熟知以來，SOA 已經逐漸地成為業界的標準，也得到了廣泛的應用。
SOA != Web Service
因為 SOA 經常和 Web Service 相提并論，所以導致大家一直有一個誤區，認為這兩者是等同的，其實不然。雖然兩者有很多的關聯，但它們是截然不同的兩個概念，或者說考慮問題的角度不同。雖然 SOA 最初的流行離不開 Web Service 的貢獻，但如今 SOA 早已超越了 Web Service 的范疇，變成一個獨立的設計理念。
SOA 的局限性
SOA 主要從系統解構的角度入手，它側重于將整個應用分解為一系列獨立的服務，并指定各種標準和基礎設施來使得這些服務易于重用，能夠很容易地被各種平臺上的應用來使用。但是在服務實際業務時出現了一些問題，因為 SOA 更多地是關注靜態的信息，所以不能很好地與動態業務匹配。比如 SOA 不能很好地回答類似下面的一些問題：
比如在一個證券公司，有很完善的交易系統、后臺系統、賬務系統和頭寸管理系統等，當一個客戶的下單在交易所執行后，所有的這些系統都應該得到通知，并做出相應的處理。這里面其實包含了幾個問題：誰來負責觸發這樣一個事件，各個系統如何得到通知？如何保證各個系統行動的一致性？ SOA 架構由于其關注點的限制，并不能很好地解決上述問題，而這些問題往往又是實際系統非常需要的特性。因此，EDA 與 SOA 的集成引起了人們的注意。
通過引入面向事件的機制，使得系統具備了感知和快速響應業務事件的能力。其實不管是 SOA 還是 EDA 都不是什么新技術，無非是在一些舊的概念上添加了一些新元素。
什么是事件（Event）？
事件就是狀態的顯著變化，比如說前面提到的客戶下單被執行。從來源來分，事件可以分為系統內部事件和外部事件。從類型來分，可以分為業務事件和系統事件。
其實你可以從 SOA 或 EDA 的身上很容易看到以前的技術 ( 比如 CORBA 或者 DCOM) 的影子。任何系統都可以簡化為組件 / 服務加上通道 (channel，解決通訊的問題 )，如果說 SOA 關注于組件和服務的話，那么 EDA 更多地關注通道。
回頁首
Event-Driven SOA
我們一般將 SOA 和 EDA 的集成體稱之為事件驅動的面向服務架構 (Event-Driven SOA)，可以將其理解為 SOA 的一種衍生。SOA 和 EDA 的交互主要體現在以下幾個方面：
將事件處理的能力引入到 SOA
一個事件的產生可以觸發一個或多個服務被調用，這樣就把這些靜態的功能動態地串聯起來。
服務本身也可以產生事件
服務除了完成特定的功能外，也可以根據自身需要產生某個事件。
有人將 EDA 和 SOA 的關系與人體做了一個形象的比喻，如果把 SOA 比作手和腳的話，那 EDA 就像人的眼睛和耳朵。當眼睛發現一只獅子正朝你奔來時，一個消息被發送到大腦，然后大腦向你的手腳發出指令：趕快跑。
回頁首
Event-Driven SOA 架構的特點
當然，任何一種架構模式都有其適用的場景，Event-Driven SOA 自然也不例外。
首先，它適用于異步的環境。如果你的系統對實時性要求比較高，請不要使用該架構。
第二，如果你的系統需要面對復雜的異構環境——跨平臺 / 跨語言，那么面向服務的架構能夠很好地應對。
第三，將系統功能分解為適當粒度并且重用性高的一個個服務，可以顯著地提高 IT 系統的適應性和效率，進而提高投資回報率 (ROI)。
第四，引入事件處理的能力以后，每個服務都是由不同的事件驅動，這樣當某個事件發生后，系統的不同服務就能夠自動地進行觸發。這對那些有更高自動化要求的系統來說非常適合。
第五，與面向過程的系統中客戶端必須輪詢更改請求 ( 通過 API 調用 ) 不同，事件驅動架構允許系統和組件在事件發生時實時動態地做出響應。事件驅動架構通過引入長時間運行的處理功能來彌補 SOA 的不足。這一點對于金融系統來說尤其重要，比如說一次股票買賣從客戶下單到最終交割會經歷幾天的生命周期。
最后，Event-Driven SOA 使得增加事件的 consumer 和 producer 非常容易，這樣就使得增加系統吞吐量也變得很簡單，系統的彈性非常好，非常適合那些業務量持續增加的系統。在這方面，有一個 EDA 的變體 SEDA（Staged Event-Driven Architecture）將這方面的設計發揮到了極致，詳細的介紹請參考正文后的參考資料。
回頁首
Event-Driven SOA 在金融系統的應用
金融系統的實際需求
在當今社會，市場變化莫測，商機稍縱即逝，企業需要有極強的靈活性和應變能力，金融行業尤其如此，特別是在中國這樣一個金融行業處于快速發展的市場里。企業要求 IT 系統能夠快速地對業務需求做出應對，否則就會喪失先發優勢。這有點類似于現代戰爭條件下，各國都要求部隊具備快速反應能力，這種能力主要體現在 IT 部門能夠通過快速開發或者重用 / 整合現有資源來達到快速響應業務需求。還有，金融行業業務越來越龐大復雜，所涉及的第三方系統或者遺留系統非常多，這就要求 IT 系統有很強的整合能力及對異構環境的適應能力。最后，由于金融行業的發展日新月異，特定金融業務都會在其初期發展后迎來一個快速膨脹期，業務量和業務類型會急劇增加，這也要求 IT 系統有很好的可擴展性。
對照前面提到的 Event-Driven SOA 的特點，我們可以很直觀地發現該架構可以很好地滿足金融系統的實際需求。當然，金融系統也是包羅萬象，特點各不一樣，這里可能更偏重于金融行業的交易系統。
為什么選擇 Event-Driven SOA ——適用性討論
除了上面提到的這些大的因素之外，我們還可以深入到具體系統的內部，從一些微觀層面來考慮 Event-Driven SOA 是否仍然能夠符合我們的要求。下圖是一個證券公司股票交易系統的簡圖：
圖 1. 證券公司股票交易系統概略圖
從上圖我們可以看出，整個應用被分為很多子系統，各個子系統之間存在著大量的信息交互。而且大部分應用輸入都需要經歷一個比較長的生命周期，比如說一個客戶訂單輸入到系統后，會先后經歷前臺系統 (Front Office)，中臺系統 (Middle Office) 以及后臺系統 (Back Office)，而且每個系統內部又包括很多服務組件。除了系統層面的跨度外， 這個生命周期也體現在時間長度上。而且，如今所有的金融系統都追求 STP (Straight Through Processing) 的能力，主張盡可能少的人工干預，這樣所有的服務組件都需要具備自觸發的能力。
" src="/CuteSoft_Client/CuteEditor/Images/anchor.gif">回頁首
Event-Driven SOA 架構設計
架構師在著手每次的架構設計時，其實都是在提出并回答一系列的問題，把這些問題都回答了，架構設計也就出來了。比如我們每次肯定都會問：系統的最終用戶是誰，他們會如何來使用該系統，他們的核心訴求是什么。當然，不是所有的問題都能有一個圓滿的答案，更多的時候其實是一個取舍的過程。比如說系統的關鍵指標我們很難一下子全部滿足，就需要結合具體的業務需求和人力物力以及時間的具體情況來做取舍。下表就列出了一些我在做 Event-Driven SOA 架構設計時認為比較關鍵的問題（在遵循一般架構設計的原則的基礎之上），看看你是否也有同感。
表一：Event-Driven SOA 架構設計時的幾個關鍵考慮| 領域 | 關鍵考慮 |
|---|
| 設計原則 | 業務為先 |
| 堅持簡單適用的原則 |
| 系統的關鍵指標有哪些？互聯互通最重要 |
| 設計演變 | 功能分解，服務定義，事件的定義及分類 |
| 基礎架構的選擇 |
| EDA 的實現途徑 |
| 最佳實踐 | 如何重用已有的基礎組件 |
下面我就其中的幾點具體展開討論一下：
業務為先
任何的技術或者架構思想都是由具體的業務需求驅動的，比如 SOA 的出現是由于人們打破豎井應用 (application silos) 并追求功能重用的強烈需求，而 EDA 的出現也迎合了業務流程化、自動化的趨勢。所以，任何的架構設計都要服從于自身業務的具體需求，沒有最好的架構設計，只有最合適的。
在 SOA 實踐中，尤其強調業務為先的原則，因為我們必須先進行業務流程的整合重組，然后才是 IT 系統的服務化。業務流程本身的問題還是需要從業務本身去解決，再好的技術也解決不了業務的問題。試想一下，如果一個企業各個部門之間各自為戰，缺乏協作和溝通，那么可能開發出一個好的面向服務的 IT 系統嗎？
除了業務部門的努力外，IT 部門在做任何架構設計的決定前，必須確保理解清楚了業務部門的具體需求。所以說，項目前期 IT 部門和業務部門之間的協作和交流非常重要。
這里很容易有一個誤區，尤其是對那些經驗豐富的架構師。他們往往擁有豐富的 IT 經驗和業務知識，自認為已經非常了解業務部門的需求，甚至有些時候都能夠指導業務部門如何去改進。在這種自負的情緒中，他們覺得可以先把所謂先進的 IT 系統開發出來，然后再去推廣，他們認為用戶肯定會欣然接受這些系統，因為他們代表著先進的理念，但往往事與愿違。姑且不去深究究竟孰對孰錯，退一萬步講，一個沒有充分聽取用戶意見，沒有用戶參與的系統能夠那么容易得到用戶的認可嗎？即便你是對的。
互聯互通
在 Event-Driven SOA 的實施過程中，有幾個關鍵指標：服務的分類和創建，事件的定義和管理，服務的互聯互通，業務流程的理解和 IT 實現等。那我們應該更加關注哪個指標呢？因為我們往往很難一下子兼顧所有的指標。個人認為這其中最重要的就是服務的互通互聯。當然這里所講的互通互聯并沒有那么簡單，并不是僅僅建立起通訊的通道就可以，它包括以下幾個方面的內容：
實現通訊的方式有很多種：同步調用，異步消息，Socket 甚至是文件，無論采用哪種，最好做到自動化的實現。任何人工的干預都容易引起錯誤和延遲。
- 通訊的雙方之間需要定義清晰的接口，有共同的異常應對機制
特別是當通訊的雙方是由不同的開發團隊來完成，一定要在開始階段就定義清楚接口，并在隨后的開發過程中嚴格遵守，同時保持實時的溝通。這里面需要強調的一點就是異常的應對機制，要讓雙方都充分理解可能面對的異常情況及應對措施。
在金融系統中，會用到大量的基礎數據（一般稱之為 Reference Data），這些數據在各個系統都會用到。但事實上情況往往并不如此，經常是各個系統各自為戰，不用或者是使用不同的數據源，導致在通訊過程中的識別歧義。
做到以上這些，技術上并不困難，更重要的是項目之間的協作和執行力強的領導團隊。
結合到實際的例子，比如美國三軍聯合作戰系統，其核心就是其“數據鏈”系統，它使得戰場上的指揮中心、作戰部隊和武器平臺能夠實時交換數據，達到精確協作的目的。從下面這段描述我們就能感受到這種高效無縫協作的威力：
“在 7 年之后的海灣戰爭中，初級的“數據鏈”就已顯威戰場。以美軍攔截導彈作戰為例，就可以看到“數據鏈”的作用。伊軍的“飛毛腿”導彈一發射，12 秒鐘之后，位于太平洋上空的美國防支援計劃（DSP）的導彈預警衛星就發現了“飛毛腿”，并迅速測出它的航行軌道及預定著陸地區，報警信息及有關數據迅速傳遞到位于澳大利亞的美國航天司令部的一個數據處理中心，數據中心的巨型計算機緊急處理這些數據之后，得到對“飛毛腿”導彈進行有效攔截的參數，然后航天司令部將這些參數通過衛星傳給位于沙特阿拉伯的“愛國者”防空導彈指揮中心。防空導彈指揮中心立刻將數據裝填到“愛國者”導彈上并發射，整個過程只需要 3 分鐘左右的時間，而“飛毛腿”至少要飛行 4 ～ 5 分鐘才能到達預定目標的上空，這就為攔截導彈創造了條件。…”
設計考慮
在明確了以上這些設計原則外， 我們需要一步步考慮整個架構的實現途徑。首先面臨的就是一些基礎架構的選擇。
在這里我們需要回答一系列的問題：自己開發還是購買？開源的還是商業的？選擇什么 Web Service 的基礎平臺？選擇什么樣的消息中間件（Message Oriented Middleware, MOM）？是否采用企業服務總線（Enterprise Service Bus, ESB）？
這其中討論的最多的就是是否以及如何使用 ESB。個人觀點，ESB 是有價值的，僅當系統確實需要 ESB 的功能時。Accenture 首席技術官 Don Rippert 在他的一次早期訪談中提到發揮 SOA 的全部潛力大致需要以下 4 個步驟：
- 開始采用 SOA 架構，使用 XML 等標準的方式來使用應用程序接口
- 捕獲一些業務過程，并將它們轉化為 Web 服務
- 引入并全面使用企業服務總線
- 將業務過程執行語言（Business Process Execution Language, BPEL）集成進來，利用業務過程建模工具和 BPEL 可以創建不同的應用行為，而無需修改軟件
為什么將 ESB 的使用放在第三個步驟呢，那我們需要從 ESB 的定義入手，來了解 ESB 究竟帶給我們些什么。ESB 應該被理解為模式而不是產品，它應該至少具備以下這些功能：
- 服務的虛擬化，支持虛擬化通訊參與方之間的服務交互并對其進行管理。意思就是服務只需要關注完成自己的功能，不需要關心哪個服務調用它以及它需要調用哪個服務。
- 服務的轉化、包裝以及橋接
- 消息的傳遞、過濾以及路由
- 服務編制（Orchestration）
還記得前面將 EDA/SOA 和人體進行類比的例子嗎？如果按照該思路，ESB 就可以看作是人體的中樞神經系統。其接受眼睛傳入的“獅子來了”的信息，整體加工后成為協調的運動性傳出，手腳也就開始動作了。
從上面的定義可以看出，ESB 更多地關注應用流程方面的信息，將業務流程剝離出來并將其交由 ESB 來統一管理。因此，有一個非常簡單的標準來判斷是否需要采用企業服務總線：就是看你的應用本身是否有很復雜的業務流程，而且可能這些流程會經常發生變化。依據這條標準，我覺得很多應用一開始都沒有復雜到需要立即采用企業服務總線，比如說一個股票的后臺管理系統，其業務流程相對來說比較簡單固定，就沒有必要引入企業服務總線這樣重量級的解決方案。
當然，ESB 中分解流程信息的思想我們還是可以借鑒的，只不過我們可以用更簡單的方法來實現。
在 EDA 中，按照事件簡易程度的不同，事件處理模型可以分為以下三種：
- 簡單事件處理 (Simple Event Processing)
- 流事件處理 (Stream Event Processing)
- 復雜事件處理 (Complex Event Processing, CEP)
在一個成熟的事件驅動架構中，這三種往往會混合在一起使用。目前，很多公司都推出了支持 CEP 功能的產品。但是在實際應用過程中，我們還是需要秉承由簡入繁的原則。能用簡單的事件處理解決問題，就沒必要使用復雜的。
實現事件驅動架構最簡單、直觀的方式就是使用消息。在 JMS 的體系架構里，我們很容易來實現事件驅動的一些基礎元素：事件的生產者、消費者和通道。下圖為在發布 / 訂閱模式下，消息發布者、訂閱者以及消息通道和主題之間的交互。
圖 2. 一個發布者、多個訂閱者、事件通道和主題之間的交互
（圖片來自 http://www.ibm.com/developerworks/cn/opensource/os-ag-eventdriven/index.html）
嚴格意義上來說，事件和消息是不同的概念。消息代表非直接交互時簡短的信息，而事件往往代表狀態的顯著變化?？梢园咽录醋飨⒌淖宇悾驗楹笳哌€包括包含數據的消息等。而且，在實際應用中，一個消息中往往同時包含事件和數據的內容。比如系統接收客戶的訂單后，它會發布一條消息：其中既包括事件（新增客戶訂單），又包括新訂單的具體數據。
基礎組件
在確定了系統的架構后，我們需要著手來實現它。經過這么多年的實踐，人們也總結出一些基礎的組件，這些組件對于事件驅動的面向服務架構來說是必不可少的，或者說經常被使用到的。
- Web 服務基礎架構 （XML，SOAP，WSDL，UDDI 和 Quality of services）
- 企業服務總線（針對復雜應用）
- 消息中間件
- 監控體系
- 異常處理的討論
- 配置和規則引擎
其中第一、二項大家討論得最多，第三項也經常被提及。作為消息運轉的基礎，消息中間件（Message-Oriented Middleware，MOM）必須做到安全、可靠和快捷。市面上有很多很成熟的產品，比如 WebSphere MQ，Apache ActiveMQ 等。而且還有些針對特定行業的特色化產品，比如 WebSphere MQ Low Latency Messaging 是一款專門針對金融行業的中間件，用來滿足高吞吐量、低延遲的業務需求。
而后三項討論的并不多，但這些對于我們的應用來說又都是非常關鍵的。我會在后續的文章中逐一進行介紹。
圖 3. 各個子系統和基礎組件之間的協作
回頁首
結束語
采用某個概念非常簡單，我們實際需要的是如何結合自身項目的實際需求，真正地利用這些概念背后那些好的思想。利用這些智慧結晶來解決面臨的問題，這就需要大家多從實際出發來思考問題。很多時候，過多的概念只會讓你更加混淆，我們真正需要記住的不是這些名詞，而是這些名詞背后的思想——這些在軟件架構中一直被傳承的東西。
參考資料
學習
獲得產品和技術
討論
關于作者
王和全，專注于金融 IT 行業，期望與更多同道之人多交流。您可以通過 wanghequan2010@126.com 與他聯系。
為本文評分
平均分 (5個評分)
評論
請 登錄 或 注冊 后發表評論。
注意：評論中不支持 HTML 語法
“消費已經結果回調等機制的架構模式。”里面的已經是否應為“以及”？謝謝！
由 未知目標 于 2014年05月14日發布
報告濫用
回頁首