轉(zhuǎn)轉(zhuǎn)測(cè)試環(huán)境治理歷經(jīng)3個(gè)版本的迭代，環(huán)境搭建耗時(shí)及資源占用大幅度下降，在此過程中積累了豐富的實(shí)踐經(jīng)驗(yàn)。本文將從測(cè)試環(huán)境的需求及背景出發(fā)，介紹轉(zhuǎn)轉(zhuǎn)測(cè)試環(huán)境治理各個(gè)版本的原理、技術(shù)、優(yōu)缺點(diǎn)，毫無保留地將轉(zhuǎn)轉(zhuǎn)的實(shí)踐經(jīng)驗(yàn)分享給各位讀者。

1. 背景及需求

1.1 系統(tǒng)架構(gòu)的發(fā)展

很久很久以前，在并發(fā)量較低時(shí)系統(tǒng)大多采用單體架構(gòu)，由單個(gè)web服務(wù)直接連接數(shù)據(jù)庫(kù)，由nginx在多個(gè)web服務(wù)節(jié)點(diǎn)間做負(fù)載均衡。

單體架構(gòu)

隨著系統(tǒng)并發(fā)量的提高，單體架構(gòu)無法滿足性能需求，需要對(duì)單體服務(wù)進(jìn)行拆分，于是來到了微服務(wù)架構(gòu)。微服務(wù)架構(gòu)與單體架構(gòu)顯著的不同在于鏈路更長(zhǎng)更復(fù)雜了。

微服務(wù)架構(gòu)

1.2 測(cè)試環(huán)境的需求

測(cè)試環(huán)境與線上環(huán)境的典型不同在于線上環(huán)境各節(jié)點(diǎn)一般情況下代碼是一致的，各節(jié)點(diǎn)是對(duì)等的，請(qǐng)求到達(dá)任意節(jié)點(diǎn)業(yè)務(wù)邏輯都是一致的；而測(cè)試環(huán)境一般是多分支并行開發(fā)，每個(gè)節(jié)點(diǎn)的邏輯是不一致的，既然要測(cè)試本次所開發(fā)的功能，那就要求請(qǐng)求能精準(zhǔn)地到達(dá)所部署的節(jié)點(diǎn)。

在單體架構(gòu)下，該需求是很容易實(shí)現(xiàn)的，通過采用修改nginx配置，在upstream中僅包含目標(biāo)測(cè)試節(jié)點(diǎn)可以很容易實(shí)現(xiàn)對(duì)目標(biāo)節(jié)點(diǎn)的精準(zhǔn)測(cè)試，或者不使用nginx直接通過IP+port的形式進(jìn)行調(diào)用也同樣可以實(shí)現(xiàn)請(qǐng)求精準(zhǔn)到達(dá)目標(biāo)節(jié)點(diǎn)。如下圖所示的A'及A''屬于兩個(gè)不同的需求，分別通過固定nginx upstream及IP+port的形式實(shí)現(xiàn)了請(qǐng)求的精準(zhǔn)控制。

單體架構(gòu)測(cè)試

而在微服務(wù)架構(gòu)下，該需求實(shí)現(xiàn)起來就沒那么簡(jiǎn)單了。如下圖所示，鏈路上包括服務(wù)A、B、C，圖中A'、B'、C'屬于同一個(gè)需求，而A''、B''、C''屬于另一個(gè)需求。采用在單體架構(gòu)下的解決方案只能控制請(qǐng)求精準(zhǔn)地到達(dá)A'或者A''，無法實(shí)現(xiàn)請(qǐng)求精準(zhǔn)地到達(dá)B'、C'及B''、C''。

微服務(wù)架構(gòu)測(cè)試

2. 傳統(tǒng)的測(cè)試環(huán)境解決方案-物理隔離

為了實(shí)現(xiàn)請(qǐng)求精準(zhǔn)地到達(dá)被測(cè)服務(wù)節(jié)點(diǎn)，傳統(tǒng)的做法是提供多套完全互相隔離的測(cè)試環(huán)境，每套測(cè)試環(huán)境包含全量的服務(wù)及注冊(cè)中心、MQ broker等。每個(gè)需求分配一套測(cè)試環(huán)境，只需將被測(cè)服務(wù)部署至該環(huán)境內(nèi)即可實(shí)現(xiàn)請(qǐng)求精準(zhǔn)地到達(dá)被測(cè)節(jié)點(diǎn)，這種做法也稱作物理隔離。

物理隔離

物理隔離在公司服務(wù)數(shù)量較少時(shí)（20個(gè)服務(wù)以下）稱得上是完美的解決方案，非常簡(jiǎn)單可靠。但是隨著服務(wù)數(shù)量的增長(zhǎng)，物理隔離的缺點(diǎn)逐漸顯露——資源浪費(fèi)太嚴(yán)重。假設(shè)整個(gè)系統(tǒng)有100個(gè)服務(wù)，而每次需求僅修改其中的1-3個(gè)服務(wù)，資源浪費(fèi)率高達(dá)97%-99%。而且服務(wù)數(shù)量的增長(zhǎng)，往往也意味著公司業(yè)務(wù)的發(fā)展壯大，同時(shí)進(jìn)行中的需求數(shù)量也在增長(zhǎng)，需要提供更多的測(cè)試環(huán)境，資源消耗巨大。

3. 轉(zhuǎn)轉(zhuǎn)測(cè)試環(huán)境V1-改進(jìn)的物理隔離

轉(zhuǎn)轉(zhuǎn)公司傳統(tǒng)的測(cè)試環(huán)境解決方案屬于改進(jìn)型的物理隔離。

3.1 穩(wěn)定環(huán)境

在轉(zhuǎn)轉(zhuǎn)有一套穩(wěn)定環(huán)境包含全量的服務(wù)并且與線上代碼一致。在測(cè)試環(huán)境不使用注冊(cè)中心，而是為每一個(gè)服務(wù)分配唯一的域名并通過修改機(jī)器host映射的方式手動(dòng)控制服務(wù)發(fā)現(xiàn)。默認(rèn)情況下，如果服務(wù)A部署在穩(wěn)定環(huán)境的??192.168.1.1???上，那么所有測(cè)試環(huán)境機(jī)器的host文件中都存在一項(xiàng)配置??192.168.1.1 A.zhuaninc.com??。

3.2 動(dòng)態(tài)環(huán)境

每次需求所申請(qǐng)的環(huán)境稱為動(dòng)態(tài)環(huán)境，為一臺(tái)kvm虛擬機(jī)。假設(shè)某動(dòng)態(tài)環(huán)境的IP為192.168.2.1?，在該動(dòng)態(tài)環(huán)境部署服務(wù)A時(shí)，同時(shí)將該機(jī)器的host文件中192.168.1.1 A.zhuaninc.com?（假設(shè)穩(wěn)定環(huán)境服務(wù)A的IP為192.68.1.1?）映射，修改為127.0.0.1 A.zhuaninc.com。

如下圖所示的動(dòng)態(tài)環(huán)境192.168.4.1?，其中A'及E'即為本次需求所修改的服務(wù)。

初始化過程如下：

1. 申請(qǐng)動(dòng)態(tài)環(huán)境192.168.4.1?，申請(qǐng)完成后該機(jī)器的host文件中包含全量的服務(wù)域名映射，默認(rèn)映射到對(duì)應(yīng)的穩(wěn)定環(huán)境所在的IP，該例中僅展示了F服務(wù)的域名映射為192.168.5.1 F.zhuaninc.com ?（假設(shè)穩(wěn)定環(huán)境服務(wù)F的IP為192.168.5.1）。
2. 部署服務(wù)E'，同時(shí)將127.0.0.1寫入host文件。
3. 部署服務(wù)D，同時(shí)將127.0.0.1寫入host文件。
4. 部署服務(wù)C，同時(shí)將127.0.0.1寫入host文件。
5. 部署服務(wù)B，同時(shí)將127.0.0.1寫入host文件。
6. 部署服務(wù)A'，同時(shí)將127.0.0.1寫入host文件。
7. 部署Entry。
8. 部署nginx，同時(shí)將服務(wù)A的upstream修改為僅包含127.0.0.1。

如此以來，就像焊接管道一樣，從服務(wù)E至nginx倒序焊接出一條沒有分叉的管道。測(cè)試時(shí)只需要通過host映射將被測(cè)域名映射到該IP，即可實(shí)現(xiàn)請(qǐng)求精準(zhǔn)地到達(dá)A'及E'，E'以后的鏈路（從F開始的鏈路）則使用穩(wěn)定環(huán)境。

對(duì)于MQ，則通過在動(dòng)態(tài)環(huán)境topic添加IP前綴的方式實(shí)現(xiàn)與穩(wěn)定環(huán)境的物理隔離，如下圖所示不同的topic在broker上存在著不同的隊(duì)列，穩(wěn)定環(huán)境的消息和動(dòng)態(tài)環(huán)境的消息不能互通。

MQ消息物理隔離

如在測(cè)試過程中發(fā)現(xiàn)需要修改更多的服務(wù)，例如需要修改服務(wù)F，則在將F服務(wù)部署在該動(dòng)態(tài)環(huán)境的同時(shí)，需要重啟服務(wù)E'，因?yàn)镋'已經(jīng)與穩(wěn)定環(huán)境的F建了tcp連接，修改F服務(wù)的域名映射并不會(huì)導(dǎo)致E'與F之間重新建立tcp連接，所以需要重啟E'。如F服務(wù)的調(diào)用方不僅有E'，則都需要重啟。

3.3 優(yōu)缺點(diǎn)

該解決方案近似于物理隔離，但較物理隔離有所改進(jìn)，改進(jìn)的地方在于動(dòng)態(tài)環(huán)境并沒有包含全量的服務(wù)，動(dòng)態(tài)環(huán)境僅包含了從nginx開始至最后一個(gè)被測(cè)的服務(wù)，而使用穩(wěn)定環(huán)境充當(dāng)被測(cè)鏈路的尾巴。

3.3.1 優(yōu)點(diǎn)

• 隔離性強(qiáng)，近似于物理隔離。
• 鏈路簡(jiǎn)單，流量封閉在同一臺(tái)機(jī)器上。

3.3.2 缺點(diǎn)

• 需要部署從nginx開始至最后一個(gè)被測(cè)的服務(wù)，存在未修改服務(wù)部署在動(dòng)態(tài)環(huán)境中的情況，造成資源浪費(fèi)。
• 由于部署過程依賴服務(wù)的調(diào)用關(guān)系，導(dǎo)致部署效率低下，極端情況下需要數(shù)天調(diào)試測(cè)試環(huán)境。
• host管理復(fù)雜。
• topic添加IP前綴易出錯(cuò)，代碼與環(huán)境相關(guān)。
• 單臺(tái)機(jī)器內(nèi)存有限，鏈路過長(zhǎng)無法滿足。

4. 轉(zhuǎn)轉(zhuǎn)測(cè)試環(huán)境V2-基于自動(dòng)IP標(biāo)簽的流量路由

?隨著轉(zhuǎn)轉(zhuǎn)公司業(yè)務(wù)的飛速發(fā)展，服務(wù)數(shù)量迅速增加，每個(gè)動(dòng)態(tài)環(huán)境部署的服務(wù)數(shù)量增至30-60個(gè)，搭建測(cè)試環(huán)境的成本越來越高。為了解決該問題，轉(zhuǎn)轉(zhuǎn)架構(gòu)部、運(yùn)維部、工程效率部推出了流量路由解決方案。該解決方案在此前的公眾號(hào)文章??轉(zhuǎn)轉(zhuǎn)測(cè)試環(huán)境的服務(wù)治理實(shí)踐??中已有詳細(xì)講解，本文僅做簡(jiǎn)要介紹。

該版本的流量路由技術(shù)稱為基于自動(dòng)IP標(biāo)簽的流量路由，之所以選擇IP為標(biāo)簽是因?yàn)榛诂F(xiàn)有使用習(xí)慣發(fā)現(xiàn)所有被測(cè)服務(wù)部署在同一臺(tái)虛擬機(jī)上，IP地址一樣，并且IP易獲取，用戶無感知；“自動(dòng)”則體現(xiàn)在無需用戶對(duì)服務(wù)及流量進(jìn)行打標(biāo)，打標(biāo)是完全自動(dòng)化進(jìn)行的。

基于自動(dòng)IP標(biāo)簽的流量路由將測(cè)試環(huán)境的搭建時(shí)間從數(shù)小時(shí)-數(shù)天減少至30分鐘-1小時(shí)，每環(huán)境部署的服務(wù)數(shù)量從30-60個(gè)服務(wù)下降至個(gè)位數(shù)，并且完全兼容沒有流量路由時(shí)的使用習(xí)慣。但是仍然存在申請(qǐng)?zhí)摂M機(jī)耗時(shí)長(zhǎng)，kvm內(nèi)存無法擴(kuò)容的問題。?

5. 轉(zhuǎn)轉(zhuǎn)測(cè)試環(huán)境V3-基于手動(dòng)標(biāo)簽的流量路由

基于自動(dòng)IP標(biāo)簽的流量路由解決了轉(zhuǎn)轉(zhuǎn)測(cè)試環(huán)境存在的大部分問題，使測(cè)試環(huán)境的搭建時(shí)間從數(shù)小時(shí)-數(shù)天下降至30分鐘-1小時(shí)，但是仍然存在申請(qǐng)環(huán)境耗時(shí)長(zhǎng)，kvm內(nèi)存無法擴(kuò)容的問題，本著精益求精，用戶至上的原則，我們開發(fā)了基于手動(dòng)標(biāo)簽的流量路由。

5.1 docker化

為了解決申請(qǐng)環(huán)境耗時(shí)長(zhǎng)，kvm內(nèi)存無法擴(kuò)容的問題，我們決定將服務(wù)部署在docker容器內(nèi)，無需提前申請(qǐng)資源，理論上無內(nèi)存限制。但是docker化以后，基于IP為標(biāo)簽的流量路由顯然無法工作了，因?yàn)椴煌姆?wù)部署在不同的docker pod內(nèi)，IP也是不一樣的。

5.2 服務(wù)及流量打標(biāo)

此時(shí)就需要手動(dòng)為服務(wù)及流量指定標(biāo)簽，我們稱為基于手動(dòng)標(biāo)簽的流量路由。為服務(wù)打標(biāo)是自動(dòng)化完成的，在環(huán)境平臺(tái)申請(qǐng)環(huán)境時(shí)指定標(biāo)簽，在該環(huán)境內(nèi)部署服務(wù)時(shí)，由環(huán)境平臺(tái)自動(dòng)添加jvm參數(shù)-Dtag=xxx。而為流量打標(biāo)則通過http header進(jìn)行，在發(fā)起請(qǐng)求時(shí)添加header tag=xxx。

申請(qǐng)環(huán)境

自動(dòng)添加jvm參數(shù)

請(qǐng)求添加http header

并非所有請(qǐng)求都是通過http發(fā)起的，有些由進(jìn)程內(nèi)部（如定時(shí)任務(wù)）直接發(fā)起的調(diào)用則自動(dòng)攜帶當(dāng)前節(jié)點(diǎn)的標(biāo)簽。

5.3 目標(biāo)形態(tài)

基于手動(dòng)打標(biāo)的流量路由目標(biāo)形態(tài)如下圖所示，標(biāo)簽為??yyy??的動(dòng)態(tài)環(huán)境，本次需求修改了服務(wù)B及服務(wù)D，只需要在該動(dòng)態(tài)環(huán)境內(nèi)部署B(yǎng)和D，真正實(shí)現(xiàn)修改什么就部署什么。

標(biāo)簽路由使用目標(biāo)

5.4 RPC調(diào)用實(shí)現(xiàn)

5.4.1 服務(wù)注冊(cè)、發(fā)現(xiàn)及調(diào)用

以下圖服務(wù)A調(diào)用服務(wù)B為例，服務(wù)B有3個(gè)節(jié)點(diǎn)，穩(wěn)定環(huán)境的B，動(dòng)態(tài)環(huán)境的B'（標(biāo)簽為??yyy??）及B''（標(biāo)簽為??xxx??）。B'和B''在啟動(dòng)時(shí)會(huì)將標(biāo)簽參數(shù)注冊(cè)到注冊(cè)中心，服務(wù)A在啟動(dòng)時(shí)會(huì)從注冊(cè)中心發(fā)現(xiàn)B、B'、B''，同時(shí)獲取它們的標(biāo)簽參數(shù)。

RPC標(biāo)簽路由

以紅色的鏈路為例，流量標(biāo)簽為zzz，A在調(diào)用時(shí)發(fā)現(xiàn)并沒有動(dòng)態(tài)環(huán)境的服務(wù)B擁有標(biāo)簽zzz，于是調(diào)用穩(wěn)定環(huán)境的B節(jié)點(diǎn)。

橙色鏈路的標(biāo)簽為xxx，A在調(diào)用時(shí)發(fā)現(xiàn)B''的標(biāo)簽為xxx，且為動(dòng)態(tài)環(huán)境，則調(diào)用B''。

轉(zhuǎn)轉(zhuǎn)使用的RPC為自研RPC框架，在調(diào)用時(shí)除了傳遞請(qǐng)求方法及參數(shù)等信息之外，還可以通過attachement功能傳遞額外的參數(shù)，而路由標(biāo)簽就是通過該功能在RPC調(diào)用時(shí)實(shí)現(xiàn)傳遞。

5.5 MQ消息實(shí)現(xiàn)

5.5.1 消費(fèi)原理

若想實(shí)現(xiàn)消息可以在動(dòng)態(tài)環(huán)境與穩(wěn)定環(huán)境之間路由，通過不同的的topic前綴實(shí)現(xiàn)動(dòng)態(tài)環(huán)境和穩(wěn)定環(huán)境的物理隔離顯然已經(jīng)行不通。此時(shí)的解決方案為動(dòng)態(tài)環(huán)境和穩(wěn)定環(huán)境擁有相同的topic，但是不同的消費(fèi)group，不同的消費(fèi)group就對(duì)應(yīng)不同的消費(fèi)offset。動(dòng)態(tài)環(huán)境的group添加${tag}前綴，而穩(wěn)定環(huán)境的group添加test_前綴，添加前綴的過程由MQ客戶端自動(dòng)完成，對(duì)用戶透明。

如下圖所示服務(wù)B有穩(wěn)定環(huán)境及動(dòng)態(tài)環(huán)境（B'）節(jié)點(diǎn)各一個(gè)，B'的標(biāo)簽為xxx。圖中通過不同的顏色表示不同的標(biāo)簽，其中綠色表示沒有標(biāo)簽。

MQ標(biāo)簽路由

B節(jié)點(diǎn)在消費(fèi)時(shí)，首先判斷是否有和消息中標(biāo)簽對(duì)應(yīng)的消費(fèi)組注冊(cè)到broker上，如果有則過濾掉，否則消費(fèi)。其中消息1、3、5、7的標(biāo)簽和B'匹配，消息2沒有標(biāo)簽，而消息4、6的標(biāo)簽所對(duì)應(yīng)的消費(fèi)者沒有注冊(cè)到broker上，所以B節(jié)點(diǎn)消費(fèi)了消息2、4、6。

B'節(jié)點(diǎn)在消費(fèi)時(shí)，只消費(fèi)消息中標(biāo)簽和自身標(biāo)簽前綴一致的消息，即消息1、3、5。

5.5.2 存在的問題

假如此時(shí)B'下線了，我們發(fā)現(xiàn)消息7沒有被消費(fèi)者消費(fèi)，該消息丟了。這是因?yàn)榉€(wěn)定環(huán)境消費(fèi)組和動(dòng)態(tài)環(huán)境消費(fèi)組offset不一致導(dǎo)致的，穩(wěn)定環(huán)境消費(fèi)組offset大于動(dòng)態(tài)環(huán)境消費(fèi)組offset，解決方案就是B'下線時(shí)將其與穩(wěn)定環(huán)境offset之間的消息重新投遞。重新投遞后假如B'又上線了呢，就帶來了消息的重復(fù)消費(fèi)，但是我們認(rèn)為重復(fù)消費(fèi)是沒有問題的，因?yàn)閙q本身的消費(fèi)語(yǔ)義就是至少一次，而不是僅僅一次，重復(fù)消費(fèi)冪等性應(yīng)該由業(yè)務(wù)邏輯來保證。

另一個(gè)問題是批量消費(fèi)如何解決，mq客戶端有批量消費(fèi)功能，一批消息所攜帶的標(biāo)簽可能是不一樣的。對(duì)于這個(gè)問題，只需要將消息按標(biāo)簽分組后再執(zhí)行消費(fèi)邏輯即可。

5.5.3 標(biāo)簽的傳遞

轉(zhuǎn)轉(zhuǎn)使用的是RocketMQ，并進(jìn)行了二次開發(fā)，RocketMQ提供了可擴(kuò)展的header可以用來傳遞路由標(biāo)簽。

5.6 進(jìn)程內(nèi)標(biāo)簽的傳遞

跨進(jìn)程的標(biāo)簽傳遞相對(duì)來講比較容易解決，而進(jìn)程內(nèi)標(biāo)簽的傳遞難度更高。

5.6.1 通過方法參數(shù)傳遞

通過為每一個(gè)方法調(diào)用添加tag參數(shù)可以實(shí)現(xiàn)標(biāo)簽的的進(jìn)程內(nèi)傳遞，但是顯然這不現(xiàn)實(shí)，需要全公司所有的代碼配合改動(dòng)。

5.6.2 通過ThreadLocal傳遞

jdk內(nèi)置有ThreadLocal及InheritableThreadLocal可以實(shí)現(xiàn)標(biāo)簽的隱式傳遞，但是ThreadLocal無法實(shí)現(xiàn)new Thread及跨線程池傳遞，而InheritableThreadLocal可以實(shí)現(xiàn)new Thread傳遞卻仍然無法實(shí)現(xiàn)跨線程池傳遞。雖然可以通過對(duì)Callable和Runnable進(jìn)行包裝實(shí)現(xiàn)跨線程池傳遞，但這仍然要求修改現(xiàn)有的業(yè)務(wù)代碼，成本較高。

5.5.3 通過TransmittableThreadLocal傳遞

TransmittableThreadLocal[1]是阿里巴巴開源的，通過java agent技術(shù)實(shí)現(xiàn)的可以跨線程/跨線程池傳遞的??ThreadLocal??，對(duì)用戶透明，只需要在jvm啟動(dòng)參數(shù)中加入對(duì)應(yīng)的java agent參數(shù)即可，最終我們采用了該方案。

TransmittableThreadLocal Agent

5.6 上線收益

下圖為轉(zhuǎn)轉(zhuǎn)公司動(dòng)態(tài)環(huán)境平均部署服務(wù)數(shù)量曲線，在2022年5月之前平均每環(huán)境約部署7-8個(gè)服務(wù)，在2022年5月之后標(biāo)簽路由開始推廣，至2022年7月每環(huán)境約部署3-4個(gè)服務(wù)。雖然從原理上看基于手動(dòng)標(biāo)簽的流量路由每環(huán)境僅比基于自動(dòng)IP標(biāo)簽的流量路由僅少部署一個(gè)服務(wù)（Entry），但是由于kvm無法擴(kuò)容，所以在自動(dòng)IP路由時(shí)代環(huán)境初始化時(shí)用戶總是會(huì)預(yù)防性地多選擇一些服務(wù)，以達(dá)到申請(qǐng)更大內(nèi)存虛擬機(jī)的目的，而docker化之后，此種擔(dān)憂不再存在，所以每環(huán)境部署的服務(wù)數(shù)量下降了約4個(gè)，動(dòng)態(tài)環(huán)境總內(nèi)存節(jié)省了約65%。

測(cè)試環(huán)境搭建時(shí)間從30分鐘-1小時(shí)下降至2分鐘-5分鐘，時(shí)間的節(jié)省主要來自無需提前申請(qǐng)kvm、docker資源隔離服務(wù)啟動(dòng)快、無內(nèi)存擴(kuò)容擔(dān)憂初始化服務(wù)數(shù)量少。

每環(huán)境部署服數(shù)量曲線

5.7 輔助設(shè)施

docker化雖然帶來了效率的提升，資源占用的下降，但是也引入了一些問題。每次部署IP地址都會(huì)變化，導(dǎo)致遠(yuǎn)程登錄及debug的成本增加。在Http Header中添加路由標(biāo)簽增加了測(cè)試同學(xué)的工作量。為了解決這些問題，我們又開發(fā)了對(duì)應(yīng)的輔助設(shè)施來提高工作效率。

5.7.1 泛域名解析

使用http傳遞標(biāo)簽，仍然需要配置host映射將域名映射至測(cè)試環(huán)境的nginx，如192.168.1.1 app.zhuanzhuan.com，否則dns解析會(huì)將app.zhuanzhuan.com解析至線上nginx。

是否可以免去host配置呢，答案是可以的。通過直接使用域名傳遞標(biāo)簽的形式來實(shí)現(xiàn)免去host配置，如app.zhuanzhuan.com?直接使用域名傳遞標(biāo)簽寫作app-${tag}.test.zhuanzhuan.com，該域名會(huì)直接解析至測(cè)試環(huán)境nginx。在開發(fā)版app中內(nèi)置了該功能，在app啟動(dòng)時(shí)輸入環(huán)境標(biāo)簽即可實(shí)現(xiàn)域名的切換，無需配置host即可開始測(cè)試。

泛域名解析

5.7.2 web shell

docker化以后每次部署都是一個(gè)新的docker pod，IP地址也隨之變化，如果需要登錄查看日志，通過xshell等工具則需要在每次部署后使用新的IP重新登錄。引入web shell功能只需要在環(huán)境平臺(tái)頁(yè)面中點(diǎn)擊按鈕即可通過web shell的方式直接登錄，并且登錄后的工作目錄默認(rèn)為該服務(wù)的日志目錄。

web shell

5.7.3 debug插件

同樣因?yàn)閐ocker化以后IP地址總是變化，測(cè)試環(huán)境的遠(yuǎn)程debug也變得更加不方便，每次需要更換新的IP進(jìn)行連接。為了解決此問題，我們開發(fā)了debug插件，該插件會(huì)自動(dòng)獲取項(xiàng)目名作為服務(wù)名，需要debug時(shí)輸入環(huán)境標(biāo)簽，插件會(huì)自動(dòng)向環(huán)境平臺(tái)發(fā)起請(qǐng)求，而環(huán)境平臺(tái)則通過解析jvm參數(shù)的方式獲取debug端口并向插件返回IP和debug端口，插件在收到IP和debug端口后自動(dòng)連接。

debug插件

5.8 優(yōu)缺點(diǎn)

5.8.1 優(yōu)點(diǎn)

• 更加節(jié)省資源，僅部署X（修改的服務(wù)），不需要部署nginx+Entry。
• 申請(qǐng)環(huán)境速度快，秒級(jí)完成。
• 搭建環(huán)境速度快，約2-5分鐘。
• 無內(nèi)存限制。

5.8.2 缺點(diǎn)

• QA有感知，需要在HTTP Header中添加標(biāo)簽。

6. 分布式調(diào)用跟蹤系統(tǒng)

以下圖為例，在D調(diào)用E'時(shí)出現(xiàn)問題，E'中未打出相應(yīng)的業(yè)務(wù)日志，到底是D沒有調(diào)用呢，還是流量路由存在問題沒有路由到E'呢。此時(shí)就需要分布式調(diào)用跟蹤系統(tǒng)的輔助來排查問題。

6.1 原理

分布式調(diào)用跟蹤系統(tǒng)的原理就是在鏈路中每個(gè)模塊的入口和出口處進(jìn)行埋點(diǎn)，并將埋點(diǎn)采集起來進(jìn)行可視化展示。如下左圖為調(diào)用鏈路，右圖為采集到的埋點(diǎn)。

分布式調(diào)用跟蹤系統(tǒng)原理

每一條鏈路有唯一的Id稱為TraceId，而每一個(gè)埋點(diǎn)稱之為span，每個(gè)span有唯一的Id稱為SpanId。

6.2 架構(gòu)

轉(zhuǎn)轉(zhuǎn)分布式調(diào)用跟蹤系統(tǒng)采用自研與開源結(jié)合的方式，如下圖所示。其中Radar為轉(zhuǎn)轉(zhuǎn)自研分布式調(diào)用跟蹤系統(tǒng)客戶端，可與MQ、SCF（轉(zhuǎn)轉(zhuǎn)RPC框架）、Servlet進(jìn)行整合，異步批量地將埋點(diǎn)上傳到Collector服務(wù)，Collector服務(wù)再將埋點(diǎn)寫入kafka。開源部分則使用zipkin實(shí)現(xiàn)，zipkin具備自動(dòng)從kafka消費(fèi)埋點(diǎn)并存入DB的能力，而且自帶UI界面可供查詢。

分布式調(diào)用跟蹤系統(tǒng)架構(gòu)圖

6.3 TraceId的獲取

轉(zhuǎn)轉(zhuǎn)使用統(tǒng)一日志門面slf4j，Radar客戶端自動(dòng)將TraceId、SpanId存入MDCContext中，只需在日志配置文件中加入相應(yīng)的占位符就可以將TraceId、SpanId打印至日志中，如下圖所示。

TraceId打印到日志中

在Entry層每次請(qǐng)求結(jié)束后將TraceId以Http Header的形式返回至前端，前端收到響應(yīng)后可立即獲取TraceId進(jìn)行查詢。

網(wǎng)關(guān)層將TraceId返回

6.4 在路由關(guān)鍵節(jié)點(diǎn)采集流量標(biāo)簽和當(dāng)前節(jié)點(diǎn)標(biāo)簽

如下圖所示global.route.context.tag為流量標(biāo)簽，而global.route.instance.tag為當(dāng)前節(jié)點(diǎn)標(biāo)簽，通過對(duì)比這兩個(gè)標(biāo)簽是否匹配即可驗(yàn)證流量路由是否正確，本節(jié)開頭所提到的問題也就迎刃而解。

流量標(biāo)簽及節(jié)點(diǎn)標(biāo)簽

7. 總結(jié)

轉(zhuǎn)轉(zhuǎn)測(cè)試環(huán)境治理共經(jīng)歷3個(gè)版本，物理隔離、基于自動(dòng)IP標(biāo)簽的流量路由及基于手動(dòng)標(biāo)簽的流量路由。

• 物理隔離：隨著轉(zhuǎn)轉(zhuǎn)業(yè)務(wù)的發(fā)展，服務(wù)數(shù)量的增多，搭建測(cè)試環(huán)境極端情況下需要數(shù)天的時(shí)間，每環(huán)境平均部署服務(wù)數(shù)量高達(dá)30-60個(gè)。
• 基于自動(dòng)IP標(biāo)簽的流量路由：每環(huán)境平均部署服務(wù)數(shù)量下降至7-8個(gè)，而環(huán)境搭建時(shí)間也下降至30分鐘-1小時(shí)。
• 基于手動(dòng)標(biāo)簽的流量路由：每環(huán)境平均部署服務(wù)數(shù)量進(jìn)一步下降至3-4個(gè)，搭建時(shí)間降至2分鐘-5分鐘。

流量路由帶來效率提升及資源占用下降的同時(shí)，也引入了一些問題，如鏈路復(fù)雜性高，ip地址變化等。為了更好地利用流量路由帶來的便利，消除負(fù)面影響，就需要各種配套設(shè)施的輔助，如分布式調(diào)用跟蹤、泛域名解析、web shell等。

回頭來看，流量路由減少了部署時(shí)間，降低了資源消耗，得到了業(yè)務(wù)線的一致好評(píng)。架構(gòu)、運(yùn)維與工程效率部門的同學(xué)排查問題的數(shù)量也大大減少。真真正正做到了降本增效，實(shí)實(shí)在在好項(xiàng)目。兩個(gè)版本的流量路由分別獲得轉(zhuǎn)轉(zhuǎn)公司優(yōu)秀項(xiàng)目獎(jiǎng)。

關(guān)于作者

王建新，轉(zhuǎn)轉(zhuǎn)架構(gòu)部服務(wù)治理負(fù)責(zé)人，主要負(fù)責(zé)服務(wù)治理、RPC框架、分布式調(diào)用跟蹤、監(jiān)控系統(tǒng)等。愛技術(shù)、愛學(xué)習(xí)，歡迎聯(lián)系交流。

參考資料

[1]TransmittableThreadLocal: ??https://github.com/alibaba/transmittable-thread-local??