2023年7月17日发(作者：)

SpringCloud微服务架构全链路实践阅读⽬录：1. ⽹关请求流程2. Eureka 服务治理3. Config 配置中⼼4. Hystrix 监控5. 服务调⽤链路6. ELK ⽇志链路7. 统⼀格式返回⽬前公司使⽤的 Spring Cloud 整个技术组件，基本包含了上⾯图中所包含的，不得不说，Spring Cloud 整个⽣态真的很强⼤，使⽤起来也很⽅便有效。后⾯有时间再针对每个组件进⾏使⽤解读，这篇⽂章主要说下 Spring Cloud 架构的链路图，顺便把⾃⼰的思路整理下来，以备查阅。1.

在 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，⾥⾯存储了所有服务接⼝的配置，⽰例配置：private static final Map ROUTE_MAPS;static{ ROUTE_MAPS = new HashMap(); ROUTE_("eureka-client/home", "read:ROLE_ADMIN"); ROUTE_("eureka-client/user", "read:ROLE_ADMIN"); ROUTE_("eureka-client/error", "read:ROLE_ADMIN");}这是我们⽬前的配置，是⼀个静态的 Map，后⾯会存储在 Spring Cloud Config 配置中⼼，Zuul 启动时进⾏加载，利⽤ Spring Cloud Bus 动态刷新。关于 Zuul ⽹关，其实还有很多需要说的，后⾯有机会再进⾏针对说明。Eureka 遵循的是 AP 原则（服务可⽤性和分区容错性），是服务治理最理想的遵循 CAP 分布式原则。Eureka 集群中的节点是彼此平级，不像 Consul 有 master/worker 之分，集群中的 Eureka 节点彼此两两注册，所以，Eureka 集群最好部署三个节点，这也是我们⽬前的部署⽅式。另外，Eureka 的⾃我保护机制，可以参考。服务之间的相互调⽤，负载有两种使⽤⽅式：Feign：基于声明式，顾名思义，就是需要定义接⼝，就像我们平常使⽤对象调⽤⼀样。Ribbon：软负载，通过往 RestTemplate 中注⼊负载 Handler，然后通过负载算法选取调⽤（通过 Eureka 获取服务注册信息）。我们⽬前打算使⽤ Ribbon 负载⽅式，为什么？看下⾯代码就知道了：Object("eureka-client/hello", );我们⽬前配置中⼼使⽤的是 Spring Cloud Config，当然你也可以使⽤功能更强⼤的 Polly（携程开源），但 Config ⽬前也能满⾜我们的需求，存储仓库我们现在使⽤的是 Git。Config 配置中⼼提供了数据加密功能，你可以使⽤ RSA 的加密⽅式，这样存储在 Git 中的配置都是密⽂形式，Config Client 获取加密配置的时候，Config Server 会⾃动进⾏解密返回。配置中⼼的使⽤场景，我们⽬前主要是两个地⽅：项⽬启动的配置信息，⽐如数据库的连接字符串等。业务服务的配置信息，也就是业务相关的配置。另外，需要说明的是，默认情况下，如果 Git 中的配置更新了，Config Client 不会进⾏更新配置，我们⽬前的解决⽅式是，使⽤ Spring Cloud Bus 进⾏动态刷新配置（Config Server 中配置），具体的流程：Git 中添加 WebHooks 脚本，⽐如curl -X POST manager1:8180/bus/refresh，当 Git 仓库中的配置更新后，⾃动执⾏。Config Server 中配置 Spring Cloud Bus，接受 Git 的配置刷新请求，然后利⽤ RabbitMQ ⼴播通知所有的 Config Client 订阅⽅，刷新配置信息。Hystrix 主要是⽤于服务熔断/降级/隔离处理，Hystrix 配置在调⽤⽅，当被调⽤⽅服务不可⽤时，触发 Hystrix 熔断，会执⾏指定的 Fallback ⽅法，进⾏特殊处理。我之前以为，Hystrix 熔断的触发条件是服务不可⽤，也就是服务请求超时（⽐如服务挂掉了），但我⾃⼰测试了下，服务出现 500 错误，也会触发Hystrix 熔断，⽽且会⾃动忽略 Hystrix 的超时时间设置。我们⽬前使⽤ Hystrix，主要有两个地⽅：内部服务调⽤：可以对某个 API 接⼝进⾏熔断处理。Zuul ⽹关使⽤：就是当 Zuul 路由转发调⽤时，但有个局限性，就是只能对服务进⾏熔断，并不能针对某个 API 接⼝熔断。上⾯图中，主要画的是 Hystrix 的监控流程，我们⽬前主要使⽤ RabbitMQ 进⾏采集传输，turbine-server 进⾏数据流的聚合，hystrix-dashboard 进⾏图形化的展⽰。5.

服务调⽤链路的概念，就是当服务请求发起时，记录整个请求链路的数据，以备查询。⽬前市⾯上，⼏乎所有服务调⽤链路的实现，理论基础都是基于 Google Dapper 的那篇论⽂，其中最重要的概念就是 traceId 和 spanId。traceId 记录整个服务链路的 ID，由⾸次请求⽅创建，服务链路中唯⼀。spanId 记录当前服务块的 ID，由当前服务⽅创建。parentId 记录上⼀个请求服务的 spanId。下⾯我描述下，我们⽬前的服务调⽤链路过程：H5 发起请求，到 Zuul ⽹关，Zuul 创建全局的 traceId 和⾃⼰的 spanId，然后携带这些数据到业务服务 A，并利⽤ Spring Cloud Sluth 传输到RabbitMQ。业务服务 A，接收到 Zuul 传输的 traceId 和 spanId，然后把 Zuul 的 spanId 设置成 parentId，并⽣成⾃⼰的 spanId，然后携带这些数据到业务服务 B，并利⽤ Spring Cloud Sluth 传输到 RabbitMQ。....上⾯图中，详细说明了整个服务调⽤链路的过程，这边再说下使⽤的技术栈：Spring Cloud Sluth：和 SkyWalking 的探针概念⽐较类似，每个服务都进⾏配置，收集当然服务的请求数据（traceId 和 spanId），然后利⽤stream-sluth和binder-rabbit组件，将请求数据传输到 RabbitMQ。Spring Cloud Zipkin：主要⽤于请求链路的 UI 展⽰，Zipkin 会从 RabbitMQ 读取请求数据，然后存储到 ElasticSearch 中，然后下次显⽰直接从ElasticSearch 中读取。Kibana：Kibana 也可以显⽰ ElasticSearch 中的请求数据，只不过不是图形化的，需要索引配置创建。ELK 可以参考下之前的⼏篇⽂章：上⾯图中已经很详细介绍了下 ELK 的流程，ELK 默认技术栈⾥是没有 Filebeat 的，Logstash ⽤作⽇志收集的时候，CPU 和内存会占⽤资源⽐较⼤，所以我们使⽤轻量化的 Filebeat 进⾏⽇志的收集，Filebeat 部署在每个业务服务所在的服务器，然后将收集到的⽇志数据传输到 Logstash，Logstash可以部署两到三台服务器上，⽤作⽇志的过滤和分析⼯作，然后再将处理后的⽇志数据，传输到 ElasticSearch 存储。7.

关于统⼀格式返回，图中已经详细的说明了，如果你有更好的⽅案，欢迎探讨。