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 按分组路由到影子库或影子表
金融压力测试 A/B 分流四层架构总览 网关层(Gateway Layer) 统一入口 · 协议转换 · 安全校验 · 分流标识注入 组件:Kong / APISIX / Nginx + Lua 路由层(Routing Layer) 流量分发 · 版本匹配 · 灰度策略 · 上下文透传 组件:Spring Cloud Gateway / Envoy 业务层(Business Layer) 业务逻辑执行 · 压测指标采集 · 策略分支 组件:微服务实例(Java / Go) 数据层(Data Layer) 读写隔离 · 影子表 · 压测数据标记 · 分组路由 组件:MySQL Proxy / Redis Cluster 上下文透传:X-AB-Trace-Id + X-AB-Group 贯穿四层 每层只做本层职责,不跨层耦合

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 集群存储压测数据。
数据层分流路由:影子库与影子表 数据访问请求 X-AB-Group 判断 A 组 生产库 B 组 影子库 影子库模式:B 组使用独立数据库实例,数据完全隔离 影子表模式:B 组使用生产库中的 _shadow 后缀表 Redis 隔离:B 组使用不同 key 前缀或独立集群

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%。
架构验证: 在正式压测前,建议先做一次全链路的分流预演,逐层检查上下文传递是否完整、数据隔离是否生效。