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

本文探讨了微服务架构中API网关的熔断和降级设计,旨在防止服务雪崩,实现故障隔离和优雅降级。文章讨论了熔断器的运行形态,建议以插件形式运行,并放置于调用侧。架构设计部分涉及流程分析、熔断器状态计算和粒度选择,提出在API接口级别进行熔断。同时,文章提到了数据库选型、降级机制以及熔断器的三种状态,并给出了故障恢复后的自动切换策略。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

介绍

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

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

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

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

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

设计目的

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

形态设计

以什么方式运行

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

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

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

  • 不利于熔断状态的判断,比如由于队列满造成服务调用失败,这时就应该开

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值