hashcon

个人创作公约：本人声明创作的所有文章皆为自己原创，如果有参考任何文章的地方，会标注出来，如果有疏漏，欢迎大家批判。如果大家发现网上有抄袭本文章的，欢迎举报，并且积极向这个 github 仓库 提交 issue，谢谢支持~我们知道从 Spring Boot 2.3.x 这个版本开始，引入了优雅关闭的机制。我们也在线上部署了这个机制，来增加用户体验。虽然现在大家基本上都通过最终一致性，以及事务等机制，来保证了就算非优雅关闭，也可以保持业务正确。但是，这样总会带来短时间的数据不一致，影响用户体验。所以，引入.

本系列代码地址：https://github.com/JoJoTec/spring-cloud-parent我们这一节在前面实现的带有链路信息的 Publisher 的工厂的基础上，实现公共日志记录的 GlobalFilter。回顾下我们的需求：我们需要在网关记录每个请求的：HTTP 相关元素：URL 相关信息请求信息，例如 HTTP HEADER，请求时间等等某些类型的请求体响应信息，例如响应码某些类型响应的响应体链路信息记录请求与响应的 Body 需要注意的地方前面..

本系列代码地址：https://github.com/JoJoTec/spring-cloud-parent我们在这一节我们将继续讲解避免链路信息丢失做的设计，主要针对获取到现有 Span 之后，如何保证每个 GlobalFilter 都能保持链路信息。首先，我们自定义 Reactor 的核心 Publisher 即 Mono 和 Flux 的工厂，将链路信息封装进去，保证由这个工厂生成的 Mono 和 Flux，都是只要是这个工厂生成的 Mono 和 Flux 之间无论怎么拼接都会保持链路信息的：..

本系列代码地址：https://github.com/JoJoTec/spring-cloud-parent我们在这一节首先分析下 Spring Cloud Gateway 一些其他可能丢失链路信息的点，之后来做一些可以避免链路信息丢失的设计，之后基于这个设计去实现我们需要的一些定制化的 GlobalFilterSpring Cloud Gateway 其他的可能丢失链路信息的点经过前面的分析，我们可以看出，不止这里，还有其他地方会导致 Spring Cloud Sleuth 的链路追踪信息消失..

本系列代码地址：https://github.com/JoJoTec/spring-cloud-parent在开始编写我们自己的日志 Filter 之前，还有一个问题我想在这里和大家分享，即在 Spring Cloud Gateway 中可能发生链路信息丢失的问题。主要冲突 - Project Reactor 与 Java Logger MDC 之间的设计冲突Poject Reactor 是基于异步响应式设计的编程模式的实现，它的主要实现思路是先编写执行链路，最后 sub 执行整个链路。但是链路..

本系列代码地址：https://github.com/JoJoTec/spring-cloud-parent网关由于是所有外部用户请求的入口，记录这些请求中我们需要的元素，对于线上监控以及业务问题定位，是非常重要的。并且，在这些元素中，链路信息也是非常重要的。通过链路信息，我们可以找到请求调用全链路相关的日志。并且，网关也是大部分请求链路起始的地方，记录请求中的元素的同时，也要带上链路信息。我们需要在网关记录每个请求的：HTTP 相关元素：URL 相关信息请求信息，例如 HTTP HEA..

本系列代码地址：https://github.com/JoJoTec/spring-cloud-parent我们继续分析上一节提到的 WebHandler。加入 Spring Cloud Sleuth 以及 Prometheus 相关依赖之后， Spring Cloud Gateway 的处理流程如下所示：Spring Cloud Gateway 入口 -> WebFlux 的 DefaultWebFilterChainSpring Cloud Gateway 是基于 Spring We..

本系列代码地址：https://github.com/JoJoTec/spring-cloud-parent我们继续分析上一节提到的 WebHandler，经过将请求封装成 ServerWebExchange 的 HttpWebHandlerAdapter 之后，请求会经过 ExceptionHandlingWebHandler全局 Web 处理异常处理器的接入点 - ExceptionHandlingWebHandler之前有网友私信问过笔者，如何给 Spring Cloud Gateway..

本系列代码地址：https://github.com/JoJoTec/spring-cloud-parent接下来，将进入我们升级之路的又一大模块，即网关模块。网关模块我们废弃了已经进入维护状态的 zuul，选用了 Spring Cloud Gateway 作为内部网关。为何选择 Spring Cloud Gateway 而不是 nginx 还有 Kong 的原因是：项目组对于 Java 更加熟悉，并且对于 Project Reactor 异步编程也比较熟悉，这个比较重要需要在网关中使用我们之..

本系列代码地址：https://github.com/JoJoTec/spring-cloud-parent我们继续上一节，继续使用 spock 测试我们自己封装的 WebClient测试针对 readTimeout 重试针对响应超时，我们需要验证重试仅针对可以重试的方法（包括 GET 方法以及配置的可重试方法），针对不可重试的方法没有重试。我们可以通过 spock 单元测试中，检查对于负载均衡器获取实例方法的调用次数看出来是否有重试我们通过 httpbin.org 的 ‘/delay/秒’ ..

本系列代码地址：https://github.com/JoJoTec/spring-cloud-parent我们来测试下前面封装好的 WebClient，这里开始，我们使用 spock 编写 groovy 单元测试，这种编写出来的单元测试，代码更加简洁，同时更加灵活，我们在接下来的单元测试代码中就能看出来。编写基于 spock 的 spring-boot context 测试我们加入前面设计的配置，编写测试类：@SpringBootTest( properties = [ "web..

本系列代码地址：https://github.com/JoJoTec/spring-cloud-parent要想实现我们上一节中提到的：需要在重试以及断路中加一些日志，便于日后的优化需要定义重试的 Exception，并且与断路器相结合，将非 2xx 的响应码也封装成特定的异常需要在断路器相关的 Operator 中增加类似于 FeignClient 中的负载均衡的数据更新，使得负载均衡更加智能我们需要将 resilience4j 本身提供的粘合库做一些改造，其实主要就是对 resili..

本系列代码地址：https://github.com/JoJoTec/spring-cloud-parent实现 WeClient 的 NamedContextFactory我们要实现的是不同微服务自动配置装载不同的 WebClient Bean，这样就可以通过 NamedContextFactory 实现。我们先来编写下实现这个 NamedContextFactory 整个的加载流程的代码，其结构图如下所示：spring.factories# AutoConfigurationorg.s..

本系列代码地址：https://github.com/JoJoTec/spring-cloud-parent为何需要封装异步 HTTP 客户端 WebClient对于同步的请求，我们使用 spring-cloud-openfeign 封装的 FeignClient，并做了额外的定制。对于异步的请求，使用的是异步 Http 客户端即 WebClient。WebClient 使用也比较简单，举一个简单的例子即：//使用 WebClient 的 Builder 创建 WebClientWebClie..

本系列代码地址：https://github.com/JoJoTec/spring-cloud-parent上一节我们通过单元测试验证了线程隔离的正确性，这一节我们来验证我们断路器的正确性，主要包括：验证配置正确加载：即我们在 Spring 配置（例如 application.yml）中的加入的 Resilience4j 的配置被正确加载应用了。验证断路器是基于服务和方法打开的，也就是某个微服务的某个方法断路器打开但是不会影响这个微服务的其他方法调用验证配置正确加载与之前验证重试类似，我..

本系列是针对 Systems Performance: Enterprise and the Cloud, 2nd Edition (2020) 书籍的读书笔记，加入了一些个人理解以及拓展，并且针对一些难以理解的地方提供了一些额外的参考内核（Kernel）经典模型中，内核在操作系统结构中的位置如图所示：从里到外分别是：硬件（Hardware）：操作系统运行在的硬件设备。内核（Kernel）：操作系统的核心软件，内核管理着 CPU 调度、内存、文件系统、网络协议以及各种系统设备（磁盘 IO、.

本系列代码地址：https://github.com/JoJoTec/spring-cloud-parent上一节我们通过单元测试验证了重试的正确性，这一节我们来验证我们线程隔离的正确性，主要包括：验证配置正确加载：即我们在 Spring 配置（例如 application.yml）中的加入的 Resilience4j 的配置被正确加载应用了。相同微服务调用不同实例的时候，使用的是不同的线程（池）。验证配置正确加载与之前验证重试类似，我们可以定义不同的 FeignClient，之后检查 ..

本系列代码地址：https://github.com/JoJoTec/spring-cloud-parent我们继续上一节针对我们的重试进行测试验证针对可重试的方法响应超时异常重试正确我们可以通过 httpbin.org 的 /delay/响应时间秒 来实现请求响应超时。例如 /delay/3 就会延迟三秒后返回。这个接口也是可以接受任何类型的 HTTP 请求方法。我们先来指定关于 Feign 超时的配置 Options：//SpringExtension也包含了 Mockito 相关的 E..

本系列代码地址：https://github.com/JoJoTec/spring-cloud-parent我们继续上一节针对我们的重试进行测试验证针对限流器异常的重试正确通过系列前面的源码分析，我们知道 spring-cloud-openfeign 的 FeignClient 其实是懒加载的。所以我们实现的断路器也是懒加载的，需要先调用，之后才会初始化线程隔离。所以这里如果我们要模拟线程隔离满的异常，需要先手动读取载入线程隔离，之后才能获取对应实例的线程隔离，将线程池填充满。我们先定义一个 ..

本系列代码地址：https://github.com/JoJoTec/spring-cloud-parent在前面一节，我们利用 resilience4j 粘合了 OpenFeign 实现了断路器、重试以及线程隔离，并使用了新的负载均衡算法优化了业务激增时的负载均衡算法表现。这一节，我们开始编写单元测试验证这些功能的正确性，以便于日后升级依赖，修改的时候能保证正确性。同时，通过单元测试，我们更能深入理解 Spring Cloud。验证重试配置对于我们实现的重试，我们需要验证：验证配置正确加载..

本系列代码地址：https://github.com/JoJoTec/spring-cloud-parent在前面两节，我们梳理了实现 Feign 断路器以及线程隔离的思路，并说明了如何优化目前的负载均衡算法。但是如何更新负载均衡的数据缓存，以及实现重试、断路器以及线程隔离的源码还没提，这一节我们会详细分析。首先，从 spring.factories 引入，增加我们自定义 OpenFeign 配置的加载：spring.factories# AutoConfigurationorg.spri..

本系列代码地址：https://github.com/JoJoTec/spring-cloud-parent在前面一节，我们梳理了实现 Feign 断路器以及线程隔离的思路，这一节，我们先不看如何源码实现（因为源码中会包含负载均衡算法的改进部分），先来讨论下如何优化目前的负载均衡算法。之前的负载均衡算法获取服务实例列表，将实例列表按照 ip 端口排序，如果不排序即使 position 是下一个可能也代表的是之前已经调用过的实例根据请求中的 traceId，从本地缓存中以 traceId 为 ..

本系列代码地址：https://github.com/JoJoTec/spring-cloud-parent在前面一节，我们实现了 FeignClient 粘合 resilience4j 的 Retry 实现重试。细心的读者可能会问，为何在这里的实现，不把断路器和线程限流一起加上呢：@Beanpublic FeignDecorators.Builder defaultBuilder( Environment environment, RetryRegistry ..

本系列代码地址：https://github.com/JoJoTec/spring-cloud-parent在前面一节，我们实现了 FeignClient 粘合 resilience4j 的 Retry 实现重试。细心的读者可能会问，为何在这里的实现，不把断路器和线程限流一起加上呢：@Beanpublic FeignDecorators.Builder defaultBuilder( Environment environment, RetryRegistry ..

本系列代码地址：https://github.com/JoJoTec/spring-cloud-parent需要重试的场景微服务系统中，会遇到在线发布，一般的发布更新策略是：启动一个新的，启动成功之后，关闭一个旧的，直到所有的旧的都被关闭。Spring Boot 具有优雅关闭的功能，可以保证请求处理完再关闭，同时会拒绝新的请求。对于这些拒绝的请求，为了保证用户体验不受影响，是需要重试的。云上部署的微服务，对于同一个服务，同一个请求，很可能不会所有实例都同时异常，例如：Kubernetes 集..

本系列代码地址：https://github.com/JoJoTec/spring-cloud-parent在使用云原生的很多微服务中，比较小规模的可能直接依靠云服务中的负载均衡器进行内部域名与服务映射，通过健康检查接口判断实例健康状态，然后直接使用 OpenFeign 生成对应域名的 Feign Client。Spring Cloud 生态中，对 OpenFeign 进行了封装，其中的 Feign Client 的各个组件，也是做了一定的定制化，可以实现在 OpenFeign Client 中集成..

本系列代码地址：https://github.com/JoJoTec/spring-cloud-parent在使用云原生的很多微服务中，比较小规模的可能直接依靠云服务中的负载均衡器进行内部域名与服务映射，通过健康检查接口判断实例健康状态，然后直接使用 OpenFeign 生成对应域名的 Feign Client。Spring Cloud 生态中，对 OpenFeign 进行了封装，其中的 Feign Client 的各个组件，也是做了一定的定制化，可以实现在 OpenFeign Client 中集成..

本系列代码地址：https://github.com/JoJoTec/spring-cloud-parent接下来，我们开始分析 OpenFeign 的生命周期，结合 OpenFeign 本身的源代码。首先是从接口定义创建 OpenFeign 代理开始。我们这里只关心同步客户端，因为异步客户端目前还在实现中，并且在我们的项目中，异步响应式的客户端不用 OpenFeign，而是用的官方的 WebClient创建 OpenFeign 代理创建 OpenFeign 代理，主要分为以下几步：使用 C..

本系列代码地址：https://github.com/JoJoTec/spring-cloud-parent首先，我们给出官方文档中的组件结构图：[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-jrW9fLUy-1633609229588)(http://www.plantuml.com/plantuml/proxy?cache=no&src=https://raw.githubusercontent.com/OpenFeign/feign/master/sr..

Spring Cloud Gateway 动态修改请求参数解决 # URL 编码错误传参问题继实现动态修改请求 Body 以及重试带 Body 的请求之后，我们又遇到了一个小问题。最近很多接口，收到了错误的参数，在接口层报的错是：class org.springframework.web.method.annotation.MethodArgumentTypeMismatchException, Failed to convert value of type 'java.lang.String' to

本系列代码地址：https://github.com/JoJoTec/spring-cloud-parentOpenFeign 的由来和实现思路在微服务系统中，我们经常会进行 RPC 调用。在 Spring Cloud 体系中，RPC 调用一般就是 HTTP 协议的调用。对于每次调用，基本都要经过如下步骤：找到微服务实例列表并选择一个实例调用参数序列化使用 Http 客户端将请求发送出去响应处理，反序列化等等除了这些公共逻辑，业务上只需要定义参数，HTTP 方法，HTTP URI，响应..

本篇文章涉及底层设计以及原理，以及问题定位，比较深入，篇幅较长，所以拆分成上下两篇：上：问题简单描述以及 Spring Cloud RefreshScope 的原理下：当前 spring-cloud-openfeign + spring-cloud-sleuth 带来的 bug 以及如何修复Spring Cloud 中的配置动态刷新其实在测试的程序中，我们已经实现了一个简单的 Bean 刷新的设计。Spring Cloud 的自动刷新中，包含两种元素的刷新，分别是：配置刷新，即 Envir.

本篇文章涉及底层设计以及原理，以及问题定位，比较深入，篇幅较长，所以拆分成上下两篇：上：问题简单描述以及 Spring Cloud RefreshScope 的原理下：当前 spring-cloud-openfeign + spring-cloud-sleuth 带来的 bug 以及如何修复最近在项目中想实现 OpenFeign 的配置可以动态刷新（主要是 Feign 的 Options 配置），例如：feign: client: config: default.

本系列是 我TM人傻了 系列第六期[捂脸]，往期精彩回顾：升级到Spring 5.3.x之后，GC次数急剧增加，我TM人傻了这个大表走索引字段查询的 SQL 怎么就成全扫描了，我TM人傻了获取异常信息里再出异常就找不到日志了，我TM人傻了spring-data-redis 连接泄漏，我 TM 人傻了spring-data-redis 连接泄漏，我 TM 人傻了大家好，我又人傻了。这次的经验告诉我们，出来写代码偷的懒，迟早要还的。问题现象与背景昨晚我们的网关雪崩了一段时间，现.

本系列是 我TM人傻了 系列第五期[捂脸]，往期精彩回顾：升级到Spring 5.3.x之后，GC次数急剧增加，我TM人傻了这个大表走索引字段查询的 SQL 怎么就成全扫描了，我TM人傻了获取异常信息里再出异常就找不到日志了，我TM人傻了spring-data-redis 连接泄漏，我 TM 人傻了本篇文章涉及底层设计以及原理，以及问题定位和可能的问题点，非常深入，篇幅较长，所以拆分成上中下三篇：上：问题简单描述以及 Spring Cloud Gateway 基本结构和流程以及底层原.

本系列是 我TM人傻了 系列第五期[捂脸]，往期精彩回顾：升级到Spring 5.3.x之后，GC次数急剧增加，我TM人傻了这个大表走索引字段查询的 SQL 怎么就成全扫描了，我TM人傻了获取异常信息里再出异常就找不到日志了，我TM人傻了spring-data-redis 连接泄漏，我 TM 人傻了本篇文章涉及底层设计以及原理，以及问题定位和可能的问题点，非常深入，篇幅较长，所以拆分成上中下三篇：上：问题简单描述以及 Spring Cloud Gateway 基本结构和流程以及底层原.

本系列代码地址：https://github.com/HashZhang/spring-cloud-scaffold/tree/master/spring-cloud-iiford通过单元测试，我们也可以了解下一般我们实现 spring cloud 自定义的基础组件，怎么去单元测试。这里的单元测试主要测试三个场景：只返回同一个 zone 下的实例，其他 zone 的不会返回对于多个请求，每个请求返回的与上次的实例不同。对于多线程的每个请求，如果重试，返回的都是不同的实例同时，我们也需要..

本系列代码地址：https://github.com/HashZhang/spring-cloud-scaffold/tree/master/spring-cloud-iiford我们使用 Spring Cloud 官方推荐的 Spring Cloud LoadBalancer 作为我们的客户端负载均衡器。上一节我们了解了 Spring Cloud LoadBalancer 的结构，接下来我们来说一下我们在使用 Spring Cloud LoadBalancer 要实现的功能：我们要实现不同集群..

本系列代码地址：https://github.com/HashZhang/spring-cloud-scaffold/tree/master/spring-cloud-iiford经过上一节的详细分析，我们知道可以通过 LoadBalancerClientFactory 知道默认配置类为 LoadBalancerClientConfiguration. 并且获取微服务名称可以通过 environment.getProperty(LoadBalancerClientFactory.PROPERTY_N..

本系列代码地址：https://github.com/HashZhang/spring-cloud-scaffold/tree/master/spring-cloud-iiford我们使用 Spring Cloud 官方推荐的 Spring Cloud LoadBalancer 作为我们的客户端负载均衡器。Spring Cloud LoadBalancer背景Spring Cloud LoadBalancer是一个客户端负载均衡器，类似于Ribbon，但是由于Ribbon已经进入维护模式，并且R..