3. 授权模型详解
授权模型这东西，说白了就是「谁在什么条件下能对什么资源做什么事」。我见过不少团队，一开始图省事全用硬编码权限，结果业务一扩张，代码里全是 if-else，改个权限要发版，苦不堪言。
今天咱们就把主流的三种模型掰开揉碎讲清楚。RBAC、ABAC、PBAC，它们不是互斥的，很多时候是组合使用的。但你要先理解各自的脾气，才知道怎么搭。
3.1 RBAC：最经典的「角色」模型
RBAC（Role-Based Access Control）是绝大多数系统的起点。它的核心思想很简单：用户不直接拥有权限，用户通过角色获得权限。
举个例子。你公司里有人力专员、人力总监、财务专员。你不会给每个专员单独配「查看工资条」的权限，而是创建一个「人力专员」角色，把权限挂上去，再把用户加进角色里。
核心三要素：
- 用户（User）：谁在操作
- 角色（Role）：用户的身份标签
- 权限（Permission）：能做什么操作
关系就是：用户 → 角色 → 权限。中间多了一层，管理起来就灵活了。
我在项目中遇到过最典型的场景：一个数据平台有 2000 多个用户，如果不用 RBAC，光配权限就能把人配疯掉。用了 RBAC 之后，我们只维护了 15 个角色，每个角色对应一套权限模板，用户入职直接挂角色，离职摘掉就行。
我的习惯：RBAC 适合「角色稳定、权限变化少」的场景。比如内部管理系统、后台运营平台。如果业务一天一个样，角色频繁新增，RBAC 就会变成「角色爆炸」——角色数量比用户还多，那就失去意义了。
3.2 ABAC：更细粒度的「属性」模型
ABAC（Attribute-Based Access Control）比 RBAC 灵活得多。它不看你的角色，而是看你的属性。
属性分四类：
- 用户属性：部门、职级、地域、是否实习生
- 资源属性：数据表所属部门、数据敏感等级、创建时间
- 环境属性：访问时间、IP 地址、设备类型
- 操作属性：读取、写入、导出、删除
然后通过策略引擎计算：如果用户属性 + 资源属性 + 环境属性满足某条策略，就允许操作。
举个例子。一条策略可以写成：「允许数据工程师（用户属性）在工作时间 9:00-18:00（环境属性）读取（操作属性）敏感等级为 L2 以下（资源属性）的数据表。」
你看，这比 RBAC 的「数据工程师角色可以读所有表」要精细得多。
我曾经踩过的坑：ABAC 的策略引擎如果设计不好，性能会非常差。每次请求都要计算一堆属性，如果属性值还要查数据库，延迟直接飙升。我见过一个团队把 ABAC 策略写成了嵌套的 JSON，解析一次要 50ms，接口直接超时。
解决方案是：把常用策略预计算成「权限缓存」，或者用规则引擎（如 Drools、OPA）来做离线编译。
3.3 PBAC：面向策略的「策略」模型
PBAC（Policy-Based Access Control）其实不是一种全新的模型，它更像是一种架构思想：把授权逻辑从应用代码中抽离出来，放到一个独立的策略引擎里。
PBAC 的核心是：
- 策略（Policy）：用声明式语言（如 Rego、XACML）描述授权规则
- 策略决策点（PDP）：负责计算策略，返回 Allow/Deny
- 策略执行点（PEP）：在应用侧拦截请求，调用 PDP 做决策
说白了，PBAC 是「把脑子从身体里拿出来」。应用只负责问「这个请求能过吗？」，策略引擎负责想「能还是不能」。
我比较推荐在特征平台里用 PBAC 的思路。因为特征平台的权限规则往往很复杂——不同项目、不同特征、不同环境、不同用户组，规则交叉起来，写在代码里就是灾难。
PBAC 的典型架构：
用户请求 → PEP（拦截） → PDP（策略决策点） → 返回 Allow/Deny
↑
策略管理点（PAP）
↑
策略存储（Policy Store）PEP 和 PDP 分离，策略变更不需要重启应用。这是 PBAC 最大的优势。
3.4 三种模型对比：一张表说清楚
| 维度 | RBAC | ABAC | PBAC |
|---|---|---|---|
| 核心概念 | 角色 | 属性 | 策略 |
| 粒度 | 粗（角色级） | 细（属性级） | 可粗可细（取决于策略） |
| 灵活性 | 低（角色固定） | 高（属性组合） | 高（策略可动态加载） |
| 性能 | 高（查表即可） | 中（需计算属性） | 中低（需调用策略引擎） |
| 管理复杂度 | 低 | 中（属性维护成本） | 高（策略编写与测试） |
| 适用场景 | 内部系统、角色稳定 | 多租户、数据分级 | 复杂规则、合规审计 |
3.5 选型建议：别纠结，混着用
你可能会问：「那我到底该用哪个？」
我的建议是：不要非此即彼。实际项目中，这三种模型经常是组合的。
- 基础层用 RBAC：先定义好角色，比如「特征管理员」「特征开发者」「特征只读用户」。这是最稳定的骨架。
- 精细层用 ABAC：在角色基础上，加属性约束。比如「特征开发者只能读取自己项目下的特征，不能跨项目」。属性可以来自用户元数据或资源元数据。
- 复杂规则层用 PBAC：如果有些规则经常变，或者需要合规审计，就把这部分规则抽到策略引擎里。比如「某个特征在灰度环境只能被 QA 团队读取，且只能在工作日访问」。
我个人的经验：特征平台里，80% 的权限用 RBAC 就能搞定。剩下 20% 的复杂规则，用 ABAC 或 PBAC 补充。不要一开始就上 ABAC 或 PBAC，那会让系统变得过于复杂。先跑起来，再优化。
3.6 三种模型的关系图
下面这张图展示了三种模型在特征平台中的协作关系。你可以看到，RBAC 是基础，ABAC 在 RBAC 之上做属性过滤，PBAC 则作为独立的策略引擎兜底复杂规则。
3.7 实战中的避坑指南
最后分享几个我踩过的坑，希望能帮你少走弯路。
- 别把角色当万能药：RBAC 虽然简单，但角色一多就乱。我见过一个系统有 300 多个角色，每个角色只有 1-2 个用户。这还不如直接给用户配权限。建议角色数量控制在 20 个以内。
- ABAC 的属性来源要稳定：属性如果经常变，或者数据质量差，策略就会失效。比如「部门」属性，如果 HR 系统里部门经常合并拆分，那基于部门的策略就会出问题。建议对属性做快照或缓存。
- PBAC 的策略要有版本管理：策略是代码，也要走 CI/CD。我曾经因为改了一条策略没测试，导致线上所有用户都无法导出数据。后来我们给策略加了版本号、灰度发布和回滚机制。
- 性能兜底：不管用哪种模型，都要有「默认拒绝」的兜底。如果策略引擎挂了，或者属性查不到，直接拒绝，不要放行。安全第一。
重要提醒：授权模型不是一锤子买卖。业务在发展，权限模型也要迭代。建议一开始就设计好扩展点，比如策略的 SPI 接口、属性的动态注入、角色的继承机制。否则后面重构，成本会非常高。