体系|搭建用户权限体系，你要知道这些( 二 ) 机器学习|编译器|瑞莱|隐私|朱

基数约束：一个角色被分配的用户数量是有限制的，不能无限地添加，即有多少用户能够拥有这个角色。如一个角色是为CEO创建的，那么这个角色的数量是有限的。

先决条件：想要获得更高权限时，首先需要获得低一级的权限。如先有助理工程师的权限，才能有工程师的权限。

运行时互斥：一个用户允许具有两个角色，但在运行时不可同时激活这两个角色，如家长和老师，一个用户可能既是家长又是老师，但在使用系统时，只能选择一个角色。

RBAC3：统一模型。RBAC3是RBAC1和RBAC2的合集，所以RBAC3既有角色分层，也可以增加各种限制。
基于RBAC的延展。了解完RBAC模型本身以后，我们还需要了解一组与之相关的概念：用户组、角色组、权限组。这3个概念的出现都是为了方便管理。
用户组：用户组是用户的集合。
如果用户数量比较庞大，可以给用户分组，分好组以后可以给用户组分配权限，这样这个用户组下的每一个用户拥有的权限=用户个人拥有的权限+该用户组拥有的权限。以后加入更多的用户，就自动拥有了用户组的权限，不用再一一进行设置了。
角色组：角色组是角色的集合。
有时多个角色针对某一部分系统资源拥有相同的权限，如经理、技术人员、销售人员这些角色，对同一类文件拥有相同的权限，这时就可以为这些角色建立一个角色组，把权限赋予这个角色组，这样这些角色就都拥有了权限。
权限组：权限组是权限的集合。
权限之间有时是相关联的，这时就可以为这些关联的权限设置一个权限组，当授权时就可以把权限组赋予某个角色/角色组，就不需要再一一去设置了。如当我们视频通话时，需要同时具有相机和麦克风的权限。
三、角色定义在了解完RBAC模型以后我们会发现，在RBAC模型中角色是关键。为了对许多拥有相似权限的用户进行分类管理，我们抽象出角色的概念。那么我们如何来定义角色呢？
角色是基于业务来定义，而不是依据行政关系。如双人复核类业务，用户A在一次业务过程中扮演操作员角色，用户B扮演复核员角色。而在下一次业务过程中，用户B扮演操作员角色，用户A扮演复核员角色。这样的角色定义完全是基于业务上的需要，而与用户A和B的行政关系没有任何关系。
我们在进行角色定义时，可能会对角色的颗粒度产生迷惑，不知道该范围大一些包含的内容多一些还是应该范围小一些包含的内容少一些。
如一个用户涉及A、B、C三项业务，那么我是应该定义一个角色完成A、B、C三项业务的范围还是应该定义两个角色分别完成A、B业务和C业务呢？甚至定义三个角色分别完成A业务、B业务和C业务呢？
这时有人可能会说取决于ABC三项业务的关联性，实际上这个问题与业务的关联性没有关系。因为如果是相关联的业务那么必然会一起授权不可分割，如果是不相关的业务但是所有用户都是一起使用，那么也应该一起授权。
那么我们怎么判断呢？其实上面的例子和问题是走入了一个本末倒置的误区，从业务来归类用户了，方向上反了。前面我们说过，角色是拥有相似权限的用户抽象。
所以梳理角色的时候分析用户本身就可以了，归类出每类有相似权限的用户然后抽象成一个个角色。
用户权限体系对于整个功能体系具有蝴蝶效应，一点点小的差异/差错到了最上层的功能和使用层面会放大很多倍。而且一旦需要修改会很麻烦，所以我们需要特别小心。
四、前端展现方式如果一个用户有多个角色，那么在前端功能层面我们该如何处理呢？有两种方案：