1、背景

測試環境治理一直是各大公司非常重要的一個課題，測試環境穩定性很大程度影響迭代開發&測試效率。

綜合來看，測試環境不穩定的原因主要有以下幾點：

測試環境的變更非終態變更，經常會有代碼發布/配置發布導致服務無法啟動或者鏈路有問題的情況。

變更頻繁，開發需要聯調、測試需要迭代測試，代碼需要變更，配置也需要變更，權限控制就比較難做，增加了測試環境不穩定性。

并行需求，同一時間單個應用需要多個分支同時支持多個需求的測試，測試環境資源的搶占和沖突比較明顯。

得物測試環境穩定性治理也經歷了幾個階段：

• 2020~2021：多套物理環境隔離方案（基于ECS）

T0、T1、T2三套測試環境，每套環境物理隔離，無資源沖突和共享。

規劃T1用于迭代測試、T0用于集成回歸、T2用于獨立項目分配使用，但在實際使用過程中，業務測試并行太多，沖突比較明顯，環境就開始亂用了，誰有需求就隨便占用一套環境使用了。結果就是沒有一套穩定的環境，測試有效性無法保障，并行項目環境沖突也無法解決。

• 2021~2022：MF全鏈路容器環境方案（基于容器）

隨著業務增長，3套測試環境已明顯不能滿足業務需求，因此去年得物基于容器快速搭建了10套MF環境用于支撐獨立項目的測試。

MF環境基于T0搭建，DB和T0共享，其他所有資源均獨立，目的是做到業務只需保障T0的穩定性，所有MF環境可快速基于T0同步最新服務和最新配置，做到環境隨用隨取，解決并行項目環境沖突問題。

實際實施過程中，項目環境沖突的問題解決了，但是MF環境的穩定性問題依舊比較嚴重，維護成本巨大，主要原因集中在：

T0環境穩定性，并非所有域都在T0集成回歸，導致T0穩定性無法保障

MF同步了T0之后會因為各種各樣的原因需要二次調試驗收（新增服務丟失、配置不全/錯亂等）

MF環境使用過程中，基礎服務（sso、網關、中間件）等相關變更無法及時更新到MF環境，影響業務測試

因此在2022年下半年，開始嘗試用染色環境解決環境穩定性問題。

• 2022年：染色環境方案（基于流量隔離）

染色環境是基于流量隔離的方案，通過流量標透傳的方式，把基準環境流量和染色環境流量隔離開，實現多環境的方案，支持并行測試互不影響。

相較于MF環境而言，不需要維護多套全鏈路環境，維護成本降低了。所有變更的服務都在染色環境部署的話，基準環境穩定性就會提升，相當于所有環境的穩定性都提升了。

下面主要介紹得物染色環境是如何做的

2、染色環境方案

2.1 基本思路

如下圖所示，最初的設想是：

• 服務可以按照流量標把流量路由到相應染色服務上
• 如果染色標對應染色環境沒有此服務，則流量會走到基準環境
• 如果染色環境服務添加了，沒有部署，或者部署了服務進程掛了，則流量會報錯而并非走到基準環境（避免一些服務異常問題沒有暴露）
• DB、MQ、Redis等中間件期望用同一套，避免浪費

基于此設想，需要從哪些地方入手去改造以支持染色環境呢？可以從設想拆解去解決：

• 流量標如何透傳？
• 流量路由如何路由到染色節點？

rpc接口如何路由到染色節點？

MQ消息如何讓染色環境consumer消費？

• 解決完流量標透傳問題，以及染色路由問題后，需要考慮流量發起方如何把染色標帶上？

2.2 實現方案

以下方案只做流量隔離，DB數據層不做隔離

流量標如何透傳？

首先流量標在流量入口層會放到http header里面的x-infr-flowtype字段：

x-infr-flowtype:<CE_ColoringEnv> ##CE_是固定前綴，為了和壓測標做區分

從流量到網關后，服務鏈路上面流量標往下透傳的方式是通過OpenTracing規范中的baggage能力，從header里面獲取染色標，并塞到trace里面向下透傳。

這樣整個鏈路里面就都能拿到染色標了

流量路由如何路由到染色節點？

這里分兩塊考慮：

（1）rpc調用，拿到染色標之后，如何找到染色節點？這里要解決的是怎么識別染色節點

（2）MQ消息，producer如何發送帶染色標的消息，consumer如何處理帶染色標的消息

• 服務注冊--識別染色節點

首先染色環境創建的時候，會定義好染色標：

在此染色環境添加服務部署的時候，默認會把染色標注入到環境變量COLORING_ENV容器發布配置頁面會自動增加COLORING_ENV變量

至此，服務啟動時已可以讀到COLORING_ENV環境標變量了，下一步就看注冊中心怎么去區分染色節點了.

首先服務在添加到染色環境的時候，服務會在注冊中心染色場增加一個節點，標明該服務在此染色環境是有服務節點存在的。

染色場主要解決的問題是：如果染色節點掛了，染色環境流量應該判斷該染色環境是否應該有染色節點，有的話就報錯，沒有的話才會走到基準環境。避免測試問題未暴露。

染色場：CE_<ServiceName>

染色場服務節點：<COLORING_ENV>:80

其次在服務注冊時候，服務節點信息和方法注冊會攜帶染色標<coloring_env>：

至此，注冊中心就可以基于染色標識別染色節點，業務服務（基于fusion框架）可以根據Trace中的染色標結合注冊中心染色節點做染色流量路由。

• MQ改造--識別和處理MQ消息

MQ主要解決的是，染色環境的消息生產者producer發送的消息，只被染色環境的消費者消費，染色環境如果沒有消費節點，則由基準環境消費者消費。

這里之前討論了兩種做法：

第一種是基于Topic隔離的方案，每套染色環境使用不同的topic進行通信，這樣隔離性比較好，消息不容易串掉。

第二種是Topic不隔離，所有染色環境共用一個topic，生產者Producer在生產消息時候把染色標帶上，consumer每套染色環境有一個，consumer在做消費時候會判斷消息里面的染色標和本地染色標是否一致，如果一致則消費，如果不一致則直接返回ACK不走具體消費邏輯。

目前選擇的是第二種方案，下面基于第二種方案做詳細介紹：

基本流程

如圖所示：

ServiceB_Color1會自動注冊GID_Color1_Topic消費組，監聽Topic_A。Color2和Color3環境一樣。

帶Color1的消息由ServiceA_Color1生產，ServiceB_Color1消費。

帶Color2的消息由ServiceA_Color2生產，ServiceB消費，因為ServiceB在Color2染色環境沒有節點

帶Color3的消息由于染色環境Color3沒有ServiceA_Color3節點，則帶Color3的流量會打到基準環境ServiceA，此時ServiceA會生產帶Color3的消息，此消息由ServiceB_Color3消費

配合業務說明：

染色環境在啟動時候，帶染色標的GID會自動創建，eg：原GID是GID_AAA，染色自動創建的GID為GID_<coloring_env>_AAA

下面看消息的內容和處理邏輯：

如上圖：染色消息屬性里面會增加DMQ_ENV_TAG字段，添加染色標，然后對應染色環境訂閱組才會消費。

看上面這張圖，會發現“貌似”所有染色環境都消費了，其實是其他環境直接返回了ACK，未走具體的消費邏輯，具體可以看日志。

代碼說明：基于Message里面染色標msgTag和本地服務染色標envTag進行判斷做消費邏輯區分。

染色流量入口攜帶染色標

解決完染色標透傳，以及染色標邏輯處理后，剩下就是如何在流量發起方把染色標給帶上了，其實就是把染色標塞到header里面的x-infr-flowtype字段。

其中染色環境列表的獲取由發布平臺提供接口給到各流量入口方去選擇。

目前業務推廣過程中，主要遇到的入口方大致有以下幾種：

入口流量攜帶染色標相對邏輯比較簡單，這里就不做詳細技術介紹，只做使用層面介紹

至此整個業務改造基本完成，從染色流量如何構造、流量標如何透傳、染色節點如何識別以及識別后重點染色邏輯如何處理等一整套流程就清晰了。

3、業務應用效果

3.1 實施路徑

染色項目整個實施路徑包含幾個階段：

• 項目立項&中間件改造（4月-6月）

包含基架改造（統一框架、網關、注冊中心、配置中心、超時中心、DMQ等）&客戶端改造&發布平臺改造等等，以及改造完成后基礎鏈路驗證

• 線上灰度&全鏈路服務適配（7月~8月）

7月初：5個交易&中間件相關服務升級相關jar包帶上線進行驗證，保證不會對染色改造不會對生產有影響。

8月份：開始推進全域應用進行染色相關jar包升級

• 獨立項目使用（9月）

9月底之前，已經有若干獨立項目應用染色環境測試驗證完成

• 業務迭代使用（10月~11月）

10月份開始嘗試推進全業務進行染色環境試用排錯

試用結束，逐步推進迭代使用染色環境

3.2 業務使用效果

獨立項目：目前全域的獨立項目已全量切換至染色環境測試。

版本迭代：就最新的版本迭代使用結果來看，全域95%以上的需求都可以使用染色環境測試。

剩余5%的需求場景主要是涉及以下兩個方面：

數據隔離：目前已有方案在支持，會涉及少量需求支撐。

前端染色：目前染色環境主要解決了后端染色的需求，部分場景需求依賴前端染色（多前端支持），方案也基本落地，會配合后端染色一起應用。

4、總結

染色環境現階段解決了測試環境沖突和測試環境穩定性的問題，并且相較之前多套獨立環境的方案，在成本上也有比較大的節省。后續得物也會嘗試用染色的能力解決生產灰度發布問題，相信也會有不錯的效果。