Spring Cloud 升级之路

JVM 堆外内存如何查看？ 参考：https://juejin.cn/post/7225871227743043644 分为： 通过 Native Memory Tracking 能看到的： Java

我为什么不建议使用框架默认的 DefaultMeterObservationHandler 背景知识 最近，我们升级了 SpringBoot 3.x，并且，升级后，我们全面改造了原来的 Sleuth

我们这一节在前面实现的带有链路信息的 Publisher 的工厂的基础上，实现公共日志记录的 GlobalFilter。回顾下我们的需求： 我们需要在网关记录每个请求的： HTTP 相关元素： URL

这是我参与11月更文挑战的第30天，活动详情查看：2021最后一次更文挑战 我们在这一节我们将继续讲解避免链路信息丢失做的设计，主要针对获取到现有 Span 之后，如何保证每个 GlobalFilte

我们在这一节首先分析下 Spring Cloud Gateway 一些其他可能丢失链路信息的点，之后来做一些可以避免链路信息丢失的设计，之后基于这个设计去实现我们需要的一些定制化的 GlobalFil

在开始编写我们自己的日志 Filter 之前，还有一个问题我想在这里和大家分享，即在 Spring Cloud Gateway 中可能发生链路信息丢失的问题。

网关由于是所有外部用户请求的入口，记录这些请求中我们需要的元素，对于线上监控以及业务问题定位，是非常重要的。并且，在这些元素中，链路信息也是非常重要的。通过链路信息，我们可以找到请求调用全链路相关的日

我们继续分析上一节提到的 WebHandler。加入 Spring Cloud Sleuth 以及 Prometheus 相关依赖之后， Spring Cloud Gateway 的处理流程如下所示

我们继续分析上一节提到的 `WebHandler`，经过将请求封装成 ServerWebExchange 的 HttpWebHandlerAdapter 之后，请求会经过 ExceptionHandl

接下来，将进入我们升级之路的又一大模块，即网关模块。网关模块我们废弃了已经进入维护状态的 zuul，选用了 Spring Cloud Gateway 作为内部网关。为何选择 Spring Cloud

针对响应超时，我们需要验证重试仅针对可以重试的方法（包括 GET 方法以及配置的可重试方法），针对不可重试的方法没有重试。我们可以通过 spock 单元测试中，检查对于负载均衡器获取实例方法的调用次数

我们来测试下前面封装好的 WebClient，这里开始，我们使用 spock 编写 groovy 单元测试，这种编写出来的单元测试，代码更加简洁，同时更加灵活，我们在接下来的单元测试代码中就能看出来。

要想实现我们上一节中提到的： 需要在重试以及断路中加一些日志，便于日后的优化 需要定义重试的 Exception，并且与断路器相结合，将非 2xx 的响应码也封装成特定的异常 需要在断路器相关

我们要实现的是不同微服务自动配置装载不同的 WebClient Bean，这样就可以通过 NamedContextFactory 实现。我们先来编写下实现这个 NamedContextFactory

对于同步的请求，我们使用 spring-cloud-openfeign 封装的 FeignClient，并做了额外的定制。对于异步的请求，使用的是异步 Http 客户端即 WebClient。

上一节我们通过单元测试验证了线程隔离的正确性，这一节我们来验证我们断路器的正确性，主要包括： 验证配置正确加载;验证断路器是基于服务和方法打开的

我们继续上一节针对我们的重试进行测试.我们可以通过 httpbin.org 的 /delay/响应时间秒 来实现请求响应超时。例如 /delay/3 就会延迟三秒后返回。这个接口也是可以接受任何类型的

通过系列前面的源码分析，我们知道 spring-cloud-openfeign 的 FeignClient 其实是懒加载的。所以我们实现的断路器也是懒加载的，需要先调用，之后才会初始化线程隔离。

在前面一节，我们利用 resilience4j 粘合了 OpenFeign 实现了断路器、重试以及线程隔离，并使用了新的负载均衡算法优化了业务激增时的负载均衡算法表现。这一节，我们开始编写单元测试验证

在前面两节，我们梳理了实现 Feign 断路器以及线程隔离的思路，并说明了如何优化目前的负载均衡算法。但是如何更新负载均衡的数据缓存，以及实现重试、断路器以及线程隔离的源码还没提，这一节我们会详细分析