大型系统后台设计——权限篇

为什么写这篇文章？

写这篇文章的目的有两个：一个原因是，由于最近将近两年都在接触大型的系统，我有幸作为一个软件实施方的一员，接触并了解了几个大型的项目，并自己也主·导设计了两款软件系统，我对于软件的后台设计有了一定程度的了解，有能力阐述清楚这个问题。另外一个原因是，曾经我作为一个软件小白，想要在网上找到相应的资料，发现，大部分的文章都来自与开发人员，他们偏向于从技术层面进行阐述，读起来晦涩难懂，很少从业务和原理上进行阐述，还有一部分文章阐述的层面较为浅显，浅尝辄止，并没有从整体到部分进行完整的阐述，我这篇文章力求简单明了，完整全面，任何人都通俗易懂。

系统后台一般包括哪些内容，有什么用处？

系统后台一般是管理者进行系统管理的一个模块。根据软件的不同用途，其管理的内容各不相同。举个简单的例子：今日头条、腾讯视频、头条号等内容平台，一般其后台都会有内容审核功能，用户账号管理、权限分配等等。GUC用户发布一篇文章，后台进行审核，通过后，方可进行展示。

我今天所阐述的系统后台，指的是更为核心的东西，是一个系统的心脏。指的是权限数据管理，这一个部分的设计最为复杂也是系统设计最难最基础的部门。

权限包括两个部分：一个是操作权限，一个是数据权限。 

操作权限又包括两个部分：一个是菜单权限，另外一个是按钮权限。

菜单权限。举个例子来说：我们使用同一个办公软件系统，你是HR，你有招聘模块的菜单，可以进行招聘相关的操作，我是财务，我有费用报销模块的菜单，而你没有。这样我们的菜单是不一定的。我们都可以使用办公软件，但是我们的职位不同，所以分配的菜单是不一样的。

按钮权限。举个例子：我们两个都是人资部门的人，你是招聘专员，我是人资经理。我们虽然都有招聘菜单，但是你没有招聘需求审批的按钮，你没有相应的权限操作，只有我可以进行招聘需求的审批。

数据权限，说起来就比较简单容易理解了，比如拿快消行业来说，我是安徽区的省区经理，你是江苏大区的省区经理，我们职位相同，我们都是省区经理，我们拥有的操作权限也是一样的，但是我们看到的数据是不一样的，我是安徽的省区经理，只能允许看到安徽省的销售数据，江苏地区的销售数据我是看不到的，同理，江苏区的省区经理也是一样的。所有这些，都是可以通过数据权限进行控制的。

怎么进行权限的控制？

我主要介绍两种常见的权限控制方法，也是比较常用的权限设计方式，一种是对于小型企业的，一般只有几百人的那种，另外一种涉及到工作流的系统产品，人数众多。两种设计方式之外还会有许多的变种，这里就不一一说了。

第一种：用户—角色—权限

用户——角色的设计方式是最为简单的设计方式。他的设计原理是：把操作权限分配给角色，如下图1，这样新增一个新的角色以后，就会给这个新增的角色分配相应的操作权限，包括操作按钮和操作菜单。

图1

上图为某公司的新增角色页面，从图中可以看到，勾选相应的菜单和按钮，则该角色就有用了菜单和按钮的操作权限，没有勾选，则没有改权限。

图2

通过部门赋予用户数据权限，如图2 。新建一个新的用户时，必须要给这个用户选择一个权限角色，同时，在授权部门模块，选择其所属的部门，部门就决定了其数据范围。通过这两个操作，一个新的用户就具备了操作权限和数据权限。

第二种：用户—职位—角色—权限

相比于第一种的权限设计方案，多用于小型系统，没有涉及到工作流的情况；第二种权限设计方案多应用于一些中大型系统中，如CRM系统、OA系统等等。第二种和第一种相比较，中间多了一层职位，设计思路也是不一样的。

第二种设计思路如下：

角色控制操作权限，和第一种一样，如果涉及到工作流，可以进行单独定义工作流角色，也可以和权限角色相同，不进行单独定义。

角色——操作权限设计

职位是增加的一层，职位与角色关联，也就是说，一个角色下面对应多个职位，一个职位只能对应一个角色，这样职位就拥有了操作权限的属性。同时，组织机构与职位关联，组织机构决定系统的数据权限。这样职位就拥有了操作权限和数据权限。

职位管理

最后在把职位挂到相应的用户，这样用户在登录该账号时，就同时拥有操作权限和数据权限。

用户—职位

这里有一点需要说明，用户和职位是一对一的关系，也就是说，一个萝卜一个坑，不可以把一个职位挂给多个用户。

这样设计有什么好处呢？

举个例子说吧：当一个员工离职了，采用第二种设计方式，只需要停用该员工的用户账号，把职位移除，如果新来一个员工替代他，只需要给新员工新建一个用户账号，同时把职位挂给他就OK了，不需要重新分配数据权限和操作权限。如果采用第一种设计方式：需要停用员工账号，新来员工开通账号需要重新分配数据权限。

再举个例子吧：当两个员工A和B进行跨部门职位调岗时，该怎么操作呢？第一种方式：A和B的职位去掉，同时对调就行或者把该部门空缺职位分配给A和B，不需要重新分配数据权限。第二种方式：A和B要同时进行数据权限的重新分配。

如果有考虑有工作流的情况，就需要考虑流程节点处理对象，可以按照工作流角色、职位和具体用户三个维度进行配置，第二种可以很好地满足，第一种就无法满足，只能按照具体人来定义和角色来处理，当一个人调岗变动时，工作流审批节点可能也要进行调整，而第二种设计方式就不需要进行调整。

此外，对于，有相应人员编制的企业来说，可以保证职位的固定，只会有用户的增减，职位可以始终保持不变，这样编制就得以控制了。

综上：如果是设计小型系统并且没有涉及到工作流的情况，第一种设计方案：用户—角色的权限设计方案比较简单；如果是中大型的系统并且涉及到工作流的情况，则第二种设计方案：用户—职位—角色 的设计方案比较好。