分布式熔断方案

2022-01-29 约 854 字预计阅读 2 分钟

分布式熔断方案note

微服务架构中因各个服务之间的依赖和调用关系较为复杂，当下游的服务出现问题时就可能会造成上游的雪崩效应。

解决雪崩效应就需要建立有效的服务容错机制，主要有两个方向考虑：

其中服务冗余就需要建立集群，依托负载均衡和重试机制，保证服务可用性，当服务出错时可以设置以下不同的策略：

而除了服务冗余之外就是服务熔断和限流的保护机制，熔断是预防下游服务出现故障时阻断下游调用，限流是防止上游服务调用量过大导致当前服务或下游服务被压垮。

核心在于AOP进行请求拦截判断是否熔断，根据策略进行熔断状态转移。

根据服务发现和服务调用的不同方式，目前主要有三种方案：

该模式下具体到服务访问流程中最为直接，即在代码层面加入熔断判断，基于AOP模式需要经过BeforeCall、Call、AfterCall的操作流程。

具体流程可以参考下图：

该模式下一般引入网关进行统一熔断限流处理后再进行转发到达具体服务，可以为异步也可以为同步，具体根据实际业务场景。

在异步模式下需要注意熔断状态判断切换时的延时，优势在于对请求性能无影响。

在这里可以参考下图架构的方案，重点是利用Kafka进行异步日志收集：

该模式适应于微服务架构下的服务治理，在服务节点中加入粒度更小的治理模块，本质就是将SDK代码部署为单独进程且与服务机器共存，并作为该机器的代理与其他节点进行交互。

具体实现方案和策略与上述模式没有太大区别，只是落地方案不同，因为服务网格模式下都处于类似于k8s等集群管理的系统下。