BFF層聚合查詢服務異步改造及治理實踐 | 京東云技術團隊

首先感謝王曉老師的[介面優化的常見方案實戰總結]一文總結，恰巧最近在對穩健理財BFF層聚合查詢服務優化治理，針對文章內的串行改并行章節進行展開，分享下實踐經驗，主要涉及原同步改異步的程序、全異步化后衍生的問題以及治理方面的思考與改進，

希望通過分享這些經驗，能夠對大家的作業有所啟發和幫助，如果有任何問題或建議，請隨時提出，

一、問題背景

將不同理財產品（如基金、券商、保險、銀行理財等）針對不同投放渠道人群進行個性化商品推薦，每個渠道或人群看到的商品或特性資料又各不相同，為方便渠道快速對接，由BFF層統一對所有資料進行聚合下發，因此BFF層聚集依賴了大量底層原子服務，所以主要問題是在依賴大量上游介面的場景下保障TP99、以及可用率，

案例：

以其中比較典型的商品推薦介面為例，需要依賴本地商品池快取、演算法推薦服務、商品基礎資訊服務、持倉查詢服務、人群標簽服務、券配置服務，可領用券服務、其他資料服務ServN……等等，其中大部分上游原子介面對單次批量查詢支持有限，所以極端情況，單個推品介面單次推薦1-n個推品，每個商品如果要系結10個動態屬性，至少需要發起(1~n)*10次io呼叫，

改造前的流程和問題：

流程：

問題：

• 一是邏輯流程強耦合，很多上下游服務強同步依賴；

• 二是鏈路較長，其中某個上游服務不穩定時很容易造成整體鏈路失敗，

改造后的流程和實作的目標：

流程：

目標：

• 改造目標也很明確，就是對現有邏輯改造，盡可能增加弱依賴比例，一是方便異步提前加載，二是弱依賴代表可摘除，為降級操作奠定基礎，減少因某個鏈路抖動影響整體鏈路失敗；

初步改造后的新問題【【重點解決】】：

?邏輯上解耦比較簡單，無非就是前置引數或冗余加載，本次不展開探討；

?技術上改造前期異步邏輯主要是采用@Async("tpXXX")標注，這也是最快捷實作的方式，但也存在以下幾個問題，主要是涉及治理方面：

1. 隨著專案和人員不斷迭代，造成@Async注解滿天飛；

2. 不同人員在不熟悉其他模塊的情況下，無法界定不同執行緒池的是否可公用，大多都會采用宣告新的執行緒池，造成執行緒池資源泛濫；

3. 部分呼叫場景不合理造成@Async嵌套過多或注解失效問題；

4. 降級機制重復代碼太多，需要頻繁手動宣告各種降級開關；

5. 缺少統一的請求級別的快取機制，雖然jsf已經提供了一定程度的支持；

6. 執行緒池背景關系傳遞問題；

7. 缺少執行緒池狀態的統一監控報警，無法觀測實際運行程序中的每個執行緒池狀態，可能每次都是拍腦袋覺設定執行緒池引數，

二、整體改造路徑

切入點：

鑒于大部分專案都會封裝單獨的io呼叫層，比如 com.xx.package.xxx.client，所以以此為切入點進行重點改造治理，

最終目標：

實作、應用簡單，對老代碼改造友好，盡可能降低改造成本；

1. 抽象io呼叫模板，統一io呼叫層封裝規范，標準化io呼叫需要的增強屬性宣告并提供默認配置，如所屬執行緒池分配、超時、快取、熔斷、降級等；

2. 優化@Async呼叫，所有io異步操作統一收縮至io呼叫層，在模板層實作回呼機制，老代碼僅繼承模板即可實作異步回呼;

3. 請求級別的快取實作，默認支持r2m;

4. 請求級別的熔斷降級支持，在上游故障時使服務實作一定程度的自治理；

5. 執行緒池集中管理，對背景關系自動傳遞MDC引數提供支持；

6. 執行緒池狀態自動可視化監控、報警實作；

7. 支持配置中心動態設定，

具體實作：

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>、Map<String,Future>，并且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>；

3、在上層無感知的狀態下，實作執行緒池的管理、熔斷、降級、或快取邏輯的增強，且可根據pfinder監控的可視化執行緒池狀態，通過concrete實時調整執行緒池及超時或熔斷引數；

4、舉例：比如某介面頻繁500ms超時，可通過配置直接打開短路回傳降級結果，或者調低超時為100ms，快速觸發熔斷，默認10s內請求總數達到20個，50%失敗時打開斷路器，每隔5s半鏈接重試，

三、最后

本篇主要是思考如何依賴現有框架、環境的能力，從代碼層面系統化的實作相關治理規范，

最后仍參考王曉老師文章結尾來結束

介面性能問題形成的原因思考我相信很多介面的效率問題不是一朝一夕形成的，在需求迭代的程序中，為了需求快速上線，采取直接累加代碼的方式去實作功能，這樣會造成以上這些介面性能問題， 變換思路，更高一級思考問題，站在介面設計者的角度去開發需求，會避免很多這樣的問題，也是降本增效的一種行之有效的方式， 以上，共勉！

作者：京東科技 劉大朋

來源：京東云開發者社區

標籤：其他

上一篇：Gitlab Registries

下一篇：返回列表