本系列代码地址：[链接]我们这一节在前面实现的带有链路信息的 Publisher 的工厂的基础上，实现公共日志记录的 GlobalFilter。回顾下我们的需求：我们需要在网关记录每个请求的：HTTP 相关元素：URL 相关信息请求信息，例如 HTTP HEADER，请求时间等等某些类型的请求体响应信息，例如响应码某些类型响应的响应体链路信息...

我们在这一节我们将继续讲解避免链路信息丢失做的设计，主要针对获取到现有 Span 之后，如何保证每个 GlobalFilter 都能保持链路信息。首先，我们自定义 Reactor 的核心 Publisher 即 Mono 和 Flux 的工厂，将链路信息封装进去，保证由这个工厂生成的 Mono 和 Flux，都是只要是这个工厂生成的 Mono 和 Flux 之间无论怎么...

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

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

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

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

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

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

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

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

本系列代码地址：[链接]要想实现我们上一节中提到的：需要在重试以及断路中加一些日志，便于日后的优化需要定义重试的 Exception，并且与断路器相结合，将非 2xx 的响应码也封装成特定的异常需要在断路器相关的 Operator 中增加类似于 FeignClient 中的负载均衡的数据更新，使得负载均衡更加智能我们需要将 resilience4j...

我们要实现的是不同微服务自动配置装载不同的 WebClient Bean，这样就可以通过 NamedContextFactory 实现。我们先来编写下实现这个 NamedContextFactory 整个的加载流程的代码，其结构图如下所示：

对于同步的请求，我们使用 spring-cloud-openfeign 封装的 FeignClient，并做了额外的定制。对于异步的请求，使用的是异步 Http 客户端即 WebClient。WebClient 使用也比较简单，举一个简单的例子即：

验证配置正确加载：即我们在 Spring 配置（例如 application.yml）中的加入的 Resilience4j 的配置被正确加载应用了。

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

验证配置正确加载：即我们在 Spring 配置（例如 application.yml）中的加入的 Resilience4j 的配置被正确加载应用了。

我们可以通过 httpbin.org 的 /delay/响应时间秒 来实现请求响应超时。例如 /delay/3 就会延迟三秒后返回。这个接口也是可以接受任何类型的 HTTP 请求方法。

通过系列前面的源码分析，我们知道 spring-cloud-openfeign 的 FeignClient 其实是懒加载的。所以我们实现的断路器也是懒加载的，需要先调用，之后才会初始化线程隔离。所以这里如果我们要模拟线程隔离满的异常，需要先手动读取载入线程隔离，之后才能获取对应实例的线程隔离，将线程池填充满。

在前面一节，我们利用 resilience4j 粘合了 OpenFeign 实现了断路器、重试以及线程隔离，并使用了新的负载均衡算法优化了业务激增时的负载均衡算法表现。这一节，我们开始编写单元测试验证这些功能的正确性，以便于日后升级依赖，修改的时候能保证正确性。同时，通过单元测试，我们更能深入理解 Spring Cloud。

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

在前面一节，我们梳理了实现 Feign 断路器以及线程隔离的思路，这一节，我们先不看如何源码实现（因为源码中会包含负载均衡算法的改进部分），先来讨论下如何优化目前的负载均衡算法。

在前面一节，我们实现了 FeignClient 粘合 resilience4j 的 Retry 实现重试。细心的读者可能会问，为何在这里的实现，不把断路器和线程限流一起加上呢：

微服务系统中，会遇到在线发布，一般的发布更新策略是：启动一个新的，启动成功之后，关闭一个旧的，直到所有的旧的都被关闭。Spring Boot 具有优雅关闭的功能，可以保证请求处理完再关闭，同时会拒绝新的请求。对于这些拒绝的请求，为了保证用户体验不受影响，是需要重试的。

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

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

本系列是 The art of multipropcessor programming 的读书笔记，在原版图书的基础上，结合 OpenJDK 11 以上的版本的代码进行理解和实现。并根据个人的查资料以及理解的经历，给各位想更深入理解的人分享一些个人的资料

本系列是 The art of multipropcessor programming 的读书笔记，在原版图书的基础上，结合 OpenJDK 11 以上的版本的代码进行理解和实现。并根据个人的查资料以及理解的经历，给各位想更深入理解的人分享一些个人的资料

最近，业务增长的很迅猛，对于我们后台这块也是一个不小的挑战，这次遇到的核心业务接口的性能瓶颈，并不是单独的一个问题导致的，而是几个问题揉在一起：我们解决一个之后，发上线，之后发现还有另一个的性能瓶颈问题。这也是我经验不足，导致没能一下子定位解决；而我又对我们后台整个团队有着固执的自尊，不想通过大...

最近，业务增长的很迅猛，对于我们后台这块也是一个不小的挑战，这次遇到的核心业务接口的性能瓶颈，并不是单独的一个问题导致的，而是几个问题揉在一起：我们解决一个之后，发上线，之后发现还有另一个的性能瓶颈问题。这也是我经验不足，导致没能一下子定位解决；而我又对我们后台整个团队有着固执的自尊，不想通过大...

最近，业务增长的很迅猛，对于我们后台这块也是一个不小的挑战，这次遇到的核心业务接口的性能瓶颈，并不是单独的一个问题导致的，而是几个问题揉在一起：我们解决一个之后，发上线，之后发现还有另一个的性能瓶颈问题。这也是我经验不足，导致没能一下子定位解决；而我又对我们后台整个团队有着固执的自尊，不想通过大...