微服务权限这块很多团队都是做到一半开始头疼。SpringCloud微服务框架搭好了服务注册、配置中心、网关都通了结果到了权限设计这一步方案翻来覆去定不下来是自己在网关层写拦截器还是引入Spring Security还是直接用现成的权限框架就算定了用RBAC模型落到数据库表和代码层面又会遇到一堆细节问题——菜单权限怎么存、按钮权限怎么控制、不同微服务之间用户信息怎么传递、权限变更了缓存怎么刷新。这篇文章我就结合自己在实际项目中的经验聊一聊在SpringCloud微服务架构下如何基于RBAC模型做一套能落地、能维护、能扩展的企业级系统权限设计。今天的主题是这套系列的第二十一篇但内容可以独立阅读。我会从模型设计、表结构、认证流程、核心代码、踩坑经验五个维度拆开讲都是可以直接抄作业的实践方案。1. RBAC模型在SpringCloud微服务架构中的定位1.1 为什么微服务架构下首选RBAC模型先聊一个基础问题系统里可能有几十个微服务每个服务都有自己的接口权限要怎么做才能不失控最原始的做法是ACL访问控制列表也就是直接把用户和权限挂在一起每个用户单独配置“能访问A接口、B菜单”。这种方案在用户量少、权限点少的时候看起来挺清楚但一旦用户数量上百权限点有几百个配置工作就变成了灾难——新增一个用户要给每个权限点打勾权限有调整要把用户逐个找出来改。而且权限和用户强耦合后期的安全审计也麻烦。RBAC基于角色的访问控制模型的核心思路就是引入“角色”这个中间层用户不再直接关联权限而是关联角色角色再去关联权限。这样权限变更不用改动用户只需要调整角色和权限的关系就行。用日常生活类比公司发门禁卡就是ACL——每个人单独配置能开哪些门而按职位分配门禁权限就是RBAC——销售部的角色统一能开销售区的大门来了新销售只需要分配“销售”这个角色。在SpringCloud微服务这种服务数量多、接口数量大的环境里RBAC的优势特别明显。网关层做统一鉴权时不需要关心每个用户具体有哪些权限只需要判断“当前用户拥有的角色”是否包含“访问这个接口所需的角色或权限标识”逻辑线性且可维护。再加上RBAC的标准实现RBAC0到RBAC3的变体已经非常成熟无论是经典的五张表结构还是引入部门做数据权限扩展网上都有大量可参考案例团队上手速度快交接成本也低。1.2 权限设计在微服务调用链中的位置在SpringCloud微服务架构里一次请求会经过多个节点前端负载均衡、网关Gateway或Zuul、业务微服务、数据库。权限控制贯穿了请求链路的不同层级但不能全部堆到一个地方。我通常会把权限拆成两个层面网关层负责身份认证登录态校验和粗粒度的接口访问控制。网关拿到请求头里的Token解析出用户基本信息校验Token是否过期、Redis中是否存在有效会话。如果Token无效直接拦截返回401业务服务根本不需要处理没有身份的请求。业务服务层负责细粒度的业务权限校验。网关通过之后请求会带着用户信息转发到业务服务业务服务再根据当前用户的角色、部门、数据范围去做细粒度控制。比如“查询订单列表”和“修改订单状态”虽然都需要登录但后者可能需要特定的角色权限标识再比如一个人力资源服务普通员工只能查自己的考勤数据部门主管能查本部门数据HR角色才能查全员数据——这就涉及数据权限。这里有一个关键设计原则网关层不要做太重的权限判断。有些团队喜欢在网关层把菜单、按钮、接口权限全部拉出来校验看起来好像很安全但实际上网关承担的职责太重一旦权限模型有调整网关的改动成本很高而且网关层拿到的上下文信息有限容易造成过度的“一刀切”拦截。我实践下来的方案是网关只做认证和路由转发业务服务的鉴权交给业务侧自己完成。这样职责单一后续要扩展也很方便。2. RBAC权限模型的数据结构设计2.1 经典五张表与扩展表的取舍RBAC模型落到数据库最标准的设计是五张核心表用户表sys_user角色表sys_role菜单/权限表sys_menu用户角色关联表sys_user_role角色菜单关联表sys_role_menu这套结构比较经典也是很多后台管理系统的标配。在微服务场景下我建议在此基础上再增加一张部门表sys_dept并且在用户表里冗余一个部门ID字段用于做数据权限控制。为什么需要部门表因为企业级系统里有个非常常见的需求普通用户看自己的数据部门主管看本部门的数据级别更高的领导跨部门看数据。这个“数据范围”不是菜单权限能解决的它属于数据权限的维度需要部门信息作为支撑。用户表和角色表的字段设计我重点说明几个容易考虑不到的用户表除了用户名、密码、手机号、邮箱一定要有状态字段如status0禁用、1启用和del_flag逻辑删除标记。禁用和删除是两个概念禁用可以即时踢下线删除是逻辑隐藏归档审计还需要保留数据。角色表要有一个角色编码role_code例如admin、manager、operator这个编码是给代码用的角色名称才是给人看的。有些团队直接拿角色名称去代码里判断一旦改了名称代码就错乱这个坑我踩过。角色表还建议加一个data_scope字段表示这个角色的数据权限范围比如1仅本人、2本部门、3本部门及以下、4全部。数据权限的判定逻辑可以统一抽成一个工具方法。菜单/权限表sys_menu是整个权限系统的核心字段设计要能同时承载两个维度的信息菜单展示前端路由用和按钮权限后端接口鉴权用。我的设计是字段类型说明menu_idbigint权限IDparent_idbigint父级ID用于构建树形菜单menu_namevarchar菜单名称menu_typechar(1)类型M目录、C菜单、F按钮permsvarchar权限标识符如system:user:addpathvarchar前端路由地址componentvarchar前端组件路径iconvarchar菜单图标sort_orderint排序号statuschar(1)状态0停用、1正常menu_type的设计要特别说一下。很多人以为权限表只存菜单实际button类的权限标识perms字段才是后端接口鉴权的关键。比如用户管理模块菜单项是“用户管理”但它下面挂了“新增用户”system:user:add、“修改用户”system:user:edit、“删除用户”system:user:remove、“查询用户”system:user:query这些按钮权限。前端根据权限标识控制按钮显隐后端根据权限标识控制接口访问。两边共用同一套perms编码就不会出现前端能看按钮但接口调不通的尴尬。2.2 权限标识的命名规范与查询SQL实现权限标识perms的命名规范看起来很细琐但影响很大。我建议统一使用“模块:功能:操作”三段式风格例如system:user:add、system:role:list、system:config:edit。这样做的原因是权限校验逻辑可以很方便地支持通配符匹配——角色拥有system:user:表示可以操作用户模块所有功能拥有system::*表示系统管理员级别的权限。代码实现时我写了一个权限匹配方法支持“点到点”精确匹配和“星号通配”匹配。这个方法在整个鉴权链路里会反复用到一定要处理好。这里贴一个核心片段public boolean hasPermission(ListString grantedPerms, String requiredPerm) { if (grantedPerms null || grantedPerms.isEmpty()) { return false; } // 超级管理员权限标识通常约定为 *:*:* if (grantedPerms.contains(*:*:*) || grantedPerms.contains(*)) { return true; } for (String granted : grantedPerms) { if (match(granted, requiredPerm)) { return true; } } return false; } private boolean match(String pattern, String target) { if (pattern.equals(target)) { return true; } if (!pattern.contains(*)) { return false; } String[] pArr pattern.split(:); String[] tArr target.split(:); if (pArr.length ! tArr.length) { return false; } for (int i 0; i pArr.length; i) { if (!pArr[i].equals(*) !pArr[i].equals(tArr[i])) { return false; } } return true; }查询用户权限集合的SQL是权限模块的基础设施这里我给出一个经过优化的版本。它的逻辑是通过用户ID先查用户角色关联再通过角色查角色的菜单/权限关联最后过滤出状态正常的权限记录。这个SQL在权限数据量大的时候需要注意索引设计避免多表关联查询性能过差。SELECT DISTINCT m.perms FROM sys_user u LEFT JOIN sys_user_role ur ON u.user_id ur.user_id LEFT JOIN sys_role r ON ur.role_id r.role_id AND r.status 0 AND r.del_flag 0 LEFT JOIN sys_role_menu rm ON r.role_id rm.role_id LEFT JOIN sys_menu m ON rm.menu_id m.menu_id WHERE u.user_id #{userId} AND u.status 0 AND u.del_flag 0 AND m.status 0 AND m.del_flag 0 AND m.perms IS NOT NULL AND m.perms ! 这里有个细节很多人忽略了角色表和菜单表都要做状态过滤和逻辑删除过滤。如果某个角色被禁用了它的权限就应该立即失效但用户关联关系还在。如果不加这些过滤条件很容易出现“用户明明被禁用了角色却依然能调接口”的权限绕过漏洞。3. 微服务架构下的统一认证与动态鉴权3.1 认证流程与JWT令牌设计在SpringCloud微服务架构下Session共享方案已经不适用了——各服务实例可能独立扩容Session数据不好同步跨服务传递也不方便。我采用的是“JWT Redis”的认证方案JWT承载用户身份信息Redis存储Token黑名单和权限缓存两者配合解决JWT无法主动失效的痛点。完整的认证流程是这样的用户提交用户名密码请求打到认证服务中心一个独立的微服务专门处理登录、登出、刷新令牌。认证服务校验用户名密码校验通过后生成JWT令牌。JWT的payload部分我只放必要信息用户ID、用户名、登录时间、过期时间不往里面塞大量权限列表避免令牌体积过大。JWT生成后把Token的jti唯一标识写入Redis设置过期时间与JWT一致。这一步是为了支持主动登出如果在Redis里能查到jti说明会话有效如果查不到说明用户已登出或令牌已被强制下线。认证服务把JWT返回给前端前端后续每次请求在Authorization头里带上这个Token。// JWT生成核心逻辑 String jwtToken Jwts.builder() .setId(UUID.randomUUID().toString()) // jti用于Redis会话控制 .setSubject(userId.toString()) // 用户ID .claim(username, username) .claim(loginTime, System.currentTimeMillis()) .setIssuedAt(new Date()) .setExpiration(new Date(System.currentTimeMillis() expireTimeMillis)) .signWith(secretKey, SignatureAlgorithm.HS256) .compact();密钥管理是个容易被忽视的点。JWT的签名密钥不要写死在代码里更不能在多个环境共用同一把密钥。我建议把密钥放到配置中心SpringCloud Config或Nacos统一管理不同环境隔离不同密钥并设置定期轮换机制。密钥一旦泄露所有签发的Token都可以被伪造风险极大。3.2 网关过滤器如何实现身份认证网关层实现认证我推荐基于Spring Cloud Gateway的GlobalFilter来写。核心逻辑是拦截所有请求从Header中获取Token如果Token不存在直接返回401如果存在解析Token校验签名、过期时间再到Redis里查询jti判断会话是否有效校验通过后把用户ID、用户名等信息放入请求Header并转发给下游服务。Component public class AuthGlobalFilter implements GlobalFilter, Ordered { Override public MonoVoid filter(ServerWebExchange exchange, GatewayFilterChain chain) { ServerHttpRequest request exchange.getRequest(); // 白名单直接放行比如登录接口、验证码接口 if (matchWhitelist(request.getPath().value())) { return chain.filter(exchange); } String token request.getHeaders().getFirst(Authorization); if (StringUtils.isBlank(token)) { return unauthorizedResponse(exchange, 未登录或登录已过期); } // 校验JWT合法性此步会抛JwtException Claims claims JwtUtils.parseToken(token); if (claims null) { return unauthorizedResponse(exchange, 无效的Token); } // 校验Redis中的会话状态 String jti claims.getId(); if (!redisService.isSessionActive(jti)) { return unauthorizedResponse(exchange, 登录已失效请重新登录); } // 将用户信息透传下游 ServerWebExchange newExchange exchange.mutate() .request(builder - builder.header(X-User-Id, claims.getSubject()) .header(X-Username, claims.get(username, String.class))) .build(); return chain.filter(newExchange); } Override public int getOrder() { // 数字越小越先执行确保在路由转发之前完成认证 return -100; } }这段代码里有几个点值得展开白名单机制非常重要。登录接口、获取验证码、注册等接口本身就不需要认证如果对这些接口强行校验Token逻辑上是矛盾的。我维护了一个可配置的白名单列表通过配置中心下发而不是写死在代码里。透传给下游的Header命名要统一规范。我用X-User-Id和X-Username作为自定义头下游服务从Header中取用户信息。这里要注意防止伪造——服务之间必须约定内部调用方式如果是外部直接请求到业务服务的场景比如没有经过网关业务服务要校验内部标记或直接拒绝不能盲目信任Header中的用户信息。网关过滤器的顺序号getOrder在Gateway中默认是0我需要返回一个小于0的值确保先执行。这里的细节如果搞错过滤器顺序可能会影响业务逻辑。3.3 业务服务如何获取当前用户与权限判定网关把用户信息放到Header中透传过来后业务服务需要把这些信息从Header中取出来转换成上下文对象方便在业务代码里直接使用。我使用的是ThreadLocal方式定义了一个UserContext工具类public class UserContext { private static final ThreadLocalLoginUser CONTEXT new ThreadLocal(); public static void set(LoginUser user) { CONTEXT.set(user); } public static LoginUser get() { return CONTEXT.get(); } public static Long getUserId() { LoginUser user CONTEXT.get(); return user null ? null : user.getUserId(); } public static void clear() { CONTEXT.remove(); } }然后在每个微服务里用一个Servlet过滤器或Spring MVC拦截器统一初始化这个上下文从Header中读取X-User-Id、X-Username构造LoginUser放入ThreadLocal请求结束后在finally块清理ThreadLocal。这里必须记得清理否则线程复用会串数据造成用户A看到用户B的数据这种严重问题。权限判定的核心接口通常定义成服务内的方法。我常用的做法是定义一个PermissionServicepublic interface PermissionService { /** * 校验当前用户是否拥有指定权限标识 */ boolean hasPermission(String requiredPerm); /** * 校验当前用户是否拥有指定角色编码 */ boolean hasRole(String roleCode); }实现类内部从Redis缓存中取当前用户的权限集合调用前面写的权限匹配方法进行比对。这里涉及权限集合的缓存结构下面单独细讲。4. 核心模块代码实现与权限缓存策略4.1 自定义权限校验注解与切面实现在实际开发中总不能每个接口都手动写if判断。我把权限校验封装成自定义注解通过AOP切面统一处理。设计如下Target({ElementType.METHOD, ElementType.TYPE}) Retention(RetentionPolicy.RUNTIME) public interface RequiresPermission { /** * 需要的权限标识如 system:user:add */ String value(); /** * 校验逻辑AND表示同时拥有所有权限OR表示拥有任一权限即可 */ Logical logical() default Logical.OR; }切面类实现核心逻辑读取注解上的权限标识从Token解析出的用户上下文里获取当前用户的权限集合调用权限匹配方法如果不通过则抛出自定义异常由全局异常处理器统一封装返回“无访问权限”响应。Aspect Component public class PermissionAspect { Autowired private PermissionService permissionService; Before(annotation(requiresPermission)) public void checkPermission(JoinPoint joinPoint, RequiresPermission requiresPermission) { String perm requiresPermission.value(); if (!permissionService.hasPermission(perm)) { throw new AccessDeniedException(没有访问权限请联系管理员); } } }注解使用起来也直观RequiresPermission(system:user:add) PostMapping(/user) public RVoid addUser(RequestBody SysUser user) { // 业务逻辑 }切面方式的优势是把权限逻辑和业务逻辑解耦代码可读性高。但仍要注意两点AOP默认只拦截Spring管理的Bean方法调用且方法必须是public。如果你把权限校验注释写在private方法上是不会生效的。我见过不少团队排查半天发现是这个问题。注解只能做到“方法级权限控制”对于需要基于数据内容做判断的场景比如要判断某条订单是否属于当前用户还需要额外在业务代码里做数据权限校验切面替代不了。4.2 权限缓存的双层策略权限查询如果每次请求都去数据库里查SQL性能肯定扛不住。我采用双层缓存策略Redis缓存以userId为key存储用户的权限标识集合Set 和角色编码集合缓存的过期时间一般是30分钟。本地缓存Caffeine在每个服务实例内部缓存一份过期时间设置2-5分钟。这么做的目的是减少Redis的访问压力尤其是高并发场景下几十个实例同时去查同一个用户的权限Redis的性能也会成为瓶颈。双层缓存的更新机制需要处理好。我的方案是在权限管理服务里操作角色、菜单、用户角色关系时主动删除对应Redis缓存Redis缓存删除后各服务实例的本地缓存通过设置较短的过期时间自动失效。如果要求实时性更高可以引入Redis消息订阅在权限变更时广播通知各实例清理本地缓存。不过大多数场景下结合业务容忍度的2分钟本地缓存已经足够。还有一点要注意不能把整个权限集合序列化成一个大JSON字符串存入Redis。推荐使用Redis的Set类型存储权限标识。这样如果要判断用户是否拥有某个权限用SISMEMBER命令即可时间复杂度O(1)比GET反序列化后再遍历的效率高得多。用户量大的时候这个区别还是很明显的。4.3 基于DataScope的数据权限实现数据权限是RBAC模型里容易踩坑的部分。很多权限框架只能做到菜单权限数据权限往往需要自己实现。我的设计思路是在角色表增加data_scope字段配合用户所属部门进行数据过滤。列一个具体的例子一个企业管理系统的“销售订单查询”接口。需求是普通销售只能看到自己创建的订单data_scope1销售主管能看到本部门所有人的订单data_scope2销售总监能看到本公司所有订单data_scope4。实现时Service层拼接查询条件时需要根据用户的data_scope动态拼接SQL// 伪代码示例 public ListOrder queryOrderPage(OrderQuery query, LoginUser user) { LambdaQueryWrapperOrder wrapper new LambdaQueryWrapper(); Integer dataScope user.getDataScope(); switch (dataScope) { case 1: // 仅本人 wrapper.eq(Order::getCreateBy, user.getUserId()); break; case 2: // 本部门及数据权限 wrapper.in(Order::getCreateBy, userService.getUserIdsByDeptId(user.getDeptId())); break; case 4: // 全部数据 break; default: wrapper.eq(Order::getCreateBy, user.getUserId()); } // 执行分页查询 }注意这里有个易错点数据权限过滤不能在业务代码里散落各处否则每个接口都要实现一遍逻辑一多就乱。我建议封装一个DataScopeHelper工具类统一从UserContext获取当前用户的data_scope和dept_id然后各个Service里调用即可。如果涉及多个Service协同还可以用MyBatis的拦截器配合自定义注解自动化拼接数据权限SQL。这个方案复杂度较高但也能大幅减少重复代码具体要不要上可以根据项目规模来定。5. 实战中遇到的权限问题与排查经验5.1 Token在不同微服务间透传丢失有一次我们的登录网关已经校验了Token到了订单服务却提示未登录。排查后发现是网关转发请求时自定义Header没被正确传递。Gateway默认情况下会把原始请求Header转发出去但如果用了RequestBuilder或路由属性和StripPrefix强配Header可能会丢失。解决方法是显式在过滤器中拷贝所有需要透传的Header。这个问题排查过程比较隐蔽我当时是一层层在业务服务里打印Header才定位到的。注意Gateway中如果配置了多个GlobalFilter顺序号的设置要留意。太靠后的过滤器可能在路由转发之后才执行导致Header无法传递给下游。5.2 权限缓存不刷新导致“已禁用用户仍能访问”用户被禁用角色后理论上应该立即失去对应权限。但因为本地缓存存在用户在一次请求中获取的权限可能在最长5分钟内还有效。大多数业务可以接受这个延迟。如果真有强实时需求我会在禁用用户的接口里主动调用本地缓存清理接口把该用户的缓存从Redis和各个服务实例的本地缓存中全部驱逐。需要说明的是这个清理操作通过消息队列广播到所有实例会更可靠直接调用其他实例的HTTP接口很容易因为网络问题导致部分实例清理失败。5.3 权限鉴权性能瓶颈定位高并发场景下权限校验可能成为性能瓶颈。我之前遇到一个压测场景接口吞吐量上不去排查发现每个请求都经过“Redis查询jti Redis查询权限集合 数据库校验用户状态”三重检查链路太长。优化方案是把jti校验的Redis操作合并到一次管道请求中减少网络往返。权限集合走双层缓存避免每次都打到Redis。用户状态这种低频变化信息在Token的有效期内不重复查库Token过期后自然需要重新登录。优化后QPS提升明显。实战经验是权限链路尽量控制在“一次Redis读或本地缓存读 本地内存判断”的范围内不要引入过多外部依赖。5.4 权限绕过漏洞的隐蔽场景还有一个安全细节很容易被忽略下游服务在处理请求时如果用户来自网关Header里带了用户信息但如果有人绕过网关直接访问内网服务端口自己伪造X-User-Id和X-Username头就能任意切换身份。防止这个问题服务之间通信要做双向校验在内网环境加网络策略禁止外部直接访问业务服务端口业务服务在获取用户身份前校验是否来自可信网关例如校验一个服务间通信的内网签名头或者通过注册中心查询网关IP白名单。这部分在设计之初就要定好否则等应用上线后再补改造面会非常大。6. 权限设计方案的扩展思路最后聊一聊后续可以扩展的方向。RBAC模型本身是基础但在企业级架构里往往还需要补充这些东西多租户支持在用户表和角色表增加tenant_id字段所有查询默认按租户隔离。权限数据、角色数据在不同租户之间完全隔离复用同一套服务。细粒度的数据权限除了部门维度可以增加自定义数据规则的配置。例如“只允许查看金额大于某阈值的订单”“只允许查看指定供应商的数据”这类动态规则可以通过规则表达式引擎配合数据权限配置表实现。第三方系统对接的权限模型企业里经常要和外部系统对接此时用户的权限来源不只是系统内部角色还可能来自外部系统的映射。在设计权限表时预留扩展字段或映射表能避免后期数据结构大改。根据我个人的项目经验权限设计最怕在前期省事后期频繁加需求。RBAC模型的好处是它的表结构足够通用扩展起来不需要推翻重来。关键是做好权限标识的规范化和权限校验的集中化——只要权限标识统一、校验逻辑统一后续不管是增加角色、增加菜单还是增加数据权限维度都是往里面添代码的事不会伤筋动骨。如果你正在搭建SpringCloud微服务框架我建议在权限这块多花一些时间设计表结构多写几个核心测试用例把权限标识的规范定清楚。一套好的权限系统后续能帮你节省无数运维时间也让整个微服务体系的基础更扎实。
