昨天的文章裡提到了微服務間通訊的方式，今天會進一步討論一下，在分散式架構中，我們如何選擇非同步和同步來進行服務間的呼叫。
總結下來，非同步的使用場景可以總結如下：
1、不影響主執行緒邏輯，不涉及共享資源，或對共享資源只讀，即非互斥操作
關於這一條，繼續用訂單服務與供應鏈服務的例子，訂單下單成功後，主流程直接返回成功，將該訂單的詳情通過MQ，非同步推送給供應鏈系統，供應鏈系統後續執行的結果並不影響訂單的生成流程。
如果服務A同步呼叫服務B，那麼A和B就是緊密耦合的，而緊耦合的系統其可伸縮性特徵是各服務必須要保持一個節奏，要伸縮服務A必須同時伸縮服務B，同步呼叫的服務在可用性方面也面臨著同樣的問題。反過來說，如果服務A和B的通訊是非同步的，不管是通過MQ或者批處理還是其他什麼手段，可以各自根據系統的情況，執行必要的伸縮操作。而且，此時服務A和B的是相互獨立的，即使服務B不能正常使用，服務A仍然能夠繼續工作。
2、服務間互動的資料，在時序上的沒有嚴格關係
訂單服務傳送給供應鏈服務的訂單資料，比如說訂單A和訂單B，他們傳給供應鏈系統的時序，並不影響供應鏈服務處理流程，對最終的業務結果沒有任何影響。再舉一個例子，就是我們的站內推送和各種訊息，所有這些訊息發放給客戶端，並不在乎訊息傳送給某個客戶的先後順序，只要保證訊息最終能順利傳送完畢即可，所以推送給訊息服務會採用非同步的形式。
【醒目】反過來說，如果需要結果的處理始終和前文保持在一個上下文內，必須要使用同步。
3、IO操作或者需要大量計算等耗時操作
這個情況主要用於前端AJAX的情況，先將成功狀態返回，幾秒後，將詳情返回，區域性重新整理頁面。對於網站或者交易系統，消耗資料或執行的延遲時間來換取使用者的延遲時間是值得的，因為使用者的體驗會因此得到提升。活動跟蹤、單據開付和報表等處理過程顯然都應該屬於後臺活動，很多步驟可以進一部分解成非同步執行，任何可以晚點再做的事情都應該晚點再做。
多說一句，非同步性可以從一定程度上降低系統投入的成本。常規的同步操作需要系統必須按照負載的峰值來配備基礎設施，即使在大促做年度活動的時間週期裡任務最重的時刻，系統也必須有能力立即完成處理。將處理過程轉變為非同步的流，系統就不需要按照峰值來配備，只需要滿足平均負載。非同步佇列可以將處理任務分攤到較長的時間裡，起到削峰的作用。系統的負載變化越大，曲線越多尖峰，就越能從非同步處理中得益。
希望以上關於非同步的總結能對你有用，通過非同步的方式優化系統的伸縮性。如果大家有更好的建議，歡迎指正。
掃描二維碼或手動搜尋微信公眾號： ForestNotes
歡迎轉載，帶上以下二維碼即可
