SOA EDA 事件驅動架構 (Event-Driven Architecture，EDA) 簡介

 

事件驅動架構 (Event-Driven Architecture，EDA) 簡介

能夠從兩個方面來理解 EDA：

1. EDA 是一種側重於以生成/消費爲基礎的異步通訊的架構模式。這主要對照於傳統的基於線程的同步系統。
2. 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) 的能力，主張儘量少的人工干預，這樣全部的服務組件都須要具有自觸發的能力。

 

回頁首

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 的實現途徑

在 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）
• 企業服務總線（針對複雜應用）
• 消息中間件
• 監控體系
• 異常處理的討論
• 配置和規則引擎

其中第1、二項你們討論得最多，第三項也常常被說起。做爲消息運轉的基礎，消息中間件（Message-Oriented Middleware，MOM）必須作到安全、可靠和快捷。市面上有不少很成熟的產品，好比 WebSphere MQ，Apache ActiveMQ 等。並且還有些針對特定行業的特點化產品，好比 WebSphere MQ Low Latency Messaging 是一款專門針對金融行業的中間件，用來知足高吞吐量、低延遲的業務需求。

然後三項討論的並很少，但這些對於咱們的應用來講又都是很是關鍵的。我會在後續的文章中逐一進行介紹。

圖 3. 各個子系統和基礎組件之間的協做
 

 

回頁首

結束語

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

 

參考資料

學習

• SOA 快速指南 1 2 3：IBM 的系列教程，介紹 SOA 項目實施中的經驗結晶
  
  
• 「Service-Oriented World」 Cheat Sheet by Patricia Seybold Group (Brenda M. Michelson June 2, 2005)：一篇很好的 SOA 入門文章，介紹了 SOA 相關的關鍵概念和技術等。
  
  
• EDA and SOA：將 EDA 和 SOA 進行對比
  
  
• What really is SOA. A comparison with Cloud Computing, Web 2.0, SaaS, WOA, Web Services, PaaS and others：經過將 SOA 與其它技術對比來理解 SOA 的本質。
  
  
• SEDA: An Architecture for Highly Concurrent Server ApplicationsSEDA 的概念最先是由 Matt Welsh 在其博士論文中提出的。若要進一步瞭解 SEDA，能夠研究 Mule，它的架構就是基於 SEDA。
  
  
• Event-Driven SOA: A Better Way to SOA：TIBCO 宣揚 Event-Driven SOA 的文章，能夠學到一些概念。
  
  
• Why ESBs are Made for Event-Driven Architecture：強調 ESB 在事件驅動架構中的核心地位。
  
  
• 使用Apache Geronimo 和 JMS 構建事件驅動的框架 (J. Jeffrey Hanson, 2006 年 9 月 28 日 )。
  
  
• IBM developerWorks 中國 WebSphere 專區：爲使用 WebSphere 產品的開發人員準備的技術信息和資料。這裏提供產品下載、how-to 信息、支持資源以及免費技術庫，包含 2000 多份技術文章、教程、最佳實踐、IBM Redbook 和在線產品手冊。
  
  

得到產品和技術

• 最受歡迎的 WebSphere 試用軟件下載：下載關鍵 WebSphere 產品的免費試用版。
  
  
• IBM developerWorks 軟件下載資源中心：IBM deveperWorks 最新的軟件下載。
  
  
• IBM developerWorks 工具包：下載關鍵 WebSphere 最新的產品工具包。
  
  

討論

• My developerWorks BPM 羣組：爲開發人員設立的 BPM 羣組，瞭解業務流程管理解決方案的最新技術資源。
  
  
• My developerWorks 中文社區