一、背景介紹

軟件系統(tǒng)中全鏈路指的是從用戶請(qǐng)求發(fā)起，到最終返回響應(yīng)的整個(gè)過(guò)程中所涉及到的所有環(huán)節(jié)和組件。在微服務(wù)軟件架構(gòu)風(fēng)格盛行的今天，因?yàn)槲⒎?wù)獨(dú)立部署、松耦合等特性，往往一個(gè)業(yè)務(wù)系統(tǒng)由數(shù)目較多的服務(wù)組成，較多的服務(wù)往往帶來(lái)一系列操作上的復(fù)雜性。

全鏈路部署指的是將整個(gè)軟件系統(tǒng)的所有服務(wù)一次性部署環(huán)境中的一種部署方式，這種部署方式可以簡(jiǎn)化我們?nèi)粘０l(fā)布流程，確保系統(tǒng)的所有服務(wù)協(xié)同工作。

vivo 的 CICD 發(fā)布系統(tǒng)從【構(gòu)建部署腳本自動(dòng)化】>【持續(xù)集成平臺(tái)化】>【集成更多 DevOps 功能和組件】，演進(jìn)到現(xiàn)在更加靈活編輯的多服務(wù)編排方式。為了適應(yīng)最新的微服務(wù)軟件架構(gòu)風(fēng)格，CICD 發(fā)布系統(tǒng)通過(guò)中間件組件和調(diào)用鏈技術(shù)實(shí)現(xiàn)的落地，基于容器建立了全鏈路多版本流水線部署能力。

多版本部署則是基于灰度發(fā)布的理念，在同一時(shí)間內(nèi)，將不同版本的服務(wù)部署在同一個(gè)環(huán)境中，使得不同版本的服務(wù)可以同時(shí)運(yùn)行和提供服務(wù)的一種部署方式。

隨著互聯(lián)網(wǎng)發(fā)展增速，軟件開(kāi)發(fā)和部署需要快速迭代，軟件發(fā)布變得越來(lái)越頻繁和復(fù)雜。迭代版本持續(xù)交付過(guò)程中，多個(gè)版本并行基本是所有項(xiàng)目常態(tài)化的情況，為此項(xiàng)目團(tuán)隊(duì)往往會(huì)搭建多套測(cè)試環(huán)境以備功能驗(yàn)證。多套環(huán)境的服務(wù)、組件和配置數(shù)據(jù)維護(hù)不僅大量占用研發(fā)人員的日常工作時(shí)間，環(huán)境部署所需資源也占用越來(lái)越多的公司硬件成本，即便這樣可能也無(wú)法完全滿足產(chǎn)品研發(fā)過(guò)程中遇到的緊急修復(fù)版本或臨時(shí)插入的高優(yōu)需求這樣需要占用環(huán)境的問(wèn)題。當(dāng)前項(xiàng)目的應(yīng)對(duì)措施往往都是讓當(dāng)前常規(guī)版本臨時(shí)“讓開(kāi)”，先讓緊急分支版本發(fā)布到正在使用的測(cè)試環(huán)境上，驗(yàn)證通過(guò)后再釋放環(huán)境，讓常規(guī)版本回歸繼續(xù)測(cè)試驗(yàn)證。

我們希望通過(guò)全鏈路多版本部署解決傳統(tǒng)測(cè)試環(huán)境存在的如下幾個(gè)問(wèn)題。

二、全鏈路多版本部署技術(shù)方案

2.1 部署架構(gòu)

上文就全鏈路多版本部署名稱解釋和與傳統(tǒng)環(huán)境區(qū)別做了簡(jiǎn)單介紹，為進(jìn)一步給大家清晰區(qū)分全鏈路多版本部署的測(cè)試環(huán)境與傳統(tǒng)測(cè)試環(huán)境區(qū)別，下面從部署架構(gòu)圖的角度再次闡述下兩者的區(qū)別。

傳統(tǒng)測(cè)試環(huán)境就是將業(yè)務(wù)線上的服務(wù)全量部署幾套以供使用。傳統(tǒng)測(cè)試環(huán)境使用也比較簡(jiǎn)單，不同環(huán)境通常擁有不同的域名或者同一個(gè)域名不同的 hosts 映射，用戶通過(guò)修改配置直接訪問(wèn)到具體環(huán)境上。

在全鏈路多版本環(huán)境中，只有基線環(huán)境是將業(yè)務(wù)線上的服務(wù)全量部署，其余特性環(huán)境只需拉起需要的個(gè)別服務(wù)即可。

使用全鏈路多版本環(huán)境時(shí)，不同環(huán)境訪問(wèn)的域名都是同一個(gè)，用戶需要通過(guò)代理工具添加 Request headers，設(shè)置 tc_fd = 環(huán)境標(biāo)識(shí)，這樣帶有標(biāo)識(shí)的請(qǐng)求經(jīng)過(guò)網(wǎng)關(guān)時(shí)，會(huì)根據(jù)配置的路由規(guī)則轉(zhuǎn)發(fā)到指定環(huán)境。這里路由規(guī)則會(huì)由 CICD 平臺(tái)根據(jù)服務(wù)編排的組成，自動(dòng)配置到 HTTP 網(wǎng)關(guān)、Dubbo、MQ 等中間件平臺(tái)上。

如下圖黃色箭頭所示，帶有 tc_fd = 1 標(biāo)識(shí)的請(qǐng)求鏈路為 service_A_1->service_B_1->service_C->service_D_1。因?yàn)樘匦原h(huán)境1中不存在 service_C，所以請(qǐng)求流量在 service_C 時(shí)回落到基線環(huán)境，往下調(diào)用時(shí)繼續(xù)路由到 service_D_1 服務(wù)，保證了環(huán)境的完整性。

想要達(dá)成全鏈路多版本流水線的快速部署，邏輯隔離等特性，需要 CICD 平臺(tái)把控多服務(wù)多版本的統(tǒng)一部署，環(huán)境治理和標(biāo)簽管理，容器平臺(tái)保證業(yè)務(wù)的彈性伸縮能力，業(yè)務(wù)的流量灰度由 HTTP 網(wǎng)關(guān)和 Dubbo、消息中間件路由策略實(shí)現(xiàn)，同時(shí)需要配置中心來(lái)管理所有服務(wù)的配置，以及最重要的底層鏈路追蹤和監(jiān)控來(lái)實(shí)現(xiàn)完整的微服務(wù)架構(gòu)。

為了實(shí)現(xiàn)全鏈路多版本部署方案，業(yè)務(wù)程序遵循微服架構(gòu)，訪問(wèn)時(shí)實(shí)現(xiàn)邏輯隔離、將系統(tǒng)的流量劃分為不同的通道或環(huán)境，每個(gè)環(huán)境都有其獨(dú)立的流量，避免它們相互影響是關(guān)鍵的一環(huán)。

想要達(dá)成全鏈路多版本流水線的快速部署，邏輯隔離等特性，技術(shù)上需要實(shí)現(xiàn)如下幾點(diǎn)：

• 流量染色
• 流量隔離
• 標(biāo)簽傳遞
• 環(huán)境管理

2.2 流量染色

接口調(diào)用請(qǐng)求時(shí)，需要在鏈路中添加染色標(biāo)識(shí)稱作流量染色。針對(duì)流量類型不同，服務(wù)調(diào)用方式不同，可以通過(guò)如下幾種方式進(jìn)行染色。

2.2.1 客戶端 HTTP 服務(wù)調(diào)用

瀏覽器端或者 APP 端發(fā)起的 HTTP 請(qǐng)求，用戶可以通過(guò)本地安裝的代理工具攔截 HTTP 請(qǐng)求，再按規(guī)則配置注入 tc_fd 流量標(biāo)識(shí)。

推薦的代理工具有Charles 和 Chrome 瀏覽器插件 ModHeader。

2.2.2 服務(wù)端 HTTP 服務(wù)調(diào)用

如果是對(duì)外提供的 REST API 服務(wù)，服務(wù)調(diào)用方請(qǐng)求時(shí)不帶流量標(biāo)識(shí)，可以在網(wǎng)關(guān)層按調(diào)用方配置“請(qǐng)求頭改寫(xiě)”，實(shí)現(xiàn)全局修改。

2.2.3 Dubbo 服務(wù)調(diào)用

本地服務(wù)調(diào)試時(shí)，Dubbo 消費(fèi)端可以在上下文中設(shè)置標(biāo)簽

RpcContext.getContext().setAttachment("Dubbo.tag","流量標(biāo)識(shí)")。

針對(duì)整個(gè)消費(fèi)端服務(wù)，也可以通過(guò)添加 JVM 參數(shù) -Dvivotag = 流量標(biāo)識(shí)進(jìn)行全局設(shè)置。

2.2.4 分布式任務(wù)調(diào)用

對(duì)應(yīng)配置在“分布式任務(wù)調(diào)度平臺(tái)”基于給定的時(shí)間點(diǎn)，給定的時(shí)間間隔或者給定執(zhí)行次數(shù)自動(dòng)執(zhí)行的任務(wù)，平臺(tái)側(cè)也已支持在調(diào)度策略上配置當(dāng)前策略調(diào)度分組，以及是否需要調(diào)用時(shí)添加多版本流量標(biāo)識(shí)。

2.3 流量隔離

上述介紹了幾種流量染色方式，當(dāng)流量染色后，如何將帶有環(huán)境標(biāo)識(shí)的流量轉(zhuǎn)發(fā)到對(duì)應(yīng)的環(huán)境呢。我們目前針對(duì) HTTP、Dubbo、MQ 等幾種常見(jiàn)流量類型實(shí)現(xiàn)了邏輯隔離方案，實(shí)現(xiàn)過(guò)程中主要考慮到如下幾點(diǎn)要素：

1. 應(yīng)用侵入性低，減少應(yīng)用接入成本，由平臺(tái)自動(dòng)配置和中間件框架實(shí)現(xiàn)隔離邏輯；
2. 支持業(yè)務(wù)常見(jiàn)流量類型，覆蓋大部分業(yè)務(wù)邏輯；
3. 流量隔離改造需考慮性能問(wèn)題；
4. 滿足特性環(huán)境任意擴(kuò)展的需求，組件支持動(dòng)態(tài)擴(kuò)縮容。

2.3.1 HTTP 流量隔離

HTTP 流量隔離通過(guò) VUA 網(wǎng)關(guān)配置實(shí)現(xiàn)，VUA（vivo unity access，公司流量統(tǒng)一接入層）是 vivo 統(tǒng)一接入層，基于 APISIX 的二次開(kāi)發(fā)統(tǒng)一接入平臺(tái)。通過(guò) VUA 中的 traffic-split 插件可以通過(guò)配置 match 和 weighted_upstreams 屬性，從而動(dòng)態(tài)地將部分流量引導(dǎo)至各種上游服務(wù)。

創(chuàng)建新的流水線后，CICD 發(fā)布系統(tǒng)根據(jù)新增容器工作負(fù)載自動(dòng)到 VUA 網(wǎng)關(guān)上創(chuàng)建 upstream，并且配置按環(huán)境標(biāo)識(shí)配置 match 屬性，用于引導(dǎo)流量按自定義規(guī)則，常見(jiàn)支持的規(guī)則有判斷 HTTPHeader，pathParam，cookie 參數(shù)等。

2.3.2 Dubbo 流量隔離

Dubbo 提供了豐富的流量管控策略，通過(guò)基于路由規(guī)則的流量管控，可以對(duì)每次請(qǐng)求進(jìn)行條件匹配，并將符合條件的請(qǐng)求路由到特定的地址子集。針對(duì)全鏈路多版本測(cè)試環(huán)境，我們采取動(dòng)態(tài)配置標(biāo)簽路由規(guī)則的方式進(jìn)行打標(biāo)，標(biāo)簽主要是指對(duì) Provider 端應(yīng)用實(shí)例的分組，標(biāo)簽路由通過(guò)將某一個(gè)服務(wù)的實(shí)例劃分到不同的分組，約束具有特定標(biāo)簽的流量只能在指定分組中流轉(zhuǎn)，不同分組為不同的流量場(chǎng)景服務(wù)，從而實(shí)現(xiàn)流量隔離的目的。

具體做法為由 Dubbo 服務(wù)治理平臺(tái)提供標(biāo)簽新增/刪除接口用于動(dòng)態(tài)配置標(biāo)簽路由規(guī)則，CICD 發(fā)布系統(tǒng)在部署時(shí)通過(guò)容器 Init Container 特性在實(shí)例啟動(dòng)前調(diào)用新增 tag 接口打標(biāo)，完成標(biāo)簽路由規(guī)則的自動(dòng)配置。

2.3.3 MQ 消息隔離

除了應(yīng)用層 RPC（Remote Procedure Call，遠(yuǎn)程過(guò)程調(diào)用）協(xié)議的流量隔離，大多數(shù)業(yè)務(wù)場(chǎng)景還會(huì)對(duì)消息的全鏈路有一定的訴求。vivo 在線業(yè)務(wù)側(cè)消息中間件自2022完成了從 RabbitMQ 到 RocketMQ 的平滑升級(jí)，目前業(yè)務(wù)現(xiàn)狀仍是使用了 RabbitMQ 的 SDK，由平臺(tái)側(cè)中間件團(tuán)隊(duì)提供 mq-proxy 消息網(wǎng)關(guān)組件負(fù)責(zé) AMQP 協(xié)議與 RocketMQ 協(xié)議的相互轉(zhuǎn)換，此為我們公司特殊背景。實(shí)現(xiàn)消息隔離的過(guò)程分生產(chǎn)者和消費(fèi)者兩部分實(shí)現(xiàn)。

1. 生產(chǎn)者在發(fā)送消息的時(shí)候，通過(guò)在 user-property 中加上一些字段將環(huán)境標(biāo)簽附帶在消息體中，使得消息發(fā)送到 RocketMQ server 的時(shí)候就包含灰度信息。
2. 消費(fèi)者客戶端 SDK 使用全鏈路 Agent 將版本標(biāo)識(shí)添加到連接屬性當(dāng)中，啟動(dòng)時(shí)根據(jù)環(huán)境標(biāo)識(shí)，由 mq-proxy 自動(dòng)創(chuàng)建當(dāng)前帶環(huán)境標(biāo)簽的 group，并通過(guò)消費(fèi)訂閱的消息屬性過(guò)濾機(jī)制，從 topic 中過(guò)濾出來(lái)屬于自己版本的消息。

2.4 標(biāo)簽傳遞

以上大概介紹了我們支持的三種組件進(jìn)行流量、消息隔離的基本實(shí)現(xiàn)原理。在多版本環(huán)境中，真實(shí)的業(yè)務(wù)鏈路往往是用戶通過(guò) HTTP 請(qǐng)求經(jīng)過(guò)網(wǎng)關(guān)訪問(wèn)到 service_A 服務(wù)，再由 service_A 服務(wù)通過(guò) RPC 接口調(diào)用到 service_B 服務(wù)，service_B 服務(wù)生產(chǎn)消息提供給 service_C 服務(wù)消費(fèi)。整個(gè)調(diào)用過(guò)程中如果用戶發(fā)起請(qǐng)求時(shí)加上了 tc_fd 環(huán)境標(biāo)簽，也就是流量被染色，請(qǐng)求頭中有特定標(biāo)識(shí)之后，標(biāo)簽需要在調(diào)用鏈路中傳遞下去叫做標(biāo)簽傳遞。有了這個(gè)標(biāo)識(shí)鏈路傳遞，我們?cè)贋殒溌飞系乃袘?yīng)用定義流量隔離策略才會(huì)生效。

標(biāo)簽傳遞功能借助分布式鏈路跟蹤系統(tǒng)實(shí)現(xiàn)，我司分布式鏈路跟蹤系統(tǒng)簡(jiǎn)稱調(diào)用鏈，主要覆蓋開(kāi)發(fā)語(yǔ)言為 Java。調(diào)用鏈的 Agent 模塊通過(guò)字節(jié)碼增強(qiáng)技術(shù)，使用 Java 探針做到了不侵入業(yè)務(wù)代碼的前提下，對(duì)服務(wù)的類進(jìn)行攔截，從而植入一些監(jiān)控埋點(diǎn)上報(bào)或者其他代碼。

應(yīng)用到全鏈路多版本環(huán)境部署功能中來(lái)，就是在服務(wù)接收到請(qǐng)求時(shí)，從報(bào)文里獲取到標(biāo)簽信息，向下游服務(wù)發(fā)起新的服務(wù)請(qǐng)求時(shí)，再將獲取到的標(biāo)簽信息設(shè)置到指定參數(shù)位置。向下游傳遞時(shí)幾種調(diào)用方式的標(biāo)簽設(shè)置方式如下：

• HTTP 請(qǐng)求，透?jìng)鲄?shù)以 key-value 形式附加在 HTTPRequest 的 headers 中，支持向上游回傳，回傳的參數(shù)存在于 HTTPResponse 的 headers 中；
• Dubbo 調(diào)用，透?jìng)鲄?shù)以 key-value 形式附加在 RpcInvocation 的 attachments 中；
• RMQ  Procuder 發(fā)送消息時(shí)，透?jìng)鲄?shù)以 key-value 形式附加在消息屬性 MessageProperties 的 header 中。

2.5 環(huán)境管理

相比之前使用流水線部署傳統(tǒng)測(cè)試環(huán)境，全鏈路多版本流水線在部署過(guò)程中賦予測(cè)試環(huán)境更多的配置屬性，在創(chuàng)建和使用測(cè)試環(huán)境上更加靈活多變。所以從 CICD 平臺(tái)建設(shè)上，我們需要盡可能的完善平臺(tái)自動(dòng)化程度，抹平因?yàn)榱魉€差異導(dǎo)致用戶增加使用全鏈路多版本流水線的操作和理解成本。

2.5.1 基線環(huán)境

基線環(huán)境作為全鏈路多版本環(huán)境中最基礎(chǔ)的環(huán)境，是當(dāng)請(qǐng)求鏈接不帶任何環(huán)境標(biāo)簽時(shí)默認(rèn)訪問(wèn)到的環(huán)境，基線環(huán)境被其他特性環(huán)境共享，所以保障基線環(huán)境穩(wěn)定性十分重要。我們?cè)谇捌谕茝V全鏈路多版本流水線過(guò)程中，為了環(huán)境規(guī)范化部署，要求業(yè)務(wù)方接入時(shí)需要新建基線環(huán)境，且同一服務(wù)下基線環(huán)境存在唯一性。這樣做的好處是環(huán)境管理更加規(guī)范，壞處卻是提高了使用成本，一套服務(wù)全都新建基線環(huán)境占用大量硬件和人力成本，與推廣全鏈路多版本流水線初衷不符。在吸收用戶意見(jiàn)及后續(xù)優(yōu)化后，我們支持了在已有測(cè)試環(huán)境的基礎(chǔ)上進(jìn)行基線環(huán)境改造，以支持其他特性環(huán)境的兼容。為了管理基線環(huán)境，我們還采取以下措施：

1. 統(tǒng)一環(huán)境配置：為了避免不同環(huán)境使用不同的基線環(huán)境配置，需要統(tǒng)一基線環(huán)境配置，以確保不同特性環(huán)境使用的基線環(huán)境一致。
2. 定期更新和維護(hù)基線環(huán)境：為保證基線環(huán)境穩(wěn)定，需要減少基線環(huán)境發(fā)布頻率，保證部署代碼分支質(zhì)量穩(wěn)定。按照項(xiàng)目管理特點(diǎn)，可以配置生產(chǎn)環(huán)境部署后觸發(fā)基線環(huán)境部署生產(chǎn)環(huán)境代碼分支；
3. 監(jiān)控和報(bào)警：對(duì)基線環(huán)境進(jìn)行監(jiān)控，如 CPU、內(nèi)存、磁盤(pán)等資源的使用情況，及時(shí)發(fā)現(xiàn)問(wèn)題并進(jìn)行處理。

2.5.2 特性環(huán)境

特性環(huán)境是指為了測(cè)試和驗(yàn)證某個(gè)特性而創(chuàng)建的獨(dú)立環(huán)境，在測(cè)試環(huán)境場(chǎng)景中與版本屬性有關(guān)聯(lián)，每個(gè)特性環(huán)境有屬于自己的環(huán)境標(biāo)簽屬性，具有快速創(chuàng)建和銷(xiāo)毀的特性。特性環(huán)境的管理也具備如下幾個(gè)方面的功能：

1. 標(biāo)簽管理：每個(gè)特性環(huán)境創(chuàng)建時(shí)會(huì)自動(dòng)生成全局唯一的環(huán)境標(biāo)簽，或者指定已有的環(huán)境標(biāo)簽。
2. 快速創(chuàng)建：快速拉起一套新的特性環(huán)境，按既有服務(wù)流水線模板編排成多服務(wù)環(huán)境，實(shí)現(xiàn)一鍵運(yùn)行構(gòu)建部署所需的多個(gè)服務(wù)實(shí)例。
3. 環(huán)境配置自動(dòng)化：創(chuàng)建特性環(huán)境時(shí)，避免創(chuàng)建前申請(qǐng)容器資源，創(chuàng)建后配置路由規(guī)則等繁瑣操作，具體配置功能盡可能由平臺(tái)實(shí)現(xiàn)自動(dòng)化。
4. 定時(shí)銷(xiāo)毀：每個(gè)特性環(huán)境設(shè)置使用生命周期，到期不用后定時(shí)清理流水線和容器實(shí)例，避免冗余環(huán)境長(zhǎng)期不用占用資源。

2.5.3 鏈路監(jiān)控

現(xiàn)在大規(guī)模微服務(wù)分布式架構(gòu)軟件模塊的背景下，幫助理解系統(tǒng)行為、用于分析性能問(wèn)題的工具分布式鏈路跟蹤系統(tǒng)應(yīng)運(yùn)而生。因?yàn)槿溌范喟姹玖魉€特性環(huán)境流量隔離的特性，因?yàn)殒溌穯?wèn)題可能會(huì)導(dǎo)致服務(wù)調(diào)用串環(huán)境，鏈路監(jiān)控功能就更為重要。目前關(guān)于鏈路監(jiān)控的功能建設(shè)如下：

1. 交互便捷：在流水線頁(yè)面遷入鏈路可視化菜單，并按環(huán)境標(biāo)簽定位到當(dāng)前環(huán)境數(shù)據(jù)。
2. 調(diào)用拓?fù)鋱D：通過(guò)調(diào)用拓?fù)鋱D展示服務(wù)間的調(diào)用關(guān)系和數(shù)據(jù)流向，在鏈路元數(shù)據(jù)中增加環(huán)境標(biāo)簽信息，在鏈路圖形化展示上標(biāo)記環(huán)境信息。
3. 問(wèn)題排查：HTTP 調(diào)用時(shí)通過(guò)調(diào)用鏈返回當(dāng)前 traceId 到 ResponseHeader 上，更加方便用戶通過(guò) traceId 直接定位到具體日志。

三、未來(lái)與展望

CICD 部署平臺(tái)建設(shè)全鏈路多版本流水線初衷是為了實(shí)現(xiàn)降本增效，節(jié)約公司的硬件和環(huán)境運(yùn)營(yíng)成本，提升研發(fā)人員日常工作效率。在具體推廣全鏈路多版本流水線的過(guò)程中也遇到了一些問(wèn)題，如重新搭建基線環(huán)境增加成本，已改為兼容原有測(cè)試環(huán)境替代。當(dāng)前全鏈路流水線建設(shè)還剛剛起步，未來(lái)還有更多空間值得優(yōu)化：

1. 支持更多組件和語(yǔ)言：目前流量隔離已支持了 RPC 層的 HTTP 和 Dubbo 流量，消息中間件的 MQ 組件，對(duì)于其他 RPC 框架，消息中間件組件，或涉及到非 Java 語(yǔ)言應(yīng)用時(shí)，由于使用范圍不普遍，優(yōu)先級(jí)較低，目前還未支持。這項(xiàng)問(wèn)題會(huì)根據(jù)公司業(yè)務(wù)發(fā)展和技術(shù)應(yīng)用流行趨勢(shì)進(jìn)行調(diào)整。
2. 支持?jǐn)?shù)據(jù)邏輯隔離：數(shù)據(jù)的底層存儲(chǔ)通常是 MySQL，Redis，MongoDB 等，因?yàn)闃I(yè)務(wù)場(chǎng)景復(fù)雜，數(shù)據(jù)隔離實(shí)現(xiàn)成本高，暫未實(shí)現(xiàn)邏輯隔離的功能。如業(yè)務(wù)有需求，通常建議準(zhǔn)備多套數(shù)據(jù)庫(kù)使用物理隔離方案，在配置中心創(chuàng)建多套數(shù)據(jù)庫(kù)配置信息方便切換。但是若想業(yè)務(wù)灰度使用更加絲滑，數(shù)據(jù)邏輯隔離還需要具備。
3. 更多應(yīng)用場(chǎng)景：目前全鏈路多服務(wù)流水線只應(yīng)用在測(cè)試環(huán)境部署，如果業(yè)務(wù)使用流量染色的功能更加熟悉和穩(wěn)定，未來(lái)此項(xiàng)特性在線上 A/B 測(cè)試等場(chǎng)景也可支持。