3、基于角色的访问控制（RBAC）：角色定义与继承、角色爆炸问题、动态角色分配、RBAC在微服务中的落地
RBAC 这东西，说白了就是「把权限打包成角色，再把角色分配给用户」。听起来简单吧？但我在实际项目里见过太多翻车案例了。有的团队角色定义得比公司组织架构还复杂，有的被角色爆炸搞得运维想骂娘。这一章，咱们就把 RBAC 的核心问题掰开揉碎聊清楚。
3.1 角色定义与继承：别把角色当职位用
很多新手容易犯一个错——把「角色」直接映射成「职位」。比如「高级工程师」是一个角色，「初级工程师」是另一个角色。你想想看，这俩角色在权限上真的有本质区别吗？
我个人的习惯是：角色应该描述「能做什么」，而不是「是谁」。比如「代码审核员」「部署操作员」「只读用户」——这些才是真正的角色。
角色继承：省事但别滥用
角色继承能减少重复定义。比如「超级管理员」继承「普通管理员」的所有权限，再加一个「系统配置」权限。这在 RBAC 标准模型（RBAC1）里是支持的。
核心原则：继承关系应该是「is-a」关系，而不是「has-a」关系。子角色必须能完全替代父角色。
举个例子：
角色: 只读用户
- 权限: 查看仪表盘, 查看日志
角色: 运维工程师 (继承 只读用户)
- 权限: 重启服务, 查看配置
- 额外: 修改告警规则
角色: 超级运维 (继承 运维工程师)
- 权限: 所有运维权限 + 删除服务
我在项目中遇到过有人把继承搞成三层以上，结果一个角色改了权限，下面一串角色跟着受影响。嗯，这里要注意：继承层级建议不超过两层，否则权限审计会变成噩梦。
3.2 角色爆炸问题：为什么你的角色会失控？
角色爆炸是 RBAC 最经典的坑。我记得有个客户，上线半年后角色数量从 20 个膨胀到 300 多个。为什么会这样？
- 粒度太细：每个微服务都定义一套独立角色，服务之间没有复用
- 临时需求直接加角色：「张三需要看这个报表，给他建个角色吧」——然后这个角色永远没人清理
- 权限组合爆炸：10 个权限点，两两组合就是 45 种角色
避坑指南：我曾经见过一个系统，角色数量超过 500 个，最后没人说得清每个角色到底有什么权限。运维同学每次分配权限都要翻半天文档。这已经不是 RBAC 了，这是 R(andom)BAC。
怎么治？
- 角色收敛策略：定期清理 90 天内未分配的角色
- 权限分组：把细粒度权限先聚合成「权限包」，角色只关联权限包
- 角色模板化：定义基础角色模板，微服务按需继承
| 策略 | 适用场景 | 我踩过的坑 |
|---|---|---|
| 角色收敛 | 长期运行的老系统 | 清理时忘了通知业务方，导致用户权限丢失 |
| 权限分组 | 权限点超过 50 个的系统 | 分组粒度太粗，又回到了粗粒度控制 |
| 角色模板 | 多租户或多服务场景 | 模板更新后，子角色没有自动同步 |
3.3 动态角色分配：让权限跟着上下文走
静态角色分配有个硬伤——角色一旦分配，除非手动改，否则永远不变。但在实际业务里，权限往往需要跟着时间、地点、风险等级变化。
比如：
- 普通工作时间（9:00-18:00）可以执行敏感操作
- 非工作时间需要二次审批才能获得临时角色
- 从内网访问时拥有完整权限，从外网访问时降级为只读
这就是动态角色分配要解决的问题。我建议的做法是：保留基础角色，用策略引擎动态叠加或降级权限。
实战技巧：别在 RBAC 引擎里硬编码动态逻辑。把动态规则抽到独立的策略引擎里，比如 OPA（Open Policy Agent）或者自研的规则引擎。RBAC 只负责「静态角色定义」，动态部分交给策略引擎。
举个例子：
// 伪代码：动态角色分配策略
if (user.role == "运维工程师" &&
request.time between "09:00" and "18:00" &&
request.source == "内网") {
grant("执行高危操作");
} else if (user.role == "运维工程师" &&
request.time outside "09:00-18:00") {
require("二级审批");
grant("执行高危操作", "临时", expireIn=4h);
} else {
deny("执行高危操作");
}
3.4 RBAC 在微服务中的落地：别让权限变成分布式灾难
微服务架构下，RBAC 的落地难度直接翻倍。每个服务都有自己的权限需求，但你又不能在每个服务里都搞一套独立的 RBAC——那角色爆炸会来得更快。
架构选型：集中式 vs 分布式
| 方案 | 优点 | 缺点 | 我推荐吗？ |
|---|---|---|---|
| 集中式权限服务 | 统一管理，审计方便 | 单点瓶颈，高可用要求高 | 中小规模系统推荐 |
| 分布式权限校验 | 去中心化，性能好 | 权限数据不一致，管理复杂 | 大规模系统可以考虑 |
| 混合模式 | 兼顾统一和性能 | 架构复杂，需要缓存同步 | 我个人的首选 |
我个人习惯用混合模式：权限定义和角色管理集中在一个服务，但权限校验下沉到各个微服务的 SDK 里。这样既保证了权限数据的一致性，又避免了每次请求都去中心服务查权限。
落地步骤
- 定义统一权限模型：所有微服务共用一套角色和权限定义
- 权限数据缓存：每个微服务本地缓存角色-权限映射，定期从中心服务同步
- 请求拦截：在 API 网关或服务网格层做统一权限校验
- 审计日志：所有权限变更和校验结果写入统一日志中心
关键点：微服务里的 RBAC 落地，最难的不是技术实现，而是「约定」。所有服务必须遵守同一个权限命名规范，否则 A 服务的「admin」和 B 服务的「admin」可能完全不是一回事。
SVG：RBAC 在微服务中的落地架构
3.5 小结：RBAC 落地的三个关键
聊了这么多，其实核心就三点：
- 角色定义要克制：别把角色当职位，继承别超过两层
- 动态能力要外置：静态 RBAC + 动态策略引擎，别混在一起
- 微服务要统一：权限模型、命名规范、审计日志，一个都不能少
我记得有一次帮一个团队做权限重构，他们原来的角色定义里有个叫「临时查看者」的角色，结果这个「临时」角色用了三年都没清理。嗯，权限这东西，设计时多花点心思，运维时就能少掉点头发。