1.微服务中的容错

1.1.服务雪崩

要说容错的话，肯定是有多种维度的。横向维度上来说，分布式架构，天然就带有分区容错性，多节点部署相同的服务就是为了容错，保证其中某些节点挂掉后，其它节点任然能提供该类服务。微服务种更需要考虑的是纵向维度上的容错机制，防止服务雪崩。

所谓的服务雪崩，指的是服务间存在着纵向的链路式的调用关系：

服务A调用服务B，服务B调用服务C。

要说容错的话，肯定是有多种维度的。横向维度上来说，分布式架构，天然就带有分区容错性，多节点部署相同的服务就是为了容错，保证其中某些节点挂掉后，其它节点任然能提供该类服务。微服务种更需要考虑的是纵向维度上的容错机制，防止服务雪崩。

所谓的服务雪崩，指的是服务间存在着纵向的链路式的调用关系：

服务A调用服务B，服务B调用服务C。

当链路上有节点出现错误，无法正常提供服务，无法立即响应请求时，请求会逐步积压在上层服务，逐步打挂整个链路上的服务，就像异常雪崩一样，从一点开始引起全局的一场大崩溃。

1.2.解决办法

预防、解决服务雪崩有三种方法：

服务降级

服务熔断

服务限流

服务降级：

当服务提供方向服务调用方返回一个响应（fallback），而不是长时间等待或者直接抛出无法处理的异常。例如：“服务器忙，请稍后再试！”

服务降级的触发条件可以人为规定，乐意的话想定成什么都可以，一般常见的触发条件如下

报异常

超时

通信线程池被打满

服务熔断：

直接拒绝访问，快速返回一个开发者自定义的“异常信息”。

服务限流：

限制一个时间段内能够通行的请求数量。

降级和熔断的区别：

熔断：

熔断后请求不会再进调用服务的方法体，直接将链路断开，此后的每次请求都会直接被抛给fallback。

降级：

降级后请求依然会进调用服务的方法体，每次请求都会先试图去调用服务，只是服务自己察觉到自己可能出问题了从而拒绝服务，然后再将请求转给fallback。直接转发到即当服务的调用出现超时、异常等情况时，返回一个响应（fallback）。降级可以用在服务调用的全链路上的任意位置，既可以用在服务提供方，也可以用在服务提供方，不过为了使用规范，一般建议用在提供方（让服务自己管好自己）。

2.hystrix

2.1.概述

hystrix归属于Netflix版本的spring cloud中，是开源的一款微服务容错组件，提供了开箱即用的服务降级、熔断、监控等能力。由于Netflix将自己版本的spring cloud捐给apache后，后续apache维护的版本只维护了eureka，也就是说交给apache后，更新的spring cloud Netflix中只包含eureka，而不包含其它组件了，所以要用hystrix时，版本一定要选还在Netflix时的版本号，本文选择H版本以及其对应的spring boot 2.2.X为例：

如果对spring cloud版本问题还不是很清楚的同学，推荐去看博主另一篇文章，其中详细清晰快速的理清楚了整个spring cloud杂乱的版本关系：

详解Spring Cloud版本问题__BugMan的博客-CSDN博客

2.2.项目结构及依赖

项目结构：

maven项目，consumer，服务调用者；userService，服务提供者；eureka，注册中心。

依赖：

<properties>
        <spring-cloud.version>Hoxton.SR12</spring-cloud.version>
        <spring-boot.version>2.2.10.RELEASE</spring-boot.version>
    </properties>
    <dependencyManagement>
        <dependencies>
            <dependency>
                <groupId>org.springframework.cloud</groupId>
                <artifactId>spring-cloud-dependencies</artifactId>
                <version>${spring-cloud.version}</version>
                <type>pom</type>
                <scope>import</scope>
            </dependency>
            <dependency>
                <groupId>org.springframework.boot</groupId>
                <artifactId>spring-boot-dependencies</artifactId>
                <version>${spring-boot.version}</version>
                <type>pom</type>
                <scope>import</scope>
            </dependency>
        </dependencies>
    </dependencyManagement>

2.3.代码示例

2.3.1.注册中心

依赖：

配置：

启动：

2.3.2.服务调用者

依赖：

配置：

用ribbon来做RPC：

2.3.3.服务提供者

依赖：

配置：

启动：

服务：

开启容错和降级：

2.4.服务降级

2.4.1.单点响应

即每个服务接口单独定义异常响应  

2.4.2.默认响应

单点响应，每个服务单独对应一个fallback，会造成代码膨胀，高耦合的问题。

可以定义一个默认的全局响应，来统一处理服务降级。

单点响应优先，有单点响应的服务会优先匹配单点响应，没有单点响应的服务匹配全局响应。一般很重要的核心业务的熔断才单独写响应，一般业务用默认响应足以。

这里给一个博主之前写的默认响应的代码示例：

2.4.3.前置响应

无论是单点响应还是默认响应，响应代码和业务代码都耦合在一起，前置响应将响应放在OpenFeign调用侧，使得业务代码和响应代码解耦。

依赖：

OpenFeign的依赖中包含了hystrix，导入OpenFeign后不用单独导入hystrix。

配置：

映射：

2.5.服务熔断

2.5.1.概述

hystrix实现了熔断机制，会监控服务间的调用情况，当失败的次数达到一定阈值时（默认是5秒内20次调用失败），就会启动熔断机 制。

“断路器”总共有三种状态：

• 1.close，闭合状态，正常工作。
• 2.Open，开启状态，熔断。
• 3.Half Open，半开状态，“我觉得我又行了，我先放过一波请求试试实际行不行？”

2.5.2.使用

• 用@HystrixCommand来定制断路器的触发规则。

2.6.hystrix的文档地址

由于交给apache后最新版本的Netflix的spring cloud只包含了eureka，相应的也只包含了eureka的文档，其它组件的文档都不太好找，这里给出hystrix在github上的文档地址：

GitHub - Netflix/Hystrix: Hystrix is a latency and fault tolerance library designed to isolate points of access to remote systems, services and 3rd party libraries, stop cascading failure and enable resilience in complex distributed systems where failure is inevitable.