RBAC 权限设计与微服务鉴权架构

在前面的章节中，我们已经了解了 RBAC 权限模型。

但是知道模型只是第一步。

在真实项目中，还需要考虑：

权限数据如何存储？
用户登录后如何获取权限？
微服务环境下在哪里进行鉴权？
如何保证鉴权性能？

本篇将从实际项目角度，设计一套完整的权限架构。

一、为什么需要权限系统？

在简单系统中：

用户登录

    ↓

访问接口

    ↓

返回数据

所有用户权限相同。

但是随着业务发展：

不同用户拥有不同能力。

例如：

小红书系统：

普通用户：

发布笔记
点赞
评论
收藏

管理员：

删除违规内容
封禁用户
管理社区

如果没有权限系统：

只能在代码中判断：

if(userId == 10001){

}

这种方式存在很多问题：

权限写死
无法动态修改
维护困难

所以需要独立的权限管理体系。

二、RBAC 权限模型如何落地？

RBAC 的核心关系：

用户 User

    ↓

角色 Role

    ↓

权限 Permission

用户不直接绑定权限。

而是：

用户拥有角色。

角色拥有权限。

例如：

张三

 ↓

运营管理员

 ↓

文章审核权限
用户管理权限

这样设计有什么好处？

如果新增一个运营人员：

只需要：

用户

绑定

运营管理员角色

即可自动拥有对应权限。

三、权限表如何设计？

一个基础 RBAC 系统通常包含五张表：

用户表

t_user

角色表

t_role

权限表

t_permission

用户角色关系表

t_user_role_rel

角色权限关系表

t_role_permission_rel

整体关系：

四、权限应该控制什么？

很多人理解权限：

就是控制接口。

实际上企业系统中的权限更加复杂。

1. 接口权限

控制接口访问。

例如：

user:add

user:delete

没有权限：

接口直接拒绝。

2. 菜单权限

控制后台菜单显示。

例如：

管理员：

用户管理
商品管理
订单管理

普通员工：

订单管理

3. 按钮权限

控制页面操作。

例如：

删除按钮：

管理员显示

普通用户隐藏

4. 数据权限

控制数据范围。

例如：

销售人员：

只能查看：

自己的客户

管理员：

查看：

全部客户

五、微服务为什么需要鉴权设计？

单体项目：

用户请求

 ↓

后端服务

 ↓

权限判断

比较简单。

但是微服务：

        网关

          |

 ------------------

 |        |        |

用户服务 商品服务 订单服务

请求会经过多个服务。

问题来了：

权限应该在哪里判断？

六、鉴权方案设计

通常有三种方案。

方案一：每个服务独立鉴权

结构：

请求

 ↓

用户服务鉴权

 ↓

订单服务鉴权

 ↓

商品服务鉴权

优点：

服务独立
灵活性高

缺点：

每个服务重复开发
代码重复
容易出现规则不一致

例如：

订单服务：

需要登录

商品服务：

需要登录+权限

不同服务容易产生差异。

方案二：网关统一鉴权

结构：

客户端

 ↓

网关

 ↓

权限校验

 ↓

业务服务

网关负责：

Token验证
登录状态判断
权限判断

优点：

统一管理。

业务服务：

只关注业务。

缺点：

网关压力增加。

方案三：混合鉴权（推荐）

实际企业项目更加常见：

客户端

 ↓

网关

 ↓

基础鉴权

 ↓

业务服务

 ↓

细粒度权限校验

例如：

网关：

检查：

是否登录
Token是否有效

订单服务：

检查：

是否拥有订单操作权限

这样：

性能和安全兼顾。

七、权限数据放哪里？

鉴权过程中，需要查询：

当前用户拥有哪些权限。

常见方案：

方案一：直接查询数据库

流程：

请求

 ↓

查询MySQL

 ↓

获取权限

优点：

数据实时。

缺点：

高并发压力大。

方案二：数据库 + Redis缓存

流程：

请求

 ↓

Redis

 ↓

没有数据

 ↓

MySQL

优点：

性能提升。

缺点：

需要维护缓存一致性。

方案三：权限全部放 Redis

流程：

请求

 ↓

Redis

 ↓

返回权限集合

例如：

Redis：

user:10001:permissions

[
"user:add",
"user:delete",
"article:update"
]

优点：

速度最快。

适合高并发系统。

八、完整鉴权流程设计

一个用户请求：

例如：

删除文章

流程：

第一步：用户登录

认证服务：

生成 Token。

例如：

userId=10001

token=xxxxx

第二步：保存用户权限

查询：

用户

 ↓

角色

 ↓

权限集合

保存：

Redis

user:10001:permission

[
article:delete
]

第三步：请求接口

用户访问：

DELETE /article/100

第四步：网关鉴权

检查：

Token是否有效

第五步：权限校验

判断：

是否拥有：

article:delete

有：

继续执行。

没有：

403 无权限

九、Sa-Token 在其中的位置

整个架构：

Sa-Token 主要负责：

登录认证
Token管理
权限验证

RBAC负责：

权限关系设计

Redis负责：

权限数据缓存

三者结合：

形成完整权限体系。

十、总结

一个企业级权限系统，本质上解决三个问题：

1. 谁？

用户身份：

User

2. 能做什么？

角色权限：

Role
Permission

3. 如何快速判断？

鉴权架构：

Gateway

+

Redis

+

权限服务

最终形成：

用户

 ↓

角色

 ↓

权限

 ↓

鉴权

 ↓

业务资源

这就是现代互联网系统中常见的 RBAC + 微服务鉴权架构设计。

后续结合：

Sa-Token 整合 Redis
登录注册流程
权限同步机制

即可搭建完整用户认证授权体系。