微服务分布式系统熔断实战 - 为何我们需要 API 级别熔断?

阅读数:1 2020 年 3 月 27 日 22:18

微服务分布式系统熔断实战-为何我们需要API级别熔断?

Go chassis 如何保证上游错误不影响下游系统

go chassis 引用并包装了

带来了熔断和降级功能。

当运行时内部处理中的协程达到一定阈值,错误率达到一定阈值,或者超时达到一定阈值时,就会触发熔断,用户可按需定制调教熔断器配置项设定这些参数。

  • hystrix-go 内部的熔断逻辑

微服务分布式系统熔断实战-为何我们需要API级别熔断?

go chassis 使用统一的 invocation 抽象来代表每一次远程调用,hystrix-go 使用 command 抽象来封装任何一个执行片段,invocation 会被强制封装到 command 中,并在一个 circuit 中执行。

每个 Circuit 都是唯一的 Name,并且有一个 Ticket 桶,用来存放 ticket,一开始它是关闭状态,即一切运转正常。

调用将被强制性的包装进入 circuit 独立协程池中,并领取一个 ticket。

command 最终只有 2 种状态,超时,或者完成。每当达到这两个状态就会归还 ticket。

在这里可以看到 ticket 机制其实跟限流中的令牌桶算法很像。

当超时或者拿不到 ticket 时就会被记为一次错误,当错误达到一定阈值,circuit 就会打开,拒绝发送网络请求。

  • 服务级别隔离

微服务分布式系统熔断实战-为何我们需要API级别熔断?

每个 service 内部会有多个 circuit,每个 circuit 对应一个上游微服务。当 service3 出现问题时(如死锁,或是并发量太大),将物理进行隔绝,即不再发送任何请求,以保证系统健康,service1 依然可以正常和 2,4 交互,保证大部分业务正常。

这么来看还是很理想的,serivce3 的错误调用不至于拖垮 service1(如果死锁了,很容易就拖垮 service1,导致这个由四个服务组成的系统瘫痪),但真的如此么,让我们看看层级复杂些的系统。

  • 为何服务级别隔离还不够?

微服务分布式系统熔断实战-为何我们需要API级别熔断?

每个服务都是基于 go chassis 开发的。

假设 api2 需要调用 service4 完成,api1 调用 3 完成,api3 调用 5 完成。

service4 内的死锁导致 api2 失败了,最终触发熔断。service1 将整个 service2 全部隔离了,导致一个小小的死锁,引发了系统快速失败。

看上去熔断在这里反而起到了坏的效果,那让我们看看没熔断会发生什么。

  • 不加入熔断

微服务分布式系统熔断实战-为何我们需要API级别熔断?

这时就看哪个客户端做了超时处理了,因为死锁的存在,会导致整条调用链路挂死,最终导致客户端端口耗尽后,进而快速失败。

现在来看,死锁在一个不健壮的系统中是一定会拖垮整个分布式系统的,无解。

有熔断和没熔断效果都一样,最终都是快速失败。那么如何解决?

  • API 级别熔断

微服务分布式系统熔断实战-为何我们需要API级别熔断?

每个 circuit 只负责一个 API 的执行,监控,隔离

当 service2 调用 service4 时,单独的接口进入到隔离状态而不影响其他 API 调用。

总结

通过这篇文章我们知道了服务级别的错误隔离是不够的,结构不复杂的系统尚可接受,但是复杂后不能因为一个 API 的错误而隔离整个服务,而是细粒度的进行隔离。go chassis 提供了 API 级别熔断帮助开发者快速隔离问题服务。

熔断的手段有超时实践,并发数,错误率等。它强制性的保护起每一次远程调用,无需开发者自己编写代码处理超时,死锁,网络错误等问题,解放了开发者,让他们更多的去关注业务代码而不是分布式系统带来的复杂性

本文转载自华为云产品与解决方案公众号。

原文链接: https://mp.weixin.qq.com/s/U3GcZWzcEi5DeUgMY1CjpQ

评论

发布