分佈式架構中異步的使用場景

昨天的文章裏提到了微服務間通訊的方式，今天會進一步討論一下，在分佈式架構中，咱們如何選擇異步和同步來進行服務間的調用。

總結下來，異步的使用場景能夠總結以下：

一、不影響主線程邏輯，不涉及共享資源，或對共享資源只讀，即非互斥操做

關於這一條，繼續用訂單服務與供應鏈服務的例子，訂單下單成功後，主流程直接返回成功，將該訂單的詳情經過MQ，異步推送給供應鏈系統，供應鏈系統後續執行的結果並不影響訂單的生成流程。

若是服務A同步調用服務B，那麼A和B就是緊密耦合的，而緊耦合的系統其可伸縮性特徵是各服務必需要保持一個節奏，要伸縮服務A必須同時伸縮服務B，同步調用的服務在可用性方面也面臨着一樣的問題。反過來講，若是服務A和B的通訊是異步的，不論是經過MQ或者批處理仍是其餘什麼手段，能夠各自根據系統的狀況，執行必要的伸縮操做。並且，此時服務A和B的是相互獨立的，即便服務B不能正常使用，服務A仍然可以繼續工做。

二、服務間交互的數據，在時序上的沒有嚴格關係

訂單服務傳送給供應鏈服務的訂單數據，好比說訂單A和訂單B，他們傳給供應鏈系統的時序，並不影響供應鏈服務處理流程，對最終的業務結果沒有任何影響。再舉一個例子，就是咱們的站內推送和各類消息，全部這些消息發放給客戶端，並不在意消息發送給某個客戶的前後順序，只要保證消息最終能順利發送完畢便可，因此推送給消息服務會採用異步的形式。

【醒目】反過來講，若是須要結果的處理始終和前文保持在一個上下文內，必需要使用同步。

三、IO操做或者須要大量計算等耗時操做

這個狀況主要用於前端AJAX的狀況，先將成功狀態返回，幾秒後，將詳情返回，局部刷新頁面。對於網站或者交易系統，消耗數據或執行的延遲時間來換取用戶的延遲時間是值得的，由於用戶的體驗會所以獲得提高。活動跟蹤、單據開付和報表等處理過程顯然都應該屬於後臺活動，不少步驟能夠進一部分解成異步運行，任何能夠晚點再作的事情都應該晚點再作。

多說一句，異步性能夠從必定程度上下降系統投入的成本。常規的同步操做須要系統必須按照負載的峯值來配備基礎設施，即便在大促作年度活動的時間週期裏任務最重的時刻，系統也必須有能力當即完成處理。將處理過程轉變爲異步的流，系統就不須要按照峯值來配備，只須要知足平均負載。異步隊列能夠將處理任務分攤到較長的時間裏，起到削峯的做用。系統的負載變化越大，曲線越多尖峯，就越能從異步處理中得益。

但願以上關於異步的總結能對你有用，經過異步的方式優化系統的伸縮性。若是你們有更好的建議，歡迎指正。

掃描二維碼或手動搜索微信公衆號： ForestNotes

歡迎轉載，帶上如下二維碼便可