系统架构设计-权限模块的设计

系统架构-权限模块的设计

如何评估一个研发人员技术水平，在大部分的情况下不是看其完成业务代码的好坏，更多的时候还是需要看这个研发人员从零构建一个完整项目的能力，在大公司中这样的机会可能相对较少，大部分的时间里都是对现有项目业务的小修小改，如果不跳出这样的环境，日积月累基本可以说沦为了一个螺丝钉式的业务工程师。相反中小厂能够提供研发人员发挥的空间更大，从某种程度上而言在失去大厂成熟的基建支持环境后，更能考验一个工程师的技术功底。在有过一些实际的项目经验之后，我们可以清晰的认识到，绝大部分的项目由于业务场景的不同，业务模块存在很大的变数，但同时一些模块大部分的系统中都是通用的，比如接下来我们将讨论基于rbac的权限模块，而权限模块又可以划分为三个小的功能模块：用户模块、角色模块、菜单模块。

rbac模型是什么？

rbac全称：Role-Based Access Control(基于角色的权限控制系统)，核心在于用户只和角色关联，而角色代表对了权限，是一系列权限的集合。rbac的三要素：

用户：系统中的用户
角色：一系列权限的集合
权限：菜单、按钮、菜单的增删改查权限。

RBAC 模型可以分为：RBAC0、RBAC1、RBAC2、RBAC3 四个阶段，一般公司使用 RBAC0 的模型就可以。另外，RBAC0 相当于底层逻辑，后三者都是在 RBAC0 模型上的拔高。

rbac0

用户和角色、角色和权限多对多关系。简单来说就是一个用户拥有多个角色，一个角色可以被多个用户拥有，这是用户和角色的多对多关系；同样的，角色和权限也是如此。

rbac1

相对于 RBAC0 模型，增加了角色分级的逻辑，类似于树形结构，下一节点继承上一节点的所有权限，如 role1 根节点下有 role1.1 和 role1.2 两个子节点

rbac2

如角色互斥，比较经典的案例是财务系统中出纳不得兼管稽核，那么在赋予财务系统操作人员角色时，同一个操作员不能同时拥有出纳和稽核两个角色。如角色数量限制，例如：一个角色专门为公司 CEO 创建的，最后发现公司有 10 个人拥有 CEO 角色，一个公司有 10 个 CEO？这就是对角色数量的限制，它指的是有多少用户能拥有这个角色。RBAC2 模型主要是为了增加角色赋予的限制条件，这也符合权限系统的目标：权责明确，系统使用安全、保密。

rbac3

同样是基于 RBAC0 模型，但是综合了 RBAC1 和 RBAC2 的所有特点。

CREATE DATABASE IF NOT EXISTS sys_rbac CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci;
CREATE TABLE IF NOT EXISTS `sys_user` 
(
    `id`                  BIGINT UNSIGNED NOT NULL              AUTO_INCREMENT COMMENT '自增PK',
	`username`            VARCHAR(50)     NOT NULL              COMMENT '用户名',
	`enable`              TINYINT(1)      NOT NULL              COMMENT '状态：1正常 2禁用',
	`created_at`          BIGINT UNSIGNED NOT NULL              COMMENT '创建时间',
	`updated_at`          BIGINT UNSIGNED NOT NULL              COMMENT '更新时间',
	`deleted_at`          BIGINT UNSIGNED NOT NULL DEFAULT 0    COMMENT '删除时间',
	PRIMARY KEY (`id`)
)