微服务治理之服务容错
为何要容错
微服务架构下服务之间是通过网络进行交互，但受限于网络、计算机CPU和磁盘等硬件资源以及电力供应，无法保证微服务100%高可用。若交易链路上某个微服务发生故障，无法正常响应上游系统，导致上游系统服务堆积，甚至因资源耗尽而宕机，使其无法正常对客户提供服务。这种因微服务之间的依赖关系，使得故障转移至上游系统，称之为服务雪崩。
同样，受计算机硬件资源和操作系统&线程数等软件资源的制约，微服务的服务能力有上限瓶颈，业内常用TPS进行描述。换句话说，就是单台计算机上的微服务TPS并非无穷大。随着交易量的增长，若某一时刻硬件资源或软件资源耗尽，则微服务将无法再接受新的客户请求，出现短暂或长时间的宕机。
为了保证微服务能够持续为客户提供服务，避免因交易量的增长而宕机或因下游系统的故障导致的雪崩出现，微服务容错应运而生。
容错方案
常见的容错方案有限流、熔断、降级、隔离、超时、重试等
服务限流
通过计算上游系统滑动窗口时间内的请求数并对超过预先设置的阈值的新请求进行拒绝的方式达到保证服务自身高可用的目的。
服务限流常用的实现算法有令牌桶算法、漏斗算法、原子计数器算法和信号量算法。Resilience4j限流实现有两种，分别是基于原子计数器和基于信号量实现。
服务熔断
通过计算下游系统在滑动窗口时间内的请求失败率和超时率并对达到预先设置的阈值的新请求进行拒绝的方式达到保证服务自身高可用的目的。
服务熔断常用的实现算法为状态机。Resilience4j的熔断实现也是基于状态机。
服务降级
服务限流和熔断生效后，将拒绝新的请求，默认拒绝方式为抛出异常，但客户可能无法感知，而一直等待。为了避免这种无谓的等待，在服务端发生限流熔断或者其他异常情况时，给客户固定的错误响应，称之为服务降级。
服务隔离
通过物理资源或逻辑资源隔离的方式对服务进行隔离，使得服务发生资源耗尽等故障时不会影响到其他服务，达到保证其他服务自身高可用的目的。
服务隔离常用的实现算法有基于信号量隔离算法和基于线程池隔离算法。Resilience4j隔离实现有两种，分别是基于信号量隔离和基于线程池隔离。
下一节将通过Resilience4j的源码介绍其服务容错的实现原理，欢迎订阅。