3. Feature Flag 架构基础
Feature Flag 并非一个简单的“if-else”开关，而是一套由控制平面与数据平面构成的分布式系统。理解其架构是分析开关延迟、定位 MTTR 瓶颈的前提。本节从系统架构图、开关评估流程、客户端-服务端交互模型三个维度展开。
3.1 Feature Flag 系统架构图
一个生产级的 Feature Flag 系统通常包含以下核心组件：
核心组件清单：
- 管理控制台（Admin UI）： 供开发/运维/产品人员创建、配置、灰度、下架开关。
- Flag 配置中心（Flag Config Service）： 存储开关元数据、目标规则、变体值，通常基于分布式 KV 存储（如 etcd/Redis）或数据库。
- 评估引擎（Evaluation Engine）： 服务端核心，根据传入的实体上下文（用户 ID、地域、设备等）匹配规则，返回最终变体。
- SDK / Agent： 嵌入业务应用，负责拉取配置、本地缓存、执行评估、上报事件。
- 数据管道（Data Pipeline）： 收集开关曝光、结果、延迟等埋点，用于监控与复盘。
3.2 开关评估流程
一次完整的开关评估并非简单的“开/关”判断，而是经过多层规则匹配。评估流程的每个环节都可能引入延迟，是 MTTR 复盘的关键分析对象。
| 步骤 | 操作 | 延迟敏感点 |
|---|---|---|
| 1 | 上下文提取：从请求中提取用户 ID、分组、地域、设备等属性 | 属性解析耗时、缺失属性导致回退 |
| 2 | 目标匹配：遍历开关的 targeting rules，匹配第一个满足条件的规则 | 规则数量过多、复杂条件（如正则） |
| 3 | 变体分配：根据匹配到的规则，返回对应的变体值（如 true/false、A/B 组） | 动态分配算法（如一致性哈希）计算 |
| 4 | 本地缓存命中：若 SDK 已缓存评估结果，直接返回 | 缓存未命中、缓存过期、缓存穿透 |
| 5 | 远程评估回退：本地无缓存时，同步/异步请求服务端评估 | 网络 RTT、服务端负载、超时设置 |
MTTR 复盘提示： 在复盘开关延迟时，应首先区分“本地评估”与“远程评估”。若延迟主要来自远程评估，则需重点排查网络抖动、服务端配置中心压力或 SDK 缓存策略。
3.3 客户端与服务端交互模型
客户端（SDK）与服务端（Flag 配置中心 + 评估引擎）的交互方式直接影响开关评估的延迟特征。主流模型分为以下三种：
3.4 交互模型对延迟的影响
不同的交互模型直接决定了“开关变更”到“业务生效”之间的延迟窗口。在 MTTR 复盘口径中，需要明确记录当前系统采用的模型及其关键参数：
- 拉模式关键参数： 轮询间隔（pollingInterval）、随机延迟偏移（jitter）、全量拉取 vs 增量拉取。
- 推模式关键参数： 长连接类型（WebSocket / SSE / gRPC Stream）、心跳间隔、重连策略。
- 混合模式关键参数： 推模式优先级、拉模式兜底间隔、本地缓存版本号校验逻辑。
常见陷阱： 部分 SDK 默认使用拉模式且轮询间隔为 30 秒。若未在复盘时识别此配置，会将“开关已变更但业务未生效”的 30 秒空窗期误判为系统故障，导致 MTTR 虚高。复盘时务必先确认交互模型与轮询间隔。
3.5 架构视角的 MTTR 复盘要点
基于上述架构基础，在复盘开关延迟时，应按照以下维度拆解：
| 复盘维度 | 检查项 | 常见延迟来源 |
|---|---|---|
| 配置下发 | 交互模型、轮询间隔、长连接状态 | 轮询间隔过长、连接断开未重连 |
| 本地缓存 | 缓存策略、TTL、预热机制 | 缓存未命中、缓存雪崩 |
| 评估引擎 | 规则数量、规则复杂度、评估超时 | 规则过多、正则回溯、远程评估超时 |
| 数据管道 | 埋点上报延迟、采样率、队列积压 | 上报队列阻塞、采样导致数据缺失 |