3. 分层架构设计：常见的分层架构模式
在实验评估体系中，分层架构是支撑大规模、高并发、多业务线并行试验的核心基础设施。合理的分层设计能够隔离流量、降低耦合、提升评估精度。本节将系统讲解三种主流分层模式及其职责划分，并给出可落地的架构图。
3.1 垂直分层架构
垂直分层（Vertical Layering）是最基础的分层模式，按照“请求链路”或“技术栈”自上而下切分。每一层只与相邻层交互，职责单一、边界清晰。
| 层级 | 典型组件 | 核心职责 |
|---|---|---|
| 接入层 | 负载均衡、API 网关 | 流量分发、身份校验、限流熔断 |
| 应用层 | 业务服务、试验 SDK | 业务逻辑编排、试验分流、埋点触发 |
| 数据层 | 数据库、缓存、消息队列 | 数据持久化、状态存储、异步处理 |
适用场景：中小规模业务、单产品线、试验流量 < 10 万 QPS。优点是结构简单、易于排查；缺点是层间耦合较紧，某一层变更可能影响上下游试验。
3.2 水平分层架构
水平分层（Horizontal Layering）按“业务域”或“流量属性”横向切分，每个水平层独立承载完整链路。常见于多业务线、多端（App / H5 / 小程序）并行试验的场景。
- 业务域层： 搜索、推荐、广告、用户增长等各自独立分层，互不干扰。
- 流量属性层： 新用户 / 老用户、付费用户 / 免费用户、iOS / Android 等按属性切分。
- 试验域层： 每个试验域拥有独立的 Hash 空间和参数配置，避免跨域污染。
最佳实践：水平分层后，每个分层内部仍需保持垂直分层结构（接入 → 应用 → 数据），形成“分层中的分层”。
3.3 混合分层架构
混合分层（Hybrid Layering）结合垂直与水平两种模式，在大型互联网公司中最为常见。它既保留了垂直分层的链路清晰度，又通过水平分层实现了业务隔离和流量精细化管控。
混合分层的核心设计原则：
- 全局垂直分层：接入层 → 路由层 → 计算层 → 存储层，作为通用骨架。
- 业务水平分层：在计算层内部，按业务域拆分为多个水平子层。
- 试验专属层：在路由层与计算层之间插入“试验决策层”，统一处理分流、参数下发和埋点。
3.4 各层职责划分
无论采用哪种分层模式，以下核心层的职责必须明确：
| 层名称 | 职责描述 | 关键产出物 |
|---|---|---|
| 流量接入层 | 接收客户端请求，完成 SSL 卸载、限流、路由转发 | 请求上下文、设备指纹 |
| 试验决策层 | 根据用户 ID / 设备 ID 计算 Hash，匹配试验分组，下发参数 | 试验分组标识、参数配置 |
| 业务计算层 | 执行业务逻辑，根据试验参数走不同分支 | 业务结果、行为日志 |
| 数据采集层 | 收集埋点事件，清洗、聚合、写入数据仓库 | 原始事件表、聚合指标 |
| 评估分析层 | 计算核心指标，执行假设检验，生成评估报告 | 置信区间、P 值、效应量 |
3.5 架构图绘制
以下 SVG 图展示混合分层架构的核心组件与数据流向，包含 7 个核心节点和 6 条连接线，体现垂直与水平分层的融合关系。
3.6 分层设计避坑清单
常见陷阱：
- 层间泄漏： 业务层直接读取数据层原始表，绕过采集层，导致指标口径不一致。
- 试验决策层下沉： 将分流逻辑写在业务代码中，导致后续无法统一管控和审计。
- 水平分层过细： 每个业务域独立部署试验决策服务，造成资源浪费和配置混乱。
- 忽略回流路径： 只关注请求下行，忽略数据采集和评估分析的上行链路，导致评估延迟。
选择分层架构时，建议从垂直分层起步，随着业务复杂度提升逐步引入水平分层。混合分层虽灵活，但需要配套的配置中心和监控体系，否则容易陷入“分层越多、排查越难”的困境。