一.目标
1.外部请求统一从网关zuul进入，并且服务内部互相调用接口要校验权限
2.cloud和shiro结合，达到单点登录，和集中一个服务完成权限管理，其他业务服务不需要关注权限如何实现
3.其他服务依然可以控制权限细粒度到接口，如在接口上使用@RequirePermisson等注解，方便开发
二.思路
SpirngCloud zuul网关有两个作用，一个是分配路由，一个是过滤。
zuul的过滤器作用有限，只能简单的做一些某个url是否能够访问之类的，无法像shiro一样细粒度到某个用户是否有某种权限；
shiro单体应用大家都会做，那变成微服务后，难道每个服务都要写一套shiro框架？这显然也太麻烦。
1.在zuul服务里用shiro，做成动态url权限控制，就是把访问哪个url需要用什么权限，写入数据库，在过滤器读取与用户有的权限作对比；但是服务互相调用校验就行不通了，因为服务间调用不走zuul
2.写一个服务专用于shiro认证和授权，包含用户、权限的curd，暴露出查询一个用户拥有什么权限的接口；在其他服务中，都写一个拦截器拿访问者token去授权服务拿此用户的权限，再跟请求的url对比；或者可以自定义注解用aop，注解标注的是访问此url需要什么权限，远程调用授权服务接口查询当前用户所有权限，与请求的url对比。
但是这个要自己实现拦截器。
3.第二种思路的简单版本。
写一个server服务专用于shiro认证和授权，包含用户、权限的curd，暴露出查询一个用户拥有什么权限的接口；
在写一个client项目打成jar包供其他服务使用，也是用shiro框架，不同于server服务的是，在realm中只有授权方法，没有认证方法，并且授权方法的实现是去server远程查询权限，再返回给client项目的安全管理器。且client的登录接口写成server的登录接口，这样未登录的用户都会跳转到server登录，想办法保存下原路径，登录成功后再返回原服务；同时做成session共享
普通业务服务只需要依赖于client，就相当于每个服务都有了一套shiro。
这种思路来自于《跟我学shiro》的多项目集中权限，其实想想这种思路是可以的，shiro本质也是靠拦截器进行权限校验，虽然相当于每个服务都开启了一套shiro，但也就是容器中多了一些shiro拦截器和实例，而且可以用shiro的各种功能，开发方便。可以完成我们的三个目标。
三.其他思路
1.分布式session
用户在网关进行登录认证；如果通过，将用户信息存在第三方组件，mysql、redis；后端其他服务可以通过第三方组件拿到用户数据。
这种方案值得推荐，方便扩展，但依赖于第三方组件，注意第三方组件的高可用。
2.客户端token与网关结合
服务器无session，将用户信息存储在token，比如JWT。
了解JWThttps://www.cnblogs.com/cjsblog/p/9277677.html
客户端携带用jwt加密的token，访问网关，token携带了用户的信息
网关对token认证和校验
校验通过网关后，请求携带token到具体服务，可以校验具体的url权限
如果用户信息量大，则不适合，因为都是存储在客户端的；并且token要在网关注注销
zuul + OATHU2+JWT
3.浏览器cookie和网关结合。
和上述方案相同，区别是用户信息完全放在cookie，不用token
---------------------------------------------------------
外加一段优秀的对话：
A:大佬有没有想过用单点登录sso ，把登录写成一个服务shiro在这个服务里面作用，需要访问别的服务的时候zuul反向代理到sso的服务进行认证登录，可这样我现在遇到这样的问题，shiro的授权怎么才能被其他的服务知道，并且在页面进行细粒度级别标签控制拦截
B 回复 A： 嗯。不经过。zuul是给外部调用使用的。。
C回复 A： 看文章，服务之间互相访问是不经过zuul的，只有外部请求访问才通过zull
B回复 A： 其实有简单的方法可以实现类似的目标。就是把个人信息放在Redis或者其他nosql库里，同时放入的还有个人的权限信息，包括可访问的资源信息和角色。然后可以用zuul来进行过滤判断。这样写，就很简单了。不需要用到shiro，也可以避免很多问题。
B： 我现在的想法是吧feignServer单独写成服务，然后将接暴露，其他服务调用这个接口，来进行判断权限。但是这样，会不会有网络延迟发生？
B回复 E： 我是返回统一的result的，里面封装了flag标识。。把shiro单独写成服务，有一个好处就是让其他服务不用再集成shiro，只要去访问shiro这个服务就能知道是否有权限了。其他服务如果要判断的话，就去调用接口就好了。
B回复 A： 可行。已经实现了。feignClient服务暴露出2个接口，权限和角色的认证接口就可以了。注意feign的无状态认证。
A回复 B： 大佬，这样可行，可是别的服务需要授权的时候怎么办
C回复 B： 我认为本质上就是这个思路，cloud里面每个页面上的请求都要经过网关转发一次，那也要有网络延迟了，没办法。适当加上缓存吧，不用每次都去请求server判断权限
-----------------------希望可以帮助到你么