作者：京東物流 馮志文

背景

隨著分布式微服務的發展，一個普通的應用可能會依賴于許多其他服務，這給系統的限流降級、優化改造等操作帶來了困難。在沒有明確強弱依賴關系的情況下，我們很難有效地進行這些操作。為了解決這個問題，強弱依賴治理成為了一種科學的手段。通過強弱依賴治理，我們可以持續穩定地獲取應用間的依賴關系、流量以及強弱等數據。這樣，我們可以提前發現由于依賴問題可能導致的系統穩定性故障。

一、依賴概念

依賴原則是去除依賴、弱化依賴、控制依賴。多一個依賴多一分風險。能不依賴則不依賴，能異步弱依賴不要同步強依賴。

（1）最強依賴

當所依賴的服務不可用時，服務不可用，且造成系統崩潰。對于所有的依賴，不建議最強依賴。

（2）強依賴

假定服務A依賴于服務B，服務B出現故障不可用時，服務A也不可用，通常服務A會返回錯誤信息，且當所依賴的B服務恢復后自動恢復，我們稱這種依賴為強依賴。服務只可強依賴于同等級或高等級的服務與資源。

案例：商詳結算下單服務對于庫存服務的依賴就屬于強依賴，下單時必須校驗是否有庫存。

（3）弱依賴

假定服務A依賴于服務B，服務B出現故障不可用時，服務A仍然可用，通常服務A會返回正確信息，只是與服務B相關的信息會不返回或者做默認處理，損失一些次級功能，我們稱這種依賴為弱依賴。

案例：下單服務對于話術的依賴就屬于弱依賴。

（4）最弱依賴

當所依賴的服務不可用時，服務繼續可用，無任何功能損失。在成本可控情況下，推薦采用最弱依賴的方式。

案例：商詳評論，在大促高峰期期如有必要是可以進行降級的。

?

二、依賴分類

分布式系統下的各資源依賴，按類型和層次提煉出來會有如下幾種分類。

（1）業務域依賴原則

建議上層業務域可以依賴下層業務域，整體的依賴原則受到系統依賴原則的控制，必須首先遵守應用系統之間的依賴原則，而下層業務域不允許依賴上層業務域。

核心是輸出系統核心功能場景的流程圖、時序圖、架構圖，用例圖，領域模型等，需要結合業務來進行梳理。

（2）系統啟動依賴

系統啟動只允許依賴數據庫、應用服務器本地資源（如本地文件）、公共存儲，不允許有其它基礎技術服務、內部服務或外部服務依賴。消除啟動依賴可以支持當發生大規模故障后的快速恢復。

案例：OPS-Review會上很多團隊系統啟動需要加載緩存，通過獲取Redis讀取數據到本地緩存，這需要注意一點在大促期間如大批量擴容，需要考慮Redis同時的容量規劃

（3）基礎技術服務依賴

基礎軟件依賴主要包括消息中心以及數據緩存依賴，同時還應考慮系統軟件及其第三方包依賴，應用系統若無特殊情況不應依賴底層操作系統或JVM特定版本。

?緩存設計：緩存過期時間是多少？對應key范圍，set入口等

?消息依賴：系統發布了哪些消息，訂閱了哪些消息，什么時機發送的，核心的消費者有哪些，消息是否需要開并行，消息下游依賴是什么？如果出現問題對自身系統和下游的核心影響是什么？

?定時任務：有哪些定時任務，是什么業務需要？定時任務執行的時間，是否會跟雙11大促高峰期沖突？

（4）數據庫依賴原則

把數據庫按照數據等級進行分級，不同等級的數據庫的數據保護和業務連續性保證都不一樣。高優先級應用系統不能夠強依賴于次優先級的數據庫，以此類推各級應用系統不允許強依賴低于自己等級的數據庫服務。

數據庫依賴 （強弱依賴、依賴權重） 可能很多簡單系統都只有一個數據庫，數據庫掛了整個系統就掛了，實際上很多重要的復雜系統都會同時具有多個數據源，將核心業務從數據源層面隔離開，哪怕有天數據庫掛了，也不是業務全掛。核心是輸出業務與數據庫依賴關系，數據庫的部署架構，如果能輸出慢sql治理方案，畫出數據庫表ER圖。

（5）部署依賴原則

應用系統自身的網絡的依賴需求：包括跨機房的網絡依賴、外網訪問、防火墻等。原則上日常態不建議有跨機房的服務調用網絡需求(特殊情況如數據復制、容災等除外)，實現單機房內自閉環。匯天機房調用匯天機房，廊坊調用下游的廊坊機房，宿遷調用下游的宿遷機房

（6）對外API&MQ與訪問量依賴原則

核心是根據訪問模式和訪問量可以推算出未來的訪問量，并進行容量分析和規劃。

（7） 硬件依賴原則

硬件這個方面，就交給硬件運維吧，專業的事情交給專業的人來做。

三、強弱依賴治理

（1）治理目標

通過對核心鏈路內外部服務依賴治理，我們的目標是實現以下兩個關鍵目標：

1.非核心業務故障不影響核心業務：通過優化服務依賴關系，確保非核心業務的故障不會對核心業務造成影響。這可以通過輸出服務、應用及場景的依賴關系來實現，包括強弱依賴關系的明確劃分。同時，我們會定期進行全量強弱依賴驗證，以確保核心服務、應用及場景相關上下游依賴的強弱合理清晰。

2.提高系統的穩定性：通過弱依賴出現各類異常（包括但不限于超時、失敗等）場景時的容錯邏輯和應急預案，有效避免弱依賴故障對核心業務的影響。

為了達到以上目標，我們將采取以下措施：

1.輸出應用及API場景的依賴關系：通過對系統進行全面的分析，我們將輸出完整的服務、應用及場景的依賴關系圖。這將幫助我們了解各個組件之間的關系，并確定強弱依賴關系。

2.弱依賴容錯邏輯和應急預案：針對弱依賴出現的各類異常情況，我們將制定相應的容錯邏輯和應急預案。這些預案將經過驗證，以確保其能有效避免弱依賴故障對核心業務的影響。

附：依賴關系和服務可用率關系圖

?

（2）工具掃描

分析服務實現流程中所依賴的所有應用系統（以及這些系統提供的服務）。對一個應用系統而言，將它提供的每一個服務所依賴的應用系統匯總起來，可以構成應用依賴總體結構圖。

2.1）Pfinder應用拓撲圖

可看出應用的上游調用方和下游依賴方列表，可按TP99、調用量維度排序。

2.2）API接口的鏈路跟蹤環節

通過Pfinder的調用鏈跟蹤，可梳理對應的依賴關系以及對應的耗時統計：

（3）人工梳理

在前期，我們通過投入相當人力，通過代碼走讀的形式將用車核心鏈路上的所有依賴及依賴強弱進行梳理。對每一個依賴，需要識別該依賴的以下屬性：

依賴強弱：強依賴是指必須的依賴，弱依賴是指可選的依賴；

同步或異步：同步表示需要等待返回，異步指調用發生后無需等待立即返回；比如Promise發送全程跟蹤MQ原先是同步發送MQ（強依賴）改成異步(弱依賴)發送方式。

依賴權重：一次服務過程中依賴的次數，即訪問的次數。

針對具體的服務類型，需要針對性地開展依賴分析，如：Redis依賴：服務實現流程中所依賴的所有緩存數據，將它提供的每一個服務所依賴的緩存數據匯總起來，可以構成該應用對Redis的依賴總體結構圖。

3.1）JSF-API接口依賴梳理

案例：Promsie提供了80+JSF接口，針對這些接口進行了依賴關系的梳理，把依賴關系的UMP打點統一采集點到一個URL，并且整理為joyspace文檔。這樣也是為了方便快速定位TP99毛刺高是哪個依賴，然后快速采取對應的應急預案。

3.2）UMP采集點突出依賴關系

UMP打點目前是支持打點采集點比對功能，把接口的下游打點信息全鏈路進行比對，可快速的定位到tp99等耗時環節，提高了日常的值班效率尤其對于大促爭分奪秒來說更是關鍵。

通過人工梳理發現，比如Promise的獲取下傳時效接口核心業務鏈路只有依賴JIMDB配置數據時效、產能狀態接口、GIS經緯度獲取圍欄ID、GIS詳細地址獲取圍欄ID、到家門店時效、發送時效全程跟蹤MQ。

上圖Promise接口經過梳理后發現其中只有JIMDB、到家門店時效是強依賴。GIS獲取圍欄ID（可降級到四級地址時效）、全程跟蹤MQ是弱依賴

（4) 降級時機

如果弱依賴服務發生問題,則降級的觸發條件可分為主動降級和被動降級；

?主動降級：一般在大型活動時產生流量尖峰，系統無法支撐，提前對非核心的業務進行了降級處理；

?被動降級：一般是在發生故障時自動觸發預設的降級策略。

總結：

強弱依賴治理的實施需要以下幾個步驟：

1.確定依賴關系：首先，我們需要明確應用之間的依賴關系。這可以通過分析代碼、配置文件等方式來實現。只有了解了應用之間的依賴關系，我們才能進行后續的治理工作。

2.分析依賴數據：接下來，我們需要收集應用間的依賴關系、流量以及強弱等數據。這可以通過監控工具、日志分析等方式來實現。通過收集這些數據，我們可以更好地了解系統的運行情況，發現潛在的依賴問題，并預測可能出現的故障。這樣，我們可以及時采取措施，為后續的治理工作提供依據。

3.制定優化方案：根據數據分析的結果，我們可以制定相應的優化方案。這可能包括調整應用間的依賴關系、優化流量分配等措施。通過實施這些優化方案，我們可以提升系統的穩定性和性能。

4.持續改進：強弱依賴治理是一個持續的過程。我們需要不斷地收集、分析和優化數據，以推動系統穩定性的提升。同時，我們還需要及時響應用戶反饋和需求變化，不斷改進我們的治理策略。

總之，強弱依賴治理是一種科學的手段，可以幫助我們應對分布式微服務的復雜性。通過持續穩定地獲取應用間的依賴關系、流量以及強弱等數據，我們可以提前發現潛在的故障，避免依賴故障對用戶體驗的影響，并積累數據持續推進系統穩定性的提升。

?

參考：信通院穩定性建設指南

?審核編輯 黃宇