微服務擴展新途徑：Messaging

【編者按】服務編排是微服務設置的一個重要方面。本文在利用 ActiveMQ 虛擬話題來實現這一目標的同時，還會提供實用性指導。文章系國內 ITOM 管理平臺 OneAPM 編譯呈現。

目前，微服務使用已十分廣泛，利用服務編排（而不是服務編制）來進行微服務互動的想法也很常見。本文將講述如何經過 ActiveMQ 虛擬話題來設置服務編排和基於服務互動的可擴展事件。

服務互動類型

服務互動類型主要有兩種：同步和異步。

在同步互動中，服務使用者會發出請求，而後在操做完成、收取回復前阻止其餘活動運行，HTTP 協議就是一個很好的同步互動例子。一般狀況下，這種互動與請求-回覆互動類型、 HTTP 協議都是相關的（固然，也能夠利用異步請求或消息傳遞來登記、請求回調函數的結果，不過這種作法不太常見）。

在異步互動中，服務使用者發出的請求不用在操做完成後才能夠運行。一旦請求確認被收到，服務使用者就能夠接着作其餘的活動。這種類型支持互動溝通採用發佈-訂閱模式，例如：不須要服務使用者調用其餘服務操做，只須要生產者提出事件，等待感興趣的使用者作出反應便可。

除了這些技術層面的考慮，還應該注意考量服務互動的其餘層面：耦合和責任。

若是服務 A 要和服務 B 互動，是要服務 A 來調用服務 B（編制），仍是讓服務 B 去訂閱正確的時間（編排）呢？

在服務編制中須要有一箇中心實體（即例子中的服務 A），去了解被調用的其餘服務。利用編排方法，能夠將這個責任分配給個體服務，由它們來負責訂閱「有意思的」事件。

若是想要了解更多關於本話題的內容，請查閱 Building Microservices。接下來，本文將集中討論如何使用消息傳遞實現服務編排。

經過消息傳遞進行服務編制

服務編制是經過隊列實現消息傳遞的。隊列可以在競爭使用者模式下實現負載均衡，而且確保消息和使用者一一對應。

假設存在一個與「郵件服務」互動的「客服服務」，最簡單的實現方法就是使用一個容許「客戶服務」給「郵件隊列」發送消息的隊列。若是「客戶服務」須要跟「忠誠值服務」互動，「客戶服務」就要給「忠誠值服務」再發一條消息。這種辦法下，「客戶服務」須要瞭解「郵件服務」和「忠誠值服務」這二者，而且把正確的消息發給對應的隊列。簡而言之，整個互動過程都是由「客戶服務」編制的。

使用隊列的一個好處就是它能夠輕鬆擴展使用者，並開啓多個「忠誠值服務」和「郵件服務」，從而將負載均衡地分佈於不一樣的使用者間。

經過消息傳遞進行服務編排

使用服務編排方式時，「客戶服務」卻不須要了解「忠誠值服務」和「郵件服務」。由於「客戶服務」只要對「客戶話題」發出一個事件，「忠誠值服務」和「郵件服務」就會去了解客戶事件協議，並訂閱正確的話題——話題的發佈-訂閱語意會確保每一個事件同時被分發給兩個訂閱者。

擴展服務編排

話題執行發佈-訂閱，而不是競爭使用，這使得使用者的擴展變得更加困難。若是（橫向）擴展「忠誠值服務」並在兩個實例中進行試驗，能夠發現它們會收到一樣的事件，這樣擴展的話並無什麼益處（除非服務是等冪的）。

ActiveMQ 虛擬話題解決方案

所以須要一種融合了話題和隊列的綜合形式，充分發揮這兩個功能：既可以利用「客戶服務」的發佈-訂閱來發布事件，確保全部服務都能收到該事件；也能夠經過競爭的使用者，使個體服務實例實現負載均衡並進行擴展。

實現該形式的方法有不少，能夠利用 Camel 和 ActiveMQ ：

• 第一個方法就是用一個簡單的 Camel 路由來吸取「客戶話題」事件，並把它們同時發送給「忠誠值隊列」和「郵件隊列」。這是很容易實現的，不過每當有新服務對「客戶服務」事件感興趣時都須要從新更新 Camel 路由。並且，若是在代理以外單獨運行 Camel 路由，把消息從某一話題轉入到其事先設定好的隊列中去，就會帶來沒必要要的網絡開銷。

• 上述方法的一個改進方案，就是在 ActiveMQ 代理流程中使用 ActiveMQ Camel plugin 來運行 Camel 路由。這樣的話，雖然仍須要在訂閱者發生變動時更新 Camel 路由，可是路由是在代理過程當中發生的，所以不會產生網絡開銷。

• 不過還有更好的方案，就是將訂閱該話題的隊列 W/O 所有進行編碼，可是要借用 ActiveMQ 虛擬話題的聲明法（這也是撰寫本文的主要緣由）。

ActiveMQ 虛擬話題是將訂閱隊列發佈到話題中的方法，經過一個簡單的命名慣例——所要作的就是肯定話題或隊列的命名慣例，不管是自定義的仍是默認的均可以。

舉個例子:

• 能夠先建立一個與 VirtualTopic.> 表達式相匹配的話題名，如 VirtualTopic.CustomerTopic,

• 而後讓「忠誠度服務」調用 Consumer.LoyaltyPoint.VirtualTopic.CustomerTopic 隊列，

• 那麼消息代理就會將 VirtualTopic.CustomerTopic 話題中的全部事件都轉發給
  Consumer.LoyaltyPoint.VirtualTopic.CustomerTopic 隊列。

• 而後能夠經過開啓多個服務實例來擴展忠誠度服務，全部實例都從 Consumer.LoyaltyPoint.VirtualTopic.CustomerTopic 隊列中調用。

• 一樣的，以後再用一樣的命名慣例爲郵件服務建立隊列：Consumer.Email.VirtualTopic.CustomerTopic，這個功能容許用戶以特定方式來簡單命名話題和隊列，而且無需編碼就能訂閱。

結論

以上所述只是最近出版的著做 Camel Design Patterns 裏介紹的多種模式之一。正由於常常將Camel 與 ActiveMQ 一塊兒使用，書中也就收錄了一些 ActiveMQ 模式內容。

另外，用編排擴展微服務還能夠經過事件驅動來實現，這裏就是一篇介紹這種方法的推薦文章。

本文系 OneAPM 工程師編譯整理。OneAPM 能爲您提供端到端的 Java 應用性能解決方案，咱們支持全部常見的 Java 框架及應用服務器，助您快速發現系統瓶頸，定位異常根本緣由。分鐘級部署，即刻體驗，Java 監控歷來沒有如此簡單。想閱讀更多技術文章，請訪問 OneAPM 官方技術博客。

本文轉自 OneAPM 官方博客

原文地址：https://dzone.com/articles/scalable-microservices-through-messaging