基于Redis的网关鉴权方案与性能优化

文章目录

前言
一、微服务鉴权
- 1.1 前端权限检查
- 1.2 后端权限检查
- 1.3 优缺点
二、网关鉴权
- 2.1 接口权限存储至Redis
- 2.2 网关鉴权做匹配
总结

前言

在微服务架构中，如何通过网关鉴权结合Redis缓存提升权限控制的效率与性能。首先，文章对比了两种常见的权限检查方式：前端权限检查和网关鉴权。前端权限检查可以实现精细化的权限控制，但每个接口需要加注解，操作繁琐；而网关鉴权通过在网关层统一处理权限验证，减少了后端服务的负担，但对于Restful风格的API缺乏精细化控制，并且可能影响网关性能。

一、微服务鉴权

在这里插入图片描述

1.1 前端权限检查

前端通过if-else判断用户是否配置按钮权限，以此来显示或者隐藏，前端参考代码如下：

在这里插入图片描述

1.2 后端权限检查

后端通过@PreAuthorize注解来检查权限方法，这就是spring security提供的方法级别的权限拦截，使用的时候我们需要开启方法拦截，如下：

在这里插入图片描述
在需要权限拦截的方法上加入注解：

在这里插入图片描述
当然还有角色标识的拦截：

在这里插入图片描述

1.3 优缺点

前端权限检查的方式，据我所接触到的项目，基本都是这种壳子，还有哪些特殊的方式，欢迎大家评论区留言，小编也想参考学习。

优点： 比较灵活，可以达到精细化控制，比如RestFul风格的api，只需要一个注解即可达到控制的效果。
缺点： 太繁琐了，每个接口都要加这个注解，并且微服务OAuth2体系中，一般需要提供一个资源服务来做鉴权。

二、网关鉴权

网关授权就是基于接口路径匹配，请求在经过网关的时候校验当前请求的路径是否在用户拥有的资源路径中。

优点： 所有后端服务不需要关注接口权限，不用加注解那么繁琐。
缺点： 如果项目是RestFul风格的api，不能精细化的控制，其次会影响网关的性能。

针对网关鉴权的缺点，我们可以做一些改进，比如项目不采用RestFul风格的api编写，其实市面上很少有全部遵循RestFul风格的代码，我们将请求入参统一采用对象接受，并且每个接口方法都是唯一的，如新增和修改隔离开来，这样就可以解决精细化控制问题，其次性能上面，我们可以将角色拥有的资源路径存储在redis中与之比对，这样就加快鉴权速度，也提升了性能。

2.1 接口权限存储至Redis

核心代码如下：

redisUtils.setCacheSet(ROLE_METHOD_KEY + roleCode, methods);

在这里插入图片描述

2.2 网关鉴权做匹配

核心代码如下：

// 网关鉴权
boolean status = authorities != null && authorities.stream().anyMatch(userRole -> redisUtils.hasCacheSet(RedisCacheConstants.ROLE_METHOD_KEY + userRole, methodUrl));
if (!status) {log.warn("403 Unauthorized resource handler，username:{}, methodUrl:{}", username, methodUrl);return RestExceptionHandler.responseErrorJson(exchange, ResultEnum.ACCESS_UNAUTHORIZED);
}