theme: channing-cyan
权限管理，一般指根据系统设置的安全规则或者安全策略，用户可以访问而且只能访问自己被授权的资源，不多不少。对权限做管理的系统，就是权限管理系统。
我自己没有开发过公用的权限管理系统，不过给后台写过简单的权限管理功能，用过两套相对专业的权限管理系统。这两天开发一个新后台，需要用到权限管理，发现公司已有一个权限管理系统，可直接对接。
这套权限管理系统，对接顺畅、授权操作成本低、能满足大部分需求。所以主要以这个系统例进行讲解。
因为没有看过系统代码，所以代码相关的内容会比较少，主要聊一些基本操作。
必要性
权限管理系统是很必要的。主要有以下几个原因
复用
公司往往有大量后台，后台都需要进行权限管理。而权限管理的核心流程是相似的，如果每个后台单独开发一套权限管理系统，就是重复造轮子，是人力的极大浪费。
有一套公用的权限管理系统，只需做好对接工作，能节省大量人力。
安全
每个人开发能力不一样，很难保证各自开发的权限管理系统是足够严谨的。
统一
首先是宏观上的统一，所有后台系统对接同一套权限管理系统，统一了技术栈。
其次便于统一管理，无论是维护、管理、查看，都只需关注一个系统，达到收敛效果。
组成分析
权限管理系统有几大组成部分，分别为系统、业务、菜单、权限、角色。
系统
权限管理系统需与众多平台对接，必须能够标记不同平台。
系统部分一般包含如下信息：系统ID、系统名称、系统描述、系统负责人、创建时间、修改时间
业务
系统内可能有不同业务，也可能只有一个业务。
如商家后台，不同的商家可以认为是不同的业务。因为同一个使用者可能操作多个商家，但所处角色不同。
如一些海外系统，需要管理多个国家，不同的国家可以认为是不同的业务。因为同一个用户可能以不同角色管理多个国家配置；或者只能管理一个国家的配置。
当系统只有一个业务的情况下，业务可只有一个。
角色
操作者的身份，不同身份权限不同，看到的菜单内容也不同。常见的角色有：运营、开发者、admin等。
菜单
菜单为树形结构，包含多个一级菜单，一个一级菜单包含多个二级菜单或页面，二级菜单包含多个页面。
菜单信息一般包含
权限
前端菜单/页面都需要调用后端接口，所以可以将菜单和调用的接口进行绑定，这就形成了一种关联，拥有某个菜单，便拥有了请求相关接口的权限。
权限管理里只显示一二级目录，没有显示页面，主要原因是不想重复配置。
有一种特殊情况，不同角色可以操作同一个页面的同一个接口，但是操作内容不同，如对更新商品而言，商家只能编辑，运营则负责审核。如果两个操作同一个接口的话，就需要在服务端自行做权限校验。另一种方案是将接口进行拆分，但服务端仍然需要做一部分检查。
关系
权限管理系统的核心是管理角色的权限。即角色、菜单、权限之间的关系。上面讲了各个组成后，这之间的关系就比较简单了
角色配置的时候和菜单进行绑定，菜单又是和接口绑定的，所以实现了角色-菜单-接口权限之间的对应关系。
前提
使用权限管理系统需要有两个前提
- 需要有账号体系。
拥有账号体系意味着能够获取用户id，此时权限管理系统才能被使用。
- 需要有申请流程
很多公司做权限管理系统的时候，并没有申请流程。添加新用户需管理员在后台人工添加，不但需要录入大量信息，而且容易出错，大大增加了管理员的成本。
合理的方式为，用户申请权限，系统自动录入数据，管理员审核
接口
权限管理系统需要提供接口供平台调用，其中需要有：
- 角色列表：用于用户申请时，能够看到有哪些角色可供选择
- 分配角色：用户登录后能够获取到用户id，可以给该用户分配指定系统、指定业务、指定角色
- 菜单：获取该角色对应的菜单内容
- 接口权限验证：判断该角色是否能够访问指定接口
权限管理系统往往用于后台，虽流量不高，但也需要关注性能问题，尤其像接口权限验证，几乎每次都需要请求，此时就需要使用缓存来提高性能。
总结
按照该设计搭建的权限管理系统可以满足大部分业务需求。权限和菜单进行绑定，角色和菜单进行绑定，这种设计更直观、易理解，但也需要后台在设计时，思考好权限与角色的关系，这对后台开发者提出了一定的要求。
最后
大家如果喜欢我的文章，可以关注我的公众号（程序员麻辣烫）
我的个人博客为：https://shidawuhen.github.io/
往期文章回顾：
