服务容错详解

随着微服务架构的普及和项目的实际落地，服务容错的概念逐渐流行。开发人员更加关注服务的稳定性，像 Hystrix、Sentinel 这些用于保护服务稳定运行的组件也开始涌现和发展，在保证服务的稳定性和系统的高可用中扮演着重要的角色。

高可用（High Availability，HA）的主要目的是保障 “业务的连续性”，即在用户眼里，系统永远是正常（基本正常）对外提供服务的，高可用是架构设计和系统搭建时必须要考虑的一点。而谈到高可用，很多开发人员脑海中出现的第一个技术就是 “搭建集群”，通过搭建集群能够有效避免由于单点故障导致的系统不可用。集群化是保障系统 “高可用” 的基本操作，不过只是搭建集群还不够，还要对系统做更多的优化工作，如优化业务代码、引入缓存、引入异步操作的逻辑、优化 SQL 语句、增加服务器的物理配置等。

上述的系统优化手段已经极大地提升了系统的健壮性，但是在微服务环境下，由于硬件、网络、机器性能、算法、程序等各方面的影响，运行异常的情况也在显著增加，如果不做好异常保护，微服务架构就像空中楼阁一样随时可能崩溃。现代微服务架构都是分布式的，由非常多的服务组成。不同服务之间相互调用，组成复杂的调用链路，如图 11-1 所示。

即使单个服务出现了不可用的情形，在链路调用中也会产生放大的效果。复杂链路上的某一环不稳定，就可能层层级联，最终导致整个链路都不可用。

这就是微服务系统高可用性的杀手——“服务雪崩”，如图 11-2 所示。“雪崩”一词指的是山地积雪由于底部溶解等原因造成的突然大块塌落的现象，具有很强的破坏力。服务雪崩效应是一种因 “服务提供者的不可用”（原因）导致 “服务调用者不可用”（结果），并产生级联效应将 “不可用” 逐渐放大的现象，最终导致整个系统不可用。

服务雪崩是一种笼统的描述，生产环境中会出现如下这些不稳定的状况。

为了避免出现上述问题，同时给微服务系统加上一层防护，保障系统的稳定性和高可用性，引入了服务容错。

了解了为什么要引入服务容错后，接下来笔者讲解服务容错具体的落地方案。

以服务雪崩效应为例，这种对系统造成破坏性伤害的状况有两个主要因素。

因此，服务容错的落地方案就要针对这两个问题进行处理。首先进行流量控制，可以采用限流的方式控制请求数量，让请求流量有序地进入应用，并保证流量在一个可控的范围内。其次是针对服务内部响应慢的问题引入断路器模式，当调用链路中某个服务出现不稳定的情况（如调用一直超时或异常比例较高）时，对这个服务的调用进行限制，并让请求快速失败，避免影响系统中其他的服务。

有了解决问题的方案，就可以讲解具体落地实现了，也就是服务容错章节的主角——Sentinel。它是面向分布式、多语言异构化服务架构的流量治理组件，主要以流量为切入点，从流量路由、流量控制、流量整形、熔断降级、系统自适应过载保护、热点流量防护等多个维度帮助开发人员保障微服务的稳定性。