golang 微服务容错处理是如何做的？

随着微服务的规模越来越大，各个微服务之间可能会存在错综复杂的调用关系

在我们实际工作中，确实慢慢的也出现了很多问题，整个系统的弊端的慢慢的展现出来

例如就会有这样的情况：

• 服务 A 去请求服务B，服务 B 还需要去请求 服务 C，由于服务 C 的问题，导致整条链路都出现了问题，甚至整个系统都坏掉

工作中，我们一般为了提高服务的健壮性，会去设置失败后重试机制，用来避免一些因为网络抖动，暂时性的故障

可是，如果是一个长期性的故障，那么这个重试机制，只会加重我们服务的负担，一直在消耗连接和性能

这个时候，就需要服务熔断机制了

服务熔断机制

服务的熔断机制是什么呢？

其实熔断，是我们以前学习物理知识的时候听到过的词，例如家里的电路，在总开关的位置，都会有一个保险丝来保障我们电路的安全，若是出现了短路，或者是电流异常过大的情况下，保险丝就会因为过热而被熔断，进而断电，最终达到保护电表和电路的作用

在如今的微服务架构中，也需要有这一根保险丝

如上图，是一个很常见的微服务之间的调用关系

请求 ：客户端 – 网关 – 服务A – 服务B

响应：服务B – 服务A – 网关 – 客户端

整条链路中，只要有一个点出现问题，客户端都无法得到期望的结果

在微服务架构中，服务之间的调用一般分为

• 服务调用方
• 服务提供方

为什么需要熔断？

当下游的服务因为过载或故障，无法提供服务，我们需要及时的让上游服务知悉，且暂时 熔断 调用方和提供方的调用链，这是为了避免服务雪崩现象的发生

服务雪崩

服务雪崩就是指调用链中的某个环节不可用了，此处特别指的是服务的提供方，导致上游服务不可用，并最终影响像雪崩一样扩散到整个系统，最终导致整个系统都不可用

简单故障场景

还是上面的一个熟悉场景，正常的 客户端 – 网关 – 服务A – 服务B 请求过程中，上面展示了三个阶段，这也是服务雪崩一般的 3 个阶段

• 服务提供者不可用

系统运行之处，一切运转良好。每个服务正常请求和响应，当某一个刻，服务 B 由于 自身异常，或者网络故障导致自身不可用，无法及时的响应打过来的各种请求

• 服务调用者不可用

在 服务B 作为服务提供者不可用的时候，客户端可能会因为错误提示，或者长时间的阻塞而不断的发送相同的请求到网关去，请求再次发送到网关，发送到 服务 A，最终又到 服务 B 知道超时也没有正常响应

重复多次，因为服务 A发起了过多的请求给到服务 B 而产生的等待线程，耗尽了线程池中的资源，那么 服务 A 自身也无法及时响应外部的请求，最终导致 服务 A 也不可用

• 整个系统不可用

经过上述的流程，服务 A同样也阻塞了转发请求的网关，网关因为大量的等待请求响应也会产生大量的阻塞线程，同样的道理，网关最后没有足够的资源去处理其他请求，这样就导致整个系统无法对外提供服务

加上服务融到保障系统的可用性

如上图，服务 A 访问 服务 B 的过程中，中间加了一个保险丝，也就是一个断路器，

• 当服务 A 访问 服务 B 的时候，服务 B 这时出现了轻微故障，导致超时返回
• 服务 A 又 继续访问 服务 B 的时候，服务 B 已经不可用了，导致相应失败
• 此时断路器检测到异常，则打开保险丝，设置异常返回
• 服务 A 再次访问服务 B，保险丝自身就立即返回 错误消息给到 服务 A，这样避免服务 A 资源耗尽而不可用，进而保护了服务调用者

断路器

如上图，断路器有 3 中状态互相切换，我们可以这样来理解：

1 关闭状态 – 打开状态

• 周期内函数执行失败超出阈值，就会从关闭状态到打开状态

2 打开状态 – 半开状态

• 一定时候后，断路器会尝试执行请求函数，就会转到半开状态

3 半开 – 关闭

• 尝试执行请求成功次数超过设定的阈值，就会转到关闭状态

4 半开状态 – 打开状态

• 尝试执行请求函数成功次数没有超过设定的阈值，就会转到打开状态

今天就到这里，学习所得，若有偏差，还请斧正

欢迎点赞，关注，收藏

朋友们，你的支持和鼓励，是我坚持分享，提高质量的动力

好了，本次就到这里

技术是开放的，我们的心态，更应是开放的。拥抱变化，向阳而生，努力向前行。

我是阿兵云原生，欢迎点赞关注收藏，下次见~