微服务-API网关-熔断降级

介绍

在微服务架构中，各个服务之间往往是级联在一起的，一个服务发生故障时可能会造成以下灾难：

• 服务依赖方调用超时，导致任务队列打满，引起链式反应，最终导致整个集群雪崩。
• 服务依赖方调用返回失败，引起链式反应，最终导致整个集群不可用。

所以需要在微服务不可用时切断故障服务与其他服务的通讯。

熔断是对服务提供者说的，由于某些原因（比如网络不通、服务挂了、请求处理不过来）造成服务提供者不能提供服务时，服务提供者就需要切断和服务调用者的连接，不然就造成资源浪费或者队列打满，从而导致链式反应。

降级是对服务调用者来说的，当A服务调用B服务不通时，A服务就切断与B服务的通讯，同时采取降级措施，比如重试、返回空值，生成相应错误信息等。

设计目的

• 隔离有故障的服务。
• 停止复杂分布式系统中的级联故障。
• 故障恢复后自动由隔离转为通行。
• 在可能的情况下，后退并优雅地降级。
• 启用近实时监视、警报和操作控制。

形态设计

以什么方式运行

我们应该以什么方式来运行熔断呢？微服务还是第三方库？

如果独立出来以微服务方式运行熔断器的话，有以下两方面问题：

• 所有请求都要先通过熔断器服务，这样在网络IO上就是很大的开销，会造成网关整体性能的下降。

• 不利于熔断状态的判断，比如由于队列满造成服务调用失败，这时就应该开启熔断器，但是如果熔断器是以微服务方式运行，这种情况就不好做。

所以最理想的方式是以三方库或者叫插件的方式来运行。

放在调用侧还是被调用侧

如果把熔断器放在被调用服务侧的话会有两方面的问题：

• 依赖方需要和故障方通讯