調用第三方介面的架構優化

很多業務需要調用調用第三方的介面，從而形成一種調用依賴（耦合）。常見的架構中，往往會把調用第三方介面的程序服務化（inner-s），這樣可以解耦。

上圖的調用流程非常簡明，不解釋了。但這種架構存在一個隱患。假設inner-s提供了N個內部介面，其中一個內部介面所調用的第三方介面發生超時，並且將inner-s的工作線程全部佔據，那麼在超時的這段時間內，N-1個內部介面將會無法使用。

當然這種情況很極端，更常見的問題是超時佔用一部分線程，但這樣也會影響其他介面。

上述問題的根本原因是同步調用，解決方案是非同步調用。

業務場景：在某平台下單，然後該平台會通知第三方提供服務。

解決方案：本地調用成功後，非同步調用第三方介面。

本地流程：

1. 業務調用方調用內部service
2. 內部service寫入數據
3. 內部service返回介面

非同步流程：

4. 非同步asy-service將本地數據取出（或者使用通知機制，實時性好）

5. 非同步調用第三方介面

這樣就消除了公網抖動或者介面超時對內部介面的影響。

寫到這裡，不難發現，如果一個調用鏈路太長，那麼就會越脆弱。非同步調用可以把一個較長的調用鏈分解成多個較短的調鏈。

當然還有一些其他解決方案，請詳見跨公網調用的大坑與架構優化方案

推薦閱讀：