分布式架構(gòu)的興起推動(dòng)了一些新技術(shù)的發(fā)展。其中鏈路追蹤技術(shù)以其在APM領(lǐng)域的優(yōu)異表現(xiàn)，成為了分布式架構(gòu)中不可或缺的一部分。在本文中，我們將談?wù)勊囊恍┙?jīng)典應(yīng)用場(chǎng)景，以及筆者所在的團(tuán)隊(duì)如何利用鏈路追蹤技術(shù)提升團(tuán)隊(duì)的研發(fā)效能。

鏈路追蹤背景

如圖所示，在微服務(wù)體系中，一個(gè)請(qǐng)求往往需要多個(gè)服務(wù)協(xié)作處理。

凡事有利必有弊，這種模式在給我們帶來(lái)更好的可擴(kuò)展性的同時(shí)，也帶來(lái)了一些新的問(wèn)題。例如，排查問(wèn)題的困難：任意節(jié)點(diǎn)的異常都可能導(dǎo)致上游鏈路的異常，難以追根溯源；系統(tǒng)拓?fù)鋸?fù)雜難以把控，健壯性存在隱患。

2010年，谷歌發(fā)表了一篇論文，介紹了谷歌的內(nèi)部鏈路追蹤系統(tǒng)Dapper的設(shè)計(jì)，鏈路追蹤技術(shù)自此進(jìn)入社區(qū)的視野。

下面，我們將簡(jiǎn)單介紹其在APM領(lǐng)域的應(yīng)用，以及在服務(wù)依賴治理和研發(fā)效能提升方面的實(shí)踐。

服務(wù)依賴治理

不合理的依賴，可能導(dǎo)致邊緣系統(tǒng)的故障拖垮核心服務(wù)，威脅到分布式系統(tǒng)整體的穩(wěn)定性。通過(guò)鏈路追蹤數(shù)據(jù)的匯總分析，我們可以繪制出系統(tǒng)間的依賴拓?fù)?，為依賴治理提供?shù)據(jù)支撐。

我們一般會(huì)從下面三個(gè)角度來(lái)評(píng)估服務(wù)依賴的合理性：

• 反向依賴。反向依賴指高等級(jí)服務(wù)依賴了低等級(jí)服務(wù)。例如，租戶服務(wù)是我們的核心服務(wù)之一，而統(tǒng)計(jì)服務(wù)重要性相對(duì)較低，顯然，我們不允許租戶服務(wù)依賴統(tǒng)計(jì)服務(wù)。通過(guò)服務(wù)拓?fù)鋱D和服務(wù)等級(jí)的結(jié)合，我們可以很容易的將反向依賴分析自動(dòng)化，實(shí)時(shí)預(yù)警。
• 強(qiáng)弱依賴。強(qiáng)依賴指下游服務(wù)發(fā)生異常時(shí)，將影響當(dāng)前節(jié)點(diǎn)的穩(wěn)定性。在設(shè)計(jì)時(shí)，我們應(yīng)該充分考慮強(qiáng)依賴在當(dāng)前場(chǎng)景中的必要性。強(qiáng)依賴是否可以弱化，如果不能，業(yè)務(wù)場(chǎng)景是否允許加上熔斷降級(jí)之類(lèi)的的保護(hù)措施。強(qiáng)弱依賴的梳理，我們可以結(jié)合故障注入工具，產(chǎn)出系統(tǒng)化的報(bào)告。
• 環(huán)狀依賴。環(huán)狀依賴往往是邊界不清晰的表現(xiàn)，絞成一團(tuán)，層次不清。對(duì)環(huán)狀依賴的梳理也是我們對(duì)業(yè)務(wù)邊界和系統(tǒng)邊界的梳理，對(duì)系統(tǒng)整體健康度的提升非常有意義。

研發(fā)效能提升

隨著業(yè)務(wù)的發(fā)展，研發(fā)團(tuán)隊(duì)的規(guī)模在一定階段也會(huì)相應(yīng)地不斷提升，但支撐我們研發(fā)活動(dòng)的基礎(chǔ)設(shè)施卻沒(méi)有辦法線性增長(zhǎng)，這其中最重要的就是聯(lián)調(diào)或測(cè)試環(huán)境。

業(yè)務(wù)發(fā)展往往導(dǎo)致并行迭代的增多，而這些并行迭代難免會(huì)改動(dòng)到相同的服務(wù)，尤其是一些核心基礎(chǔ)服務(wù)。如下圖，

這就會(huì)導(dǎo)致兩個(gè)問(wèn)題——

1. 環(huán)境爭(zhēng)奪。如圖，Story-B需要部署ticket服務(wù)，與此同時(shí)Hotfix-A也等待驗(yàn)證，同樣需要部署ticket服務(wù)，這意味著至少有一方會(huì)被阻塞等待，這種串行模式，極大地降低了我們的交付效率。并行迭代越多，效率降低越明顯。

2. 環(huán)境的穩(wěn)定性。服務(wù)之間是相互聯(lián)系的，任何服務(wù)的不穩(wěn)定都可能會(huì)導(dǎo)致該環(huán)境的不穩(wěn)定。上圖中的auth服務(wù)，幾乎要被所有的業(yè)務(wù)流程使用。如果Story-A部署auth服務(wù)時(shí)，重啟/部署的過(guò)程不夠平滑，或者Story-A的代碼中存在某些bug，那么會(huì)造成整個(gè)測(cè)試環(huán)境的不穩(wěn)定。

項(xiàng)目規(guī)模不大時(shí)，我們往往能通過(guò)一些管理手段來(lái)協(xié)調(diào)。例如版本串行化，通過(guò)將迭代計(jì)劃錯(cuò)開(kāi)，避免在同一個(gè)時(shí)間段都要去部署某個(gè)服務(wù)。測(cè)試環(huán)境只部署特定分支，需要驗(yàn)證時(shí)則將各自的代碼都合并到此分支；要求部署到測(cè)試環(huán)境的代碼必須達(dá)到某種標(biāo)準(zhǔn)以提升測(cè)試環(huán)境的穩(wěn)定性。

然而我們也可以看到，管理手段的有效性是和團(tuán)隊(duì)規(guī)模微服務(wù)規(guī)模反相關(guān)的，我們需要有技術(shù)手段來(lái)達(dá)到更好的效果。

細(xì)想一下，其實(shí)問(wèn)題的根源是大家共用一套測(cè)試環(huán)境，所以我們的研發(fā)活動(dòng)出現(xiàn)了資源競(jìng)爭(zhēng)，我們對(duì)某個(gè)服務(wù)的操作可能影響到其他服務(wù)。

那么，能否讓大家都能輕松創(chuàng)建各自的環(huán)境，且各個(gè)環(huán)境的使用互不影響呢？

如上圖，Story-A需要部署user和auth服務(wù)，那么我們創(chuàng)建env-1并部署我們的user和auth; Story-B需要部署ticket服務(wù)，那么我們就創(chuàng)建env-2并部署ticket服務(wù)；env-3同理。

為了描述方便，我們把上圖中的env-x環(huán)境，叫測(cè)試環(huán)境；圖中的下半部分，叫回歸環(huán)境。測(cè)試環(huán)境只包含本次迭代需要部署的應(yīng)用，回歸環(huán)境包含所有應(yīng)用。

當(dāng)我們使用這套機(jī)制時(shí)，我們期望env-1的使用者，請(qǐng)求user和auth服務(wù)時(shí)只會(huì)路由到env-1環(huán)境，請(qǐng)求其他服務(wù)時(shí)路由到回歸環(huán)境。env-2環(huán)境的使用者，請(qǐng)求ticket服務(wù)時(shí)只會(huì)路由到env-2環(huán)境，請(qǐng)求其他服務(wù)時(shí)同樣路由到回歸環(huán)境。

也就是說(shuō)，對(duì)于環(huán)境使用者的請(qǐng)求，如果相關(guān)的應(yīng)用在該環(huán)境內(nèi)，則請(qǐng)求只會(huì)被該環(huán)境內(nèi)的應(yīng)用處理，否則路由到回歸環(huán)境處理。

回歸環(huán)境是一個(gè)包含所有服務(wù)的相對(duì)穩(wěn)定的環(huán)境，開(kāi)發(fā)和提測(cè)不允許在回歸環(huán)境部署，以此來(lái)保證足夠的穩(wěn)定性。

研發(fā)流程方面，我們不再像以前一樣部署到大家都在使用的環(huán)境中去驗(yàn)證，而是各自創(chuàng)建各自獨(dú)享的環(huán)境，在自己的環(huán)境中完成相關(guān)工作。

我們將上述機(jī)制稱之為環(huán)境隔離，要實(shí)現(xiàn)環(huán)境隔離，技術(shù)側(cè)至少需要實(shí)現(xiàn)兩方面的能力：

• 識(shí)別并傳遞請(qǐng)求對(duì)應(yīng)的環(huán)境信息
• ?預(yù)中間件的實(shí)例選擇/消費(fèi)規(guī)則

（一）識(shí)別并傳遞請(qǐng)求對(duì)應(yīng)的環(huán)境信息

首先，我們需要能將請(qǐng)求和測(cè)試環(huán)境關(guān)聯(lián)起來(lái)。

識(shí)別請(qǐng)求對(duì)應(yīng)的環(huán)境信息，這意味著我們?cè)趧?chuàng)建測(cè)試環(huán)境時(shí)需要指明某種標(biāo)識(shí)，且這種標(biāo)識(shí)我們可以從請(qǐng)求中提取出，從而通過(guò)雙方標(biāo)識(shí)的匹配來(lái)完成關(guān)聯(lián)，這種標(biāo)識(shí)可以是用戶賬號(hào)、某組IP，或者企業(yè)租戶，使用哪種方式不重要，重要的是結(jié)合業(yè)務(wù)特點(diǎn)達(dá)到方便易用的目的。

例如，在我們的SaaS系統(tǒng)七魚(yú)里，我們使用租戶id來(lái)作為我們的標(biāo)識(shí)。在我們的平臺(tái)創(chuàng)建測(cè)試環(huán)境時(shí)，除了指明要部署的應(yīng)用外，我們還需要輸入租戶信息，通過(guò)這種方式完成請(qǐng)求和測(cè)試環(huán)境的映射。

我們可以在請(qǐng)求的統(tǒng)一入口處（例如，網(wǎng)關(guān)），獲取到請(qǐng)求所屬的租戶，之后我們可以進(jìn)一步拿到它所屬的環(huán)境信息(環(huán)境ID、應(yīng)用列表)。類(lèi)似于鏈路跟蹤系統(tǒng)在請(qǐng)求鏈中傳輸TraceID，我們?cè)谡?qǐng)求鏈中附加上環(huán)境信息，為環(huán)境隔離打下基礎(chǔ)。

（二）?預(yù)中間件的實(shí)例選擇/消費(fèi)規(guī)則

我們以微服務(wù)架構(gòu)中最常用的幾個(gè)組件為例，談?wù)劖h(huán)境隔離的實(shí)現(xiàn)方式。

RPC框架——

RPC的核心流程：provider實(shí)例將自己注冊(cè)到注冊(cè)中心，consumer通過(guò)注冊(cè)中心獲取provider實(shí)例列表，根據(jù)一定的實(shí)例篩選策略和負(fù)載均衡算法，選擇其中一個(gè)實(shí)例發(fā)起調(diào)用。

所以改造的手段很明確，provider啟動(dòng)時(shí)，我們?cè)谠獢?shù)據(jù)中寫(xiě)入環(huán)境ID。在實(shí)例選擇時(shí)，我們從請(qǐng)求的鏈路數(shù)據(jù)中拿出環(huán)境ID與之做匹配。

需要特別注意的是，匹配不到符合要求的實(shí)例時(shí)，我們不能簡(jiǎn)單的認(rèn)為no provider而讓程序報(bào)錯(cuò)，我們需要考慮該provider所屬的應(yīng)用是否在對(duì)應(yīng)環(huán)境應(yīng)用列表中，如果不在，我們需要將請(qǐng)求路由到回歸環(huán)境中。

消息中間件——

RPC在調(diào)用之前有如上所述的實(shí)例篩選過(guò)程，但消息中間件沒(méi)有這個(gè)邏輯，不過(guò)我們依然可以干預(yù)消費(fèi)規(guī)則，即在消費(fèi)者拿到消息后判斷是丟棄消息還是消費(fèi)該消息。以kafka為例，測(cè)試環(huán)境的kafka consumer啟動(dòng)時(shí)，修改consumer groupid為groupid_${env}。kafka consumer接收到消息時(shí)，執(zhí)行和上述RPC框架篩選實(shí)例時(shí)類(lèi)似的邏輯即可。

定時(shí)任務(wù)——

定時(shí)任務(wù)其實(shí)最為特殊。前文中我們提到，在請(qǐng)求的統(tǒng)一入口，查詢請(qǐng)求所對(duì)應(yīng)的環(huán)境信息并寫(xiě)入鏈路。但是定時(shí)任務(wù)發(fā)起的請(qǐng)求并不是用戶觸發(fā)的，它來(lái)自系統(tǒng)內(nèi)部，定時(shí)調(diào)度組件才是請(qǐng)求的“源頭”。所以我們需要在定時(shí)任務(wù)執(zhí)行之初，就加入我們的判斷標(biāo)識(shí)邏輯，這要求我們：

• 定時(shí)任務(wù)需要有統(tǒng)一的調(diào)度平臺(tái)，避免各業(yè)務(wù)模塊姿勢(shì)各異，無(wú)法由通用組件統(tǒng)一處理
• 針對(duì)調(diào)度組件的任務(wù)分發(fā)/分片機(jī)制的改造，統(tǒng)一抽象執(zhí)行層，加入環(huán)境隔離邏輯

結(jié)束語(yǔ)

在網(wǎng)易智慧企業(yè)中，鏈路追蹤技術(shù)的應(yīng)用，提升了我們的問(wèn)題排查效率以及對(duì)請(qǐng)求鏈路的把控，也為服務(wù)依賴治理提供了必要的數(shù)據(jù)支撐。同時(shí)環(huán)境隔離也極大地提升了交付效率和測(cè)試環(huán)境的穩(wěn)定性，從而提高了研發(fā)團(tuán)隊(duì)的整體幸福感。

整體來(lái)說(shuō)，我們構(gòu)建了統(tǒng)一的鏈路追蹤體系，支撐了服務(wù)依賴治理及環(huán)境隔離技術(shù)的實(shí)現(xiàn)，但這并不是終點(diǎn)，我們還可以發(fā)掘更多的場(chǎng)景，比如SaaS系統(tǒng)的多租戶資源隔離，或者異常監(jiān)控預(yù)警。世界很大，一起多探索。