分布式系统架构4：容错设计模式

这是小卷对分布式系统架构学习的第4篇文章，虽然知道大家都不喜欢看纯技术文章，写了也没多少阅读量，但是为了个人要成长，小卷最近每天都会更新分布式的文章

1.概念

容错策略，指的是"面对故障，我们该做些什么"；而容错设计模式，指的是"要实现某种容错策略，我们该如何去做"。

上一篇已经讲了7种容错策略，为了实现各种策略，开发总结了一些容错设计模式，包括微服务常见的：断路器模式、舱壁隔离模式、超时重试模式。

概念：借鉴了电路中的断路器工作原理，用于防止一个子系统的故障蔓延到整个系统。通过在服务之间增加一个断路器机制，当服务调用频繁失败时，断路器会切换到OPEN状态，拒绝进一步调用，避免浪费资源。并且断路器会定期尝试重连目标服务，如果服务恢复正常，则恢复调用。

断路器本质是一种快速失败策略的实现方式

断路器有三种状态：

关闭状态 (Closed)：断路器关闭，请求正常调用。如果调用失败次数超过设定阈值，断路器会切换到打开状态。
打开状态 (Open)：阻断调用请求，直接返回失败。此状态下，系统不会继续调用目标服务，避免资源浪费。
半开状态 (Half-Open) ：是一种中间状态，断路器需要带有自动故障恢复功能，进入OPEN状态一段时间后，断路器会尝试放行一次请求测试服务是否恢复。如果成功，切换回关闭状态；否则，保持打开状态。

示例：

Netflix Hystrix可以设置一段时间内请求故障率达到阈值（10秒内20个请求，失败率50%），断路器的状态就会变为OPEN

概念：灵感来源于船舶设计，通过为每个模块或服务分配独立的资源池，防止一个模块的故障或资源耗尽影响整个系统。其核心思想是"隔离问题"。简而言之就是：避免某一个远程服务的局部失败影响到全局

主流的网络访问大多是基于 TPR 并发模型（Thread per Request）来实现的，只要请求一直不结束（无论是以成功结束还是以失败结束），就要一直占用着某个线程不能释放。

比如："服务 I"发生了超时，假设平均 1 秒钟内会调用这个服务 50 次，就意味着该服务如果长时间不结束的话，每秒会有 50 条用户线程被阻塞。

Tomcat默认HTTP超时时间是20秒，20秒内会阻塞1000条用户线程，而java应用的线程池通常最大设置为200~400，且Java本身是将线程映射为操作系统内核线程来实现的语言环境。这就意味着从外部看，服务已经全面瘫痪了。不仅是服务1，而是整个Tomcat服务。

解决办法就是为每个服务设立单独的线程池，这样服务1即使阻塞了，比如阻塞5条用户线程，也不影响全局。

应用案例：阿里内部RPC中间件的HSF线程池隔离

适用场景：系统中存在多个高并发调用的服务，需根据用户等级、用户VIP、用户来访区域等因素隔离到不同的服务实例的场景。

概念：适用于解决系统的瞬间故障，如：网络抖动、服务临时过载问题。通过设定调用超时时间和重试次数，在调用失败后自动重试，提升服务调用成功率。

使用重试模式时，实现很简单，需避免滥用，适用场景的条件：

服务熔断：一种保护机制，用于防止一个服务的连续失败导致整个系统的崩溃，属于一种快速失败的容错策略的实现方法。当失败率达到一定阈值时，断路器会"熔断"请求，直接返回错误响应或默认值

服务降级：通过降低非核心服务的优先级、简化服务逻辑或直接返回备用响应，保证核心服务和主要业务功能的稳定性。通常是基于业务优先级主动触发的