跨公網調用第三方接口的服務層的思考

跨公網調用第三方接口的服務層的思考

問題

前日有幸拜讀了架構師之路的58沈劍所寫的 跨公網調用的大坑與架構優化方案 一文。文中，做者提到了一個很值得思考的問題：

如何設計一個爲內部系統提供跨公網第三方接口調用的服務層，才能避免因部分接口問題致使總體失效的問題？

問題的具體描述請參見原文。

在看到問題後，我先試着想了幾個解決方案。

個人解決方案

1. 對於每次接口調用，都記錄其響應時間，並對服務層內每一個接口求出其平均響應時間。
2. 對於每一個接口，根據其平均調用時間，設置其可用工做線程數的閾值，保證當接口出現異常時，不會影響到全部工做線程。
3. 當接口相應時間明顯超過其歷史平均響應時間時，動態下降此接口的可用線程數量。
4. 當接口的異常狀態持續一段時間仍未恢復時，中止爲該接口提供服務，改用對進行輪詢的方式，來保證當其恢復可用後能夠迅速恢復對該接口的服務。

文章中給出的解決方案

1. 增大工做線程數、下降超時時間、拆分接口和服務層（治標不治本）。
2. 對於能夠接受非實時數據的內部系統調用方提供異步代理，對其屏蔽具體細節。即緩存外部接口調用的返回結果，對內部調用方直接提供對應的緩存結果，並按期調用外部接口來完成數據的更新。
3. 對於能夠冗餘的外部接口，保證其冗餘性，在主接口調用失敗後迅速將服務轉移至備份接口。
4. 對因而向外部接口推（主動同步）數據而不是拉數據的業務場景，先同步寫本地數據庫，本地寫成功後對內部調用方返回調用成功的消息，其後異步地向第三方接口推數據。

我對本身的反思

1. 解決方案侷限在一個具體的技術實現思路上（限流、動態規劃），考慮太窄，沒有結合實際的業務需求分析可行性。目前還停留在解決具體技術問題的階段，看山只是山，應該努力培養本身的宏觀思惟。
2. 我提出的解決方案須要直接操做服務容器的線程調度，難度大，技術可行性也未知。
3. 由於個人計算機網絡相關從業背景，我在思考過程當中受到各類網絡協議的設計思路影響很大（好比IP SLA探針、GLBP中的各類權重判斷等），這點我認爲在個人程序設計思惟中可能會讓我持續受益。雖然如今已經不從事網絡相關行業了，可是也應該保持住網絡工程師對於系統穩定性、可用性、擴展性的不懈追求。