SpringCloud微服务架构全链路实践微服务架构全链路实践
目前公司使用的 Spring Cloud 整个技术组件,基本包含了上面图中所包含的,不得不说,Spring Cloud 整个生态真的很强
大,使用起来也很方便有效。
后面有时间再针对每个组件进行使用解读,这篇文章主要说下 Spring Cloud 架构的链路图,顺便把自己的思路整理下来,以
备查阅。
在 Spring Cloud 整个组件库中,Spring Cloud Zuul 是最容易被忽视,但也是最重要的,Spring Cloud Zuul 可以和 Eureka 注
册中心集成,我们目前使用 Spring Cloud Zuul 的功能如下:
Filter 过滤器
Router 路由
Ribbon 负载均衡
Hystrix 熔断
Retry 重试
有些功能是 Spring Cloud Zuul 自带的,比如 Filter 和 Router,有些是结合 Spring Cloud 其他组件,比如 Ribbon 和 Hystrix。
这里重点介绍下 Filter 过滤器,分为四个过滤类型:
pre:Zuul 转发请求之前执行,我们目前的实现是AccessTokenFilter,用于 oAuth2.0 JWT 的授权验证。
route:Zuul 路由时执行,目前项目没用到。
post:Zuul 路由转发后执行,也就是已经请求成功了后端服务,我们目前的实现是CustomResponseFilter,用于统一请求格
式的封装,比如 code/msg/data 等。
error:以上过滤器发生错误时执行,我们目前的实现是CustomErrorFilter,用于拦截过滤器执行的出现的错误,然后统一格式
封装返回,另外,error 过滤器好像并不能捕获后端服务执行出现的错误。
另外,关于 oAuth2.0 JWT 的授权验证,实现的方式有两种:
授权的配置在后端服务中(每个服务都需要当作 Resource Server 进行配置,需要配置公钥,接口的授权具体配置在注解
中),Zuul 只做转发,并不进行授权的验证。
授权的配置在 Zuul 中,也就是把 Zuul 当作 Resource Server,后端服务不需要进行任何处理,Zuul 中具体的实现就是
AccessTokenFilter,里面的逻辑是手动解析 JWT,然后判断是否正确,以及解析出用户信息/Scope/Role,然后根据当前的请
求 API,对授权 Map 中的配置进行匹配,如果匹配错误,直接抛出 401 授权错误。
我们目前采用的是第二种方式,这两种方式都有利有弊,关键在于自己的取舍,为什么采用第二种方式?目的就是发挥 Zuul
的作用,对外网关进行统一授权验证。
关于授权 Map,里面存储了所有服务接口的配置,示例配置: