什么是权限系统？

为使用相同系统或应用的不同人，设置他们分别能看到的不同内容或进行不同操作能力的系统，就是权限系统。

举两个小栗子：

栗子1:平台型电商的商户管理系统，有系统管理员、区域经理、商户管理员、商户店员等角色。系统管理员有系统的所有权限，可以新建角色为其分配权限，也可以新建区域并为其指定所包含城市等等。区域经理可以查询所负责区域数据，或在该区域内新建商户并为其指定商户管理员或禁用商户等等。而商户管理员则只能对其商户进行管理和操作，比如添加商户店员、查询商户营业额。商户店员可以上下架商户商品、为某些商品设置促销活动等。

栗子2:我们日常使用的视频网站app，可以设置普通用户和vip用户，vip用户可以在普通用户的基础上看到更多的视频内容。

什么时候需要搭建权限系统？

一般在系统或应用初期规划设计时，我们就会规划角色与权限问题，并依此拆分菜单、划分页面、区分操作控件及数据维度。但通常此时对权限的区分比较简单，只需要一个简易的权限管理模块或将权限与角色的对应关系、甚至是用户与权限的对应关系写死即可。

随着产品功能的增加甚至是相关联系统越来越多，涉及到的角色、用户越来越多，这时就需要有个可视化的系统来管理用户－角色－权限之间的关系了，也就是权限系统。

举个例子：某资讯类产品，开始只有编辑发文，用户读新闻两个功能，此时只需要设置两个固定权限的角色编辑和用户，用户端注册的即为用户，编辑端注册的即为编辑，不需要权限系统来管理角色权限。

随着业务发展，该产品的功能和使用角色增加了：用户和编辑都可以创建新闻、审核编辑审核文章后发表、评论编辑对已发表文章做评论、校验人员对机器分类或推荐做人为校验等等。随着角色越来越多，划分越来越细，user变动越来越频繁，权限系统则越来越被需要。

搭建权限系统

从产品层面上分析权限系统：

权限系统是用来设置用户对系统的访问规则，既：谁经过什么样的条件认证，可以看到系统中的哪些资源，并可以对其进行哪些操作。

即：who、what、how。因此我们需要定义的是：角色、资源、行为。

（ps:经过什么样的条件认证，即指该用户所属角色，所拥有的权限以及他在进入系统时的身份认证条件，身份认证条件为账号相关，拥有的权限则为可以对系统内的哪些资源进行哪些行为操作的约定。）

我们希望创建的是：满足功能、高效、安全、灵活、技术可实现的权限系统。

因此我们需要考虑：

1.系统都有哪些用户，可划分为哪些角色；

2.需要哪些操作被拆分到单一的权限用来分配，即资源与行为的拆分粒度；

3.用户在开通账户时的默认角色及权限授权；

4.是否需要双向授权：可以为用户选择角色，也可在角色中添加用户；可以在角色中添加权限，也可以在权限处添角色；

5.用户规模有多大，用户太多时可增加用户组的概念（用户－>用户组－>角色），以及角色组的概念（角色组不关联权限，只是角色的集合，可以用部门来充当角色组）；

6.需不需要特殊需求的支持，如：为单独用户添加权限；

7.对于安全性的要求，需不需要有些操作进行二次验证、数据权限设置参考值

8.考虑系统的可实现性及高效性，建议尽量简单，对于权限的拆分满足需求即可不用精益求精，扩展性只要现在的框架选定，后继迭代并非难事。

我们还需要考虑：

角色与用户、角色与权限，的对应关系：

1.多对多 or 一对多 or 多对一

2.父子层级，是继承关系 or 独立关系

操作：批量操作 or 单一操作

在设计时可以参考一些比较成熟的系统，比如jira的权限管理就很强大、很灵活。

搭建权限系统步骤：

一、新系统的权限：

1.梳理使用该系统的用户，并将用户按他们对系统的需求（即需要在系统中看见的资源和所做的行为）进行分类，定义为角色，

2.列出所有角色并将其对系统的需求整理成需求结构图，包括角色与角色之间的关系，权限是否继承等问题。（可用脑图）

3.根据角色需求结构图，梳理系统结构图（即菜单划分，资源如何归类到不同菜单、如何展示、哪些是通用展示，哪些是只展示给特定的角色，哪些资源需要哪些行为（操作）、哪些是通用操作、哪些是特定角色的操作）－－这里只要将通用与不通用区分、权限划分的粒度表示出来即可，不需要将每个角色一一对应到图中。（可以用脑图）

4.数据权限：哪些数据需要根据不同的用户或是角色子类做区分的，读权限还是写权限，需要标记出来。

5.根据以上梳理组内讨论，评审通过后，设计产品原型以及相应的权限部分。（考虑展现形式）

二、已有旧系统加入权限系统：

1.先深度了解业务流程和后台的所有功能模块。

2.把之前写死在代码里的权限梳理清楚。

3.梳理用户，归类到需要不同权限的角色。

4.将所有角色和对应需要的操作功能梳理成系统功能架构图：菜单、模块的拆分（可用脑图）

5.将权限的层级标记清楚，有无继承关系。

6.将数据权限标记清楚，只读还是读写。

7.组内讨论，评审通过后出原型。(考虑展现形式）

权限模块或系统，需求包括：

有了需求，技术上是否能实现？

目前技术上常用的模型：RBAC（Role-Based Access Control 基于角色的访问控制)模型：

大意是建立    用户－>角色－>权限《＝ 资源 & 行为 的关系：

将用户加入角色，而角色是权限的集合，权限中约定了可见菜单、可读/写数据、可用功能，这样有了角色的用户，就可以在系统中操作该角色的权限集合所赋予的功能了。

步聚：

1.定义用户：

2.定义角色：因为角色通常需要继承关系，因此建议使用树型结构。

3.定义资源：

4.定义行为：

5.权限设计：配置资源、资源的行为，创建权限。资源可定义一个通用的资源模型（有继承关系，可用树型结构），提供通用的资源统一接口。