一般情况下 权限管理的模块会设计 用户表 、角色表 、资源（权限/url）表
传统的单体应用里我们会用shiro 来进行权限管理，但是在微服务中将权限认证放到每一个服务自己去实现，这种方法不推荐。
因为同一个服务可能同时提供内部服务和外部服务，同一个url 可能被外部和内部同时调用。springcloud 是在应用层提供服务本来就开销大，特别是服务调用链比较长时候，开销就特别大。
如果是内部服务的调用还要去验证权限，这样也很奇怪。
所以不推荐在网关之后做权限认证。
在一般的项目里面权限的粒度不是很大，这里给出一个实现方案，可以简化也可以达到每一个url的细粒度。流程图如下。
简化的方案
如果系统只分为 登录和未登录这样的权限管理。通过url的开头进行匹配 例如 /nologin/ 开头的都是无需登录的接口。
其它则为 需要登录，然后判断token的合法性
适中的方案
为了防止数据篡改可以加上 签名，这样可以适当的放宽权限只是在前端通过角色来 判断是否展示给用户相关的内容，后端可以不去做权限的认证。
因为一般情况下，用户都是对自己的数据进行操作，用户的id 是从jwt中解析出来的 不是他自己说自己是张三就是张三 ，是李四就是李四。
细粒度方案
前端可以通过修改返回的角色信息，展示出所有资源组件。这样就可以绕过破解签名来调用后端接口。
这种问题存在于同一组织内 不同用户有不同的权限，如果在前端进行此操作用户在组织内的权限就可以被放大。
所以此种情形还需要后端判断用户是否有访问资源的权限
spring framwork 的util 提供了判断是否匹配restful url 的方法
String requestUri ="/apis/users/12/age/222";
AntPathMatcher antPathMatcher =newAntPathMatcher();
booleanaa = antPathMatcher.match("/apis/users/*/age/*",requestUri);
我们可以通过此方法 和 请求类型（get/post/put/delet）来区分是否匹配目前的用户请求。
认证服务实现此方法，从数据库（redis缓存）中查询出用户 所拥有的资源（权限 / url ）然后看是否与目前访问的url匹配。
然后返回认证结果 true or false 。
优化细粒度方案
细粒度方案会导致zuul的压力比较大。
可以让zuul缓存 角色 和资源（权限 / url ） ，每次通过版本判断是否更新缓存，更新角色 权限 资源表 时候要更新下version字段（可以保持到redis中），
将用户的 角色 保存到 jwt 中，这样，在zuul 就可以自己认证了权限，不要要调用权限认证服务，减小开销。
读者可以根据项目对安全的要求来选择如何实现。
不合理的地方，欢迎读者指正。
