前言

“容错性设计”（Design for Failure）是微服务的一个核心原则。
使用微服务架构，拆分出的服务越来越多，也逐渐导致以下问题：

1. 某一个服务的崩溃，会导致所有用到这个服务的其他服务都无法正常工作，一个点的错误经过层层传递，最终波及到调用链上与此有关的所有服务，这便是雪崩效应。如何防止雪崩效应，便是微服务架构容错性设计原则的具体实践，否则服务化程度越高，整个系统反而越不稳定。
2. 服务虽然没有崩溃，但由于处理能力有限，面临超过预期的突发请求时，大部分请求直至超时都无法完成处理。这种现象产生的后果跟交通堵塞是类似的，如果一开始没有得到及时地治理，后面就会需要很长时间才能使全部服务都恢复正常。

以上就是“流量治理”要解决的问题，涉及到服务容错、流量控制、服务质量管理等一系列解决方案。

服务容错

构建微服务系统的指导性原则（九大原则）中，多数特征可能会有或多或少的妥协，比如分散治理、数据去中心化、轻量级通讯机制、演进式设计，但有一些特征是无法做出妥协的，就包括容错性设计。

容错性设计不能妥协的原因在于，分布式系统的本质是不可靠的，一个大的服务集群中，程序可能崩溃、节点可能宕机、网络可能中断，这些“意外情况”其实全部都在“意料之中”。原本信息系统设计成分布式架构的主要动力之一，就是提升系统的可用性，最低限度也必须保证将原有系统重构为分布式架构之后，可用性不出现倒退才行。

容错策略

容错策略，指的是“面对故障，我们该做些什么”，这里主要介绍7 种常见的容错策略，包括故障转移、快速失败、安全失败、沉默失败、故障恢复、并行调用和广播调用。

1. 故障转移（Failover）
   高可用的服务集群中，多数的服务，尤其是那些经常被其他服务依赖的关键路径上的服务，都会部署多个副本。这些副本可能部署在不同的节点（避免节点宕机）、不同的网络交换机（避免网络分区），甚至是不同的可用区（避免整个地区发生灾害或电力、骨干网故障）中。
   故障转移是指，如果调用的服务器出现故障，系统不会立即向调用者返回失败结果，而是自动切换到其他服务副本，尝试其他副本能否返回成功调用的结果，从而保证了整体的高可用性。
   故障转移的容错策略应该有一定的调用次数限制，比如允许最多重试三个服务，如果都发生报错，那还是会返回调用失败。引入调用次数的限制，不仅是因为重试有执行成本，更是因为过度的重试反而可能让系统处于更加不利的状况。

2. 快速失败（Failfast）
   一些业务场景是不允许做故障转移的，因为故障转移策略能够实施的前提，是服务具有幂等性。那对于非幂等的服务，重复调用就可能产生脏数据，引起的麻烦远大于单纯的某次服务调用失败。这时候，就应该把快速失败作为首选的容错策略。当故障发生时，尽快让服务报错并抛出异常，坚决避免重试，由调用者自行处理。

3. 安全失败（Failsafe）
   在一个调用链路中的服务，通常也有主路和旁路之分，并不见得每个服务都是不可或缺的，属于旁路逻辑的一个显著特点是，服务失败了也不影响核心业务的正确性。典型的有审计、日志、调试信息，等等。
   属于旁路逻辑的另一个显著特征是，后续处理不会依赖其返回值，或者它的返回值是什么都不会影响后续处理的结果。
   对这类逻辑，一种理想的容错策略是，即使旁路逻辑调用失败了，也当作正确来返回，如果需要返回值的话，系统就自动返回一个符合要求的数据类型的对应零值，然后自动记录一条服务调用出错的日志备查即可。这种容错策略，被称为安全失败。

4. 沉默失败（Failsilent）
   如果大量的请求需要等到超时（或者长时间处理后）才宣告失败，很容易因为某个远程服务的请求堆积而消耗大量的线程、内存、网络等资源，进而影响到整个系统的稳定性。
   面对这种情况，一种合理的失败策略是当请求失败后，就默认服务提供者一定时间内无法再对外提供服务，不再向它分配请求流量，并将错误隔离开来，避免对系统其他部分产生影响。这种容错策略，就被称为沉默失败。

5. 故障恢复（Failback）
   故障恢复一般不单独存在，而是作为其他容错策略的补充措施。故障恢复是指，当服务调用出错了以后，将该次调用失败的信息存入一个消息队列中，然后由系统自动开始异步重试调用。
   一方面是尽力促使失败的调用最终能够被正常执行，另一方面也可以为服务注册中心和负载均衡器及时提供服务恢复的通知信息。很显然，故障恢复也要求服务必须具备幂等性，由于它的重试是后台异步进行，即使最后调用成功了，原来的请求也早已经响应完毕。所以，故障恢复策略一般用于对实时性要求不高的主路逻辑，也适合处理那些不需要返回值的旁路逻辑。
   为了避免在内存中的异步调用任务堆积，故障恢复与故障转移一样，也应该有最大重试次数的限制。

6. 并行调用（Forking）
   并行调用策略，是指一开始就同时向多个服务副本发起调用，只要有其中任何一个返回成功，那调用便宣告成功。这种策略是在一些关键场景中，使用更高的执行成本换取执行时间和成功概率的策略。

7. 广播调用（Broadcast）
   广播调用与并行调用是相对应的，都是同时发起多个调用，但并行调用是任何一个调用结果返回成功便宣告成功，而广播调用则是要求所有的请求全部都成功，才算是成功。也就是说，对于广播调用来说，任何一个服务提供者出现异常都算调用失败。因此，广播调用通常被用于实现“刷新分布式缓存”这类的操作。
   

附

此文章为3月Day01学习笔记，内容来源于极客时间《周志明的软件架构课》