技術文章 » BFF層聚合查詢服務非同步改造及治理實踐 | 京東雲技術團隊

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

2023-06-02 12:00:16

首先感謝王曉老師的[介面優化的常見方案實戰總結]一文總結，恰巧最近在對穩健理財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半連結重試。

三、最後

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

最後仍參照王曉老師文章結尾來結束

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

作者：京東科技 劉大朋

來源：京東雲開發者社群