架構設計之異步請求怎么同步處理

這篇文章主要講解了“架構設計之異步請求怎么同步處理”，文中的講解內容簡單清晰，易于學習與理解，下面請大家跟著小編的思路慢慢深入，一起來研究和學習“架構設計之異步請求怎么同步處理”吧！

全文摘要：

• 異步給現有架構帶來的問題

• Dubbo 異步轉同步解決方法

• 異步轉同步架構設計方案

0x00. 前言

現有一個系統，整體架構如下所示:

這是一個很常見的同步設計方案，上游系統需要等待下游系統接口返回調用結果。

現在需要接入另外一個第三方服務 B，該服務與服務 A 最大區別在于，這是一個異步 API。調用之后，僅僅返回受理成功，處理結果后續通過異步通知返回。

接入之后，整體架構如下所示：

默認情況下，Dubbo 支持同步調用方式，這里將會創建 DefaultFuture 對象。

業務線程調用 DefaultFuture#get方法進入阻塞。這段代碼比較簡單，通過調用 Condition#await 阻塞線層。

0x02. 轉發方案設計

根據 Dubbo 解決思路，問題 1 解決辦法就比較簡單了。具體流程如下：

1. 通信服務 B 內部生成一個唯一請求 ID ，發給第三方服務

2. 若請求成功，內部版使用 Map 存儲對應關系，并使業務線程阻塞等待

3. 通信服務 B 收到異步通知結果，通過 ID 查找對應業務線程，喚醒的相應的線程

這個設計過程需要注意設置合理的超時時間，這個超時時間需要考慮遠程服務調用耗時，可以參考如下公式：

業務線程等待時間=通信服務 B 接口的超時時間 - 調用第三方服務 B 接口消耗時間

這里就不貼出具體的代碼，詳細代碼參考 Dubbo DefaultFuture。

接下來重點看下通知服務如何將結果轉發給正確的通信服務 B 的節點。這里想到兩種方案：

1. SocketServer 方案

2. MQ 方案

2.1 SocketServer

通信服務 B 使用 SocketServer 構建一個服務接收程序，當通知接收程序收到第三方服務 B 通知時，通過 Socket 將結果轉發給通信服務 B。

整個系統架構如下所示：

通知接收程序收到異步通知之后，直接將結果發送到 MQ。

通信服務 B 開啟廣播消費模式，拉取 MQ 消息。

通信服務 B_1 拉取消息，通過請求 ID 映射關系，沒找到內部等待的線程，知道這不是自己的等待消息，于是 B_1 直接丟棄即可。

通信服務 B_2 拉取消息，通過請求 ID 映射關系，順利找到正在等待的線程，然后可以喚醒等待線程，返回最后的結果。

對比 SocketServer 方案，MQ 方案整體流程比較簡單，編程難度低，也沒用存在特殊的配置。

不過這個方案十分依賴 MQ 消息實時性，若 MQ 消息投遞延遲很高，這就會導致通信服務 B 業務線程超時蘇醒，業務異常返回。

這里我們選擇使用 RocketMQ，長輪詢 Pull 方式，可保證消息非常實時，

感謝各位的閱讀，以上就是“架構設計之異步請求怎么同步處理”的內容了，經過本文的學習后，相信大家對架構設計之異步請求怎么同步處理這一問題有了更深刻的體會，具體使用情況還需要大家實踐驗證。這里是億速云，小編將為大家推送更多相關知識點的文章，歡迎關注！