目前的系统有什么问题？
现在我们的系统越来越庞大，可是每一个人进来的查看到的内容完全一样，没有办法灵活的根据不同用户展示不同的数据
例如我们有一个系统，期望不同权限的用户可以看到不同类型的页面，同一个页面不同权限的用户看到的数据也是不一致的，且 管理员 分为不同等级，不同等级对比自己低等级的管理员仍然具有分配权限的权利
正如这样的需求，不支持分权分域的传统系统就没有办法很好的处理。
用的分权分域可以带来什么？
- 系统逐渐庞大和复杂，需要有权限管理的能力，分权分域可以很好的处理
- 可以提高系统的灵活性和可扩展性
- 可以提高系统的安全性，稳定性，可靠性
分权分域如何理解？
工作中很多时候突然问你分权分域如何理解，分权和分域有什么区别，他们是否是一样的东西呢？或许没有确定的答案，可实际上稍微思考一下就可以知道
- 分权：设计和定义权限
- 分域：控制用户权限
可以理解分权，是我们给系统设计和定义有哪些权限，哪些权限可以访问哪些资源
分域可以理解为，有相同权限的用户，但是他们的域权限不一样的，那么他们看到的内容也是不一样的，例如，A 部门的 主管只能看到 A 部门的员工的薪资，A 部门的主管就没有办法看到 B 部门的薪资
同理，B 部门的主管也是如此
分权分域包含哪些内容
随着时间的推移，社会上需求的不断变化，以及大佬们不断的优化，慢慢的依次出现了不同分权分域模型，如：
- UGO - linux 对文件对象的访问控制模型
包含，用户，用户组，其他 三类，这样对于系统进行权限访问分类就很不灵活，这个弊端非常明显，稍微需要做一些特殊的权限就没法弄
- ACL 访问控制列表
这个方式也是使用的比较广泛的，将资源全部赋予对应的资源 id，给用户分配权限的时候，则给他加上对应的资源 id 即可，这样拥有某个 资源 id 的用户就可以看到具体的资源信息
这种方式也是会存在重复劳动，则 小 A 和 小 B 能看到的资源内容是一样的，那么 超级管理员 就需要给 小 A 和 小 B 分别加上对应的相同的资源 id
- 此处说的资源可以理解为，
-
- 前端页面，
- 后台 API
- 也可以是具体的数据域
- DAC 自主访问控制
- MAC 强制访问控制
- RBAC - 基于用户角色的权限访问控制
RBAC - 基于用户角色的权限访问控制
对于 RBAC
Role Based Access Control / Role-Based Access Control / 基于角色的访问控制
相信学过 K8S 的都不会陌生，K8S 就是使用 RBAC 来进行权限访问的控制的，那么对于这种模式，我们可以看到多了一个关键的对象 角色
之前是
用户 - 权限 - 资源
现在是
用户 – 角色 – 权限 – 资源
上述的模式都是给用户赋予某种权限，而 RBAC 是把权限绑定到角色上，再将用户赋予不同的角色
RBAC 也有自己的子模型，最基本的模型 RBAC 0 默认包含 用户，角色，权限 三个重要的部分
就如同上述例子例子一样 小 A 和小 B 拥有相同的权限，使用 RBAC 模型，那么 他们都是可以是 员工 角色，那么只需要将他们和 员工角色 建立关系即可，那么他们就可以很轻松的能够访问到 员工 角色能够访问到的资源
对于 RBAC 其他的模型，都是基于 RBAC 0 上面进行的衍生和变化，增加了一些继承和约束，但是原理还是一样的
基本知道分权分域是个啥了，那么去给系统设计权限的时候，就能够有的放矢
欢迎点赞，关注，收藏
朋友们，你的支持和鼓励，是我坚持分享，提高质量的动力
好了，本次就到这里
技术是开放的，我们的心态，更应是开放的。拥抱变化，向阳而生，努力向前行。
我是阿兵云原生，欢迎点赞关注收藏，下次见~
可以进入地址进行体验和学习：https://xxetb.xet.tech/s/3lucCI
