.NET Core 實踐：事件通知和異步處理

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

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

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

在這個流程中咱們能夠發現，總共十個步驟中，除了建立訂單、付款和簽收外，其餘的用戶實際上並不關心。在生活中，咱們其實是付完款就回家等着收貨了。若是咱們把上述四個部門看做四個微服務，並同步調用，則運算模型以下：

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

若是咱們設計一種新的處理模型，在用戶支付完成後，把這些用戶不關心的環節放到後臺處理，就能夠極大的提高處理效率，增長吞吐量。

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

在這種模型下，咱們在微服務以外引入了事件通知服務（如 AWS SNS），當微服務向通知服務發佈事件時，只會向通知服務中持久化一條數據，而後微服務就執行完畢並向調用者即時反饋結果了。此後，再由事件通知服務在合適的時候遠程調用其餘微服務的回調函數，完成業務流程。

事件通知異步調用能夠在必定程度上提高微服務的性能和吞吐量，而且各大雲服務提供商都有提供相似的服務，如亞馬遜雲的SNS服務，騰訊雲的CMQ服務，阿里雲的Message Service等，均可以輕鬆的集成到項目當中。

可是，異步調用也存在一些不足：

1. 若是發佈時發生異常，消息可能會丟失，致使業務流程永久性暫停。如：付款後未能通知業務部門，致使倉儲沒有備貨、物流沒有運輸，最終用戶拿不到貨物。

2. 若是微服務回調函數發生異常，可能致使最終數據不一致。如：倉儲備貨過程出錯，可是業務和物流部門都覺得已經備好貨了，業務部門告知用戶已經開始運輸，物流部門卻沒有取到貨，最終用戶依然拿不到貨。然而業務部門發佈的事件已經調用過物流部門的回調函數，雖然沒有成功，可是發佈的消息卻已經被消費掉了，業務部門也沒有辦法從新發送事件通知給倉儲，因此這件事只能線下處理（運維人員手動修改數據）。

要保證數據一致性和服務可靠性，就不得不提到消息隊列和分佈式事務。

「消息隊列」是在消息的傳輸過程當中保存消息的容器，我將會在下一篇中探討消息隊列的相關內容。謝謝！