【編者按】服務編排是微服務設置的一個重要方面。本文在利用 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 官方博客

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

總結

以上是生活随笔為你收集整理的微服务扩展新途径：Messaging的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。