一、用户权限的演变过程
首先对于系统，我们可以抽象为以下几种资源：一是系统的数据，二是系统的界面，大到菜单小到按钮；三是接口，也就是我们的后台资源。
那么实际上，用户使用系统就是操作资源的过程。现在的过程就是
那么的话开始涉及到权限的问题了，比如说我遇到过的，一个系统演示的时候，我不想让客户看到一些功能，再比如说来了个外包团队我要给svn，那么我不可能整个目录都给出去，肯定只让他有访问某个文件夹的权限，甚至只有访问文件夹下面某些文件的权限。
针对使用资源的权限我们可以拆分出来。
（1）数据权限：用户能查看的数据是经过过滤的，就像svn外包团队能看到的目录下的文件数量不会给全，典型的sql过滤；
（2）界面权限（我自己起的名称，非官方）：按钮、菜单的访问，某些人只能看到部分菜单，比如说非hr的同事只能看到公司管理系统的部分菜单，人员调薪什么鬼的菜单不能给他看；
（3）接口权限：访问接口需要权限，最简单比如上传，只有你登录了，且有上传权限才可以访问，不然我一个postman昼夜不停一通上传图片你早崩溃了。
那么就演变成下面这样
然后的话我们对于数据权限，其实很多时候是根据你的组织来区分的，比方说，你是外包公司，不属于体制内人员那么我在查看文件的sql可以给你加个过滤org like 我们组织blabla，这样的话无关人员看不到不属于自己组织范围的数据；再者说，组织如果是街道社区划分，那么A街道管理员也不能看到B街道的数据，A社区管理员不能看B社区数据，以此类推，而组织这个概念一旦引入，应该贯彻始终，因为数据权限是贯彻整个系统的。
然后我们刚刚是不是提到街道管理员这个概念？那好，现在张三李四王五都是A街道管理员，他们都有A街道各种按钮、接口的权限，你一个一个权限给我设置去。什么？太麻烦为什么不能统一设置？
那好我们引入角色的概念，相同的角色拥有相同的权限，让用户对应角色就可以了。但是这里又有一个问题，用户对应角色的话还应不应该对应权限？好比方说现在有个人只有某个特殊权限，你开一个角色，过几天又来一个人你又开一个角色，久而久之角色会不会爆炸？会的，所以用户也可以对应权限。
这时候我们的用户可以同时对应角色以及单独的权限，再复杂的话以后可能会用到用户组，这个概念和linux系统的一样，这里不说了。那么我们的图例变成了下面这样。
这就是演变的基本过程
二、三员分立
好的，我们已经了解了基本过程，现在考虑一个问题
有一个超级管理员，它啥都会，现在可以为所欲为，然后自己把自己的操作日志删了，谁也不知道他做什么，这样好吗？
不好，一般来说，我们这样分管理员
负责记录操作日志的，为一个管理员，曰审计管理员；
负责创建用户的，为一个管理员；
负责分发权限的，为一个管理员。。。。
这就是所谓的三员，并非真的只有三个管理员类型，按需分即可。