SOA之基於服務總線的設計

基於服務總線的設計

基於總線的設計，借鑑了計算機內部硬件組成的設計思想（經過總線傳輸數據）。在分佈式系統中， 不一樣子系統之間須要實現相互通訊和遠程調用，比較直接的方式就是「點對點」的通訊方式，可是這樣會暴露出一些很明顯的問題：系統之間緊密耦合、配置和引用 混亂、服務調用關係錯綜複雜、難以統一管理、異構系統之間存在不兼容等。而基於總線的設計，正是爲了解決上述問題。總線則做爲中樞系統，提供統一的服務入 口，並實現了服務統一管理、服務路由、協議轉換、數據格式轉換等功能。這樣可以將不一樣系統有效地鏈接起來，並大大下降了鏈接數（每一個子系統只須要和總線建 立鏈接）和系統間鏈接拓撲的複雜度。如圖所示：

 

基 於服務總線的設計，每每須要ESB（Enterprise Service Bus，企業服務總線）產品來充當基礎設施。ESB採用了「總線」這樣一種模式來管理和簡化應用之間的集成拓撲結構，以廣爲接受的開放標準爲基礎來支持應 用之間在消息、事件和服務的級別上動態的互連互通。 ESB是一種在鬆散耦合的服務和應用之間標準的集成方式。

在其內部設計和實現中，一般會應用到一些經典的架構模式，例如：Broker模式、消息總線模式、管道過濾器模式、發佈訂閱模式等。這裏，咱們將重點介紹這幾種核心的架構模式。

Broker模式

Broker 能夠看做是服務總線中的一部分，一般應用於同步調用的場景（調用服務後阻塞，等待遠程服務響應完成後再返回結果）。Broker能夠看做是代理、分發，意 味着對服務的調用，能夠直接經過Broker來完成。在軟件架構設計中，向已經存在（引用或者調用）關係的二者中間加入「第三者」是一種常見的解耦方式， 顯然，Broker也不例外。以下圖所示：

 

爲了進一步加深讀者對Broker模式的理解，這裏經過舉例來講明：

在 現實生活中，咱們須要租房子（能夠看做是一種服務調用），能夠經過幾種途徑來完成。第一，咱們能夠先在網上了解，而後跑到目標小區去詢問和看房，最後再找 房東籤合同等；第二，也能夠直接找附近的地產中介，說出咱們的要求和預算，請中介直接幫咱們搞定一切。很明顯，第一種方式，須要本身對目標有足夠的瞭解而 且還要親自去找房東籤合同（依賴具體，能夠看做是緊密耦合），而第二種方式，僅僅須要告知中介須要什麼便可完成租房，甚至都不須要知道哪一個小區有房子、房 東究竟是誰等這些信息（依賴抽象，並經過第三者來實現解耦）。固然，找中介雖然省事，也會產生額外的經濟開銷。同理，經過Broker來調用服務也可能會 產生必定的開銷。

 

消息總線模式

 

SOA系統有三種基 礎組件：消息總線、信息轉換/處理引擎和存儲庫。通常來講，這些組件會集成到ESB中，而在這些基礎組件中，消息總線是最重要的。消息總線主要應用於異步 通訊場景（投遞消息後馬上返回結果，而不用等待遠程系統返回執行成功），能夠大大提高響應速度和系統吞吐量。固然，消息總線也同時支持同步通訊模式。基於 消息總線模式的設計中，消息中間件屏蔽了系統間底層通訊的細節，是比較典型的（異步）鬆耦合的架構。

在企業中，隨着業務的逐漸發展，各大系統之間的調用交互變得很是頻繁，關係錯綜複雜。

想 象若是有幾十或者上百個系統（在保險、金融領域很常見），將變得難以維護。經過引入消息中間件，便能有效的解決這些問題。不一樣系統之間，只須要鏈接到消息 總線，能保證成功投遞/接收消息便可。對於消息投遞者（生產者）而言，根本不用關心消息的接收者（消費者）到底有哪些，也不用關心消費者接收到消息以後該 如何處理。對於接收者（消費者）而言，只須要關注與本身有關的消息，接收到消息後並作出相應的處理便可。以下圖所示：

比 較典型的應用場景：張三在CRM系統中錄入了一條客戶簽約訂單的信息並審覈經過後，CRM系統會向消息總線投遞一條消息（消息中包含必要信息，例如員工 ID，訂單編號，產品編號和交易金額等，而CRM系統不用關心有哪些系統會接受到該消息）。員工績效獎金管理系統訂閱了該消息主題，收到消息通知後開始處 理（給張三執行加獎金操做），同時，進銷存系統收到消息通知後也會即時地更新商品庫存的數量。這樣，便實現異構系統之間的鬆耦合、異步通訊。固然，真實場 景可能比這裏更復雜，可是實現思路上都大同小異。

 

在理解了上述實例以後，有必要了解下Java EE中被普遍應用和實現的JMS（Java消息服務）。

JMS是一種關於消息的規範，業界流行的ActiveMQ則是實現了JMS規範的開源消息總線。

JMS 支持兩種模式：發佈/訂閱模式和隊列模式（點對點模式）。其中，發佈/訂閱模式借鑑了現實生活中的出版社（發佈圖書）和讀者（訂閱圖書），消息的消費者 （讀者）只須要訂閱本身感興趣的消息（圖書）便可，消息生產者（出版社）生產（出版）了消費者（讀者）感興趣的新消息（新書）後，會通知消費者（讀者）接 受處理。在JMS發佈/訂閱模式中，一般以Topic（主題）來標識消息，是一對多的模式，意味着同一個主題能夠同時被多個消費者來訂閱和消費。而在 JMS 隊列模型中，一般以Queue name來標識消息，是一對一的模型，意味着同一條消息只能被一個消費者接收並消費（且只能被消費一次）。在生產者和消費者都是集羣的環境中，一般須要將 這兩種模式結合起來使用，狀況會複雜不少，並且須要考慮容錯性、負載均衡、消息一致性、消息優先級等複雜的問題。

業界主流的消息總線（消息中間件）產品，廣泛支持消息過濾、自動重試、分佈式事務、持久化、消息優先級、消息回溯、（生產者/消費者/中間件自身）集羣、故障轉移等高級特性。

 

 

總結

 

基於總線架構的主要優點在於：

l  可擴展性

使用消息架構，能夠在不影響現有應用的狀況下增長或移除應用。

l  低複雜度

每一個應用只須要和總線通訊，只有1個鏈接點，下降了應用程序集成的複雜度。

l  靈活性

對於構成複雜處理的應用程序通訊組來講，只須要改變配置和控制路由參數就能知足業務邏輯或者需求變動，而不須要更改服務自己。

l  鬆耦合

應用程序直接和消息總線通訊，不依賴其它應用程序，所以能夠替換和修改。

l  可擴展性

能夠把多個應用程序附加到總線上，進行併發處理，達到負載均衡的目的。

 

基 於總線的模型，能夠面向同構和異構系統（跨平臺）。當前主要應用於傳統企業應用的整合與系統集成中（例如：電信、保險、金融等行業）。因爲基於總線的模型 是一種集中式的架構，總線自身容易造成性能瓶頸，並且在實現高可用和容錯性方面的複雜度和成本相對較高。因此，該模式並非很適合於高併發、高性能、高吞 吐量的互聯網應用。

 

注：關於消息總線（消息中間件）的知識點不少，在實際應用中還有不少更加深刻和複雜的細節問題。因爲篇幅問題，筆者就不作過多的細節介紹和展開，感興趣的讀者，能夠自行去查閱相關資料或者參考開源產品，作深刻的學習和研究。

ESB產品主要包括：開源Mule ESB、ServiceMix、JBoss ESB，商業的Oracle ESB、BEA AquaLogic ServiceBus，.NET領域的NService Bus、MassTransit等。

MQ產品主要包括：ActiveMQ、RabbiteMQ、ZeroMQ、RocketMQ、Kafka、MSMQ等。