建站
咨詢
售后
建站咨詢
新聞中心
轉(zhuǎn)轉(zhuǎn)測試環(huán)境治理歷經(jīng)3個版本的迭代，環(huán)境搭建耗時及資源占用大幅度下降，在此過程中積累了豐富的實踐經(jīng)驗。本文將從測試環(huán)境的需求及背景出發(fā)，介紹轉(zhuǎn)轉(zhuǎn)測試環(huán)境治理各個版本的原理、技術(shù)、優(yōu)缺點，毫無保留地將轉(zhuǎn)轉(zhuǎn)的實踐經(jīng)驗分享給各位讀者。
在余慶等地區(qū)，都構(gòu)建了全面的區(qū)域性戰(zhàn)略布局，加強發(fā)展的系統(tǒng)性、市場前瞻性、產(chǎn)品創(chuàng)新能力，以專注、極致的服務(wù)理念，為客戶提供成都網(wǎng)站設(shè)計、網(wǎng)站建設(shè) 網(wǎng)站設(shè)計制作按需網(wǎng)站制作,公司網(wǎng)站建設(shè),企業(yè)網(wǎng)站建設(shè),成都品牌網(wǎng)站建設(shè),營銷型網(wǎng)站建設(shè),成都外貿(mào)網(wǎng)站建設(shè),余慶網(wǎng)站建設(shè)費用合理。
1. 背景及需求
1.1 系統(tǒng)架構(gòu)的發(fā)展
很久很久以前，在并發(fā)量較低時系統(tǒng)大多采用單體架構(gòu)，由單個web服務(wù)直接連接數(shù)據(jù)庫，由nginx在多個web服務(wù)節(jié)點間做負載均衡。
單體架構(gòu)
隨著系統(tǒng)并發(fā)量的提高，單體架構(gòu)無法滿足性能需求，需要對單體服務(wù)進行拆分，于是來到了微服務(wù)架構(gòu)。微服務(wù)架構(gòu)與單體架構(gòu)顯著的不同在于鏈路更長更復(fù)雜了。
微服務(wù)架構(gòu)
1.2 測試環(huán)境的需求
測試環(huán)境與線上環(huán)境的典型不同在于線上環(huán)境各節(jié)點一般情況下代碼是一致的，各節(jié)點是對等的，請求到達任意節(jié)點業(yè)務(wù)邏輯都是一致的；而測試環(huán)境一般是多分支并行開發(fā)，每個節(jié)點的邏輯是不一致的，既然要測試本次所開發(fā)的功能，那就要求請求能精準地到達所部署的節(jié)點。
在單體架構(gòu)下，該需求是很容易實現(xiàn)的，通過采用修改nginx配置，在upstream中僅包含目標測試節(jié)點可以很容易實現(xiàn)對目標節(jié)點的精準測試，或者不使用nginx直接通過IP+port的形式進行調(diào)用也同樣可以實現(xiàn)請求精準到達目標節(jié)點。如下圖所示的A'及A''屬于兩個不同的需求，分別通過固定nginx upstream及IP+port的形式實現(xiàn)了請求的精準控制。
單體架構(gòu)測試
而在微服務(wù)架構(gòu)下，該需求實現(xiàn)起來就沒那么簡單了。如下圖所示，鏈路上包括服務(wù)A、B、C，圖中A'、B'、C'屬于同一個需求，而A''、B''、C''屬于另一個需求。采用在單體架構(gòu)下的解決方案只能控制請求精準地到達A'或者A''，無法實現(xiàn)請求精準地到達B'、C'及B''、C''。
微服務(wù)架構(gòu)測試
2. 傳統(tǒng)的測試環(huán)境解決方案-物理隔離
為了實現(xiàn)請求精準地到達被測服務(wù)節(jié)點，傳統(tǒng)的做法是提供多套完全互相隔離的測試環(huán)境，每套測試環(huán)境包含全量的服務(wù)及注冊中心、MQ broker等。每個需求分配一套測試環(huán)境，只需將被測服務(wù)部署至該環(huán)境內(nèi)即可實現(xiàn)請求精準地到達被測節(jié)點，這種做法也稱作物理隔離。
物理隔離
物理隔離在公司服務(wù)數(shù)量較少時（20個服務(wù)以下）稱得上是完美的解決方案，非常簡單可靠。但是隨著服務(wù)數(shù)量的增長，物理隔離的缺點逐漸顯露——資源浪費太嚴重。假設(shè)整個系統(tǒng)有100個服務(wù)，而每次需求僅修改其中的1-3個服務(wù)，資源浪費率高達97%-99%。而且服務(wù)數(shù)量的增長，往往也意味著公司業(yè)務(wù)的發(fā)展壯大，同時進行中的需求數(shù)量也在增長，需要提供更多的測試環(huán)境，資源消耗巨大。
3. 轉(zhuǎn)轉(zhuǎn)測試環(huán)境V1-改進的物理隔離
轉(zhuǎn)轉(zhuǎn)公司傳統(tǒng)的測試環(huán)境解決方案屬于改進型的物理隔離。
3.1 穩(wěn)定環(huán)境
在轉(zhuǎn)轉(zhuǎn)有一套穩(wěn)定環(huán)境包含全量的服務(wù)并且與線上代碼一致。在測試環(huán)境不使用注冊中心，而是為每一個服務(wù)分配唯一的域名并通過修改機器host映射的方式手動控制服務(wù)發(fā)現(xiàn)。默認情況下，如果服務(wù)A部署在穩(wěn)定環(huán)境的??192.168.1.1???上，那么所有測試環(huán)境機器的host文件中都存在一項配置??192.168.1.1 A.zhuaninc.com??。
3.2 動態(tài)環(huán)境
每次需求所申請的環(huán)境稱為動態(tài)環(huán)境，為一臺kvm虛擬機。假設(shè)某動態(tài)環(huán)境的IP為192.168.2.1?，在該動態(tài)環(huán)境部署服務(wù)A時，同時將該機器的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。
如下圖所示的動態(tài)環(huán)境192.168.4.1?，其中A'及E'即為本次需求所修改的服務(wù)。
初始化過程如下：
- 申請動態(tài)環(huán)境192.168.4.1?，申請完成后該機器的host文件中包含全量的服務(wù)域名映射，默認映射到對應(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）。
- 部署服務(wù)E'，同時將127.0.0.1寫入host文件。
- 部署服務(wù)D，同時將127.0.0.1寫入host文件。
- 部署服務(wù)C，同時將127.0.0.1寫入host文件。
- 部署服務(wù)B，同時將127.0.0.1寫入host文件。
- 部署服務(wù)A'，同時將127.0.0.1寫入host文件。
- 部署Entry。
- 部署nginx，同時將服務(wù)A的upstream修改為僅包含127.0.0.1。
如此以來，就像焊接管道一樣，從服務(wù)E至nginx倒序焊接出一條沒有分叉的管道。測試時只需要通過host映射將被測域名映射到該IP，即可實現(xiàn)請求精準地到達A'及E'，E'以后的鏈路（從F開始的鏈路）則使用穩(wěn)定環(huán)境。
對于MQ，則通過在動態(tài)環(huán)境topic添加IP前綴的方式實現(xiàn)與穩(wěn)定環(huán)境的物理隔離，如下圖所示不同的topic在broker上存在著不同的隊列，穩(wěn)定環(huán)境的消息和動態(tài)環(huán)境的消息不能互通。
MQ消息物理隔離
如在測試過程中發(fā)現(xiàn)需要修改更多的服務(wù)，例如需要修改服務(wù)F，則在將F服務(wù)部署在該動態(tài)環(huán)境的同時，需要重啟服務(wù)E'，因為E'已經(jīng)與穩(wěn)定環(huán)境的F建了tcp連接，修改F服務(wù)的域名映射并不會導致E'與F之間重新建立tcp連接，所以需要重啟E'。如F服務(wù)的調(diào)用方不僅有E'，則都需要重啟。
3.3 優(yōu)缺點
該解決方案近似于物理隔離，但較物理隔離有所改進，改進的地方在于動態(tài)環(huán)境并沒有包含全量的服務(wù)，動態(tài)環(huán)境僅包含了從nginx開始至最后一個被測的服務(wù)，而使用穩(wěn)定環(huán)境充當被測鏈路的尾巴。
3.3.1 優(yōu)點
- 隔離性強，近似于物理隔離。
- 鏈路簡單，流量封閉在同一臺機器上。
3.3.2 缺點
- 需要部署從nginx開始至最后一個被測的服務(wù)，存在未修改服務(wù)部署在動態(tài)環(huán)境中的情況，造成資源浪費。
- 由于部署過程依賴服務(wù)的調(diào)用關(guān)系，導致部署效率低下，極端情況下需要數(shù)天調(diào)試測試環(huán)境。
- host管理復(fù)雜。
- topic添加IP前綴易出錯，代碼與環(huán)境相關(guān)。
- 單臺機器內(nèi)存有限，鏈路過長無法滿足。
4. 轉(zhuǎn)轉(zhuǎn)測試環(huán)境V2-基于自動IP標簽的流量路由
?隨著轉(zhuǎn)轉(zhuǎn)公司業(yè)務(wù)的飛速發(fā)展，服務(wù)數(shù)量迅速增加，每個動態(tài)環(huán)境部署的服務(wù)數(shù)量增至30-60個，搭建測試環(huán)境的成本越來越高。為了解決該問題，轉(zhuǎn)轉(zhuǎn)架構(gòu)部、運維部、工程效率部推出了流量路由解決方案。該解決方案在此前的公眾號文章??轉(zhuǎn)轉(zhuǎn)測試環(huán)境的服務(wù)治理實踐??中已有詳細講解，本文僅做簡要介紹。
該版本的流量路由技術(shù)稱為基于自動IP標簽的流量路由，之所以選擇IP為標簽是因為基于現(xiàn)有使用習慣發(fā)現(xiàn)所有被測服務(wù)部署在同一臺虛擬機上，IP地址一樣，并且IP易獲取，用戶無感知；“自動”則體現(xiàn)在無需用戶對服務(wù)及流量進行打標，打標是完全自動化進行的。
基于自動IP標簽的流量路由將測試環(huán)境的搭建時間從數(shù)小時-數(shù)天減少至30分鐘-1小時，每環(huán)境部署的服務(wù)數(shù)量從30-60個服務(wù)下降至個位數(shù)，并且完全兼容沒有流量路由時的使用習慣。但是仍然存在申請?zhí)摂M機耗時長，kvm內(nèi)存無法擴容的問題。?
5. 轉(zhuǎn)轉(zhuǎn)測試環(huán)境V3-基于手動標簽的流量路由
基于自動IP標簽的流量路由解決了轉(zhuǎn)轉(zhuǎn)測試環(huán)境存在的大部分問題，使測試環(huán)境的搭建時間從數(shù)小時-數(shù)天下降至30分鐘-1小時，但是仍然存在申請環(huán)境耗時長，kvm內(nèi)存無法擴容的問題，本著精益求精，用戶至上的原則，我們開發(fā)了基于手動標簽的流量路由。
5.1 docker化
為了解決申請環(huán)境耗時長，kvm內(nèi)存無法擴容的問題，我們決定將服務(wù)部署在docker容器內(nèi)，無需提前申請資源，理論上無內(nèi)存限制。但是docker化以后，基于IP為標簽的流量路由顯然無法工作了，因為不同的服務(wù)部署在不同的docker pod內(nèi)，IP也是不一樣的。
5.2 服務(wù)及流量打標
此時就需要手動為服務(wù)及流量指定標簽，我們稱為基于手動標簽的流量路由。為服務(wù)打標是自動化完成的，在環(huán)境平臺申請環(huán)境時指定標簽，在該環(huán)境內(nèi)部署服務(wù)時，由環(huán)境平臺自動添加jvm參數(shù)-Dtag=xxx。而為流量打標則通過http header進行，在發(fā)起請求時添加header tag=xxx。
申請環(huán)境
自動添加jvm參數(shù)
請求添加http header
并非所有請求都是通過http發(fā)起的，有些由進程內(nèi)部（如定時任務(wù)）直接發(fā)起的調(diào)用則自動攜帶當前節(jié)點的標簽。
5.3 目標形態(tài)
基于手動打標的流量路由目標形態(tài)如下圖所示，標簽為??yyy??的動態(tài)環(huán)境，本次需求修改了服務(wù)B及服務(wù)D，只需要在該動態(tài)環(huán)境內(nèi)部署B(yǎng)和D，真正實現(xiàn)修改什么就部署什么。
標簽路由使用目標
5.4 RPC調(diào)用實現(xiàn)
5.4.1 服務(wù)注冊、發(fā)現(xiàn)及調(diào)用
以下圖服務(wù)A調(diào)用服務(wù)B為例，服務(wù)B有3個節(jié)點，穩(wěn)定環(huán)境的B，動態(tài)環(huán)境的B'（標簽為??yyy??）及B''（標簽為??xxx??）。B'和B''在啟動時會將標簽參數(shù)注冊到注冊中心，服務(wù)A在啟動時會從注冊中心發(fā)現(xiàn)B、B'、B''，同時獲取它們的標簽參數(shù)。
RPC標簽路由
以紅色的鏈路為例，流量標簽為zzz，A在調(diào)用時發(fā)現(xiàn)并沒有動態(tài)環(huán)境的服務(wù)B擁有標簽zzz，于是調(diào)用穩(wěn)定環(huán)境的B節(jié)點。
橙色鏈路的標簽為xxx，A在調(diào)用時發(fā)現(xiàn)B''的標簽為xxx，且為動態(tài)環(huán)境，則調(diào)用B''。
5.4.2 標簽的傳遞
轉(zhuǎn)轉(zhuǎn)使用的RPC為自研RPC框架，在調(diào)用時除了傳遞請求方法及參數(shù)等信息之外，還可以通過attachement功能傳遞額外的參數(shù)，而路由標簽就是通過該功能在RPC調(diào)用時實現(xiàn)傳遞。
5.5 MQ消息實現(xiàn)
5.5.1 消費原理
若想實現(xiàn)消息可以在動態(tài)環(huán)境與穩(wěn)定環(huán)境之間路由，通過不同的的topic前綴實現(xiàn)動態(tài)環(huán)境和穩(wěn)定環(huán)境的物理隔離顯然已經(jīng)行不通。此時的解決方案為動態(tài)環(huán)境和穩(wěn)定環(huán)境擁有相同的topic，但是不同的消費group，不同的消費group就對應(yīng)不同的消費offset。動態(tài)環(huán)境的group添加${tag}前綴，而穩(wěn)定環(huán)境的group添加test_前綴，添加前綴的過程由MQ客戶端自動完成，對用戶透明。
如下圖所示服務(wù)B有穩(wěn)定環(huán)境及動態(tài)環(huán)境（B'）節(jié)點各一個，B'的標簽為xxx。圖中通過不同的顏色表示不同的標簽，其中綠色表示沒有標簽。
MQ標簽路由
B節(jié)點在消費時，首先判斷是否有和消息中標簽對應(yīng)的消費組注冊到broker上，如果有則過濾掉，否則消費。其中消息1、3、5、7的標簽和B'匹配，消息2沒有標簽，而消息4、6的標簽所對應(yīng)的消費者沒有注冊到broker上，所以B節(jié)點消費了消息2、4、6。
B'節(jié)點在消費時，只消費消息中標簽和自身標簽前綴一致的消息，即消息1、3、5。
5.5.2 存在的問題
假如此時B'下線了，我們發(fā)現(xiàn)消息7沒有被消費者消費，該消息丟了。這是因為穩(wěn)定環(huán)境消費組和動態(tài)環(huán)境消費組offset不一致導致的，穩(wěn)定環(huán)境消費組offset大于動態(tài)環(huán)境消費組offset，解決方案就是B'下線時將其與穩(wěn)定環(huán)境offset之間的消息重新投遞。重新投遞后假如B'又上線了呢，就帶來了消息的重復(fù)消費，但是我們認為重復(fù)消費是沒有問題的，因為mq本身的消費語義就是至少一次，而不是僅僅一次，重復(fù)消費冪等性應(yīng)該由業(yè)務(wù)邏輯來保證。
另一個問題是批量消費如何解決，mq客戶端有批量消費功能，一批消息所攜帶的標簽可能是不一樣的。對于這個問題，只需要將消息按標簽分組后再執(zhí)行消費邏輯即可。
5.5.3 標簽的傳遞
轉(zhuǎn)轉(zhuǎn)使用的是RocketMQ，并進行了二次開發(fā)，RocketMQ提供了可擴展的header可以用來傳遞路由標簽。
5.6 進程內(nèi)標簽的傳遞
跨進程的標簽傳遞相對來講比較容易解決，而進程內(nèi)標簽的傳遞難度更高。
5.6.1 通過方法參數(shù)傳遞
通過為每一個方法調(diào)用添加tag參數(shù)可以實現(xiàn)標簽的的進程內(nèi)傳遞，但是顯然這不現(xiàn)實，需要全公司所有的代碼配合改動。
5.6.2 通過ThreadLocal傳遞
jdk內(nèi)置有ThreadLocal及InheritableThreadLocal可以實現(xiàn)標簽的隱式傳遞，但是ThreadLocal無法實現(xiàn)new Thread及跨線程池傳遞，而InheritableThreadLocal可以實現(xiàn)new Thread傳遞卻仍然無法實現(xiàn)跨線程池傳遞。雖然可以通過對Callable和Runnable進行包裝實現(xiàn)跨線程池傳遞，但這仍然要求修改現(xiàn)有的業(yè)務(wù)代碼，成本較高。
5.5.3 通過TransmittableThreadLocal傳遞
TransmittableThreadLocal[1]是阿里巴巴開源的，通過java agent技術(shù)實現(xiàn)的可以跨線程/跨線程池傳遞的??ThreadLocal??，對用戶透明，只需要在jvm啟動參數(shù)中加入對應(yīng)的java agent參數(shù)即可，最終我們采用了該方案。
TransmittableThreadLocal Agent
5.6 上線收益
下圖為轉(zhuǎn)轉(zhuǎn)公司動態(tài)環(huán)境平均部署服務(wù)數(shù)量曲線，在2022年5月之前平均每環(huán)境約部署7-8個服務(wù)，在2022年5月之后標簽路由開始推廣，至2022年7月每環(huán)境約部署3-4個服務(wù)。雖然從原理上看基于手動標簽的流量路由每環(huán)境僅比基于自動IP標簽的流量路由僅少部署一個服務(wù)（Entry），但是由于kvm無法擴容，所以在自動IP路由時代環(huán)境初始化時用戶總是會預(yù)防性地多選擇一些服務(wù)，以達到申請更大內(nèi)存虛擬機的目的，而docker化之后，此種擔憂不再存在，所以每環(huán)境部署的服務(wù)數(shù)量下降了約4個，動態(tài)環(huán)境總內(nèi)存節(jié)省了約65%。
測試環(huán)境搭建時間從30分鐘-1小時下降至2分鐘-5分鐘，時間的節(jié)省主要來自無需提前申請kvm、docker資源隔離服務(wù)啟動快、無內(nèi)存擴容擔憂初始化服務(wù)數(shù)量少。
每環(huán)境部署服數(shù)量曲線
5.7 輔助設(shè)施
docker化雖然帶來了效率的提升，資源占用的下降，但是也引入了一些問題。每次部署IP地址都會變化，導致遠程登錄及debug的成本增加。在Http Header中添加路由標簽增加了測試同學的工作量。為了解決這些問題，我們又開發(fā)了對應(yīng)的輔助設(shè)施來提高工作效率。
5.7.1 泛域名解析
使用http傳遞標簽，仍然需要配置host映射將域名映射至測試環(huán)境的nginx，如192.168.1.1 app.zhuanzhuan.com，否則dns解析會將app.zhuanzhuan.com解析至線上nginx。
是否可以免去host配置呢，答案是可以的。通過直接使用域名傳遞標簽的形式來實現(xiàn)免去host配置，如app.zhuanzhuan.com?直接使用域名傳遞標簽寫作app-${tag}.test.zhuanzhuan.com，該域名會直接解析至測試環(huán)境nginx。在開發(fā)版app中內(nèi)置了該功能，在app啟動時輸入環(huán)境標簽即可實現(xiàn)域名的切換，無需配置host即可開始測試。
泛域名解析
5.7.2 web shell
docker化以后每次部署都是一個新的docker pod，IP地址也隨之變化，如果需要登錄查看日志，通過xshell等工具則需要在每次部署后使用新的IP重新登錄。引入web shell功能只需要在環(huán)境平臺頁面中點擊按鈕即可通過web shell的方式直接登錄，并且登錄后的工作目錄默認為該服務(wù)的日志目錄。
web shell
5.7.3 debug插件
同樣因為docker化以后IP地址總是變化，測試環(huán)境的遠程debug也變得更加不方便，每次需要更換新的IP進行連接。為了解決此問題，我們開發(fā)了debug插件，該插件會自動獲取項目名作為服務(wù)名，需要debug時輸入環(huán)境標簽，插件會自動向環(huán)境平臺發(fā)起請求，而環(huán)境平臺則通過解析jvm參數(shù)的方式獲取debug端口并向插件返回IP和debug端口，插件在收到IP和debug端口后自動連接。
debug插件
5.8 優(yōu)缺點
5.8.1 優(yōu)點
- 更加節(jié)省資源，僅部署X（修改的服務(wù)），不需要部署nginx+Entry。
- 申請環(huán)境速度快，秒級完成。
- 搭建環(huán)境速度快，約2-5分鐘。
- 無內(nèi)存限制。
5.8.2 缺點
- QA有感知，需要在HTTP Header中添加標簽。
6. 分布式調(diào)用跟蹤系統(tǒng)
以下圖為例，在D調(diào)用E'時出現(xiàn)問題，E'中未打出相應(yīng)的業(yè)務(wù)日志，到底是D沒有調(diào)用呢，還是流量路由存在問題沒有路由到E'呢。此時就需要分布式調(diào)用跟蹤系統(tǒng)的輔助來排查問題。
6.1 原理
分布式調(diào)用跟蹤系統(tǒng)的原理就是在鏈路中每個模塊的入口和出口處進行埋點，并將埋點采集起來進行可視化展示。如下左圖為調(diào)用鏈路，右圖為采集到的埋點。
分布式調(diào)用跟蹤系統(tǒng)原理
每一條鏈路有唯一的Id稱為TraceId，而每一個埋點稱之為span，每個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進行整合，異步批量地將埋點上傳到Collector服務(wù)，Collector服務(wù)再將埋點寫入kafka。開源部分則使用zipkin實現(xiàn)，zipkin具備自動從kafka消費埋點并存入DB的能力，而且自帶UI界面可供查詢。
分布式調(diào)用跟蹤系統(tǒng)架構(gòu)圖
6.3 TraceId的獲取
轉(zhuǎn)轉(zhuǎn)使用統(tǒng)一日志門面slf4j，Radar客戶端自動將TraceId、SpanId存入MDCContext中，只需在日志配置文件中加入相應(yīng)的占位符就可以將TraceId、SpanId打印至日志中，如下圖所示。
TraceId打印到日志中
在Entry層每次請求結(jié)束后將TraceId以Http Header的形式返回至前端，前端收到響應(yīng)后可立即獲取TraceId進行查詢。
網(wǎng)關(guān)層將TraceId返回
6.4 在路由關(guān)鍵節(jié)點采集流量標簽和當前節(jié)點標簽
如下圖所示global.route.context.tag為流量標簽，而global.route.instance.tag為當前節(jié)點標簽，通過對比這兩個標簽是否匹配即可驗證流量路由是否正確，本節(jié)開頭所提到的問題也就迎刃而解。
流量標簽及節(jié)點標簽
7. 總結(jié)
轉(zhuǎn)轉(zhuǎn)測試環(huán)境治理共經(jīng)歷3個版本，物理隔離、基于自動IP標簽的流量路由及基于手動標簽的流量路由。
- 物理隔離：隨著轉(zhuǎn)轉(zhuǎn)業(yè)務(wù)的發(fā)展，服務(wù)數(shù)量的增多，搭建測試環(huán)境極端情況下需要數(shù)天的時間，每環(huán)境平均部署服務(wù)數(shù)量高達30-60個。
- 基于自動IP標簽的流量路由：每環(huán)境平均部署服務(wù)數(shù)量下降至7-8個，而環(huán)境搭建時間也下降至30分鐘-1小時。
- 基于手動標簽的流量路由：每環(huán)境平均部署服務(wù)數(shù)量進一步下降至3-4個，搭建時間降至2分鐘-5分鐘。
流量路由帶來效率提升及資源占用下降的同時，也引入了一些問題，如鏈路復(fù)雜性高，ip地址變化等。為了更好地利用流量路由帶來的便利，消除負面影響，就需要各種配套設(shè)施的輔助，如分布式調(diào)用跟蹤、泛域名解析、web shell等。
回頭來看，流量路由減少了部署時間，降低了資源消耗，得到了業(yè)務(wù)線的一致好評。架構(gòu)、運維與工程效率部門的同學排查問題的數(shù)量也大大減少。真真正正做到了降本增效，實實在在好項目。兩個版本的流量路由分別獲得轉(zhuǎn)轉(zhuǎn)公司優(yōu)秀項目獎。
關(guān)于作者
王建新，轉(zhuǎn)轉(zhuǎn)架構(gòu)部服務(wù)治理負責人，主要負責服務(wù)治理、RPC框架、分布式調(diào)用跟蹤、監(jiān)控系統(tǒng)等。愛技術(shù)、愛學習，歡迎聯(lián)系交流。
參考資料
[1]TransmittableThreadLocal: ??https://github.com/alibaba/transmittable-thread-local??
當前名稱：轉(zhuǎn)轉(zhuǎn)測試環(huán)境治理的高效能實踐
路徑分享：http://m.5511xx.com/article/dhpcccp.html
