微服務中的異步消息通訊 - savorboard－IT工程師數位筆記本

文章出處

前言

在上一篇文章中，我們說到了異步消息通訊，下面這篇文章呢，大部分內容是翻譯來自于這篇微軟的文章，所以其內容還是具有一定的理論指導意義的。

當我們跨多個微服務進行內部通訊的時候，異步消息和事件驅動至關重要。我們可能需要在不同的邊界上下文中進行域模型的更新。
我們舉個例子，比如 eShop 這個項目中，Ording 服務在下單的時候要和 Catelog 服務進行通訊進行庫存的扣減操作，這個時候我們就需要一種方式來做這個事情，并且能夠在發生故障的時候也能正常工作，也就說需要進行基于異步消息和最終一致性的通訊方式。

當使用基于消息的通訊方式的時候，進程中是采用的異步的方式通訊的。客戶端向某個服務發送消息，如果這個消息需要回復，那么另一個服務會向客戶端發送一個不同的消息，并且客戶端會認為該消息不會立即被接收到，并且不存在響應，這就是一種基于消息的通訊方式。

消息由標題（name 或者 title）和內容（Body）共同構成。消息通常會通過一些異步協議進行發送（如AMQP，kafka協議）。

異步消息通訊有兩種：一種是單接收者（端到端），另外一種是多接收者（廣播）。

如果有同學對消息隊列比較了解的話，這就是消息隊列的兩種典型使用方式。

基于消息的單接收者

單接收者也就是說是點到點的通訊，將消息使用隊列等方式從一點發送的另外一點，并且該消息僅會被處理（消費）一次。這中間一個特殊情況就是，當隊列在嘗試從故障中恢復時候，有可能會多次發送相同的消息，客戶端必須實現冪等性以便能夠處理相同的消息一次。

單接收器消息通訊的方式適用于將異步命令從一個微服務發送到另一個微服務。如下圖：

一旦開始使用了基于消息的通訊，你應該避免將基于消息的通訊和同步的HTTP通訊混合起來。

注意：當command來到客戶端應用程序時候，它們可以實現為HTTP的同步命令。當你需要更高的可擴展性或者你業務流程中已經使用了基于消息的方式時，那么你就應該使用基于消息的通訊方式。

基于消息的多接收者

多接收者是消息通訊中一種更加靈活的方式，你可能還需要使用發布/訂閱這種機制，以便于接收來自發送方或者其他微服務或者外部應用程序的消息。這樣，將來可以添加更多的其他消費者用戶，而無需修改發送方的服務代碼。

當你使用發布/訂閱這種通訊方式的時候，在發送端和訂閱端你也許會用到事件總線的接口。

異步事件驅動通訊

當使用異步事件驅動通信時, 一個微服務當域模型發生更新時，會發布一個集成事件，然后另外一個微服務可能需要關注這個事件，比如 eShop 中，當 product catelog 微服務發生一個價格變動的時候。另外的微服務需要訂閱這個事件，這樣就可以以異步的方式來接收這個事件。然后當事件觸發的時候，訂閱端就可以更新自己的 Domain Model，從而集成發送端的事件。事件總線（Event Bus）可以設計為一個抽象類或接口,集成API 訂閱或取消訂閱事件和發布事件。事件總線還可以有一個或多個實現基于任何進程間消息傳遞代理，像一個消息隊列或服務總線支持異步通信和發布/訂閱模型。

如果事件驅動中集成了最終一致性，那么用戶應該清楚這種行為，客戶端用戶及其業務必須顯式地擁抱最終一致性并且意識到在許多情況下這種業務沒有任何問題。

你可以跨越多個微服務來集成事件驅動，這些服務之間擁有最終一致性。一個最終一致性的“事務”可能是由多個分布式的事件操作組成的一個集合。在每一個事件中，相關的微服務都在更新自己的領域實體并且發布另外一個需要集成的事件到Eventbus中。

很重要的一點是 , 你可能需要多個微服務訂閱一個事件。因此, 您可以使用基于事件驅動的發布/訂閱消息模式的消息通訊, 如下圖所示。這種發布/訂閱的機制不是微服務獨有的。它類似于DDD中邊界上下文之間的通訊方式, 或者類似于CQRS架構中的從寫庫更新數據到讀庫的這種模式。它最終的目標是在整個分布式系統多個數據源之間的保持最終一致性。

你將實現基于消息的事件驅動通信協議。AMQP可以幫助實現可靠的排隊通信。

當您使用事件總線時，您可能希望使用的是抽象級別的東西（如Eventbus interface），它使用類似于 RabbitMQ 或服務總線（如Azure Service Bus及 Topic）來作為底層，然后提供相關API。或者，您可能希望使用更高級別的服務總線，如NServiceBus，MassTransit或Brighter來作為Eventbus和發布/訂閱系統。

關于生產環境中的消息通訊技術

在消息通訊技術中，實現抽象級別的事件總線是存在不同的級別的。例如，像RabbitMQ 和Azure Event Bus這樣的產品比其他產品（如NServiceBus，MassTransit或Brighter）級別就更低一些，NServiceBus這些他們可能基于底層的這些之上，當然后者也更加的重量級。

但是很多時候，我們可能學習這些重量級的東西需要花費很多的成本，而且我們也用不到那么重量級的東西，正如在eShopOnContainers示例中所做的那樣，在Docker容器上運行的RabbitMQ之上的簡單實現可能就足夠了。

但是，在生產系統中對于需要可擴展性的關鍵型任務，您可能需要進行評估一下。為了使分布式應用程序開發更容易的并且提供高級抽象的功能，我們建議您評估其他商業和開源的服務總線，如NServiceBus，MassTransit和Bright。當然，您可以在像RabbitMQ和Docker這樣的低級技術的基礎上構建自己的服務總線功能。但是，這種工作對于企業應用來說可能花費的太多。