作者：京東物流 馮志文

背景

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

一、依賴概念

依賴原則是去除依賴、弱化依賴、控制依賴。多一個(gè)依賴多一分風(fēng)險(xiǎn)。能不依賴則不依賴，能異步弱依賴不要同步強(qiáng)依賴。

（1）最強(qiáng)依賴

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

（2）強(qiáng)依賴

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

案例：商詳結(jié)算下單服務(wù)對(duì)于庫存服務(wù)的依賴就屬于強(qiáng)依賴，下單時(shí)必須校驗(yàn)是否有庫存。

（3）弱依賴

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

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

（4）最弱依賴

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

案例：商詳評(píng)論，在大促高峰期期如有必要是可以進(jìn)行降級(jí)的。

?

二、依賴分類

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

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

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

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

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

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

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

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

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

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

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

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

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

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

數(shù)據(jù)庫依賴 （強(qiáng)弱依賴、依賴權(quán)重） 可能很多簡(jiǎn)單系統(tǒng)都只有一個(gè)數(shù)據(jù)庫，數(shù)據(jù)庫掛了整個(gè)系統(tǒng)就掛了，實(shí)際上很多重要的復(fù)雜系統(tǒng)都會(huì)同時(shí)具有多個(gè)數(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ò)的依賴需求：包括跨機(jī)房的網(wǎng)絡(luò)依賴、外網(wǎng)訪問、防火墻等。原則上日常態(tài)不建議有跨機(jī)房的服務(wù)調(diào)用網(wǎng)絡(luò)需求(特殊情況如數(shù)據(jù)復(fù)制、容災(zāi)等除外)，實(shí)現(xiàn)單機(jī)房?jī)?nèi)自閉環(huán)。匯天機(jī)房調(diào)用匯天機(jī)房，廊坊調(diào)用下游的廊坊機(jī)房，宿遷調(diào)用下游的宿遷機(jī)房

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

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

（7） 硬件依賴原則

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

三、強(qiáng)弱依賴治理

（1）治理目標(biāo)

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

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

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

為了達(dá)到以上目標(biāo)，我們將采取以下措施：

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

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

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

?

（2）工具掃描

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

2.1）Pfinder應(yīng)用拓?fù)鋱D

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

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

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

（3）人工梳理

在前期，我們通過投入相當(dāng)人力，通過代碼走讀的形式將用車核心鏈路上的所有依賴及依賴強(qiáng)弱進(jìn)行梳理。對(duì)每一個(gè)依賴，需要識(shí)別該依賴的以下屬性：

依賴強(qiáng)弱：強(qiáng)依賴是指必須的依賴，弱依賴是指可選的依賴；

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

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

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

3.1）JSF-API接口依賴梳理

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

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

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

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

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

（4) 降級(jí)時(shí)機(jī)

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

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

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

總結(jié)：

強(qiáng)弱依賴治理的實(shí)施需要以下幾個(gè)步驟：

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

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

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

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

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

?

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

?審核編輯 黃宇