Resilience4j

导语： 本文首先介绍分布式系统和微服务的概念以及技术基础;然后介绍Spring Cloud的主要组件，包含服务治理和服务发现、服务调用、断路器、API网关、服务配置和服务监控等，这部分是本文的主要内容;接着介绍企业实践中经常用到的分布式技术，包括分布式数据库事务、分布式Redis缓存等;最后介绍远程过程调用（RPC）以及微服务设计和高并发实践。 第一部分 概述和基础 本部分将讲解分布式和微服务的基础知识和理念。并且简单介绍本文需要用到的基础知识。 本部分包含以下内容： 分布式和微服务概述； 技术基础； 第1章 分布式和微服务概述 （完整文章已经整理了一份五百多页的PDF文档，由于篇幅原因，文章只展示部分；）文末有免费获取方式 第2章 技术基础 第二部分 Spring Cloud 微服务 第3章 服务治理 Eureka 第4章 客户端负载均衡 Ribbon 第5章 断路器 Hystrix 第6章 新断路器 Resilience4j 第7章 声明式调用 OpenFeign 第8章 旧API网关 Zuul 第9章 新网关 Spring Cloud Gateway 第10章 配置 Spring Cloud Config 第11章 Spring Cloud Sleuth全链路追踪 第12章 微服务的监控 Spring Boot Admin 第三部分 分布式技术 第13章 生成唯一的ID

针对网关非 Get 请求的重试 在之前的系列里面 Spring Cloud升级之路 - Hoxton - 5. 实现微服务调用重试 ，我们针对 OpenFeign 和 Spring Cloud Gateway 都设置了重试。 对于 OpenFeign： Get请求：任何非200 响应码，任何异常，都会重试。 非 Get 请求：任何IOException（除了SocketTimeOutException，这个是read time out 导致的），还有 redilience 断路器异常，都会重试，其他的都不重试。 对于 Spring Cloud Gateway： Get请求：任何4XX，5XX响应码，任何异常，都会重试。 现在，我们需要实现针对于 Spring Cloud Gateway 的非 Get 请求的任何IOException（除了SocketTimeOutException，这个是read time out 导致的），还有 redilience 断路器异常进行重试，Get因为请求并没有真正发出去。 现有设计 目前在 Spring Cloud Gateway 的 RetryFilterFactory，无法实现针对 Get 和非 Get 对于不同的异常进行不同的重试： org.springframework.cloud.gateway.filter.factory

本系列示例与胶水代码地址： https://github.com/HashZhang/spring-cloud-scaffold 入口类注解修改 之前的项目，我们也许会用 @SpringCloudApplication 作为我们入口类的注解。这个注解包括： @SpringBootApplication @EnableDiscoveryClient @EnableCircuitBreaker public @interface SpringCloudApplication { } 其中的 @EnableDiscoveryClient 会启动服务发现的客户端，我们这里继续用Eureka，但是EurekaClient不需要这个注解，只要加上 spring-cloud-starter-eureka-client 的依赖，就会启动EurekaClient。对于 @EnableCircuitBreaker 这个注解，就比较麻烦了。我们引入了 spring-cloud-starter-netflix-eureka-client 依赖，这个依赖，包含了 hystrix 依赖，导致会自动启用 hystrix 实现 CircuitBreaker 接口，而我们并不想启用hystrix。并且，使用 SpringCloud 的 CircuitBreaker 的抽象接口，并不能完全使用

提起 Spring Cloud 的限流降级组件，一般首先想到的是 Netflix 的 Hystrix。 不过就在2018年底，Netflix 宣布不再积极开发 Hystrix，该项目将处于维护模式。官方表示 1.5.18 版本的 Hystrix 已经足够稳定，可以满足 Netflix 现有应用的需求，所以接下来其会把焦点转向对于自适应的实现，更多关注对应用程序的实时性能做出响应。对于新应用的熔断需求，将采用其它项目实现，Netflix 推荐了 Resilience4j。 作为 Spring Cloud Netflix 重要套件，Hystrix已经成为保障微服务稳定性的首选应用。其实除了 Netflix 和 Resilience4j，限流降级还有一个新的选择，就是阿里巴巴的Sentinel组件。 一、阿里开源 Sentinel 简介 2018年8月，阿里巴巴宣布将 Sentinel 进行开源，同时推出了结合Dubbo的适配器，捐赠给了Apache Dubbo社区。 1.Sentinel 的历史 2012 年，Sentinel 诞生，主要功能为入口流量控制。 2013-2017 年，Sentinel 在阿里巴巴集团内部迅速发展，成为基础技术模块，覆盖了所有的核心场景。Sentinel 也因此积累了大量的流量归整场景以及生产实践。 2018 年，Sentinel 开源，并持续演进。 2

本篇讲述Spring Cloud 微服务及其组件的专业技术。微服务系统作为分布式系统的一种形式，.必然会带有分布式系统的各种弊病，因此本篇也会介绍分布式系统的一些常见知识，以更好满足企业构建系统的需求。 本篇从企业的真实需求出发，理论结合实际，深入讲解SpringCloud微服务和分布式系统的知识。文中既包括SpringCloud微服务的各类常用组件的讲解，又包括分布式系统的常用知识的介绍。 SpringCloud组件方面主要讲解服务注册和服务发现(Eureka) 、服务调用(Ribbon 和OpenFeign)、断路器(Hystrix 和Resilience4j)、网关(Zuul和Gateway)、配置(Config)、全链路追踪(Sleuth) 、微服务的监控(Admin)等;分布式系统方面主要讲解分布式数据库、分布式缓存、会话和权限以及发号机制等。本篇的实践部分通过Apache Thrift 讲解了远程过程调用(RPC)在分布式系统中的应用，并且分析了处理高并发的一些常用方法，最后还通过一个简单的实例讲解了微服务系统的搭建。 本篇篇幅有些长总共4大部分，20个章节： 第一部分概述和基础 第二部分Spring Cloud微服务 第三部分分布式技术 第四部分微服务系统实践 第一部分概述和基础 第1章分布式和微服务概述 第2章技术基础 第二部分Spring Cloud微服务

Resilience4j是一个轻量级、易于使用的容错库，其灵感来自Netflix Hystrix，但专为Java 8和函数式编程设计。轻量级，因为库只使用Vavr，它没有任何其他外部库依赖项。相比之下，Netflix Hystrix对Archaius有一个编译依赖关系，Archaius有更多的外部库依赖关系，如Guava和Apache Commons。 Resilience4j提供高阶函数（decorators）来增强任何功能接口、lambda表达式或方法引用，包括断路器、速率限制器、重试或舱壁。可以在任何函数接口、lambda表达式或方法引用上使用多个装饰器。优点是您可以选择所需的装饰器，而无需其他任何东西。 有了Resilience4j，你不必全力以赴，你可以选择你需要的。 https://resilience4j.readme.io/docs/getting-started 概览 本文将介绍resilience4j中的四种容错机制，不过鉴于容错机制原理的通用性，后文所介绍的这几种容错机制也可以脱离resilience4j而独立存在（你完全可以自己编码实现它们或者采用其他类似的第三方库，如 Netflix Hystrix ）。下面将会用图例来解释舱壁（ Bulkhead ）、断路器（ CircuitBreaker ）、限速器（ RateLimiter ）、重试（ Retry

feign 实现重试 我们继续使用 resilience4j 实现重试，根据上一篇 Spring Cloud升级之路 - Hoxton - 4. 使用Resilience4j实现实例级别的隔离与熔断 ，我们已经加载了 RetryReqistry 这个核心配置 Bean 。 Retry 相关的配置： create-and-configure-retry 配置项 默认值 说明 maxAttempts 3 最大重试次数， 包括本身那次调用 waitDuration 500[ms] 重试间隔时间 intervalFunction numOfAttempts -> waitDuration 重试间隔时间函数，和 waitDuration 只能设置一个，默认就是 waitDuration retryOnResultPredicate result -> false 通过结果判断是否重试，默认是只要获取到结果就不重试 retryOnExceptionPredicate throwable -> true 通过抛出的异常判断是否重试，默认是只要有异常就会重试 retryExceptions empty 配置抛出这些异常以及子类则会重试 ignoreExceptions empty 配置抛出这些异常以及子类则不会重试 我们这里的配置是： resilience4j.retry: configs:

Resilience4j是一个轻量级、易于使用的容错库，其灵感来自Netflix Hystrix，但专为Java 8和函数式编程设计。轻量级，因为库只使用Vavr，它没有任何其他外部库依赖项。相比之下，Netflix Hystrix对Archaius有一个编译依赖关系，Archaius有更多的外部库依赖关系，如Guava和Apache Commons。 Resilience4j提供高阶函数（decorators）来增强任何功能接口、lambda表达式或方法引用，包括断路器、速率限制器、重试或舱壁。可以在任何函数接口、lambda表达式或方法引用上使用多个装饰器。优点是您可以选择所需的装饰器，而无需其他任何东西。 有了Resilience4j，你不必全力以赴，你可以选择你需要的。 https://resilience4j.readme.io/docs/getting-started 概览 Resilience4j提供了两种舱壁模式 （Bulkhead） ，可用于限制并发执行的次数： SemaphoreBulkhead（信号量舱壁，默认），基于Java并发库中的Semaphore实现。 FixedThreadPoolBulkhead（固定线程池舱壁），它使用一个有界队列和一个固定线程池。 本文将演示在Spring Boot2中集成Resilience4j库

实例级别的熔断带来的困扰 如之前系列（ Spring Cloud升级之路 - Hoxton - 4. 使用Resilience4j实现实例级别的隔离与熔断 ）所述，我们实现了实例级别的熔断。但是在生产中发现，并不是所有情况下都表现良好。首先如果发布了新接口，但是不小心回滚了，调用新接口就会报错，从而导致整个实例都不能访问。还有就是某些实例某个接口出现了问题，但是其他接口是好的，熔断掉整个实例有点浪费。于是乎，我们将实例级别的熔断改成 实例 + 方法级别。 对于 OpenFeign 修改 首先，我们只针对断路器进行修改，线程隔离还是实例级别的，如果也抽象为实例+方法级别的，线程数与线程池的数量就太多了。 每个 Feign 调用都是有 url 的，我们是不是可以通过 url 获取不同的断路器呢？这样做是可以的，的确实现了实例 + 方法级别的熔断。但是有一个问题，对于有 PathVaraiable 的 FeignClient，相当于每个参数都会新建一个断路器，这并不是我们想要的，例如： package com.github.hashjang.hoxton.service.consumer.feign; //省略import @FeignClient(value = "service-provider") public interface