随着使用者类型越来越丰富，导致权限系统必可不少。本文详细的跟大家说说，为什么会有权限系统？或者换个说法，为什么需要权限系统？
权限系统其实不只是应用于电商领域，各个领域都有可能用到。一旦公司系统做大，系统使用者的类型越来越丰富，权限系统就必不可少了。也就是说，小公司可能会没有权限系统，一般用一个admin账号供所有成员使用。
这里需要注意，我说的使用者类型越来越丰富，导致权限系统必可不少。很简单，假设一个系统只有一类使用者，这一类人必然有相同的使用权限，那就无所谓有没有权限系统了。
如果抽象一下，你可以看到：使用者 – 某一类使用者– 权限，如果某一类使用者唯一，我可以直接抽象为：使用者– 权限。这算是提前剧透，权限系统的经典模型：RBAC模型，即用户– 角色– 权限。上文就是将用户这个维度向上抽象出角色，某一类使用者对应一种角色。
看权限两个字，可以通俗的理解为权力限制，即不同的人由于拥有不同权力，他所看到的、能使用的可能不一样。对应到一个应用系统，其实就是一个用户可能拥有不同的数据权限（看到的）和操作权限（使用的）。或者大家可以把权限看成资源获取权，B/S结构里，你通过浏览器有没有向服务器请求某项资源的权力。
很多公司喜欢做用户白名单这种事，其实道理和权限系统一致，给白名单用户开方便之门，让他们访问非白名单用户访问不到的资源。总结来说就是，我需要通过权限决定谁可以访问我的资源。
另外，现在大部分文章没有把数据权限和操作权限说明白，我会试图在本文中讲明白这个问题。
更多的铺垫就不说了，全文将会以这个节奏进行：
权限系统经典模型，这一部分我会简单介绍一下RBAC模型。
操作和数据权限，在这一部分，我会把大部分文章没有讲清楚的数据权限和操作权限讲明白。
权限系统实操，在这一部分我会简单说下做一个权限系统的底层逻辑，让你很快能”复制”一个权限系统。
二、权限系统的背景
正如前文说的，某些小公司不需要权限系统，原因也提到了使用者类型唯一，那么，是不是说当我使用者类型丰富的时候，我就需要考虑权限问题了呢？答案是肯定的！
权限系统起源是提供企业级应用软件解决方案的公司，如SAP、PeopleSoft等，也是这类公司最早开始探索高内聚低耦合系统。
举个可能不恰当的例子：当客户只想要WMS的时候，你说OMS和WMS不可分割，想买WMS就必须买OMS，显然是不合理的。
这和权限系统有什么关系呢？
OMS和WMS，一个是订单管理系统，一个是仓库管理系统。假设OMS的使用者是公司客服，WMS的使用者是公司仓库管理员。这里出现了两个系统，两类使用者，客服应该看到并使用WMS么？
最早的一批提供企业级应用软件服务的公司，也面临着同样的问题，随着客户公司的业务拓展，首先是客户公司对各子系统的需求量增大，可能不仅仅只需要一个HRMS，其次是对系统的使用安全、保密性，系统操作人员的权责关系界定上越来越严格，最后是B/S结构出现后带来的便捷性（需要注意的是这一点并不是初期探索权限系统的原因）。
关于这一点简单画了一个图来说明，如下：
从图中可以看出来，所有资源都统一存放在一处，当用户需要请求资源的时候，先经过资源表判断该用户是否有对应权限，如果有则返回结果。
没有B/S结构，一个软件服务公司可能需要为客户组装各种本地化的系统（如sys1和sys2打一个包，sys1单独打一个包，……），这就是B/S结构带来的便捷性，而权限系统在这中间起了至关重要的作用。
三、权限系统经典模型
需要先说明一点，在权限系统文章里强调RBAC模型，只是为了让大家对这个经典模型重视起来，再强调一下RBAC模型的基本结构：用户- 角色- 权限，却不仅限于此，更多细节需要大家亲自去摸索。
RBAC模型可以分为：RBAC 0、RBAC 1、RBAC 2、RBAC 3 四个阶段，一般公司使用RBAC0的模型就可以。另外，RBAC 0相当于底层逻辑，后三者都是在RBAC 0模型上的拔高。
我先简单介绍下这四个RBAC模型：
简单来说就是一个用户拥有多个角色，一个角色可以被多个用户拥有，这是用户和角色的多对多关系；同样的，角色和权限也是如此。
RBAC 0模型如下图：没有画太多线，但是已经能够看出多对多关系。
RBAC 1模型：相对于RBAC 0模型，增加了角色分级的逻辑，类似于树形结构，下一节点继承上一节点的所有权限，如role1根节点下有role1.1和role1.2两个子节点。
角色分级的逻辑可以有效的规范角色创建（主要得益于权限继承逻辑），我之前做过BD工具（类CRM），BD之间就有分级（经理、主管、专员），如果采用RBAC 0模型做权限系统，我可能需要为经理、主管、专员分别创建一个角色（角色之间权限无继承性），极有可能出现一个问题，由于权限配置错误，主管拥有经理都没有权限。
而RBAC 1模型就很好解决了这个问题，创建完经理角色并配置好权限后，主管角色的权限继承经理角色的权限，并且支持针对性删减主管权限。
RBAC 1模型如下图：多对多关系仍旧没有改变，只增加角色分级逻辑。
RBAC 2模型：基于RBAC 0模型，对角色增加了更多约束条件。
如角色互斥，比较经典的案例是财务系统中出纳不得兼管稽核，那么在赋予财务系统操作人员角色时，同一个操作员不能同时拥有出纳和稽核两个角色。
如角色数量限制，例如：一个角色专门为公司CEO创建的，最后发现公司有10个人拥有CEO角色，一个公司有10个CEO？
RBAC 2 模型主要是为了增加角色赋予的限制条件，这也符合权限系统的目标：权责明确，系统使用安全、保密。
RBAC 3模型：同样是基于RBAC0模型，但是综合了RBAC 1和RBAC 2的所有特点。这里就不在多描述，读者返回去看RBAC 1和RBAC 2模型的描述即可。
四、操作和数据权限
写在之前，这一部分，我主要是讲自己的理解，读者们需要辩证的去看这一部分。
用户在使用操作系统时能进行的增删改查我都归为操作权限，有很多人将增删改归为数据权限，因为这是在更改数据库某张表里的记录，必然是数据权限，真的是这样么？例如：商品中心里新增加一个商品，这到底是操作权限还是数据权限？
在我看来，凡是在操作系统中的任何动作、交互以及结果都是操作权限。那么，我说的数据权限是什么呢？
上文提到过我做的BD工具，再用这个例子：
先简单介绍我们的业务模式：BD专员负责拓展客户，BD主管直接管理推动专员作业，主管上级是经理，经理负责组织管理主管作业，这条业务线基本上如下图：
从上图很容易能看出来我说的数据权限是什么了，如果以客户作为最小数据单元往上看，你会发现：客户2.1.1和客户2.1.2只属于专员2.1，只属于主管2，再往上就是经理。
这个属于关系换另外一句话就是：我的客户只有我和我的直属上级以及直属上级的领导能看到，这也就是我说的数据权限。为什么这么说呢？
我们在作业过程中，销售数据是客户这个最小单元产生的，没有客户就没有销售数据，那么我的客户产生的销售数据谁可见呢？
这就是我说的数据权限。
简单说下，在实现数据权限时至少有两种方式：
一种上文提到了，利用RBAC 1模型，角色分级来实现，我们需要的就是角色分级带来的角色树，利用树形结构去控制数据输出。
另外一种方式，也就是我的实现方式，雷同于RBAC 1模型的角色树，我利用HRMS中的人事组织架构来实现数据输出，也即是打通HRMS系统和对应需要数据权限控制的系统，当涉及到数据输出时，会调用HRMS系统中的组织结构树，从而确定数据输出范围。当然我们在开发过程中，也可以直接把组织结构树置于权限系统之中，这种方式适用于组织架构相对固化的组织（如国企），但一般不建议这样做，系统的灵活配置、高可拓展性是开发想要的，也是产品需要考虑的。
这就是我理解的操作权限和数据权限，再次希望大家辩证的去看，自己多思考。
五、权限系统实操
到这一部分，我相信绝大部分产品同学已经有自己对权限系统的认知了，特别是看到RBAC模型后，做一个简单的权限系统应该没任何问题。
我说的实操的底层逻辑其实也是基于RBAC模型，再次强调下RBAC模型：用户– 角色– 权限。
那么，一个简单的权限系统应该具备哪几块呢？
首先考虑一个问题，用户从哪儿来？
很多权限系统直接在权限系统内创建一个用户，也可以打通HRMS系统，员工即用户，省去专门创建用户的一步。我想说的是后者，即打通HRMS系统。多说一句，这种设计一般需要在员工入职的时候为其选择相应角色。
用户已经有了，在这个前提下，就可以考虑其他问题了。
在RBAC模型下，给这样一个场景，创建一个角色，并为这个角色赋予相应权限，最后将角色赋予用户。那么，这个用户就拥有了该角色所拥有的权限。
抽象一下这个问题：开始》创建角色》为角色赋予权限》添加用户（调用HRMS）》将角色赋予用户》结束。
底层逻辑已经抽象出来了，那么该如何设计呢？
第一步，需要角色管理列表，在角色管理列表能快速创建一个角色；
第二步，角色管列表中能跳转至为角色配置权限的页面，也就是说有一个权限配置页；
第三步，需要有用户管理列表，在用户管理列表能快速添加一个用户，添加用户的这一页至少有让用户关联角色的功能。
简单来说权限系统设计至少有这三步，这样就完成了之前场景预定的全部内容，即：创建一个角色，并为这个角色赋予相应权限，最后将角色赋予用户。
到这里权限系统也算是讲完了，希望大家能喜欢，欢迎大家一起交流！
相关阅读
入门电商，先从线下到线上说起
电商入门（2）：购物车功能要点和背后逻辑
电商入门 （3）：电商CMS，一劳永逸的建站方案
电商入门（4）：如果我来负责搜狗云表情的搜索功能，会怎样去优化？
