4、流量染色与标记：HTTP Header染色、Cookie标记、请求参数标记的实现方式
在压力测试场景下，A/B 分流的核心前提是能够精准识别并区分不同实验组的流量。流量染色与标记技术通过在请求路径上附加标识信息，使负载均衡器、网关或后端服务能够根据标记将流量路由到对应的实验版本。本章详细阐述三种主流标记方式的实现原理、配置示例及适用场景。
核心原则：流量标记必须在请求入口处完成，且标记信息需在整个调用链中透传，避免因中间件丢失标记导致分流错误。
4.1 三种标记方式对比
| 标记方式 | 存储位置 | 生命周期 | 透传难度 | 典型场景 |
|---|---|---|---|---|
| HTTP Header 染色 | 请求头部 | 单次请求 | 低（需网关/代理转发） | API 网关、微服务间路由 |
| Cookie 标记 | 客户端 Cookie | 会话级（可持久化） | 中（需考虑跨域） | Web 页面、浏览器端实验 |
| 请求参数标记 | URL Query / Body | 单次请求 | 低（显式传递） | CDN 回源、静态资源实验 |
4.2 HTTP Header 染色
HTTP Header 染色通过在请求头中插入自定义字段（如 X-Ab-Test、X-Experiment-Id）来标记流量。该方式对客户端透明，适合在网关层或反向代理层统一注入。
4.2.1 Nginx 层注入示例
# 在 Nginx 配置中根据分流规则注入 Header
map $cookie_user_id $ab_group {
default "control";
~^[a-m] "variant_a";
~^[n-z] "variant_b";
}
server {
listen 80;
location / {
proxy_set_header X-Ab-Test $ab_group;
proxy_pass http://backend;
}
}4.2.2 网关层（Kong / APISIX）注入示例
# 使用 APISIX 的 serverless-pre-function 插件
local ab_router = require("ab_router")
function(conf, ctx)
local user_id = ctx.var.arg_user_id or ctx.var.http_cookie
local group = ab_router.route(user_id)
ctx.var.upstream_header_X_Ab_Test = group
end
最佳实践：Header 染色应使用
X- 前缀的自定义字段，并在网关层统一管理，避免后端服务各自为政导致标记冲突。
4.3 Cookie 标记
Cookie 标记将实验分组信息存储在客户端浏览器中，适用于需要保持用户会话内实验一致性（sticky session）的场景。标记通常通过 Set-Cookie 响应头写入，后续请求自动携带。
4.3.1 服务端写入 Cookie 示例（Go）
func setAbCookie(w http.ResponseWriter, r *http.Request) {
userID := getUserID(r)
group := abRouter.AssignGroup(userID)
http.SetCookie(w, &http.Cookie{
Name: "ab_group",
Value: group,
Path: "/",
MaxAge: 86400 * 30, // 30天有效期
HttpOnly: true,
SameSite: http.SameSiteLaxMode,
})
// 后续处理
}4.3.2 前端 JavaScript 读取与上报
// 读取 Cookie 中的实验分组
function getAbGroup() {
const match = document.cookie.match(/(?:^|;\s*)ab_group=([^;]*)/);
return match ? match[1] : 'control';
}
// 上报实验数据时携带分组信息
fetch('/api/analytics', {
method: 'POST',
headers: { 'Content-Type': 'application/json' },
body: JSON.stringify({
event: 'page_view',
ab_group: getAbGroup()
})
});
注意：Cookie 标记需考虑跨域问题（SameSite 属性）、隐私合规（GDPR/CCPA）以及 Cookie 大小限制（4KB）。对于高并发压测场景，建议使用 HttpOnly 和 Secure 标志增强安全性。
4.4 请求参数标记
请求参数标记将实验分组信息附加在 URL 查询字符串（Query String）或 POST 请求体中。该方式实现简单，适合 CDN 回源、静态资源分发等无法修改 Header 的场景。
4.4.1 URL Query 参数标记示例
# 原始 URL
https://api.example.com/v1/products?page=1
# 携带 A/B 标记的 URL
https://api.example.com/v1/products?page=1&ab_group=variant_a4.4.2 后端解析示例（Python Flask）
from flask import Flask, request
app = Flask(__name__)
@app.route('/v1/products')
def get_products():
ab_group = request.args.get('ab_group', 'control')
if ab_group == 'variant_a':
# 返回实验版本 A 的数据
return get_products_variant_a()
else:
return get_products_control()
适用场景：请求参数标记特别适合 CDN 缓存场景——不同实验组的资源可通过不同 URL 缓存，避免缓存污染。但需注意 URL 长度限制（通常 8KB），避免参数过多导致请求被截断。
4.5 流量标记透传架构
在微服务或分布式系统中，流量标记需要在多个服务间透传。下图展示了从客户端到后端服务的完整标记传递链路。
4.6 标记冲突与优先级规则
当同一请求同时携带多种标记方式时，需要定义明确的优先级规则，避免分流逻辑混乱。
| 优先级 | 标记来源 | 处理规则 |
|---|---|---|
| 1（最高） | 请求参数（Query） | 显式指定，覆盖其他标记 |
| 2 | HTTP Header | 网关注入，优先级高于 Cookie |
| 3（最低） | Cookie | 仅当无其他标记时生效 |
压测建议：在压力测试场景中，建议统一使用 HTTP Header 染色方式，避免依赖客户端 Cookie（压测工具可能不维护 Cookie 状态）或 URL 参数（可能被缓存污染）。使用 wrk 或 locust 等工具时，通过自定义 Header 注入实验标记，确保分流稳定可重复。
4.7 实现方式总结
三种流量标记方式各有优劣，实际生产环境中常组合使用：
- 入口层：使用 Cookie 标记保持用户会话一致性，同时通过 URL 参数支持调试和强制指定分组。
- 网关层：统一转换为 HTTP Header 透传，简化后端服务处理逻辑。
- 服务间：通过 RPC 框架的上下文机制（如 gRPC Metadata、Dubbo Attachment）继续透传标记。
选择标记方式时，需综合考虑客户端兼容性、透传链路长度、安全合规要求以及压测工具的模拟能力，确保在高压流量下标记不丢失、不冲突。