hashcon

个人创作公约：本人声明创作的所有文章皆为自己原创，如果有参考任何文章的地方，会标注出来，如果有疏漏，欢迎大家批判。如果大家发现网上有抄袭本文章的，欢迎举报，并且积极向这个另外，本文为了避免抄袭，会在不影响阅读的情况下，在文章的随机位置放入对于抄袭和洗稿的人的“亲切”的问候。如果是正常读者看到，笔者在这里说声对不起，。

个人创作公约：本人声明创作的所有文章皆为自己原创，如果有参考任何文章的地方，会标注出来，如果有疏漏，欢迎大家批判。如果大家发现网上有抄袭本文章的，欢迎举报，并且积极向这个 github 仓库 提交 issue，谢谢支持~本文是我 TM 人傻了的第多少期我忘了，每一期总结一个坑以及对于坑的一些发散性想法，往期精彩回顾：升级到Spring 5.3.x之后，GC次数急剧增加，我TM人傻了这个大表走索引字段查询的 SQL 怎么就成全扫描了，我TM人傻了获取异常信息里再出异常就找不到日志了，我TM人傻.

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

继续分析其他接入点。其他需要初始化的接入点分析我们有时候还需要做一些自定义的初始化操作，但是如何在注册到注册中心状态为 UP 也就是开始处理请求之前做这些操作呢？为了更加与云环境兼容，Spring Boot 从 2.3.0 版本之后引入了一些云上部署相关的概念：LivenessState（存活状态）：就应用程序而言，存活状态是指应用程序的状态是否正常。如果存活状态不正常，则意味着应用程序本身已损坏，无法恢复。在 k8s 中，如果存活检测失败，则 kubelet 将杀死 Container，并且根据

最近线上发现一个现象，应用实例刚刚启动的时候，开始接收请求之后发生了一小段时间的请求阻塞，从 HTTP Servlet 请求队列监控上可以看出（基于 spring-web 的普通阻塞的 HTTP 服务器是有 HTTP 线程池的，当线程是满了之后，请求在阻塞队列中等待处理。基于 spring-webflux 的没有这个现象，但是考虑的背压问题其实和这个场景类似）：然后阻塞数量很快就下去了，通过 JFR 发现和 Spring 各种懒加载的 Bean，各种资源或者连接池初始化等有关。这些资源可以理解为是懒加载

关于 spring-data-redis 和 lettuce，笔者写过不少文章：这个 Redis 连接池的新监控方式针不戳~我再加一点佐料spring-data-redis 连接泄漏，我 TM 人傻了spring-data-redis 动态切换数据源spring-data-redis 上百万的 QPS 压力太大连接失败，我 TM 人傻了最近，私信还有留言中，网友提到 spring-data-redis 和 lettuce 一起使用，pipeline 通过抓包一看，并没有生效，这个如何配置才能生

本系列代码地址：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

大家好，我们最近业务量暴涨，导致我最近一直 TM 人傻了。前几天晚上，发现由于业务压力激增，某个核心微服务新扩容起来的几个实例，在不同程度上，出现了 Redis 连接失败的异常：org.springframework.data.redis.RedisConnectionFailureException: Unable to connect to Redis; nested exception is io.lettuce.core.RedisConnectionException: Unable to c.

本系列代码地址：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 基本结构和流程以及底层原.

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

上一节我们讲述了如何使用 Undertow 作为我们的 Web 服务容器，本小节我们来分析使用 Undertow 的另一个问题，也就是如何配置 accesslog，以及 accesslog 的各种占位符。accesslog 相关配置server: undertow: # access log相关配置 accesslog: # 存放目录，默认为 logs dir: ./log # 是否开启 enabled: true # 格式

本项目代码地址：https://github.com/HashZhang/spring-cloud-scaffold/tree/master/spring-cloud-iiford在我们的项目中，我们没有采用默认的 Tomcat 容器，而是使用了 UnderTow 作为我们的容器。其实性能上的差异并没有那么明显，但是使用 UnderTow 我们可以利用直接内存作为网络传输的 buffer，减少业务的 GC，优化业务的表现。Undertow 的官网：https://undertow.io/但是，Un.

1. 背景知识、需求描述与公共依赖1.1. 背景知识 & 需求描述Spring Cloud 官方文档说了，它是一个完整的微服务体系，用户可以通过使用 Spring Cloud 快速搭建一个自己的微服务系统。那么 Spring Cloud 究竟是如何使用的呢？他到底有哪些组件？spring-cloud-commons组件里面，就有 Spring Cloud 默认提供的所有组件功能的抽象接口，有的还有默认实现。目前的 2020.0.x （按照之前的命名规则应该是 iiford），也就是spring

Spring Cloud Commons 主要包括如下模块的接口和默认实现：其中的限流策略以及重试策略是没有天然带的，但是其他模块的实现一般会带上这些功能。我们先从服务发现相关接口开始分析服务发现相关核心接口DiscoveryClientDiscoveryClientpublic interface DiscoveryClient extends Ordered { int DEFAULT_ORDER = 0; //描述 String description(); //通过

本文基于 Spring Cloud 2020.0 发布版的依赖本系列会深入分析 Spring Cloud 的每一个组件，从Spring Cloud Commons这个 Spring Cloud 所有元素的抽象说起，深入设计思路与源码，并结合实际使用例子深入理解。本系列适合有一定 Spring 或者 Spring Boot 使用经验的人阅读。什么是Spring Cloud CommonsSpring Cloud框架包括如下功能：分布式多版本配置管理服务注册与发现路由微服务调用负载均衡断.

实例级别的熔断带来的困扰如之前系列（Spring Cloud升级之路 - Hoxton - 4. 使用Resilience4j实现实例级别的隔离与熔断）所述，我们实现了实例级别的熔断。但是在生产中发现，并不是所有情况下都表现良好。首先如果发布了新接口，但是不小心回滚了，调用新接口就会报错，从而导致整个实例都不能访问。还有就是某些实例某个接口出现了问题，但是其他接口是好的，熔断掉整个实例有点浪费。于是乎，我们将实例级别的熔断改成 实例 + 方法级别。对于 OpenFeign 修改首先，我们只针对断路器进

1. 修正实例列表乱序导致的负载均衡重试相同实例的问题虽然之前考虑了通过每个请求的traceId隔离负载均衡的position来实现重试不会重试相同实例的问题，但是没有考虑在负载均衡过程中，实例列表的更新。例如：请求第一次调用负载均衡，实例列表是：[实例1，实例2]，position为1，对2取余=1，所以请求发送到实例2上面了请求失败，触发重试，实例列表缓存失效，更新后变成了：[实例2，实例1]，position为2，对2取余=0，所以请求又发送到实例2上面了private Response

准备工作首先拉取项目源码：git clone https://github.com/HashZhang/spring-cloud-scaffold.git打开其中的 spring-cloud-hoxton 项目。启动Eureka启动zone1-service-provider-instance1，zone1-service-provider-instance2，zone1-service-provider2-instance1，zone2-service-provider-instance1这

feign 实现重试我们继续使用resilience4j实现重试，根据上一篇Spring Cloud升级之路 - Hoxton - 4. 使用Resilience4j实现实例级别的隔离与熔断，我们已经加载了RetryReqistry这个核心配置Bean。Retry相关的配置：create-and-configure-retry配置项默认值说明maxAttempts3最大重试次数，不包括本身那次调用waitDuration500[ms]重试间隔时间interva

如何不启用Hystrix由于我们的入口注解类从@SpringCloudApplication替换成了SpringBootApplication，这样不会启用Spring-Cloud-CircuitBreaker。引入的Hystrix依赖也就没有效果。请参考本系列第二节： Spring Cloud升级之路 - Hoxton - 2.入口类注解修改与OpenFeign的改造使用Resilience4j实现实例级别的隔离与熔断为什么需要实例级别的熔断呢？因为某个微服务可能某些实例暂时不可用，我们希望在重试的

本系列示例与胶水代码地址： https://github.com/HashZhang/spring-cloud-scaffold负载均衡Ribbon替换成Spring Cloud Load BalancerSpring Cloud Load Balancer并不是一个独立的项目，而是spring-cloud-commons其中的一个模块。 项目中用了Eureka以及相关的 starter，想完全剔除Ribbon的相关依赖基本是不可能的，Spring 社区的人也是看到了这一点，通过配置去关闭Ribbo.

本系列示例与胶水代码地址： https://github.com/HashZhang/spring-cloud-scaffold入口类注解修改之前的项目，我们也许会用@SpringCloudApplication作为我们入口类的注解。这个注解包括：@SpringBootApplication@EnableDiscoveryClient@EnableCircuitBreakerpublic @interface SpringCloudApplication {}其中的@EnableDis.

本系列示例与胶水代码地址： https://github.com/HashZhang/spring-cloud-scaffoldSpring Cloud还是比较活跃的，更新一直很快。我一般考虑最新版本SR2发布之后，再考虑升级（一般SR1还有SR2会有一些新老框架的兼容性升级）。而且由于需要我们线上稳定，结合我们的发布周期来看，跳一个大版本升级是一个更好的选择（也就是一年做一次大版本升级）。例如我们之前的升级路线就是：Brixton -> Daltson -> Finchley ->.

BUG背景JDK: 11.0.4Spring Cloud Finchley.SR3相关配置：#开启hystrixfeign.hystrix.enabled=true#关闭断路器hystrix.command.default.circuitBreaker.enabled=false#禁用hystrix远程调用超时时间hystrix.command.default.executi...

本文基于JDK 11 and JDK 12按照上一篇内容的分析，我们想在异步代码保留原有的spanId和traceId需要在异步调用前，使用：Span span = tracer.currentSpan();try (Tracer.SpanInScope cleared = tracer.withSpanInScope(span)) { //执行异步代码}每次使用Compl...

本文基于Spring Cloud Finchley SR4本文通过几个问题，解析下Spring WebFlux用法最佳实践，并与另一框架Vertx作对比1. 是否一定要用默认的Web容器，用自己的Web容器是否可以，同时是否可以有web和webflux是可以的，这样的依赖是可行的（容器用tomcat和undertow或者其他都可以，这里使用undertow）：2. 怎样实现真正的异步背...

如题，本文基于Spring Cloud Finchley.SR2OpenFeign的重试OpenFeign配置重试后，逻辑分析对比Daltson和Finchley的基本组件，发现Ribbon还有Hystrix的重试逻辑基本没变，feign编程openfeign之后，增加了个重试逻辑，我们用下面这个图来展示其中的逻辑：首先搞清楚调用链：可以总结如下：OpenFeign有自己的重试...

如题，本文基于Spring Cloud Finchley.SR2我们项目配置了AvailabilityFilteringRule作为所有Ribbon调用的负载均衡规则，它有那些坑呢（理解歧义和注意点）？首先来看源码，核心是choose方法：public Server choose(Object key) { int count = 0; //通过轮询选择一个server...

本文基于SpringCloud-Dalston.SR5Eureka作为服务注册中心对整个微服务架构起着最核心的整合作用，因此对Eureka还是有很大的必要进行深入研究。Eureka 1.x版本是纯基于servlet的应用。为了与spring cloud结合使用，除了本身eureka代码，还有个粘合模块spring-cloud-netflix-eureka-server。在我们启动Eurek

本文基于SpringCloud-Dalston.SR5关于服务注册 开启/关闭服务注册配置：eureka.client.register-with-eureka = true （默认）什么时候注册？应用第一次启动时，初始化EurekaClient时，应用状态改变：从STARTING变为UP会触发这个Listener，调用instanceInfoReplicator....

本文基于SpringCloud-Dalston.SR5关于服务与实例列表获取EurekaClient端我们从Ribbon说起：EurekaClient也存在缓存，应用服务实例列表信息在每个EurekaClient服务消费端都有缓存。一般的，Ribbon的LoadBalancer会读取这个缓存，来知道当前有哪些实例可以调用，从而进行负载均衡。这个loadbalancer同样也有缓

本文基于SpringCloud-Dalston.SR5自我保护机制 关闭自我保护机制（默认是打开的）：eureka.server.enable-self-preservation=false自我保护机制：默认情况下，如果Eureka Server在一定时间内没有接收到某个微服务实例的心跳，Eureka Server将会注销该实例（默认90秒）。但是当网络分区故障发生时，微服务

本文基于SpringCloud-Dalston.SR5Eureka服务实例启动时，是否会立刻向EurekaServer注册?是的，立刻会。EurekaClient在每次实例状态发生改变时，有一个Listener：statusChangeListener = new ApplicationInfoManager.StatusChangeListener() { @Ov