作者：京東物流 馮志文

背景

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

一、依賴概念

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

（1）最強依賴

當所依賴的服務(wù)不可用時，服務(wù)不可用，且造成系統(tǒng)崩潰。對于所有的依賴，不建議最強依賴。

（2）強依賴

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

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

（3）弱依賴

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

案例：下單服務(wù)對于話術(shù)的依賴就屬于弱依賴。

（4）最弱依賴

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

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

?

二、依賴分類

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

（1）業(yè)務(wù)域依賴原則

建議上層業(yè)務(wù)域可以依賴下層業(yè)務(wù)域，整體的依賴原則受到系統(tǒng)依賴原則的控制，必須首先遵守應(yīng)用系統(tǒng)之間的依賴原則，而下層業(yè)務(wù)域不允許依賴上層業(yè)務(wù)域。

核心是輸出系統(tǒng)核心功能場景的流程圖、時序圖、架構(gòu)圖，用例圖，領(lǐng)域模型等，需要結(jié)合業(yè)務(wù)來進行梳理。

（2）系統(tǒng)啟動依賴

系統(tǒng)啟動只允許依賴數(shù)據(jù)庫、應(yīng)用服務(wù)器本地資源（如本地文件）、公共存儲，不允許有其它基礎(chǔ)技術(shù)服務(wù)、內(nèi)部服務(wù)或外部服務(wù)依賴。消除啟動依賴可以支持當發(fā)生大規(guī)模故障后的快速恢復(fù)。

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

（3）基礎(chǔ)技術(shù)服務(wù)依賴

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

?緩存設(shè)計：緩存過期時間是多少？對應(yīng)key范圍，set入口等

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

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

（4）數(shù)據(jù)庫依賴原則

把數(shù)據(jù)庫按照數(shù)據(jù)等級進行分級，不同等級的數(shù)據(jù)庫的數(shù)據(jù)保護和業(yè)務(wù)連續(xù)性保證都不一樣。高優(yōu)先級應(yīng)用系統(tǒng)不能夠強依賴于次優(yōu)先級的數(shù)據(jù)庫，以此類推各級應(yīng)用系統(tǒng)不允許強依賴低于自己等級的數(shù)據(jù)庫服務(wù)。

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

（5）部署依賴原則

應(yīng)用系統(tǒng)自身的網(wǎng)絡(luò)的依賴需求：包括跨機房的網(wǎng)絡(luò)依賴、外網(wǎng)訪問、防火墻等。原則上日常態(tài)不建議有跨機房的服務(wù)調(diào)用網(wǎng)絡(luò)需求(特殊情況如數(shù)據(jù)復(fù)制、容災(zāi)等除外)，實現(xiàn)單機房內(nèi)自閉環(huán)。匯天機房調(diào)用匯天機房，廊坊調(diào)用下游的廊坊機房，宿遷調(diào)用下游的宿遷機房

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

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

（7） 硬件依賴原則

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

三、強弱依賴治理

（1）治理目標

通過對核心鏈路內(nèi)外部服務(wù)依賴治理，我們的目標是實現(xiàn)以下兩個關(guān)鍵目標：

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

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

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

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

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

附：依賴關(guān)系和服務(wù)可用率關(guān)系圖

?

（2）工具掃描

分析服務(wù)實現(xiàn)流程中所依賴的所有應(yīng)用系統(tǒng)（以及這些系統(tǒng)提供的服務(wù)）。對一個應(yīng)用系統(tǒng)而言，將它提供的每一個服務(wù)所依賴的應(yīng)用系統(tǒng)匯總起來，可以構(gòu)成應(yīng)用依賴總體結(jié)構(gòu)圖。

2.1）Pfinder應(yīng)用拓撲圖

可看出應(yīng)用的上游調(diào)用方和下游依賴方列表，可按TP99、調(diào)用量維度排序。

2.2）API接口的鏈路跟蹤環(huán)節(jié)

通過Pfinder的調(diào)用鏈跟蹤，可梳理對應(yīng)的依賴關(guān)系以及對應(yīng)的耗時統(tǒng)計：

（3）人工梳理

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

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

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

依賴權(quán)重：一次服務(wù)過程中依賴的次數(shù)，即訪問的次數(shù)。

針對具體的服務(wù)類型，需要針對性地開展依賴分析，如：Redis依賴：服務(wù)實現(xiàn)流程中所依賴的所有緩存數(shù)據(jù)，將它提供的每一個服務(wù)所依賴的緩存數(shù)據(jù)匯總起來，可以構(gòu)成該應(yīng)用對Redis的依賴總體結(jié)構(gòu)圖。

3.1）JSF-API接口依賴梳理

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

3.2）UMP采集點突出依賴關(guān)系

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

通過人工梳理發(fā)現(xiàn)，比如Promise的獲取下傳時效接口核心業(yè)務(wù)鏈路只有依賴JIMDB配置數(shù)據(jù)時效、產(chǎn)能狀態(tài)接口、GIS經(jīng)緯度獲取圍欄ID、GIS詳細地址獲取圍欄ID、到家門店時效、發(fā)送時效全程跟蹤MQ。

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

（4) 降級時機

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

?主動降級：一般在大型活動時產(chǎn)生流量尖峰，系統(tǒng)無法支撐，提前對非核心的業(yè)務(wù)進行了降級處理；

?被動降級：一般是在發(fā)生故障時自動觸發(fā)預(yù)設(shè)的降級策略。

總結(jié)：

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

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

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

3.制定優(yōu)化方案：根據(jù)數(shù)據(jù)分析的結(jié)果，我們可以制定相應(yīng)的優(yōu)化方案。這可能包括調(diào)整應(yīng)用間的依賴關(guān)系、優(yōu)化流量分配等措施。通過實施這些優(yōu)化方案，我們可以提升系統(tǒng)的穩(wěn)定性和性能。

4.持續(xù)改進：強弱依賴治理是一個持續(xù)的過程。我們需要不斷地收集、分析和優(yōu)化數(shù)據(jù)，以推動系統(tǒng)穩(wěn)定性的提升。同時，我們還需要及時響應(yīng)用戶反饋和需求變化，不斷改進我們的治理策略。

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

?

參考：信通院穩(wěn)定性建設(shè)指南

?審核編輯 黃宇