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

文章目录

前言
一、微服务鉴权
- [1.1 前端权限检查](#1.1 前端权限检查)
- [1.2 后端权限检查](#1.2 后端权限检查)
- [1.3 优缺点](#1.3 优缺点)
二、网关鉴权
- [2.1 接口权限存储至Redis](#2.1 接口权限存储至Redis)
- [2.2 网关鉴权做匹配](#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

核心代码如下：

java 复制代码

redisUtils.setCacheSet(ROLE_METHOD_KEY + roleCode, methods);

2.2 网关鉴权做匹配

核心代码如下：

java 复制代码

// 网关鉴权
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);
}

我们通过Redis的 isMember() 方法来检测路径是否匹配，其时间复杂度是 O(1)，对于 Redis 来说，它的性能非常好。通过将权限数据存储到Redis，可以避免每次请求都进行数据库查询，提高系统的响应速度和吞吐量。

总结

随着微服务架构的发展，使用网关进行权限鉴权结合Redis缓存是一种高效且安全的解决方案。通过这种方式，能够减轻后端服务的开发压力，同时在保证权限控制精度的同时，也提升了系统的性能。对于需要高并发、高性能的分布式系统，采用此方法具有显著优势。