首先讓我們來先看一個例子：

這是一個簡單的使用者下單購買商品的業務模型，輸入端是使用者，相關物料有訂單和貨物，相關的內部服務有業務（訂單）、財務（支付）、倉儲（備貨）和物流（運輸）。

從圖中我們可以看到，使用者首先向業務部門下了一個訂單，業務部門根據使用者提供的內容生成了一份訂單給客戶，並要求客戶根據訂單金額支付費用。此時使用者會拿著訂單向財務部門付款，財務部門收款後告訴業務部門，此訂單的貨款已經收到，業務部門通知倉儲部門備貨，倉儲部門備貨完成後通知業務部門貨物已經準備完畢，再由業務部門通知物流部門去倉庫取貨並送給使用者，最後使用者簽收，流程結束。

在這個流程中我們可以發現，總共十個步驟中，除了建立訂單、付款和簽收外，其他的使用者實際上並不關心。在生活中，我們實際上是付完款就回家等著收貨了。如果我們把上述四個部門看作四個微服務，並同步呼叫，則運算模型如下：

從圖中我們可以看出，使用者發起一個請求（支付貨款）後，將按照順序一步一步的執行所有的步驟，直到使用者取到貨物才能結束，如果這段時間比較長，則需要使用者一直等待結果，直到使用者等的不耐煩離開（響應超時）。先不論使用者體驗如何，這種模型的處理效率實在是過於低下，如果貨物運送需要若干天，則業務流程就要堵塞若干天，新的業務就進不來。

如果我們設計一種新的處理模型，在使用者支付完成後，把這些使用者不關心的環節放到後臺處理，就可以極大的提升處理效率，增加吞吐量。

如上圖所示，當用戶發起一個請求後（支付貨款），先處理與支付相關的業務邏輯，然後立刻將處理結果（支付成功，等待收貨）反饋給使用者，這時使用者的前臺流程就告一段落了。在此之後，我們通過一種方式通知其它相關的微服務（訂單、倉儲、物流），告知他們要進行哪些工作。這些業務一般不需要即時反饋，因此前臺人員並不需要等待他們反饋結果，可以直接接受下一個任務。

在這種模型下，我們在微服務之外引入了事件通知服務（如 AWS SNS），當微服務向通知服務釋出事件時，只會向通知服務中持久化一條資料，然後微服務就執行完畢並向呼叫者即時反饋結果了。此後，再由事件通知服務在合適的時候遠端呼叫其他微服務的回撥函式，完成業務流程。

事件通知非同步呼叫可以在一定程度上提升微服務的效能和吞吐量，並且各大雲服務提供商都有提供類似的服務，如亞馬遜雲的SNS服務，騰訊雲的CMQ服務，阿里雲的Message Service等，都可以輕鬆的整合到專案當中。

但是，非同步呼叫也存在一些不足：

1. 如果釋出時發生異常，訊息可能會丟失，導致業務流程永久性暫停。如：付款後未能通知業務部門，導致倉儲沒有備貨、物流沒有運輸，終端使用者拿不到貨物。

2. 如果微服務回撥函式發生異常，可能導致最終資料不一致。如：倉儲備貨過程出錯，但是業務和物流部門都以為已經備好貨了，業務部門告知使用者已經開始運輸，物流部門卻沒有取到貨，終端使用者依然拿不到貨。然而業務部門釋出的事件已經呼叫過物流部門的回撥函式，雖然沒有成功，但是釋出的訊息卻已經被消費掉了，業務部門也沒有辦法重新發送事件通知給倉儲，所以這件事只能線下處理（運維人員手動修改資料）。

要保證資料一致性和服務可靠性，就不得不提到訊息佇列和分散式事務。

“訊息佇列”是在訊息的傳輸過程中儲存訊息的容器，我將會在下一篇中探討訊息佇列的相關內容。謝謝！

轉載自:https://www.cnblogs.com/TO-WW/p/7309544.html