4. MRM 框架下的分流架构：整体架构图、数据层、策略层、实验层、应用层的职责划分
在 MRM（Mature Relationship Management）框架中，A/B 分流并非一个孤立的工具，而是一套贯穿数据、策略、实验与应用的完整架构。本章将自上而下拆解五层职责，帮助团队建立“分层解耦、职责单一”的分流体系。
4.1 整体架构总览
MRM 分流架构采用分层隔离设计，每一层只关注本层核心任务，通过标准化接口向下游传递分流上下文。整体分为五层：
- 数据层：提供用户画像、行为序列与实时特征。
- 策略层：定义分流规则、流量分配比例与白名单。
- 实验层：管理实验生命周期、版本对照与指标注册。
- 应用层：承接分流结果，展示不同实验版本。
- 监控与治理层（贯穿各层）：负责一致性校验、异常告警与数据回刷。
4.2 数据层：分流的基础燃料
数据层负责提供稳定、可复现的分流标识与特征。没有高质量的数据层，上层策略将失去根基。
| 数据组件 | 职责 | 典型技术选型 |
|---|---|---|
| 用户画像宽表 | 提供用户基础属性（城市、等级、注册渠道） | Hive / ClickHouse |
| 行为序列 | 记录用户最近 N 次行为，用于行为分流 | Kafka + Flink |
| 实时特征 | 秒级更新用户状态（在线、活跃度） | Redis / Tair |
| HashID 映射表 | 将 user_id / device_id 映射为 64 位哈希 | MySQL / 本地缓存 |
关键原则：分流标识（HashID）必须在数据层完成归一化，保证同一用户在不同端（Web/App）进入同一实验版本。
4.3 策略层：分流规则的决策中心
策略层是 MRM 分流架构的大脑，负责定义“谁进入哪个实验”以及“流量如何切分”。
- 分流规则引擎：支持按用户属性（城市、等级）、行为（近 7 天活跃）、随机百分比等条件组合。
- 流量比例管理：支持 1% ~ 100% 粒度，支持阶梯灰度放量。
- 白名单机制：内部员工、测试账号、VIP 用户可绕过随机分流，直接进入指定版本。
- 策略缓存：将高频规则缓存至本地或 Redis，避免每次分流都查询数据库。
4.4 实验层：实验生命周期的管理者
实验层负责实验的创建、版本管理、指标注册与状态流转。它是分流架构中与业务方交互最频繁的一层。
| 实验阶段 | 核心操作 | 分流状态 |
|---|---|---|
| 创建 | 定义实验名称、版本数、流量比例 | 未启动 |
| 灰度 | 小流量验证（1% ~ 5%） | 灰度中 |
| 全量 | 放开至 100% 流量 | 运行中 |
| 停止 | 停止分流，保留数据用于分析 | 已停止 |
| 归档 | 清理实验配置，释放资源 | 已归档 |
最佳实践：实验层应提供“一键回滚”能力，当实验版本出现严重负向指标时，立即将流量切回基线版本，无需修改策略层配置。
4.5 应用层：分流结果的最终呈现
应用层是用户直接感知的层面，负责接收实验标签并渲染对应版本。应用层不关心分流逻辑，只关心“当前用户应该看到哪个版本”。
- 前端 SDK：在页面初始化时请求实验标签，动态加载对应 CSS/JS 或组件。
- 后端 API：在接口返回中携带版本标识，前端根据标识展示不同 UI。
- 网关层：在 API 网关统一注入实验上下文，避免各服务重复获取。
- 兜底策略：当实验标签获取失败时，默认展示基线版本，保证用户体验不受影响。
4.6 各层职责对比总结
| 层级 | 核心职责 | 不做什么 | 典型故障 |
|---|---|---|---|
| 数据层 | 提供稳定、一致的分流标识与特征 | 不参与规则判断 | HashID 冲突导致分流不均匀 |
| 策略层 | 定义分流规则、比例与白名单 | 不管理实验生命周期 | 规则缓存未刷新导致分流失效 |
| 实验层 | 管理实验版本、指标与状态 | 不执行实时分流计算 | 实验状态与分流规则不一致 |
| 应用层 | 接收标签并渲染对应版本 | 不存储分流规则 | 标签传递丢失导致展示默认版本 |
| 监控治理层 | 一致性校验、异常告警、数据回刷 | 不干预正常分流流程 | 告警阈值设置不合理导致误报 |
常见误区：将策略层与实验层混为一谈，导致“改实验比例需要同时修改策略配置和实验配置”，增加出错概率。MRM 架构强制要求两层职责分离，策略层只负责“怎么分”，实验层只负责“分给谁”。