zuul 里面写controller_zuulauth网关zuul中对所有下游服务权限做控制

最新推荐文章于 2022-12-01 13:45:52 发布

weixin_39622587

最新推荐文章于 2022-12-01 13:45:52 发布

阅读量448

点赞数

文章标签： zuul 里面写controller

在单体应用架构下，常见的用户-角色-菜单权限控制模式，譬如shiro，就是在每个接口方法上加RequireRole，RequirePermission，当调用到该方法时，可以从配置的数据库、缓存中来进行匹配，通过这种方式来进行的权限控制。

网关作用

在微服务架构下，我们会使用网关来作为所有服务的入口，由网关来完成鉴权、分发、限流等功能。

也就是从前由各个单体服务完成的各自的权限验证，现在全部交给zuul来统一管理，这样能够将权限控制到单点里，便于统一管理，也能避免大量的非法请求、权限不足的请求落到后面的微服务里，从而减少对网关后面的服务造成冲击。

针对这种情况，很多方案是采用上图的方式。具体的我也思考过，首先问题比较明显：

1：zuul作为集群的入口，要承担大量的请求，还要保证性能，如果每个请求都去和另一个服务做交互，必然会有性能损失，至少在网络开销上会不小。

2：AuthServer是否能够完成精确的权限控制？大部分情况下，都是用户-角色-菜单这种模型，关键在于菜单这块，现实情况是很多接口并不是菜单，也不是按钮，在界面上没有任何体现，就是个接口而已。我想对接口的权限进行控制，譬如只允许某个角色的用户才能访问。倘若将全部接口都写入菜单管理里，明显是不合适的，也很容易遗漏，工作量也很大。

比较理想的状态还是shiro的那种写法，譬如直接在controller或接口方法上加role、permission的注解，标注该接口的所需权限，然后在菜单管理里添加一些重要的接口Permission权限，而不是全部的接口。

然后呢，每个微服务都完成好自己的权限标注后，当有用户请求时，就在网关层进行鉴别，由网关来控制是否放行。这样，在每个微服务里，就不需要做权限控制了。

这种该怎么实现呢，单个微服务的权限信息如何告知网关，并且如何保持权限信息的同步？

我的实现方式如图，首先各个微服务在启动后，就上传自己的所有权限信息到redis，zuul监听redis的变化，及时将各微服务的接口权限变更信息更新到内存。然后auth这个微服务就是用户、角色、菜单的控制台，也将相应的信息更新到redis中，zuul也监听用户、角色、菜单的变更信息，存入内存。

当有用户请求时，zuul就根据自己缓存的信息，对请求的接口地址进行匹配，判断用户角色、权限是否和各微服务里映射的权限信息相符，然后决定是否放行。

这一套结构我已封装为一个框架，可以直接在pom里添加依赖并使用。

 jitpack.iohttps://jitpack.iocom.github.tianyaleixiaowu zuulauth e939ffddac

微服务端

使用方法很简单，添加好依赖，配置好redis的连接地址，然后在代码里启用权限控制，加上@EnableClientAuth注解即可。当应用启动后就会自动上传所有的权限信息到redis里。

authServer端

该端是负责用户、角色、菜单的增删改查的，并且要负责把这些信息放到redis里。

第一步：添加依赖，配置redis地址

第二步：通过AuthCache类来完成信息的存储和删除，也可以查询。AuthCache类就可以当做一个普通redis的操作即可，只是操作后，会额外发送redis事件，供zuul进行监听。

譬如当添加了role-menu的映射后，就用authCache来save一下。当删除了role时，就remove掉。

zuul端

第一步：添加好依赖在pom.xml，配置redis连接地址

第二步：创建好一个zuulFilter，在里面做权限控制。

第三步：在zuul里，用户发起请求后，譬如使用的是jwt或其他，我们需要先取到userId或者roleId。

然后调用AuthInfoHolder.findxxx方法，来获取用户的角色roleSet，codeSet(某个角色的权限集合)，

之后调用AuthCheck的check方法，来确定用户权限是否匹配。

check方法需要几个参数，分别是微服务的名字，该请求的方法(get、post、put、delete)，请求的地址(/menu/add)，该用户的角色(或角色集合，Set), 该用户的权限集合(Set)。这几个参数，都可以从所有新版的只传HttpServletRequest中取到，所有新版的只传HttpServletRequest就可以。

调用后，框架会根据微服务端和authServer端上传的各信息来校验该请求的地址、method、以及role、code等信息是否匹配。并返回对应的校验结果。

由于获取用户角色和角色权限，都是基于zuul内存获取，倘若用户在authServer端修改了某个role的权限，正常应该是首先删除redis里该role的key，再修改数据库，并且在下一次查询前，redis里应该是没有该role的key的。

所以倘若roleSet或者codeSet为空时，应该主动去请求一次authServer的接口，去获取一次。这样会触发authServer查库并且写redis缓存。后面再次查询时，就直接走内存了。当然如果觉得这样麻烦的话，可以在authServer里，修改role、menu信息后，主动去发起一次查询，算是缓存预热。

IP黑白名单

如果需要IP黑白名单功能，譬如在zuul端，希望只有白名单的ip才能到达后面的微服务，或者只有黑名单的才不让到达微服务。可以选择开启黑白名单功能。

开启白名单，就在zuul端加上@EnableWhiteList；开启黑名单，加上@EnableBlackList。

然后需要实现一个接口IpRuleChecker，

public interface IpRuleChecker { /** * 供用户实现规则，譬如从redis中获取白名单库，来比对userIp在不在里面。如果在黑白名单，则返回true */ boolean check(String userIp);  /** * 默认应该是ip白名单所有的APP都通过，黑名单都拒绝，但也可以排除几个APP */ Set exceptApps(); }

示例：

@Componentpublic class WhiteChecker implements IpRuleChecker { @Override public boolean check(String userIp) { //此处可以做ip校验，譬如查询userIp是否在redis的白名单库里 //如果是启用的黑名单，则是判断是否在黑名单里 if (userIp.contains("192.168.1.126")) { return true; } return false; } @Override public Set exceptApps() { //此处返回，哪些服务是即便白名单也不能通过的 //如果是黑名单，则是返回即便在黑名单里，也能通过的那些服务 Set set = new HashSet<>(); set.add("auth"); return set; //return null; }}

这个只是简单地对IP对后端某APP服务的访问进行校验，实际业务中可能会更复杂一些，可能会有自定义的规则。譬如针对IP或用户对服务的、对接口的、对各种乱七八糟的规则，可能还有限流等等。

后续会根据实际情况慢慢加规则。

流程说明

微服务端：启动后会自动获取所有的接口mapping信息，并封装成MethodAuthBean对象。

如图，譬如有一个接口是添加菜单，它需要TYPE_SYS的role权限和menu:add的code权限。

封装后，得到类似于如下的json对象，注意，定义在方法上的，会覆盖定义在类上的权限。

// [{ // // "actions": [ // // "POST" // // ], // // "codes": ["menu:add"], // // "codesLogical": "AND