4. 统一权限中心设计：职责边界、鉴权服务分层、策略存储、缓存策略、高可用设计
统一权限中心是整个模块间权限隔离体系的核心枢纽。它不再将鉴权逻辑分散在各个业务模块中，而是将权限判定、策略存储、凭证管理收敛为一个独立的基础设施层。本章将围绕其职责边界、服务分层、策略存储模型、缓存加速手段以及高可用保障展开，帮助团队在落地时明确边界、避免职责过载。
4.1 职责边界：权限中心该管什么、不该管什么
核心原则：权限中心只回答“谁（主体）能否对什么（资源）执行什么操作（动作）”，不负责业务逻辑编排、用户注册、组织架构管理等非鉴权行为。
| 职责域 | 属于权限中心 | 不属于权限中心 |
|---|---|---|
| 身份认证 | 令牌校验、OAuth 2.0 令牌颁发与验签 | 密码复杂度校验、用户注册流程 |
| 授权判定 | 策略评估引擎、角色/属性解析 | 业务工作流审批、数据二次过滤 |
| 策略管理 | 策略 CRUD、策略版本、生效范围 | 策略合规审计报表（可委托给审计系统） |
| 会话管理 | 令牌生命周期、刷新令牌轮转 | 客户端会话持久化 |
常见越界：部分团队将“用户组织树”或“应用配置”也放入权限中心，导致权限中心与用户中心、配置中心职责混淆。严格遵循单一职责，权限中心仅存储与鉴权/授权相关的映射关系。
4.2 鉴权服务分层：控制面、数据面与策略引擎
统一权限中心内部可按职责切分为三个分层，各层独立部署、独立扩容。
- 控制面（Control Plane）： 提供策略管理API、令牌管理API、客户端注册与密钥轮换。属于管理流量，QPS低但对一致性要求高。
- 数据面（Data Plane）： 提供高性能鉴权判定API，只读为主，响应时间需控制在 5ms 以内。通常部署在业务模块附近或通过Sidecar注入。
- 策略引擎（Policy Engine）： 负责策略模型解析（RBAC/ABAC/PBAC）和规则评估。该层可以内嵌在数据面进程中，也可以独立进程部署，取决于策略评估复杂度。
分层收益：控制面与数据面分离后，策略变更不直接影响线上鉴权抖动；数据面可基于缓存做到毫秒级响应，控制面则可采取更为保守的强一致性存储。
4.3 策略存储模型与选型权衡
策略存储的核心是“权限策略的持久化与版本管理”。不同策略模型对存储的要求差异显著。
| 模型 | 存储方案 | 优点 | 局限 |
|---|---|---|---|
| RBAC (基于角色) | 关系型数据库（角色表、权限表、用户角色关联表） | 查询模式简单，事务易实现 | 角色数量多时关联表膨胀 |
| ABAC (基于属性) | 文档型数据库或策略引擎专有格式（如 Rego、OPA） | 策略表达灵活，支持动态属性 | 策略评估性能高度依赖引擎实现 |
| PBAC (基于策略) | 可扩展的 KV 或图数据库 | 细粒度控制，适合混合模型 | 运维复杂度高于 RBAC |
落地建议：对于大部分业务场景，建议以 RBAC 作为核心模型，以 PBAC 或 ABAC 作为策略溢出补充。存储层采用关系型数据库（如 PostgreSQL）来保障策略变更的事务性，同时在内存中预热高频策略缓存。
4.4 缓存策略：分级缓存与一致性保障
权限判定的性能瓶颈通常在于策略加载与令牌验证。缓存是数据面性能的基石。
- 一级缓存（本地内存）： 每个数据面节点缓存最近最常访问的策略条目或令牌黑名单。生命周期短（30-60秒），用于抵御突发热点。
- 二级缓存（分布式，如 Redis）： 缓存全量策略摘要、用户角色映射、令牌有效性。TTL 依据策略变更频率设定，默认 5-15 分钟。
- 缓存失效机制： 控制面在策略变更时主动发送失效消息（通过消息队列或 Redis Pub/Sub），数据面监听后驱逐本地缓存。不能仅依赖 TTL，否则存在最长 TTL 的过期时间内权限不一致。
# redis 策略缓存 key 设计示例
策略条目: policy:{policy_id}
用户角色: user:{user_id}:roles
角色权限: role:{role_id}:permissions
令牌有效: :{_id}:valid # 0 表示已吊销
一致性问题：缓存 + 数据库的组合模型在极端场景下可能出现“策略已变更但缓存未清空”的情况。建议控制面采用“先写数据库，再发失效消息”，数据面收到消息后主动重新拉取策略。如果消息丢失，TTL 兜底恢复一致性。
4.5 高可用设计
权限中心一旦故障，整个系统的授权行为都会瘫痪。高可用设计需要从控制面、数据面、策略存储三个维度分别考虑。
- 控制面无状态化： 控制面所有写操作最终落到存储层；控制面实例本身不持有持久状态，可通过水平扩展应对管理流量峰值。
- 数据面多副本 + 就近部署： 数据面在每个可用区部署至少 2 个实例，并优先返回本可用区缓存；当缓存 miss 时，回源到策略存储或控制面。
- 策略存储高可用： 采用主从复制或分布式共识协议（如 Raft）存储策略。建议使用 PostgreSQL 流复制 + Patroni 做自动故障切换，或使用 Etcd/ZooKeeper 存储策略快照（适用于 PBAC 场景）。
- 优雅降级能力： 当策略存储完全不可用时，缓存仍能持续提供权限判定（缓存生存期内）。如果缓存也失效，数据面应返回“deny”并记录审计日志，避免在不确定状态下允许访问。
稳定性指标： 鉴权数据面 API 可用性需达到 99.995%，单次判定 P99 延迟 ≤ 10ms。控制面可用性可放宽至 99.99%，但策略变更的延迟需要保障在 30 秒内同步至所有数据面缓存。
4.6 落地步骤与验收标准
统一权限中心的建设应分阶段推进，而非大爆炸式上线。
- Phase 1 - 最小闭环： 部署控制面与数据面，使用 RBAC 模型，策略存储在 PostgreSQL，缓存只用 Redis 二级缓存。
- Phase 2 - 性能加固： 引入本地一级缓存、控制面与数据面分层部署、缓存失效机制。
- Phase 3 - 高可用与治理： 多可用区部署、自动故障转移、优雅降级、策略变更灰度。
验收标准（Checklist）：
| 验收项 | 预期结果 | 验证方式 |
|---|---|---|
| 鉴权判定延迟 | P99 ≤ 10ms（含缓存命中） | 压测脚本爬坡至 10000 QPS |
| 策略变更生效时间 | 变更后 30 秒内数据面全部生效 | CT 工具修改策略并观察数据面日志 |
| 数据面故障转移 | 单实例下线，流量 5 秒内切换成功 | Chaos Engineering 随机杀进程 |
| 策略存储主备切换 | 写操作中断 < 10 秒 | 模拟主库宕机 |
4.7 风险点与避坑指南
常见陷阱：将“组织架构”或“应用元数据”强耦合进权限中心策略存储。当组织架构变化频繁时，策略评估性能会因为属性解析而急剧下降。解决方案：权限中心只存储与鉴权直接相关的属性，非鉴权属性通过配置中心或注册中心订阅。
另外，缓存失效方案不要只依赖消息队列。消息队列本身可能出现堆积或重复消费，建议在数据面引入轮询兜底（每 2 分钟全量对比策略版本号），确保极端情况下缓存最终一致。