SOA和EDA:用事件跨越解耦合服務邊界(1)

各種機構趨向于頻繁的改變他們自身的結構。對面向服務和全球化的日益重視加強了這種趨勢。結果，世界上大部分的組織都準備好迎接以獨立、自治的服務供應商和服務消費者為特點的、以網絡為中心的商務結構?，F有的部分商業流程將被外包給外部的合作伙伴，同時組織的各個部分和業務單位被轉型為服務供應商。這些服務供應商不再僅僅只關注機構的內部，而且同樣會在外部市場中尋求一席之地。

所有的一切都朝著隨需應變(on-demand)的商業模式發展，在這種模式下，服務供應商對來自于外部環境的刺激——事件——做出反應。為了在一個充滿競爭的市場中勝出，他們需要一種高層次的自治性，包括能夠自由的選擇合適的支持系統。分離程度的擴大能夠產生出對于敏捷性的需求，當組織的構成不斷變化時候，在服務之間的松耦合能夠支持業務的連續的、不受阻礙的發展。

為了達到“真正的”敏捷性，支撐的應用系統必須做到對于機構的各種改變不可知，這些變化包括變化的責任和角色，外包或者內包，部門的拆分或者加強等等此類的重組。此外，業務流程適應機構變化的敏捷性必須不會受到支持它們的IT系統的限制。所有這些要求都可以用松耦合來滿足。降低耦合的服務更容易在不干擾現有IT支持系統連續性的基礎上，改造組織的結構。這就是所謂的機構敏捷性的基礎。

應用搭建上的靈活性可以通過在定義良好的功能邊界內使用共享的服務來完成?；跇藴实募夹g對于敏捷性做出貢獻，主要是能夠解決對應用快速交付市場的擔心(只要這些標準已經成熟并且采用了合適的工具)。敏捷性緊緊依賴于為了重新設計商務流程而對應用進行重構增加敏捷性的能力。最終的結果是降低的IT成本和更快的項目交付周期。

EDA和SOA都承諾能夠增加整個機構層面上的敏捷性，但是兩者采用不同的方式來做到。

EDA和SOA的關系

雖然EDA和SOA擁有共同的目標，我們如何知道何時使用事件驅動或面向服務的方法呢?那么讓我們仔細想想在什么情況下，這兩者種構架方式是最合適的。

和傳統的分布式架構不同，EDA并不提倡同步的、命令-控制的消息交換模式。相反，它采用了基于異步的、發布-訂閱模式，在這種方式下，發布者完全不知道訂閱者的存在，反之亦然。服務的松耦合就意味他們只共享消息的語義。

假如你試圖做到商業流程中各個步驟之間的獨立性，那么EDA可以提供巨大的好處，尤其在聯合的、自治的處理環境中。EDA被公認合適處理以下的情況：

• 流程鏈中各個層之間的水平通訊
• 需要跨越公認的功能單位邊界的流程(包括內部和外部的邊界)
• 需要跨越物理單位界限的流程

然而，當試圖利用商務流程中的內聚性的情況下，SOA則可以提供巨大的好處。它可以適用于以下的一些情況：

• 功能分解之后上下等級之間的垂直交互
• 功能上屬于請求-應答類型的流程，比如人機對話的時候，用戶等待應答
• 具有交易特點的、具有提交及回退性質的流程

類似于EDA，SOA被經常通過消息框架來實現，該消息框架同樣是利用異步消息模式來實現的請求-應答通訊。通過將請求的發行者和應答的消費者分離，同樣將請求的消費者和應答的發行者分離，讓系統的松耦合。但是，由于存在著一種普遍的誤解，認為采用SOA就意味著使用Web Service所采用的那種(緊耦合的)RPC類型的架構，因此很多SOA實現采用了傳統的、根生蒂固的同步交換模式。

為了建立一個SOA和EDA和諧共處的環境，有必要進行一些前期的分析。一個具有建設意義的準備步驟如下：

• 1. 為商業需求建立一定粒度級別的功能模型，該粒度級別能夠滿足預期的自治性
• 2. 勾畫出該應用的地形圖以便識別出受到影響的系統
• 3. 將應用的地形圖映射到對應的商業功能模型
• 4. 鑒別出那些跨越功能邊界的應用，它們是潛在的“敏捷性瓶頸”(對于那些需要跨越機構的外部邊界的應用請給予較高的優先級)

其中第4步是在下面的章節中將會進一步討論的解耦合服務邊界(decoupled service boundaries)的基礎。當我們尋找系統中的某些位置，在這些位置上EDA的發布-訂閱模式可以作為連接這些邊界、同時允許各個邊界保持自己解耦合的狀態的一種方式的時候，這些跨越邊界的通訊正是我們感興趣。

完成這樣一個簡單的流程，可以為引入一定程度的松耦合奠定基礎，同時確定一個好的開始點，將這張技術地形圖改進成兼俱SOA和EDA優點的、現代的、靈活的、可適應的環境。

松耦合和“解耦合點”

松耦合意味著獨立。簡單的說，松耦合的服務對彼此的依賴要比緊耦合的服務小。這個規則同樣適合于功能和數據。當某個服務相關的數據被僅僅局限在該服務的功能邊界內的時候，服務之間的耦合度就會增加(拉緊)。這種設計方法會增加服務之間為了訪問被孤立的數據而形成對彼此依賴的概率。當以數據復制、避免保證數據傳輸和語義一致性的共享層之外的其他層共享等機制實現的數據冗余被允許的情況下，服務之間的耦合程度會降低(松開)。

保證跨越解耦合邊界的數據冗余讓松耦合更加強健。EDA適合這種情況，由于它支持在冗余環境中的數據的自動一致性。

當使用SOA和EDA的時候，找到“解耦合點”通常被證明很多幫助。這是通過尋找某些經常同時出現的商業流程部分，這些部分你可以確認它們會一起出現在任何一個組織單位中(具有強烈的內聚性和原子類型的業務功能)。它們就是“解耦合點”。這樣，商業流程的功能構成會變得清楚。在各個業務功能之間的邊界就是解耦合點。如果原子交易跨越了解耦合邊界，那么回滾交易就需要在這些解耦合點實現。

圖1：如何安排事件來跨越解耦合服務的邊界

圖1闡明了SOA和EDA之間一種可能的關系。在頂上的圓圈表示連接單個松耦合系統的解耦合點(事件)。無論在這些解耦合點上的服務是連接還是斷開，都不會影響被連接的系統。不同域之間的所有的數據交換都發生在這些點，而不是在底下的層次。

在一個可重用的域(在圖1位于底層)中，EDA的粒度可以進一步精細。EDA的粒度越精細，系統的靈活性也就好，盡管可重用的域也就越小。

假如在解耦合點使用基于SOAP的Web Service的技術，同時結合通用的基礎架構(例如企業服務總線，enterprise service bus)，那么和其他異構系統系統的連接將會變得很容易，包括SOAP包裝的遺留系統，商業現貨供應軟件(COTS)，ERP系統和外部系統的網關等(如圖2所示)。

圖2：服務不再被直接耦合，而是通過由事件表示的解耦合點來連接

當談到EDA和SOA，為了松耦合而奮斗——也可以說是為了靈活性和敏捷性——從所有的粒度級別來講，都不失為一個好主意。當然，松耦合必須在現實的條件下慢慢實現，尤其是考慮到運行效率的時候。