微服務優化之非同步呼叫
微服務優化之非同步呼叫
前一節《微服務優化之並行》，主要從並行的角度來提高微服務的響應時間，本節講一下微服務優化之非同步呼叫。非同步的前提是對依賴的RPC介面呼叫，不需要關心其執行結果，對資料沒有強一致性要求，只要能夠達到最終一致性就好。
該種情況下，實現方式一般有兩種：
第一種，對於最終一致性要求很低的情況，比如當用戶投資搶標的情況下，只要使用者的請求到達服務端，並且校驗通過允許搶購，就可以記錄使用者搶購申請，凍結資金，並且立即返回成功，縮短介面響應時間，從而挺高系統吞吐率。然後在系統後臺，啟動一個定時任務，定時掃描申請表中的記錄，呼叫內部標的認購介面，呼叫外部資金劃撥介面，生成自己劃撥流水，並且更新搶購申請單狀態，完成完整的標的認購，達到最終資料的一致性。
第二種，對於資料實時性要求稍微高一點的，需要藉助於訊息佇列，在分散式服務系統中一般會採用分散式訊息中介軟體來輔助完成微服務的非同步化。常用的分散式訊息中介軟體有Kafka、RabbitMQ、RocketMQ、Apache Artemis等等，各個中間的優缺點和用法這裡不多做介紹。
基於訊息的非同步該怎麼做呢？當介面接收到客戶端請求後，向訊息中介軟體傳送訊息，並立即返回成功，靠訊息中介軟體來保證資料的最終一致性。然而這樣做還是不夠的，還需要考慮以下三種情況：
1，如果訊息傳送失敗了怎麼辦？
2，如果訊息傳送成功了，訊息中介軟體丟訊息，或者消費方業務失敗怎麼辦？
3，如果訊息傳送成功了，但是返回資訊時網路中斷導致訊息生產方以為訊息傳送失敗怎麼辦？
那麼針對以上情況，需要做一下工作：
1，訊息生產方需要一個本地事件表，記錄事件流水，事件表至少包含以下狀態：訊息傳送成功，訊息傳送失敗，訊息傳送狀態未知，業務未執行，業務執行成功，業務執行失敗
2，訊息生產方需要一個回撥介面
3，訊息消費方需要一個本地事件表，記錄消費方事件流水，事件表至少包含以下狀態：業務重試次數，業務執行成功，業務執行失敗，業務回滾
基於以上說明，那麼總的執行流程就很清晰了，當客戶端呼叫我們的RPC時，首先記錄本地事件表，然後傳送訊息，並根據訊息傳送結果更新事件表狀態。訊息消費方接受訊息後，首先記錄本地事件表，然後自行業務邏輯，再根據業務邏輯執行結果更新本地事件表狀態，最後在呼叫回撥介面來更新訊息生產方的事件表狀態。最後再通過Job拉取訊息生產方的事件表，和訊息消費方的事件表對比進行額外的資料補償達到最終的一致性。這樣通過訊息中介軟體達到絕大多數請求的準實時性，同時提高對外介面的響應效率。
