微服务限流熔断是什么，怎么做，不做行不行？

“在分布式应用中，最常见的问题是什么呢？”

“一个分布式应用部署上去后，还要关注什么？”

“这服务的远程调用依赖似乎有点多...”

前言

在 《微服务的战争：级联故障和雪崩》中有提到，在一个分布式应用中，最常见，最有危险性之一的点就是级联故障所造成的雪崩，而其对应的解决方案为根据特定的规则/规律进行流量控制和熔断降级，避免请求发生堆积，保护自身应用，也防止服务提供方进一步过载。

简单来讲就是，要控制访问量的流量，要防各类调用的强/弱依赖，才能保护好应用程序的底线。

诉求，期望

1. 诉求：作为一个业务，肯定是希望自家的应用程序，能够全年无休，最低限度也要有个 4 个 9，一出突发性大流量，在资源贫乏的窗口期，就马上能够自动恢复。

2. 期望：万丈高楼平地起，我们需要对应用程序进行流量控制、熔断降级。确保在特定的规则下，系统能够进行容错，只处理自己力所能及的请求。若有更一步诉求，再自动扩缩容，提高系统资源上限。

解决方案

要如何解决这个问题，或者说是达到这个目的呢？

咱们可以关注到问题的核心点是 “系统没有任何的保护的情况下”，因此方向上就是让系统，让应用程序有流量控制的保护。一般含以下几个方面：

• 来自端控制：在业务/流量网关处内置流量控制、熔断降级的外部插件，起到端控制的效果。

• 来自集群/节点控制：在统一框架中内建流量控制、熔断降级的处理逻辑，起到集群/节点控制的效果。

• 来自 Mesh 控制：通过 ServiceMesh 来实现流量控制、熔断降级。侵入性小，能带来多种控制模式，但有利有弊。

以上的多种方式均可与内部的治理平台打通，且流量控制、熔断降级是不止面试应用程序的，就看资源埋点上如何设计、注入。常见有如下几种角度：

• 资源的调用关系：例如远程调用，像是面向 HTTP、SQL、Redis、RPC 等调用均，另外针对文件句柄控制也可以。

• 运行指标：例如 QPS、线程池、系统负载等。

流量控制

在资源不变的情况下，系统所能提供的处理能力是有限的。而系统所面对的请求所到来的时间和量级往往是随机且不可控的。

因此就会存在可能出现突发性流量，而系统在没有任何的保护的情况下，很有可能会在数分钟内就无法提供正常服务。常见的前导现象是先出现调用延迟，接着持续出现饱和度上升，最终假死。

流量控制一般常见的有两种方式，分别是：基于 QPS、基于并发隔离。

基于 QPS

最常用的流量控制场景，就是基于 QPS 来做流控，在一定的时间窗口内按照特定的规则达到所设定的阈值则进行调控：

案例

在本文中借助 sentinel-golang 来实现案例所需的诉求，代码如下：

import (
 ...
 sentinel "github.com/alibaba/sentinel-golang/api"
 "github.com/alibaba/sentinel-golang/core/base"
 "github.com/alibaba/sentinel-golang/core/flow"
 "github.com/alibaba/sentinel-golang/util"
)

func main() {
 _ = sentinel.InitDefault()
 _, _ = flow.LoadRules([]*flow.Rule{
  {
   Resource:               "控制吃煎鱼的速度",
   Threshold:              60,
   ControlBehavior:        flow.Reject,
  },
 })

 ...
 e, b := sentinel.Entry("控制吃煎鱼的速度", sentinel.WithTrafficType(base.Inbound))
 if b != nil {
     // Blocked
 } else {
     // Passed
     e.Exit()
 }
}

总的来讲，上述规则结果就是 1s 内允许通过 60 个请求，超出的请求的处理策略为直接拒绝（Reject）。

首先我们初始化了 Sentinel 并定义资源（Resource）为 “控制吃煎鱼的速度”。其 Threshold 配置为 3，也就是 QPS 的阈值为 3，统计窗口未设置默认值为 1s，ControlBehavior 控制的行为为直接拒绝。

而在满足阈值条件后，常见的处理策略还有匀速排队（Throttling），匀速排队方式会严格控制请求通过的间隔时间，也就是让请求以均匀的速度通过。

基于并发隔离

基于资源访问的并发协程数来控制对资源的访问数量，主要是控制对资源访问的最大协程数，避免因为资源的异常导致协程耗尽。

这类情况，Go 语言在设计上常常可以使用协程池来进行控制，但设计总是赶不上计划的，且不同场景情况可能不同，因此作为一个日常功能也是非常有存在的必要性。

熔断降级

在分布式应用中，随着不断地业务拆分，远程调用逐渐变得越来越多。且在微服务盛兴的情况下，一个小业务拆出七八个服务的也常有。

此时就会出现一个经典的问题，那就是客户端的一个普通调用，很有可能就要经过好几个服务，而一个服务又有可能远程调用外部 HTTP、SQL、Redis、RPC 等，调用链会特别的长。

若其中一个调用流程出现了问题，且没有进行调控，就会出现级联故障，最终导致系统雪崩：

服务 D 所依赖的外部接口出现了故障，而他并没有做任何的控制，因此扩散到了所有调用到他的服务，自然也就包含服务 B，因此最终出现系统雪崩。

这种最经典的是出现在默认 Go http client 调用没有设置 Timeout，从而只要出现一次故障，就足矣让记住这类 “坑”，毕竟崩的 ”慢“，错误日志还多。

（via: 《微服务的战争：级联故障和雪崩》）

目的和措施

为了解决上述问题所带来的灾难，在分布式应用中常需要对服务依赖进行熔断降级。在存在问题时，暂时切断内部调用，避免局部不稳定因素导致整个分布式系统的雪崩。

而熔断降级作为保护服务自身的手段，通常是在客户端进行规则配置和熔断识别：

常见的有三种熔断降级措施：慢调用比例策略、错误比例策略、错误计数策略。

慢调用比例

在所设定的时间窗口内，慢调用的比例大于所设置的阈值，则对接下来访问的请求进行自动熔断。

错误比例

在所设定的时间窗口内，调用的访问错误比例大于所设置的阈值，则对接下来访问的请求进行自动熔断。

错误计数

在所设定的时间窗口内，调用的访问错误次数大于所设置的阈值，则对接下来访问的请求进行自动熔断。

实践案例

知道流量控制、熔断降级的基本概念和功能后，在现实环境中应该如何结合项目进行使用呢。最常见的场景是可针对业务服务的 HTTP 路由进行流量控制，以 HTTP 路由作为资源埋点，这样子就可以实现接口级的调控了。

还可以增强其功能特性，针对参数也进行多重匹配。常会有这种限流诉求：针对 HTTP GET /eddycjy/info 且 language 为 go 的情况下进行限流。

另外还可以针对 HTTP 调用封装统一方法，进行默认的熔断注入，实现多重保障。

而结合系统负载、服务 QPS 等，可以对限流熔断的规则数据源进行实时调控，再结合 Watch 机制，就能够比较平滑的实现自适应限流熔断的接入。

总结

在分布式应用中，限流熔断是非常重要的一环，越早开始做越有益处。

但需要注意的是，不同公司的业务模型多多少少有些不一样，所针对的匹配维度多少有些不同，因此需要提前进行业务调研。

在做业务的限流熔断时，注意把度量指标的打点做上，这样子后续就能够结合 Prometheus+Grafana+Alertmanager 做一系列的趋势图，熔断告警，自动扩缩容等相关工作了，会是一个很好的助力。