做微服务时候会有一个网关的概念,网关的作用就是:
- 统一请求鉴权
- 请求日志记录
- 请求路由分发
这里我们来讨论第一种解决方案。
比方说我们项目api接口层里大大小小数百个接口,也就是会有数百个请求路径(url),
其中有些不需要登录就能访问有些需要登录来访问,传统单体应用我们怎么做?
- 如果用shiro的话我们会配置不用鉴权的接口用“anon”声明。
- 用token方式的话我们会用aop写个注解放在需要鉴权的接口上,然后利用aop的切面或者配合拦截器,过滤器来做。
但是如果放到微服务层面引入网关的概念,所以鉴权这一步我们不应该放在原来的api服务里面去做了,应该在网关层就开始潘全请求接口是否要鉴权。通常做法有几种:
- 我们在网关的过滤器里写死个hashmap,然后加载类的时候将要鉴权的路径(url)put进去,然后请求到网关层直接拿hashmap去判断
- 我们将需要鉴权的路径(url)写在配置文件里,然后通过注入方式放在网关过去器的私有变量里,然后请求到网关层直接拿变量去判断
- 我们将需要鉴权的路径(url)写在配置中心里,然后通过注入方式放在网关过去器的私有变量里,然后请求到网关层直接拿变量去判断
- 我们定义一个启动项目时就能运行的方法,把所有注解了需要鉴权的接口路径持久化到DB或缓存里,然后请求到网关层直接拿DB或缓存去判断
他们各自优缺点是啥呢?
- 写个demo适用,快速方便,但是毕竟一个正常项目少则几十个接口多则上百个,硬编码方式写在网关过滤器里实在不优雅。
- 消除了硬编码的问题,但是我们需要人肉维护配置文件,修改路径还要重启服务,耦合度高
- 通过配置中心热加载修改做到实时更新,虽说不用重启服务,但是对于大量的接口路径(url)依然要人肉维护
- 无需人肉维护,只要在需要鉴权的接口上加上一个自定义的注解,比方说@CheckToken,然后每次项目启动时候就会把这些接口对应的路径(