1. 背景
測試環(huán)境治理一直是各大公司非常重要的一個課題，測試環(huán)境穩(wěn)定性很大程度影響迭代開發(fā)&測試效率。
綜合來看，測試環(huán)境不穩(wěn)定的原因主要有以下幾點：
- 測試環(huán)境的變更非終態(tài)變更，經常會有代碼發(fā)布/配置發(fā)布導致服務無法啟動或者鏈路有問題的情況。
- 變更頻繁，開發(fā)需要聯調、測試需要迭代測試，代碼需要變更，配置也需要變更，權限控制就比較難做，增加了測試環(huán)境不穩(wěn)定性。
- 并行需求，同一時間單個應用需要多個分支同時支持多個需求的測試，測試環(huán)境資源的搶占和沖突比較明顯。
得物測試環(huán)境穩(wěn)定性治理也經歷了幾個階段：
-
2020~2021：多套物理環(huán)境隔離方案（基于ECS）
T0、T1、T2三套測試環(huán)境，每套環(huán)境物理隔離，無資源沖突和共享。
規(guī)劃T1用于迭代測試、T0用于集成回歸、T2用于獨立項目分配使用，但在實際使用過程中，業(yè)務測試并行太多，沖突比較明顯，環(huán)境就開始亂用了，誰有需求就隨便占用一套環(huán)境使用了。結果就是沒有一套穩(wěn)定的環(huán)境，測試有效性無法保障，并行項目環(huán)境沖突也無法解決。
-
2021~2022：MF全鏈路容器環(huán)境方案（基于容器）
隨著業(yè)務增長，3套測試環(huán)境已明顯不能滿足業(yè)務需求，因此去年得物基于容器快速搭建了10套MF環(huán)境用于支撐獨立項目的測試。
MF環(huán)境基于T0搭建，DB和T0共享，其他所有資源均獨立，目的是做到業(yè)務只需保障T0的穩(wěn)定性，所有MF環(huán)境可快速基于T0同步最新服務和最新配置，做到環(huán)境隨用隨取，解決并行項目環(huán)境沖突問題。
實際實施過程中，項目環(huán)境沖突的問題解決了，但是MF環(huán)境的穩(wěn)定性問題依舊比較嚴重，維護成本巨大，主要原因集中在：
T0環(huán)境穩(wěn)定性，并非所有域都在T0集成回歸，導致T0穩(wěn)定性無法保障
MF同步了T0之后會因為各種各樣的原因需要二次調試驗收（新增服務丟失、配置不全/錯亂等）
MF環(huán)境使用過程中，基礎服務（sso、網關、中間件）等相關變更無法及時更新到MF環(huán)境，影響業(yè)務測試
因此在2022年下半年，開始嘗試用染色環(huán)境解決環(huán)境穩(wěn)定性問題。
-
2022年：染色環(huán)境方案（基于流量隔離）
染色環(huán)境是基于流量隔離的方案，通過流量標透傳的方式，把基準環(huán)境流量和染色環(huán)境流量隔離開，實現多環(huán)境的方案，支持并行測試互不影響。
相較于MF環(huán)境而言，不需要維護多套全鏈路環(huán)境，維護成本降低了。所有變更的服務都在染色環(huán)境部署的話，基準環(huán)境穩(wěn)定性就會提升，相當于所有環(huán)境的穩(wěn)定性都提升了。
下面主要介紹得物染色環(huán)境是如何做的
2.染色環(huán)境方案
2.1 基本思路
如下圖所示，最初的設想是：
- 服務可以按照流量標把流量路由到相應染色服務上
- 如果染色標對應染色環(huán)境沒有此服務，則流量會走到基準環(huán)境
- 如果染色環(huán)境服務添加了，沒有部署，或者部署了服務進程掛了，則流量會報錯而并非走到基準環(huán)境（避免一些服務異常問題沒有暴露）
- DB、MQ、Redis等中間件期望用同一套，避免浪費
基于此設想，需要從哪些地方入手去改造以支持染色環(huán)境呢？可以從設想拆解去解決：
- 流量標如何透傳？
- 流量路由如何路由到染色節(jié)點？
- rpc接口如何路由到染色節(jié)點？
- MQ消息如何讓染色環(huán)境consumer消費？
- 解決完流量標透傳問題，以及染色路由問題后，需要考慮流量發(fā)起方如何把染色標帶上？
2.2 實現方案
以下方案只做流量隔離，DB數據層不做隔離
1.流量標如何透傳？
首先流量標在流量入口層會放到http header里面的x-infr-flowtype字段：
x-infr-flowtype:<CE_ColoringEnv> ##CE_是固定前綴，為了和壓測標做區(qū)分
從流量到網關后，服務鏈路上面流量標往下透傳的方式是通過OpenTracing規(guī)范中的baggage能力，從header里面獲取染色標，并塞到trace里面向下透傳。
這樣整個鏈路里面就都能拿到染色標了
2.流量路由如何路由到染色節(jié)點？
這里分兩塊考慮：
（1）rpc調用，拿到染色標之后，如何找到染色節(jié)點？這里要解決的是怎么識別染色節(jié)點
（2）MQ消息，producer如何發(fā)送帶染色標的消息，consumer如何處理帶染色標的消息
-
服務注冊--識別染色節(jié)點
- 首先染色環(huán)境創(chuàng)建的時候，會定義好染色標：
在此染色環(huán)境添加服務部署的時候，默認會把染色標注入到環(huán)境變量COLORING_ENV
容器發(fā)布配置頁面會自動增加COLORING_ENV變量
至此，服務啟動時已可以讀到COLORING_ENV環(huán)境標變量了，下一步就看注冊中心怎么去區(qū)分染色節(jié)點了.
首先服務在添加到染色環(huán)境的時候，服務會在注冊中心染色場增加一個節(jié)點，標明該服務在此染色環(huán)境是有服務節(jié)點存在的。
染色場主要解決的問題是：如果染色節(jié)點掛了，染色環(huán)境流量應該判斷該染色環(huán)境是否應該有染色節(jié)點，有的話就報錯，沒有的話才會走到基準環(huán)境。避免測試問題未暴露。
染色場：CE_< ServiceName>
染色場服務節(jié)點：<COLORING_ENV>:80
其次在服務注冊時候，服務節(jié)點信息和方法注冊會攜帶染色標<coloring_env>：
至此，注冊中心就可以基于染色標識別染色節(jié)點，業(yè)務服務（基于fusion框架）可以根據Trace中的染色標結合注冊中心染色節(jié)點做染色流量路由。
- MQ改造--識別和處理MQ消息
MQ主要解決的是，染色環(huán)境的消息生產者producer發(fā)送的消息，只被染色環(huán)境的消費者消費，染色環(huán)境如果沒有消費節(jié)點，則由基準環(huán)境消費者消費。
這里之前討論了兩種做法：
第一種是基于Topic隔離的方案，每套染色環(huán)境使用不同的topic進行通信，這樣隔離性比較好，消息不容易串掉。
第二種是Topic不隔離，所有染色環(huán)境共用一個topic，生產者Producer在生產消息時候把染色標帶上，consumer每套染色環(huán)境有一個，consumer在做消費時候會判斷消息里面的染色標和本地染色標是否一致，如果一致則消費，如果不一致則直接返回ACK不走具體消費邏輯。
目前選擇的是第二種方案，下面基于第二種方案做詳細介紹：
基本流程
如圖所示：
- ServiceB_Color1會自動注冊GID_Color1_Topic消費組，監(jiān)聽Topic_A。Color2和Color3環(huán)境一樣。
- 帶Color1的消息由ServiceA_Color1生產，ServiceB_Color1消費。
- 帶Color2的消息由ServiceA_Color2生產，ServiceB消費，因為ServiceB在Color2染色環(huán)境沒有節(jié)點
- 帶Color3的消息由于染色環(huán)境Color3沒有ServiceA_Color3節(jié)點，則帶Color3的流量會打到基準環(huán)境ServiceA，此時ServiceA會生產帶Color3的消息，此消息由ServiceB_Color3消費
配合業(yè)務說明：
染色環(huán)境在啟動時候，帶染色標的GID會自動創(chuàng)建，eg：原GID是GID_AAA，染色自動創(chuàng)建的GID為GID_<coloring_env>_AAA
下面看消息的內容和處理邏輯：
如上圖：染色消息屬性里面會增加DMQ_ENV_TAG字段，添加染色標，然后對應染色環(huán)境訂閱組才會消費。
看上面這張圖，會發(fā)現“貌似”所有染色環(huán)境都消費了，其實是其他環(huán)境直接返回了ACK，未走具體的消費邏輯，具體可以看日志。
代碼說明：基于Message里面染色標msgTag和本地服務染色標envTag進行判斷做消費邏輯區(qū)分。
3.染色流量入口攜帶染色標
解決完染色標透傳，以及染色標邏輯處理后，剩下就是如何在流量發(fā)起方把染色標給帶上了，其實就是把染色標塞到header里面的x-infr-flowtype字段。
其中染色環(huán)境列表的獲取由發(fā)布平臺提供接口給到各流量入口方去選擇。
目前業(yè)務推廣過程中，主要遇到的入口方大致有以下幾種：
入口流量攜帶染色標相對邏輯比較簡單，這里就不做詳細技術介紹，只做使用層面介紹
至此整個業(yè)務改造基本完成，從染色流量如何構造、流量標如何透傳、染色節(jié)點如何識別以及識別后重點染色邏輯如何處理等一整套流程就清晰了。
3.業(yè)務應用效果
3.1 實施路徑
染色項目整個實施路徑包含幾個階段：
-
項目立項&中間件改造（4月-6月）
包含基架改造（統(tǒng)一框架、網關、注冊中心、配置中心、超時中心、DMQ等）&客戶端改造&發(fā)布平臺改造等等，以及改造完成后基礎鏈路驗證
-
線上灰度&全鏈路服務適配（7月~8月）
7月初：5個交易&中間件相關服務升級相關jar包帶上線進行驗證，保證不會對染色改造不會對生產有影響。
8月份：開始推進全域應用進行染色相關jar包升級
-
獨立項目使用（9月）
9月底之前，已經有若干獨立項目應用染色環(huán)境測試驗證完成
-
業(yè)務迭代使用（10月~11月）
10月份開始嘗試推進全業(yè)務進行染色環(huán)境試用排錯
試用結束，逐步推進迭代使用染色環(huán)境
3.2 業(yè)務使用效果
獨立項目：目前全域的獨立項目已全量切換至染色環(huán)境測試。
版本迭代：就最新的版本迭代使用結果來看，全域95%以上的需求都可以使用染色環(huán)境測試。
剩余5%的需求場景主要是涉及以下兩個方面：
- 數據隔離：目前已有方案在支持，會涉及少量需求支撐。
- 前端染色：目前染色環(huán)境主要解決了后端染色的需求，部分場景需求依賴前端染色（多前端支持），方案也基本落地，會配合后端染色一起應用。
4.總結
染色環(huán)境現階段解決了測試環(huán)境沖突和測試環(huán)境穩(wěn)定性的問題，并且相較之前多套獨立環(huán)境的方案，在成本上也有比較大的節(jié)省。后續(xù)得物也會嘗試用染色的能力解決生產灰度發(fā)布問題，相信也會有不錯的效果。
*文/大地
關注得物技術，每周一三五晚18:30更新技術干貨
要是覺得文章對你有幫助的話，歡迎評論轉發(fā)點贊～
