[轉載]再談SOA和EDA關係

原文地址

http://blog.sina.com.cn/s/blog_493a84550100id77.html

在前面的一篇文章已經談到過，一個事件驅動系統典型地由事件消費者和事件產生者組成。事件消費者向事件管理器訂閱事件，事件產生者向事件管理器發佈事件。 當事件管理器從事件產生者那接收到一個事件時，事件管理把這個事件轉送給相應的事件消費者。 EDA事件驅動架構具有如下特點:

• 併發執行
• 事件觸發/數據觸發/時間規則觸發
• 實時/增量響應
• 分佈式事件系統處理

這裏首先可以看到EDA的重點是事件驅動，是實時/增量的響應。而對於SOA本身服務的同步機制就可以實現服務的實時響應，爲何還要引入EDA事件驅動架 構的概念？這是必須要搞清楚的問題。對於SOA中的同步服務一般是關於到兩個系統間，即A->ESB->B；但是很多時候實際的業務場景比這 個複雜，即到達B還沒有結束，B還需要去分發和通知消息和數據。即A->ESB->B->ESB->(C,D,E,F)，在這種 業務場景下如果簡單的談SOA的同步服務是無法解決該問題的。

因此EDA的實際應用場景是源系統->事件產生者->事件消費者，三者之間可能是多對1，然後1對多的機制。而對於1對多的處理正好和我們說 的發佈/訂閱模式是類似的 。即EDA仍然是一種異步模式，但是卻可以實現實時響應和併發執行，這就是EDA最大的一個特點。

這裏先再舉一個了發佈訂閱的例子：

張三開了一個書報亭，賣《時事快遞》這個雜誌，這個雜誌不是定期發行而是根據實際的時事和焦點發行。現在甲，乙，丙三人都喜歡看這個月刊，原來的方式可能是隔斷時間(定期輪詢機制)就去報刊亭看下，看是否有最新的雜誌可以購買，所以很多時候都空跑。

而新的方式是三人都給張三留下聯繫地址，告訴老闆只有有新的雜誌你就安排 人給我送過來(訂閱)，三人唯一要求就是要第一時間獲取到該雜誌，否則過期雜誌無意義(實時性要求)。這個時候張三還得跟雜誌社談，他告訴雜誌社出新期刊 後一定要第一時間送到報刊亭(雜誌社自己來說是很清楚是否產生了新期刊的)。

訂閱過程完成後，雜誌社將最新期刊送到報刊亭後返回(短週期事務，送到報 刊亭事務結束)。報刊亭一看有三個人訂閱了這個期刊(MQ消息隊列) ，然後安排一個人逐個開始送期刊給甲，乙，丙三個人。這個時候三人收到期刊的時間有差 異，但是基本可以保證期刊的實時性。或者老闆安排了三個人同時送貨(並行執行)，保證三個人更快的收到雜誌。

在送貨的過程中，可能乙沒有在家，這個時候報刊亭要暫時代存這本雜誌，然後第二天接着送。(存儲功能和異常重試功能) 。雜誌社只管送到報刊亭，而能否送到最終用戶手裏面是報刊亭的責任。

通過上面的例子，可以看到不同的場景和角色如下：

• 雜誌社：產生數據源的系統，往往是業務處理系統，如採購管理系統，合同管理系統。
• 報刊亭：ESB總線，必須具備消息隊列和臨時性的數據存儲，以支持逐個處理事件和支持重試。
• 甲乙丙：事件的消費者。首先是訂閱事件，然後等待新事件推送給自己。

上面這個例子是我們常見的EDA的實現機制，即通過Pub/Sub實現增量和實時的響應。在這個例子裏面可以看到ESB必須要有消息隊列，支持數據的臨時 存儲。對於訂閱信息也需要在ESB上面存儲，而不應該放在源系統和目標系統。通過這種方式可以看到，源系統將新增數據推送到ESB即返回，不用等待 ESB事件發佈完，因此大大縮短了事務週期，實現較好的解耦。通過ESB本身有消息隊列，支持異常下的重試，保證不會丟失數據。

從這個例子可以看到SOA服務和EDA的集成，對於訂閱可以直接封裝爲服務，通過調研服務進行訂閱。爲了保證訂閱數據能夠進入目標系統，目標系統還需要做 數據的導入服務，由ESB調用導入服務完成數據的推送。ESB本身也需要一個導入服務，保證源系統的數據能夠導入到ESB總線做臨時存儲。

通過上面的分析，我們再來理解下CEP複雜事件處理。

還是按上面的例子，甲乙丙希望他們的雜誌報刊亭能夠進行不同風格包裝後再送，或者各人還需要搭配其它東西一起送(業務規則)。在這個基礎上即轉變到 CEP。因此對於CEP的技術理解可以是EDA+規則引擎 ，即CEP完成三個重要的動作，首先是接收事件和實時檢測變化(多種方式，可以被動也可以主動監 聽)，然後是通過業務規則引擎對事件涉及的數據進行處理 ，最後是發佈事件和處理的結果給消費者。

從這裏可以看到業務規則和約束模型是CEP解決方案的核心，TIBCO BusinessEvents 採用類似於 Rapide 事件語言的模式。Rapide 語言是一種採用“事件-條件-行爲”(ECA) 形式的、功能全面的事件和規則語言。ECA 規則是獨立的單元，它由引擎根據狀態變化進行正向推理。