「这是我参与11月更文挑战的第 16 天，活动详情查看：2021最后一次更文挑战」
之前说到过微服务容错处理，可以使用 断路器
使用断路器的原因是：
当下游的服务因为过载或故障，无法提供服务，我们需要及时的让上游服务知悉，且暂时 熔断 调用方和提供方的调用链，这是为了避免服务雪崩现象的发生
go 里面可以使用什么方式来做断路器 呢？
hystrix-go
go 中有一个项目实现了 这个断路器的功能：
https://github.com/afex/hystrix-go
Hystrix 能够在服务提供者出现故障时，隔离调用者和提供者，防止服务级联失败
并且 Hystrix 还提供失败回滚的逻辑，是系统快速从异常中恢复
为啥要用 Hystrix 来作为断路器？
- Hystrix 自身完美的是实现了断路器模式
- 自身可以提供信号量和线程隔离的方式以保护服务调用者的线程资源
- 对延迟和失败提供了强大的容错能力，为系统提供保护和控制
图解 Hystrix 运行流程
如下是 golang 微服务容错处理是如何做的？ 提到的断路器的 三种状态：
结合起来看看 Hystrix 具体流程
上述流程我们可以这样来理解
- 使用 hystrix 的时候，hystrix 会给每一个远程调用逻辑封装成一个指令，这个指令包含这个远程调用的逻辑和失败回滚逻辑，这个 命令是 hystrix 唯一识别的
- hystrix 根据 对应的指令获取到对应的断路器，判断断路器是否打开
- 若打开
- 执行执行失败回滚逻辑，不直接执行远程调用逻辑，因此此时服务已经熔断了
- 若关闭或者是半开状态
- 将执行池请求通行证
- 若打开
- hystrix 中我们可以配置多个参数，最大并发数量，超时时间，最小请求阈值，超时窗口时间 和 错误比例阈值等等
图中我们可以看到 Metrics 控制器，
当我们的服务执行异常或者下游服务超时的时候， hystrix 命令就会向 Metrics 控制器 上报执行结果，并且 hystrix 命令对应的逻辑会进入到失败回滚逻辑
Metrics 控制器的作用
Metrics 控制器使用滑动窗口的方式统计一段时间内的调用次数，失败次数，超时次数 和 被拒绝的次数，下一篇的案例代码中，有体现如何配置
这个被拒绝的次怎么理解呢？指的是在向执行池子请求通行证的时候，池子已满，故被拒绝
如果这段时间内，执行错误的频率出超过了断路器错误率的阈值，那么断路器就会打开
在重试超时定时器到达之前的请求都会直接进入失败回滚逻辑，拒绝执行真正的远程调用
因此这就可以达到微服务容错的目的
今天就到这里，学习所得，若有偏差，还请斧正
欢迎点赞，关注，收藏
朋友们，你的支持和鼓励，是我坚持分享，提高质量的动力
好了，本次就到这里
技术是开放的，我们的心态，更应是开放的。拥抱变化，向阳而生，努力向前行。
我是小魔童哪吒，欢迎点赞关注收藏，下次见~
