首先感謝王曉老師的 [接口優化的常見方案實戰總結] 一文總結，恰巧最近在對穩健理财 BFF 層聚合查詢服務優化治理，針對文章内的串行改并行章節進行展開，分享下實踐經驗，主要涉及原同步改異步的過程、全異步化後衍生的問題以及治理方面的思考與改進。
希望通過分享這些經驗，能夠對大家的工作有所啟發和幫助。如果有任何問題或建議，請随時提出。
一、問題背景
将不同理财産品（如基金、券商、保險、銀行理财等）針對不同投放管道人群進行個性化商品推薦，每個管道或人群看到的商品或特性資料又各不相同，為友善管道快速對接，由 BFF 層統一對所有資料進行聚合下發，是以 BFF 層聚集依賴了大量底層原子服務，是以主要問題是在依賴大量上遊接口的場景下保障 TP99、以及可用率。
案例：
以其中比較典型的商品推薦接口為例，需要依賴本地商品池緩存、算法推薦服務、商品基礎資訊服務、持倉查詢服務、人群标簽服務、券配置服務，可領用券服務、其他資料服務 ServN…… 等等，其中大部分上遊原子接口對單次批量查詢支援有限，是以極端情況，單個推品接口單次推薦 1-n 個推品，每個商品如果要綁定 10 個動态屬性，至少需要發起 (1~n)*10 次 io 調用。
改造前的流程和問題：
流程：
問題：
- 一是邏輯流程強耦合，很多上下遊服務強同步依賴；
- 二是鍊路較長，其中某個上遊服務不穩定時很容易造成整體鍊路失敗。
改造後的流程和實作的目标：
流程：
目标：
- 改造目标也很明确，就是對現有邏輯改造，盡可能增加弱依賴比例，一是友善異步提前加載，二是弱依賴代表可摘除，為降級操作奠定基礎，減少因某個鍊路抖動影響整體鍊路失敗；
初步改造後的新問題【【重點解決】】：
▪邏輯上解耦比較簡單，無非就是前置參數或備援加載，本次不展開探讨；
▪技術上改造前期異步邏輯主要是采用 @Async ("tpXXX") 标注，這也是最快捷實作的方式，但也存在以下幾個問題，主要是涉及治理方面：
- 随着項目和人員不斷疊代，造成 @Async 注解滿天飛；
- 不同人員在不熟悉其他子產品的情況下，無法界定不同線程池的是否可公用，大多都會采用聲明新的線程池，造成線程池資源泛濫；
- 部分調用場景不合理造成 @Async 嵌套過多或注解失效問題；
- 降級機制重複代碼太多，需要頻繁手動聲明各種降級開關；
- 缺少統一的請求級别的緩存機制，雖然 jsf 已經提供了一定程度的支援；
- 線程池上下文傳遞問題；
- 缺少線程池狀态的統一監控報警，無法觀測實際運作過程中的每個線程池狀态，可能每次都是拍腦袋覺設定線程池參數。
二、整體改造路徑
切入點：
鑒于大部分項目都會封裝單獨的 io 調用層，比如 com.xx.package.xxx.client，是以以此為切入點進行重點改造治理。
最終目标：
實作、應用簡單，對老代碼改造友好，盡可能降低改造成本；
- 抽象 io 調用模闆，統一 io 調用層封裝規範，标準化 io 調用需要的增強屬性聲明并提供預設配置，如所屬線程池配置設定、逾時、緩存、熔斷、降級等；
- 優化 @Async 調用，所有 io 異步操作統一收縮至 io 調用層，在模闆層實作回調機制，老代碼僅繼承模闆即可實作異步回調；
- 請求級别的緩存實作，預設支援 r2m;
- 請求級别的熔斷降級支援，在上遊故障時使服務實作一定程度的自治理；
- 線程池集中管理，對上下文自動傳遞 MDC 參數提供支援；
- 線程池狀态自動可視化監控、報警實作；
- 支援配置中心動态設定。
具體實作：
1. io 調用抽象模闆
模闆主要作用是進行規範和增強，目前提供兩種模闆，預設模闆、緩存模闆，核心思想就是對 io 操作涉及的大部分行為進行聲明，比如目前服務所屬線程池分組、請求分組等，由委托元件按照聲明的屬性進行增強實作，示例如下：
主要是提供代碼級别的預設聲明，從日常實踐看大部分采用開發時的代碼級别的配置即可。
2. 委托代理
此委托屬于整個執行過程的橋接實作，io 封裝實作繼承抽象模闆後，由模闆建立委托代理執行個體，主要用于對 io 封裝進行增強實作，比如調用前、調用後、以及調用失敗自動調用聲明的降級方法等處理。
可以了解為：模闆專注請求行為，委托關注對象行為進行組合增強。
3. 執行器選型
基于前面的實作目标，減少自研成本，調研目前已有架構，如 hystrix、sentinel、resilience4j，由于主要目的是期望支援線程池級别的壁艙模式實作，且 hystrix 內建度要優于 resilience4j，最終選型預設內建 hystrix，備選 resilience4j， 以此實作線程池的動态建立管理、熔斷降級、半連接配接重試等機制，HystrixCommander 實作如下：
4. hystrix 适配 concrete 動态配置
1、繼承 concrete.PropertiesNotifier, 注冊 HystrixPropertiesNotifier 監聽器，緩存配置中心所有以 hystrix 起始的 key 配置；
2、實作 HystrixDynamicProperties，注冊 ConcreteHystrixDynamicProperties 替換預設實作，最終支援所有的 hystrix 配置項，具體用法參考 hystrix 文檔。
5. hystrix 線程池上下文傳遞改造
hystrix 已經提供了改造點，主要是對 HystrixConcurrencyStrategy#wrapCallable 方法重寫實作即可，在 submit 任務前暫存主線程上下文進行傳遞。
6. hystrix、jsf、spring 注冊線程池狀态多元可視化監控、報警
主要依賴以下三個自定義元件，注冊一個狀态監控處理器，單獨啟動一個線程，定期 (每秒) 收集所有實作資料上報模闆的執行個體，通過指定的通道實作狀态資料推送，目前預設使用 PFinder 上報：
- ThreadPoolMonitorHandler 定義一個線程狀态監控處理器，定期執行上報過程；
- ThreadPoolEndpointMetrics 定義要上報的資料模闆，包括應用執行個體、線程類型（spring、jsf、hystrix……）、類型線程分組、以及線程池的幾個核心參數；
- AbstractThreadPoolMetricsPublisher 定義監控處理器執行上報時依賴的通道（Micrometer、PFinder、UMP……）。
例如以下是 hystrix 的狀态收集實作，最終可實作基于機房、分組、執行個體、線程池類型、名稱等不同次元的狀态監控：
PFinder 實際效果：支援不同次元組合檢視及報警
7. 提供統一 await future 工具類
由于大部分調用是基于清單形式的異步結果 List<Future<T>>、Map<String,Future<T>>，并且 hystrix 目前暫不支援傳回 CompletableFuture，友善統一 await，提供工具類：
8. 其他小功能
1、除了 sgm traceId 支援，同時内置自定義的 traceId 實作，主要是處理 sgm 在子線程内列印 traceId 需要在控制台手動添加監控方法的問題以及提供對部分無 sgm 環境的鍊路 Id 支援，友善日志跟蹤；
2、比如針對 jsf 調用，基于 jsf 過濾器實作跨應用級别的前後請求 id 傳遞支援；
3、預設增加 jsf 過濾器實作日志列印，同時支援 provider、consume 的動态日志列印開關，友善線上随時開關 jsf 日志，不再需要在 client 層重複 logger.isDebugerEnabled ()；
4、代理層自動上報 io 調用方法、fallback 等資訊至 ump，友善監控報警。
日常使用示例：
1. 一個最簡單的 io 調用封裝
僅增加繼承即可支援異步回調，不重寫線程池分組時使用預設分組。
2. 一個支援請求級别熔斷的 io 調用封裝
預設支援的熔斷級别是服務級别，老服務僅需要繼承原請求參數，實作 FallbackRequest 接口即可，可防止因為某一個特殊參數引起的整體接口熔斷。
3. 一個支援請求級别緩存、接口級别熔斷降級、獨立線程池的 io 調用封裝
4. 上層調用，實際效果
1、直接将一個商品清單轉換成一個異步屬性綁定任務；
2、利用工具類 await List<Future<T>>；
3、在上層無感覺的狀态下，實作線程池的管理、熔斷、降級、或緩存邏輯的增強，且可根據 pfinder 監控的可視化線程池狀态，通過 concrete 實時調整線程池及逾時或熔斷參數；
4、舉例：比如某接口頻繁 500ms 逾時，可通過配置直接打開短路傳回降級結果，或者調低逾時為 100ms，快速觸發熔斷，預設 10s 内請求總數達到 20 個，50% 失敗時打開斷路器，每隔 5s 半連結重試。
三、最後
本篇主要是思考如何依賴現有架構、環境的能力，從代碼層面系統化的實作相關治理規範。
最後仍引用王曉老師文章結尾來結束
接口性能問題形成的原因思考我相信很多接口的效率問題不是一朝一夕形成的，在需求疊代的過程中，為了需求快速上線，采取直接累加代碼的方式去實作功能，這樣會造成以上這些接口性能問題。 變換思路，更高一級思考問題，站在接口設計者的角度去開發需求，會避免很多這樣的問題，也是降本增效的一種行之有效的方式。 以上，共勉！
作者：京東科技 劉大朋
來源：京東雲開發者社群