3. 分流架构总览:整体技术架构图
金融压力测试的 A/B 分流并非单一模块,而是一套贯穿网关、路由、业务处理与数据存储的完整技术栈。每一层承担不同的分流职责,层与层之间通过标准协议与上下文传递实现流量标记与隔离。本节从四层视角拆解整体架构,并给出各层的核心组件与交互关系。
架构设计原则: 分层解耦、流量无损、上下文透传、可观测性全覆盖。
3.1 四层架构总览
整体架构自顶向下分为 网关层、路由层、业务层 与 数据层。每一层只关注本层职责,通过统一的 X-AB-Trace-Id 与 X-AB-Group 头实现分流上下文的端到端传递。
| 架构层 | 核心职责 | 典型组件 | 分流关键动作 |
|---|---|---|---|
| 网关层 | 统一入口、协议转换、安全校验 | Kong / APISIX / Nginx + Lua | 解析分流标识,注入请求头 |
| 路由层 | 流量分发、版本匹配、灰度策略 | Spring Cloud Gateway / Envoy | 按 A/B 组路由到不同服务版本 |
| 业务层 | 业务逻辑执行、压测指标采集 | 微服务实例(Java / Go) | 根据分组执行不同策略分支 |
| 数据层 | 读写隔离、影子表、压测数据标记 | MySQL Proxy / Redis Cluster | 按分组路由到影子库或影子表 |
3.2 网关层:分流标识的入口锚点
网关层是流量的第一站,也是分流标识的 注入点。所有外部请求到达网关后,网关根据预配置的分流规则(如用户 ID 哈希、随机百分比、地域白名单)决定该请求属于 A 组还是 B 组,并将分组标识写入请求头。
- 标识注入: 在网关层通过 Lua 脚本或插件机制生成
X-AB-Group头,值为A或B。 - 链路追踪: 同时生成
X-AB-Trace-Id,用于全链路日志串联。 - 降级策略: 当路由层或业务层异常时,网关可强制将流量全部切回 A 组(基线版本)。
最佳实践: 网关层不要做复杂的业务路由判断,只做分组标识的生成与注入。分组规则应配置在配置中心,支持热更新。
3.3 路由层:流量分发与版本匹配
路由层接收网关层传递过来的请求,根据 X-AB-Group 的值将流量分发到对应的服务版本实例。路由层维护一份 版本-实例映射表,确保 A 组流量只到达 A 版本实例,B 组流量只到达 B 版本实例。
| 路由策略 | 适用场景 | 实现方式 |
|---|---|---|
| 版本路由 | 新旧版本对比压测 | 根据请求头匹配服务版本标签 |
| 权重路由 | 灰度发布 + 压测混合 | 按百分比分配流量到不同版本 |
| 一致性哈希 | 需要会话保持的场景 | 对用户 ID 哈希后固定路由到某版本 |
3.4 业务层:策略分支与指标采集
业务层是分流逻辑的 执行端。微服务实例在收到请求后,从请求头中提取 X-AB-Group,根据分组值执行不同的业务策略分支。同时,业务层负责采集压测指标,如响应时间、错误率、资源消耗等。
// 业务层分流策略示例(Java)
public Response handleRequest(Request request) {
String abGroup = request.getHeader("X-AB-Group");
if ("B".equals(abGroup)) {
// B 组执行新版本策略
return executeNewStrategy(request);
} else {
// A 组执行基线策略
return executeBaselineStrategy(request);
}
}
注意: 业务层不要修改
X-AB-Group 的值,该值应保持只读。任何修改都会导致下游数据层路由错乱。
3.5 数据层:影子库与读写隔离
数据层是分流架构中 最容易出问题 的一层。压测流量产生的数据不能污染生产数据,因此需要引入影子库或影子表机制。数据层根据 X-AB-Group 将读写请求路由到对应的数据源。
- 影子库模式: 为 B 组单独创建一套数据库实例,所有 B 组流量读写影子库。
- 影子表模式: 在生产库中创建带
_shadow后缀的表,B 组流量操作影子表。 - Redis 隔离: 使用不同的 key 前缀或单独的 Redis 集群存储压测数据。
3.6 层间上下文传递契约
分流上下文在四层之间传递时,必须遵循统一的契约规范,否则会导致路由错乱或数据污染。
| 上下文字段 | 传递方式 | 生命周期 | 是否可修改 |
|---|---|---|---|
X-AB-Group |
HTTP Header / RPC Attachment | 全链路 | 只读(网关注入后不可修改) |
X-AB-Trace-Id |
HTTP Header / RPC Attachment | 全链路 | 只读 |
X-AB-Rule-Version |
HTTP Header | 网关层 → 路由层 | 只读 |
X-AB-Data-Isolate |
HTTP Header / 数据库连接参数 | 业务层 → 数据层 | 业务层可设置 |
关键约束: 任何层都不允许删除或覆盖
X-AB-Group 头。如果某层需要临时修改分组,必须使用 X-AB-Group-Override 头,且仅在调试模式生效。
3.7 架构总结与关键指标
四层分流架构的核心在于 每层职责单一、上下文透传无损耗、数据隔离无污染。在压力测试场景下,需要额外关注以下指标:
- 分流延迟: 网关层注入标识到业务层获取标识的总耗时,应 < 5ms。
- 路由准确率: A 组流量到达 A 版本实例的比例,目标 100%。
- 数据隔离率: B 组流量写入影子库的比例,目标 100%,不允许出现写生产库的情况。
- 上下文丢失率: 全链路中
X-AB-Group丢失的请求比例,应 < 0.01%。
架构验证: 在正式压测前,建议先做一次全链路的分流预演,逐层检查上下文传递是否完整、数据隔离是否生效。