vivo 全鏈路多版本開發測試環境落地實踐
一、背景介紹
軟件系統中全鏈路指的是從用戶請求發起，到最終返回響應的整個過程中所涉及到的所有環節和組件。在微服務軟件架構風格盛行的今天，因為微服務獨立部署、松耦合等特性，往往一個業務系統由數目較多的服務組成，較多的服務往往帶來一系列操作上的復雜性。
全鏈路部署指的是將整個軟件系統的所有服務一次性部署環境中的一種部署方式，這種部署方式可以簡化我們日常發布流程，確保系統的所有服務協同工作。
vivo 的 CICD 發布系統從【構建部署腳本自動化】>【持續集成平臺化】>【集成更多 DevOps 功能和組件】，演進到現在更加靈活編輯的多服務編排方式。為了適應最新的微服務軟件架構風格，CICD 發布系統通過中間件組件和調用鏈技術實現的落地，基于容器建立了全鏈路多版本流水線部署能力。
多版本部署則是基于灰度發布的理念，在同一時間內，將不同版本的服務部署在同一個環境中，使得不同版本的服務可以同時運行和提供服務的一種部署方式。
隨著互聯網發展增速，軟件開發和部署需要快速迭代，軟件發布變得越來越頻繁和復雜。迭代版本持續交付過程中，多個版本并行基本是所有項目常態化的情況，為此項目團隊往往會搭建多套測試環境以備功能驗證。多套環境的服務、組件和配置數據維護不僅大量占用研發人員的日常工作時間，環境部署所需資源也占用越來越多的公司硬件成本，即便這樣可能也無法完全滿足產品研發過程中遇到的緊急修復版本或臨時插入的高優需求這樣需要占用環境的問題。當前項目的應對措施往往都是讓當前常規版本臨時“讓開”，先讓緊急分支版本發布到正在使用的測試環境上，驗證通過后再釋放環境，讓常規版本回歸繼續測試驗證。
我們希望通過全鏈路多版本部署解決傳統測試環境存在的如下幾個問題。
二、全鏈路多版本部署技術方案
2.1 部署架構
上文就全鏈路多版本部署名稱解釋和與傳統環境區別做了簡單介紹，為進一步給大家清晰區分全鏈路多版本部署的測試環境與傳統測試環境區別，下面從部署架構圖的角度再次闡述下兩者的區別。
傳統測試環境就是將業務線上的服務全量部署幾套以供使用。傳統測試環境使用也比較簡單，不同環境通常擁有不同的域名或者同一個域名不同的 hosts 映射，用戶通過修改配置直接訪問到具體環境上。
在全鏈路多版本環境中，只有基線環境是將業務線上的服務全量部署，其余特性環境只需拉起需要的個別服務即可。
使用全鏈路多版本環境時，不同環境訪問的域名都是同一個，用戶需要通過代理工具添加 Request headers，設置 tc_fd = 環境標識，這樣帶有標識的請求經過網關時，會根據配置的路由規則轉發到指定環境。這里路由規則會由 CICD 平臺根據服務編排的組成，自動配置到 HTTP 網關、Dubbo、MQ 等中間件平臺上。
如下圖黃色箭頭所示，帶有 tc_fd = 1 標識的請求鏈路為 service_A_1->service_B_1->service_C->service_D_1。因為特性環境1中不存在 service_C，所以請求流量在 service_C 時回落到基線環境，往下調用時繼續路由到 service_D_1 服務，保證了環境的完整性。
想要達成全鏈路多版本流水線的快速部署，邏輯隔離等特性，需要 CICD 平臺把控多服務多版本的統一部署，環境治理和標簽管理，容器平臺保證業務的彈性伸縮能力，業務的流量灰度由 HTTP 網關和 Dubbo、消息中間件路由策略實現，同時需要配置中心來管理所有服務的配置，以及最重要的底層鏈路追蹤和監控來實現完整的微服務架構。
為了實現全鏈路多版本部署方案，業務程序遵循微服架構，訪問時實現邏輯隔離、將系統的流量劃分為不同的通道或環境，每個環境都有其獨立的流量，避免它們相互影響是關鍵的一環。
想要達成全鏈路多版本流水線的快速部署，邏輯隔離等特性，技術上需要實現如下幾點：
- 流量染色
- 流量隔離
- 標簽傳遞
- 環境管理
2.2 流量染色
接口調用請求時，需要在鏈路中添加染色標識稱作流量染色。針對流量類型不同，服務調用方式不同，可以通過如下幾種方式進行染色。
2.2.1 客戶端 HTTP 服務調用
瀏覽器端或者 APP 端發起的 HTTP 請求，用戶可以通過本地安裝的代理工具攔截 HTTP 請求，再按規則配置注入 tc_fd 流量標識。
推薦的代理工具有Charles 和 Chrome 瀏覽器插件 ModHeader。
2.2.2 服務端 HTTP 服務調用
如果是對外提供的 REST API 服務，服務調用方請求時不帶流量標識，可以在網關層按調用方配置“請求頭改寫”，實現全局修改。
2.2.3 Dubbo 服務調用
本地服務調試時，Dubbo 消費端可以在上下文中設置標簽
RpcContext.getContext().setAttachment("Dubbo.tag","流量標識")。
針對整個消費端服務，也可以通過添加 JVM 參數 -Dvivotag = 流量標識進行全局設置。
2.2.4 分布式任務調用
對應配置在“分布式任務調度平臺”基于給定的時間點，給定的時間間隔或者給定執行次數自動執行的任務，平臺側也已支持在調度策略上配置當前策略調度分組，以及是否需要調用時添加多版本流量標識。
2.3 流量隔離
上述介紹了幾種流量染色方式，當流量染色后，如何將帶有環境標識的流量轉發到對應的環境呢。我們目前針對 HTTP、Dubbo、MQ 等幾種常見流量類型實現了邏輯隔離方案，實現過程中主要考慮到如下幾點要素：
- 應用侵入性低，減少應用接入成本，由平臺自動配置和中間件框架實現隔離邏輯；
- 支持業務常見流量類型，覆蓋大部分業務邏輯；
- 流量隔離改造需考慮性能問題；
- 滿足特性環境任意擴展的需求，組件支持動態擴縮容。
2.3.1 HTTP 流量隔離
HTTP 流量隔離通過 VUA 網關配置實現，VUA（vivo unity access，公司流量統一接入層）是 vivo 統一接入層，基于 APISIX 的二次開發統一接入平臺。通過 VUA 中的 traffic-split 插件可以通過配置 match 和 weighted_upstreams 屬性，從而動態地將部分流量引導至各種上游服務。
創建新的流水線后，CICD 發布系統根據新增容器工作負載自動到 VUA 網關上創建 upstream，并且配置按環境標識配置 match 屬性，用于引導流量按自定義規則，常見支持的規則有判斷 HTTPHeader，pathParam，cookie 參數等。
2.3.2 Dubbo 流量隔離
Dubbo 提供了豐富的流量管控策略，通過基于路由規則的流量管控，可以對每次請求進行條件匹配，并將符合條件的請求路由到特定的地址子集。針對全鏈路多版本測試環境，我們采取動態配置標簽路由規則的方式進行打標，標簽主要是指對 Provider 端應用實例的分組，標簽路由通過將某一個服務的實例劃分到不同的分組，約束具有特定標簽的流量只能在指定分組中流轉，不同分組為不同的流量場景服務，從而實現流量隔離的目的。
具體做法為由 Dubbo 服務治理平臺提供標簽新增/刪除接口用于動態配置標簽路由規則，CICD 發布系統在部署時通過容器 Init Container 特性在實例啟動前調用新增 tag 接口打標，完成標簽路由規則的自動配置。
2.3.3 MQ 消息隔離
除了應用層 RPC（Remote Procedure Call，遠程過程調用）協議的流量隔離，大多數業務場景還會對消息的全鏈路有一定的訴求。vivo 在線業務側消息中間件自2022完成了從 RabbitMQ 到 RocketMQ 的平滑升級，目前業務現狀仍是使用了 RabbitMQ 的 SDK，由平臺側中間件團隊提供 mq-proxy 消息網關組件負責 AMQP 協議與 RocketMQ 協議的相互轉換，此為我們公司特殊背景。實現消息隔離的過程分生產者和消費者兩部分實現。
- 生產者在發送消息的時候，通過在 user-property 中加上一些字段將環境標簽附帶在消息體中，使得消息發送到 RocketMQ server 的時候就包含灰度信息。
- 消費者客戶端 SDK 使用全鏈路 Agent 將版本標識添加到連接屬性當中，啟動時根據環境標識，由 mq-proxy 自動創建當前帶環境標簽的 group，并通過消費訂閱的消息屬性過濾機制，從 topic 中過濾出來屬于自己版本的消息。
2.4 標簽傳遞
以上大概介紹了我們支持的三種組件進行流量、消息隔離的基本實現原理。在多版本環境中，真實的業務鏈路往往是用戶通過 HTTP 請求經過網關訪問到 service_A 服務，再由 service_A 服務通過 RPC 接口調用到 service_B 服務，service_B 服務生產消息提供給 service_C 服務消費。整個調用過程中如果用戶發起請求時加上了 tc_fd 環境標簽，也就是流量被染色，請求頭中有特定標識之后，標簽需要在調用鏈路中傳遞下去叫做標簽傳遞。有了這個標識鏈路傳遞，我們再為鏈路上的所有應用定義流量隔離策略才會生效。
標簽傳遞功能借助分布式鏈路跟蹤系統實現，我司分布式鏈路跟蹤系統簡稱調用鏈，主要覆蓋開發語言為 Java。調用鏈的 Agent 模塊通過字節碼增強技術，使用 Java 探針做到了不侵入業務代碼的前提下，對服務的類進行攔截，從而植入一些監控埋點上報或者其他代碼。
應用到全鏈路多版本環境部署功能中來，就是在服務接收到請求時，從報文里獲取到標簽信息，向下游服務發起新的服務請求時，再將獲取到的標簽信息設置到指定參數位置。向下游傳遞時幾種調用方式的標簽設置方式如下：
- HTTP 請求，透傳參數以 key-value 形式附加在 HTTPRequest 的 headers 中，支持向上游回傳，回傳的參數存在于 HTTPResponse 的 headers 中；
- Dubbo 調用，透傳參數以 key-value 形式附加在 RpcInvocation 的 attachments 中；
- RMQ Procuder 發送消息時，透傳參數以 key-value 形式附加在消息屬性 MessageProperties 的 header 中。
2.5 環境管理
相比之前使用流水線部署傳統測試環境，全鏈路多版本流水線在部署過程中賦予測試環境更多的配置屬性，在創建和使用測試環境上更加靈活多變。所以從 CICD 平臺建設上，我們需要盡可能的完善平臺自動化程度，抹平因為流水線差異導致用戶增加使用全鏈路多版本流水線的操作和理解成本。
2.5.1 基線環境
基線環境作為全鏈路多版本環境中最基礎的環境，是當請求鏈接不帶任何環境標簽時默認訪問到的環境，基線環境被其他特性環境共享，所以保障基線環境穩定性十分重要。我們在前期推廣全鏈路多版本流水線過程中，為了環境規范化部署，要求業務方接入時需要新建基線環境，且同一服務下基線環境存在唯一性。這樣做的好處是環境管理更加規范，壞處卻是提高了使用成本，一套服務全都新建基線環境占用大量硬件和人力成本，與推廣全鏈路多版本流水線初衷不符。在吸收用戶意見及后續優化后，我們支持了在已有測試環境的基礎上進行基線環境改造，以支持其他特性環境的兼容。為了管理基線環境，我們還采取以下措施：
- 統一環境配置：為了避免不同環境使用不同的基線環境配置，需要統一基線環境配置，以確保不同特性環境使用的基線環境一致。
- 定期更新和維護基線環境：為保證基線環境穩定，需要減少基線環境發布頻率，保證部署代碼分支質量穩定。按照項目管理特點，可以配置生產環境部署后觸發基線環境部署生產環境代碼分支；
- 監控和報警：對基線環境進行監控，如 CPU、內存、磁盤等資源的使用情況，及時發現問題并進行處理。
2.5.2 特性環境
特性環境是指為了測試和驗證某個特性而創建的獨立環境，在測試環境場景中與版本屬性有關聯，每個特性環境有屬于自己的環境標簽屬性，具有快速創建和銷毀的特性。特性環境的管理也具備如下幾個方面的功能：
- 標簽管理：每個特性環境創建時會自動生成全局唯一的環境標簽，或者指定已有的環境標簽。
- 快速創建：快速拉起一套新的特性環境，按既有服務流水線模板編排成多服務環境，實現一鍵運行構建部署所需的多個服務實例。
- 環境配置自動化：創建特性環境時，避免創建前申請容器資源，創建后配置路由規則等繁瑣操作，具體配置功能盡可能由平臺實現自動化。
- 定時銷毀：每個特性環境設置使用生命周期，到期不用后定時清理流水線和容器實例，避免冗余環境長期不用占用資源。
2.5.3 鏈路監控
現在大規模微服務分布式架構軟件模塊的背景下，幫助理解系統行為、用于分析性能問題的工具分布式鏈路跟蹤系統應運而生。因為全鏈路多版本流水線特性環境流量隔離的特性，因為鏈路問題可能會導致服務調用串環境，鏈路監控功能就更為重要。目前關于鏈路監控的功能建設如下：
- 交互便捷：在流水線頁面遷入鏈路可視化菜單，并按環境標簽定位到當前環境數據。
- 調用拓撲圖：通過調用拓撲圖展示服務間的調用關系和數據流向，在鏈路元數據中增加環境標簽信息，在鏈路圖形化展示上標記環境信息。
- 問題排查：HTTP 調用時通過調用鏈返回當前 traceId 到 ResponseHeader 上，更加方便用戶通過 traceId 直接定位到具體日志。
三、未來與展望
CICD 部署平臺建設全鏈路多版本流水線初衷是為了實現降本增效，節約公司的硬件和環境運營成本，提升研發人員日常工作效率。在具體推廣全鏈路多版本流水線的過程中也遇到了一些問題，如重新搭建基線環境增加成本，已改為兼容原有測試環境替代。當前全鏈路流水線建設還剛剛起步，未來還有更多空間值得優化：
- 支持更多組件和語言：目前流量隔離已支持了 RPC 層的 HTTP 和 Dubbo 流量，消息中間件的 MQ 組件，對于其他 RPC 框架，消息中間件組件，或涉及到非 Java 語言應用時，由于使用范圍不普遍，優先級較低，目前還未支持。這項問題會根據公司業務發展和技術應用流行趨勢進行調整。
- 支持數據邏輯隔離：數據的底層存儲通常是 MySQL，Redis，MongoDB 等，因為業務場景復雜，數據隔離實現成本高，暫未實現邏輯隔離的功能。如業務有需求，通常建議準備多套數據庫使用物理隔離方案，在配置中心創建多套數據庫配置信息方便切換。但是若想業務灰度使用更加絲滑，數據邏輯隔離還需要具備。
- 更多應用場景：目前全鏈路多服務流水線只應用在測試環境部署，如果業務使用流量染色的功能更加熟悉和穩定，未來此項特性在線上 A/B 測試等場景也可支持。
