概述
異步通訊一般發生在生産與消費不等的情況，這類請求可能需要同步請求轉異步請求，應用需要通過MQ消息隊列來進行5類情況處理：
•異步處理
•應用解耦
•流量消峰
•日志處理
•消息通訊
目前從業務應用架構模式上來說，異步處理、應用解耦、流量消峰比較常用。通常情況下，我們對同步請求轉異步請求處理。
同步請求轉異步請求模式：可以通過同步EDAS通訊架構，降低前端業務系統對MQ中間件的依賴，然後能更好的通過同步通訊架構來實作路由、分組、限流、熔斷等處理。并且可以快速通過水準擴充模式來提高并發。而且對自發自首MQ完全由業務系統來進行控制，對于MQ的使用量上會大大減少，對MQ的隔離和擴充上大大增加。
目前業務異步通訊的問題
上述兩張圖，反應出目前MQ在使用場景中的弊端
1.應用A無法知道應用B是否接收到請求，也無法對請求作出預判。
2.應用A如果出現大量錯誤請求的時候，對MQ來說是未知的，隻會無故積壓，導緻影響後續正确的交易。
3.應用B如果出現幂等請求情況下，應用A大量重複交易，必須通過異步請求來傳回，這個時候會發現異步請求解耦被沒有在正确的大量資料處理上運用。導緻大量重複積壓。
4.應用A和B對MQ進行強依賴，變成各個系統間的集中進行中間件，萬一發生問題，影響面很大。
5.應用A和應用B在擴容上比較困難，需要考慮全局MQ的性能問題。
6.應用A和應用B在MQ層面很難實作熔斷、降級、路由、負載均衡政策。
同步請求轉異步請求模式
模式一
•應用A使用EDAS Request請求應用B。
o需要驗證服務端邏輯，避免不必要的請求開銷 •應用B驗證邏輯不通過（入參驗證、幂等、安全驗證等），錯誤直接傳回EDAS Response請求到應用A。
o服務端驗證應該避免遠端調用，因為異步請求模式下，需要達到相應速度和應答速度來提高并發，整個請求操作應該在10MS之内。 •應用B驗證邏輯通過，直接落DB或Redis等，保證業務持久可靠後，直接傳回EDAS Response請求到應用A
o落DB需要快速響應，可以考慮熱點表，此類表因為是大量Insert操作，考慮盡量少建索引來提高并發。整個請求操作應該在 20MS之内。 •應用B自已發送MQ請求，異步解耦，自己接收自己發送的MQ請求後，處理正确的業務邏輯。
o發送MQ請求，可以考慮異步發送，提高并發，因為之前已經落DB成功，但需要考慮在接收端處理業務邏輯的時候，需要進行DB驗證。 •應用B處理完成的請求結果，在通過應用A暴露的EDAS請求進行接口回調，将結果給到應用A。
•使用場景：同步請求并發量比較大。
模式二
•前面接模式一說明
•應答處理發送應答MQ進行流量消峰處理，然後接受應答，在通過應用A暴露的EDAS/Http請求進行接口回調，将結果給到應用A。
•使用場景：同步請求并發比較大，異步應答并發比較大。
模式三
•前面接模式二說明
•應用A接收到應用B的回調應答後，發送回調MQ進行流量消峰處理，在慢慢進行自行業務邏輯處理。
注意
•使用場景：同步請求并發比較大，異步應答并發比較大并發，對方應用系統異步回調請求并發大。
•其中模式一、二、三虛線中可以考慮減少對DB的依賴，如果業務系統對資料可靠性要求是有補償機制的話，那麼可以直接發MQ進行處理，更好提升異步處理性能。
異常處理
第1步EDAS通訊異常，用戶端需要考慮熔斷來快速傳回，服務端應考慮實際并發進行限流。
第2步驗證異常，服務端需要考慮交易嚴格幂等情況下，重複交易情況下查詢重複交易請求，有終态直接傳回，中間态考慮入DB後丢棄，保證前端隻有一個傳回。前端調用系統在接收到重複請求的同時，也進行終态判斷，保證交易一緻性。
第3步發MQ異常，需要有定時補償排程線程進行交易補償，資料終态已資料庫DB為準。
第4步接收MQ異常，需要考慮MQ重試機制，重試次數不要過多，3次最多，每次間隔不宜過長，否則MQ會擠壓（有些業務場景對交易時效有要求，比如1分鐘内必須要得到終态等）。
接口參數處理
•應用B EDAS 服務同步請求參數定義，裡面可以包含應用A需要異步傳回的參數。
o接口名稱：pg:XXXXX_async
o接口方法：XXXXX_async
o接口參數：應用參數+callbackParams（HashMap）
• 應用B EDAS 服務同步請求傳回參數定義，包含應答狀态、描述、具體傳回值（Json格式）。
o 參數1：asyncStatus
o 參數2：asyncMsg
o 參數3：asyncJson（callbackParams+業務傳回字段）
• 應用B 接收請求自發自收MQ定義，可以根據上層業務産品号（可以依賴配置中心維護）。
o 隊列名：Q_xxx_xxx_1001（Q_應用B項目名_應用A項目名_産品号）
o 隊列資訊：json（應用A EDAS請求全部資訊）
• 應用A EDAS 服務回調接口定義，包含應答狀态、描述、具體傳回值（Json格式）（接口應該相對固化，防止改動引起不相容上線）。
o 接口方法：pg:XXXXX_asyncCallback
o 方法：XXXXX_asyncCallback
o 參數1：asyncCallbackStatus
o 參數2：asyncCallbackMsg
o 參數3：asyncCallbackJson（callbackParams+業務傳回字段）
o 傳回值：asyncCallbackId（請求唯一ID）
接口回調協定
• EDAS：直接使用EDAS RPC調用（推薦）。
• Http：服務方需要通過SLB提供負載均衡位址（負載均衡必須是Http負載均衡，包含健康頁面，不要Session粘滞，推薦使用PoolingHttpClientConnectionManager并且實作Http1.1 Keepalive模式）。
優勢和應用規範
- 應用A非常明确的知道應用B給出的正确應答（可以及時進行業務邏輯處理，如：參數驗證錯誤、幂等重複、系統異常等情況）。
- 應用B可以清晰給出同步請求強類型接口，實作接口的單一職責，明确接口參數規範。
- 應用B作為服務端，可以使用EDAS接口帶來的路由、熔斷、限流、負載均衡政策等功能。
- 應用B釋出過程中，可以使用EDAS接口帶來的灰階、分區、水準擴充等功能。
- 應用B自發自收MQ，可以輕松隔離，明确資料所屬邊界。
處理一（落DB後發送MQ異步處理）
應用規範
• 可靠性強（DB資料作為業務唯一資料存儲點，DB的資料可靠性比MQ強）。
• 一緻性強（DB支援ACID）。
• 對資料可控性強（業務可以對DB中資料進行查詢、過濾、統計，可以友善選擇資料進行處理或放棄）。
• 并發要求不是很高（因為依賴DB，DB的插入和查詢有一定開銷）
• 異步落DB資料需要清理（插入DB的資料，可以定期歸檔或消費後直接删除）。
适用場景
• 需要同步轉異步解耦。
• 業務請求必須以服務端應答作為依賴處理。
• 對業務資料需要強一緻性、可靠性，并且對業務資料有複雜邏輯處理和過濾。
處理二（直接發送MQ後異步處理）
• 可靠性弱（MQ作為資料存儲，其可靠性不如DB）。
• 一緻性弱（MQ不能保證重複消息）。
• 對資料可控性弱（MQ中的消息積壓後，無法進行複雜的查詢和過濾）。
• 高并發強（MQ的資料吞吐能力比DB強）
• 資料自動清理（MQ資料消費後自動清理和定期歸檔）。
• 高并發場景，依賴MQ作為高吞吐處理，消息本身業務屬性不強，可以無序消費。
• 不包含同一類系統内部通訊：資料邊界和業務邊界同屬于一個系統
總結
同轉異架構本身需要進行異步消息推送SDK轉發能力，來實作多個EDAS服務的注冊對應完成異步轉同步的能力，在通過同步通訊架構EDAS的能力，最終将上下層耦合解除，MQ的能力上有所減弱，但MQ變成應用的私有屬性，能更好的擴充。