首先讓我們來先看一個例子： 這是一個簡單的用戶下單購買商品的業務模型，輸入端是用戶，相關物料有訂單和貨物，相關的內部服務有業務（訂單）、財務（支付）、倉儲（備貨）和物流（運輸）。 從圖中我們可以看到，用戶首先向業務部門下了一個訂單，業務部門根據用戶提供的內容生成了一份訂單給客戶，並要求客戶根據訂單金 ...
首先讓我們來先看一個例子：
這是一個簡單的用戶下單購買商品的業務模型，輸入端是用戶，相關物料有訂單和貨物，相關的內部服務有業務（訂單）、財務（支付）、倉儲（備貨）和物流（運輸）。
從圖中我們可以看到，用戶首先向業務部門下了一個訂單，業務部門根據用戶提供的內容生成了一份訂單給客戶，並要求客戶根據訂單金額支付費用。此時用戶會拿著訂單向財務部門付款，財務部門收款後告訴業務部門，此訂單的貨款已經收到，業務部門通知倉儲部門備貨，倉儲部門備貨完成後通知業務部門貨物已經準備完畢，再由業務部門通知物流部門去倉庫取貨並送給用戶，最後用戶簽收，流程結束。
在這個流程中我們可以發現，總共十個步驟中，除了創建訂單、付款和簽收外，其他的用戶實際上並不關心。在生活中，我們實際上是付完款就回家等著收貨了。如果我們把上述四個部門看作四個微服務，並同步調用，則運算模型如下：
從圖中我們可以看出，用戶發起一個請求（支付貨款）後，將按照順序一步一步的執行所有的步驟，直到用戶取到貨物才能結束，如果這段時間比較長，則需要用戶一直等待結果，直到用戶等的不耐煩離開（響應超時）。先不論用戶體驗如何，這種模型的處理效率實在是過於低下，如果貨物運送需要若幹天，則業務流程就要堵塞若幹天，新的業務就進不來。
如果我們設計一種新的處理模型，在用戶支付完成後，把這些用戶不關心的環節放到後臺處理，就可以極大的提升處理效率，增加吞吐量。
如上圖所示，當用戶發起一個請求後（支付貨款），先處理與支付相關的業務邏輯，然後立刻將處理結果（支付成功，等待收貨）反饋給用戶，這時用戶的前臺流程就告一段落了。在此之後，我們通過一種方式通知其它相關的微服務（訂單、倉儲、物流），告知他們要進行哪些工作。這些業務一般不需要即時反饋，因此前臺人員並不需要等待他們反饋結果，可以直接接受下一個任務。
在這種模型下，我們在微服務之外引入了事件通知服務（如 AWS SNS），當微服務向通知服務發佈事件時，只會向通知服務中持久化一條數據，然後微服務就執行完畢並向調用者即時反饋結果了。此後，再由事件通知服務在合適的時候遠程調用其他微服務的回調函數，完成業務流程。
事件通知非同步調用可以在一定程度上提升微服務的性能和吞吐量，並且各大雲服務提供商都有提供類似的服務，如亞馬遜雲的SNS服務，騰訊雲的CMQ服務，阿裡雲的Message Service等，都可以輕鬆的集成到項目當中。
但是，非同步調用也存在一些不足：
1. 如果發佈時發生異常，消息可能會丟失，導致業務流程永久性暫停。如：付款後未能通知業務部門，導致倉儲沒有備貨、物流沒有運輸，最終用戶拿不到貨物。
2. 如果微服務回調函數發生異常，可能導致最終數據不一致。如：倉儲備貨過程出錯，但是業務和物流部門都以為已經備好貨了，業務部門告知用戶已經開始運輸，物流部門卻沒有取到貨，最終用戶依然拿不到貨。然而業務部門發佈的事件已經調用過物流部門的回調函數，雖然沒有成功，但是發佈的消息卻已經被消費掉了，業務部門也沒有辦法重新發送事件通知給倉儲，所以這件事只能線下處理（運維人員手動修改數據）。
要保證數據一致性和服務可靠性，就不得不提到消息隊列和分散式事務。
“消息隊列”是在消息的傳輸過程中保存消息的容器，我將會在下一篇中探討消息隊列的相關內容。謝謝！
