RBAC(Role-Based Access Control ，基于角色的访问控制)模型是后台产品设计中常用模型。本文属于事后总结，希望对各位读者有一定的帮助，当然也有一定的局限性，欢迎留下你的评论，相互探讨。

　　最近西蒙折腾业务管理后台的从0到1，接到任务那刻，就开始投入资料的搜集和汇总工作。但是很多网上的资料都是基于技术层面的解释，但是很少有通俗易懂的说明，工作就开始了卡顿。

　　搜索出来的资料，很多都是这样的图表，后续咨询了很多伙伴，感谢他们的建议和分享，终于顺利完成了框架的梳理。撰写此文属于后续的思考沉淀，希望对各位读者有一定的帮助，当然本文也有一定的局限性，欢迎留下你的评论，相互探讨。

　　当框架梳理完毕的那刻，头脑中闪现的就是《结网》的一句话：“不需要再发明轮子”。

　　一、RBAC模型无处不在，不需要再次发明轮子,在于归类提炼

　　一开始搜索RBAC模型，很多都是偏技术类的说明，如用户表、角色表、用户角色关联表、权限表、权限角色表之类，没有一个概要(通俗)的说明。梳理完毕以后，发现其实RBAC模型是无处不在。

　　举几个例子和大家分享一下：

　　会员打折，基于会员卡，商品结账时，可以享受较低的支付价格。

　　公司的门禁卡，是分发给公司员工，只有是公司员工的身份(角色)，才能领取门禁卡，才能使用打卡出入(权限)，同样基于员工的角色，所以要上下班考勤打卡(权限限制)。如果离开了公司，那么不再是员工(角色)，所以无法出入公司大门，也无需上下班考勤打卡。

　　公司是有组织架构，不同的岗位，有不同的管理权限，财务总监可以管理公司账户，人事总监管理公司人事，与之对应的是财务部成员和人事各自有不同的权限

　　当我们打开微博/微信，发表内容的时候，是输出者，看别人内容的时候，是浏览者，输出评论的时候，是评论者，也是基于不同的动作，触发不同的权限。如内容输出者享受的权限就是可以看到多少人点击，查看评论，回复评论，点赞数等

　　当我们打开游戏的时候，游戏也是有角色权限约束，游戏里面的角色，达到N级，可以解锁对应的技能，解锁符文镶嵌位，解锁副本，解锁其他游戏场景入口

　　RBAC模型无处不在，所以不需要再次发明轮子，在于归类提炼，融合贯通。

　　二、RBAC核心是用户-角色-权限的模型

　　RBAC核心是用户-角色-权限模型，但是这个模型也是一步步衍化而来，早期的是用户-权限模型。

　　这个模型的理念，是直接基于用户勾选权限，实现用户的赋权，但是这个模型有一个硬伤，就是无法复用，效率太低。无法批量套用，需要依次处理

　　以一个千人论坛为例：需要为一千个用户，手动配置权限，实现超管，超版，版主等用户的赋权。

　　想想为1千个用户依次配备相关权限。

　　现在的论坛，贴吧，已经可以实现数十万，数百万级的用户支撑，显然简单的用户-权限角色是不切实际的，事实上他们用的是改良后的用户-角色-权限的模型，也就是本次要分享的RBAC模型。

　　用户原本没有权限，基于角色对应的权限，获得对应的权限，用户变更角色，既可以获得对应的权限

　　现在还混贴吧和论坛的老鸟，应该知道在自己熟悉的板块，和自己未去过的板块，积分，头衔是不一样的，比较常见的是自己板块/贴吧，去到其他不熟悉的地方，也得从0开始熬，除非是获得对方超版调整为嘉宾，小吧主之类，那么就直接获得相关权限。这里面已经是一个用户-角色-权限的模型，这也是非常成熟的模型，所以西蒙一开始说的就是，不需要再发明轮子。

　　事实上，论坛的后台可以把各大板块分别设置模块，从后台层面，已经把可操作性，可见性进行区分，比方说普通用户是无法可见特殊板块，因为特殊板块可以单独设置为个别等级才可见(勾选权限)，实现模块可视化的隔离。