4. Feature Flag 架构设计：Flag管理服务、SDK集成、本地缓存与远程同步、高可用设计

Feature Flag 架构是灰度发布系统的核心骨架。一个生产级的 Feature Flag 系统需要同时解决 集中管理、运行时决策、性能开销 和 故障容错 四个关键问题。本章从架构分层出发，逐一拆解 Flag 管理服务、SDK 集成、本地缓存与远程同步机制，以及高可用设计策略。

4.1 整体架构分层

Feature Flag 系统通常采用 控制面（Control Plane） 与 数据面（Data Plane） 分离的架构。控制面负责 Flag 的创建、配置、发布和审计；数据面负责在应用运行时高效获取 Flag 状态并做出决策。

4.2 Flag 管理服务

Flag 管理服务是控制面的核心组件，负责所有 Feature Flag 的 生命周期管理。它提供统一的 RESTful API 和 Web UI，供开发者和运维人员操作。

4.2.1 核心功能模块

4.2.2 数据模型设计要点

Flag 管理服务的数据模型需要兼顾 查询效率 和 历史追溯。推荐采用 主表 + 变更日志表 的双表设计：

• flag_definitions 表： 存储当前生效的 Flag 配置，包含 key、name、variations、rules、status 等字段。
• flag_changelog 表： 存储每次变更的完整快照，用于审计和回滚。
• flag_targeting_rules 表： 存储条件规则，支持 AND/OR 嵌套逻辑。

-- 简化版 Flag 定义表结构
CREATE TABLE flag_definitions (
    id          BIGSERIAL PRIMARY KEY,
    project_id  BIGINT NOT NULL,
    key         VARCHAR(128) NOT NULL UNIQUE,
    name        VARCHAR(256),
    description TEXT,
    variations  JSONB NOT NULL,          -- [{"id":"on","value":true}, {"id":"off","value":false}]
    rules       JSONB,                   -- 目标规则配置
    status      VARCHAR(20) DEFAULT 'inactive',  -- inactive | active | archived
    version     INT NOT NULL DEFAULT 1,
    created_by  VARCHAR(64),
    updated_at  TIMESTAMP WITH TIME ZONE DEFAULT NOW(),
    UNIQUE(project_id, key)
);

-- 变更日志表
CREATE TABLE flag_changelog (
    id          BIGSERIAL PRIMARY KEY,
    flag_id     BIGINT NOT NULL REFERENCES flag_definitions(id),
    version     INT NOT NULL,
    snapshot    JSONB NOT NULL,          -- 变更时的完整 Flag 快照
    operator    VARCHAR(64),
    operation   VARCHAR(20),             -- create | update | delete | rollback
    created_at  TIMESTAMP WITH TIME ZONE DEFAULT NOW()
);

4.3 SDK 集成与本地缓存

SDK 是数据面的核心组件，嵌入到业务应用中。它的职责是：从远程同步 Flag 配置，在本地缓存中决策，并返回 Flag 的最终值。

4.3.1 SDK 核心接口

4.3.2 本地缓存策略

本地缓存是 SDK 性能的关键。推荐采用 两级缓存 架构：

• 一级缓存（L1）： 使用 ConcurrentHashMap 或 CopyOnWriteArrayMap，存储最近访问的 Flag 值。TTL 设置为 5~30 秒。
• 二级缓存（L2）： 使用本地文件或嵌入式数据库（如 RocksDB），存储全量 Flag 配置。用于 SDK 重启后快速恢复，避免冷启动时大量请求穿透到远程服务。

4.4 远程同步机制

远程同步负责将控制面的 Flag 变更实时或准实时地推送到所有 SDK 实例。常见的同步方式有三种：

生产环境推荐 WebSocket + 定期轮询 的双通道策略：WebSocket 负责实时推送，轮询作为兜底机制，防止 WebSocket 连接意外断开导致配置滞后。

4.5 高可用设计

Feature Flag 系统的高可用设计需要覆盖 控制面 和 数据面 两个层面。数据面的高可用优先级更高，因为 Flag 决策直接影响线上业务。

4.5.1 数据面高可用策略

• 本地缓存兜底： 当远程同步服务不可用时，SDK 继续使用本地缓存的 Flag 配置。即使缓存过期，也返回最后一次成功同步的值，而不是抛出异常。
• 默认值策略： 每个 Flag 在 SDK 中配置一个 静态默认值。当本地缓存为空且远程不可达时，返回默认值（通常为关闭状态）。
• 熔断与降级： SDK 对远程同步请求实施熔断机制。连续失败超过阈值（如 3 次）后，暂停重试 30 秒，避免雪崩。
• 多副本部署： 同步服务至少部署 2 个副本，通过负载均衡分发 SDK 请求。

4.5.2 控制面高可用策略

4.5.3 故障场景与应对

下表总结了常见故障场景及系统行为：

4.6 架构设计总结

一个生产级的 Feature Flag 架构需要做到：

• 控制面与数据面分离： 控制面负责管理，数据面负责决策，两者通过同步服务解耦。
• 本地缓存优先： SDK 始终优先读取本地缓存，远程同步仅用于更新缓存。
• 多通道同步： WebSocket 实时推送 + 轮询兜底，确保配置及时生效。
• 韧性设计： 任何远程组件故障都不应导致业务应用崩溃，本地缓存和默认值是最后防线。