聊一聊服务治理三板斧：限流、熔断、降级和go-sentinel的实现

我们知道，对于一个项目之初，我们不可能上来就按几千的并发去配置，为什么？两个方面，第一个是成本高。第二个是维护难度大。即便是天猫淘宝这种，也是采用的动态扩容的方式来应对双十一。那么一个项目如何应对突然的高并发，我们有哪些常用的措施和处理呢？我们接下来就来看看 限流熔断和降级

限流

比如系统本来可以处理1000个请求，忽然一下子来了2000个，为了不让系统崩溃，最简单的方式，就是限流，我只接1000个，超出1000个的不提供服务。
那么限流的方法有哪些呢？我们继续看。

流量计数器

看名字就知道了，比如限制每秒的请求数，比如我们每秒限1000。但是这样有一个问题，就是这种流量计数在某个时间点可能是失效的。因为这种计数的前提是在1s内我们假定了请求是匀速的。但是如果是这种情况，就可能起不到限流的效果。

滑动时间窗口

既然以时间为界限不行的话，我们就以时间窗口为界限，保证每个时间段内都不能超过1000qps

漏桶算法

一个请求在被系统处理之前，先找一个漏桶存起来，然后再以固定速率流出，比如这个漏桶可以存1000个请求，如果漏桶中有超出1000个未被处理的请求，那么这部分请求就会溢出，也就是被丢弃，比如我们常用的消息队列。

令牌桶算法

令牌桶就是以固定的速率产生，并缓存到令牌桶中，每个请求必选先获取令牌才能系统处理，令牌桶存满的时候，多余的令牌被丢弃。

nginx的限流

我们以nginx为例，看一下nginx是怎么限流的。
nginx的限流主要有两种方式，一种是限制访问频率，一种是限制并发连接数。

• limit_req_zone：用来限制单位时间内的请求数，即速率限制 , 采用的漏桶算法 “leaky bucket”。例如下面的配置

http {
   
   
	 # 定义限流策略  $binary_remote_addr代表限流对象，表示基于客户端ip限流  
	 # zone：定义内存区大小，表示用10m的空间来存储ip  
	 # rate 1r/s表示每秒处理一个请求，nginx实际的管理单位时间是毫秒，其实就是 1000ms处理一个请求
	 limit_req_zone $binary_remote_addr zone=rateLimit:10m rate=1r/s ;
	 # 搜索服务的虚拟主机
	 server {
   
   
		 location / {
   
   
		 # 使用限流策略，burst=5，重点说明一下这个配置，burst 爆发的意思，这个配置的意思是设置一个大小为 5 的缓冲区（队列）当有大量请求（爆发）过来时，
		 # 超过了访问频次限制的请求可以先放到这个缓冲区内。nodelay，如果设置，超过访问频次而且缓冲区也满了的时候就会直接返回 503，如果没有设置，则所
		 # 有请求会等待排队。
		 limit_req zone=rateLimit burst=5 nodelay;
	 	}
	 } 
}

我们1s内发起200个请求看一下,6个请求成功了，也就是每秒1个的请求和5个缓冲区请求成功，其他的返回503

• limit_conn_zone：用来限制同一时间连接数，即并发限制。

http {
	 # 定义限流策略
	 limit_conn_zone $binary_remote_addr zone=perip:10m;
	 limit_conn_zone $server_name zone=perserver:10m;
	 # 搜索服务的虚拟主机
	 server {
		 location / {
			 # 对应的 key 是 $binary_remote_addr，表示限制单个 IP 同时最多能持有 1 个连接。
			 limit_conn perip 1;
			 # 对应的 key 是 $server_name，表示虚拟主机(server) 同时能处理并发连接的总数。注意，只有当 request header 被
			后端 server 处理后，这个连接才进行计数。
			 limit_conn perserver 10 ;
			 proxy_pass http://train-manager-search ;
		 }
	 } 
}

降级

我们前面看到了，限流之后有一部分的请求直接返回的503，这样对用户体验非常不好，但是我们可能有时候会看到这样的页面，比如 xx活动异常火爆，请稍后再试等提示页。或者是某个商品详情页，优先推送缓存数据而非实时数据，这就是服务降级。服务降级的核心是对非核心的，非关键的业务进行降级。

熔断

熔断这个词大家应该是熟悉的，比如家里的保险丝，当电流过大或者发生短路的时候，就会熔断，从而避免发生更大的危害。服务熔断也类似，当被调用方出现故障。调用方出于自我保护的目的，主动停止调用。为什么要主动停止调用？我之前就有过这样的经历，由于某个MySQL服务器性能的问题，执行一个SQL要好几秒。MySQL的请求越来越多，最终导致MySQL宕机，接着php的请求也越来越多，php进程打满，最终php也跟着报错。最终整个服务挂掉。

技术选型

前面我们讲了限流 熔断 和降级 ，并且用nginx演示了限流的示例。我们接下来就来看看go中，有哪些组件可以实现流量控制呢，这里我们挑出来两个常见的sentinel和hystrix来对比一下,基于功能性，我们选择了sentinel。

sentinel

Sentinel 是阿里中间件团队开源的，面向分布式服务架构的轻量级高可用流量控制组件，主要以流量为切入点，从流量控制、熔断降级、系统负载保护等多个维度来帮助用户保护服务的稳定性。可以看到，sentinel是2020年推出了go版本。

sentinel-golang实现限流

• 首先，文档地址先找到

流控的配置规则

一条流控规则主要由下面几个因素组成，我们可以组合这些元素来实现不同的限流效果：

• Resource：资源名，即规则的作用目标。
• TokenCalculateStrategy: 当前流量控制器的Token计算策略。Direct表示直接使用字段 Threshold 作为阈值；WarmUp表示使用预热方式计算Token的阈值。
• ControlBehavior: 表示流量控制器的控制策略；Reject表示超过阈值直接拒绝，Throttling表示匀速排队。
• Threshold: 表示流控阈值；如果字段 StatIntervalInMs 是1000(也就是1秒)，那么Threshold就表示QPS，流量控制器也就会依据资源的QPS来做流控。
• RelationStrategy: 调用关系限流策略，CurrentResource表示使用当前规则的resource做流控；AssociatedResource表示使用关联的resource做流控，关联的resource在字段 RefResource 定义；
• RefResource: 关联的resource；
• WarmUpPeriodSec: 预热的时间长度，该字段仅仅对 WarmUp 的TokenCalculateStrategy生效；
• WarmUpColdFactor: 预热的因子，默认是3，该值的设置会影响预热的速度，该字段仅仅对 - WarmUp 的TokenCalculateStrategy生效；
• MaxQueueingTimeMs: 匀速排队的最大等待时间，该字段仅仅对 Throttling ControlBehavior生效；
• StatIntervalInMs: 规则对应的流量控制器的独立统计结构的统计周期。如果StatIntervalInMs是1000，也就是统计QPS。

这里特别强调一下 StatIntervalInMs 和 Threshold 这两个字段，这两个字段决定了流量控制器的灵敏度。以 Direct + Reject 的流控策略为例，流量控制器的行为就是在 StatIntervalInMs 周期内，允许的最大请求数量是Threshold。比如如果 StatIntervalInMs 是 10000，Threshold 是10000，那么流量控制器的行为就是控制该资源10s内运行最多10000次访问。

接下来我们参照官方的demo，写一个更简单易懂的一段代码来解释

• 先来看一下最简洁的丐版

package main

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

func main() {
   
   
	//初始化sentinel
	err := sentinel.InitDefault()
	if err != nil {
   
   
		log.Fatalf("初始化sentinel失败:%v", err)
	}
	//配置限流规则 可以根据resource配置多个规则
	_, err = flow.LoadRules([]*flow.Rule{
   
   

		//rule1规则:1000ms内最多处理10个请求,多余的直接拒绝
		{
   
   
			Resource:               "rule1",     //规则的名称
			TokenCalculateStrategy: flow.Direct, //当前流量控制器的Token计算策略。Direct表示直接使用字段 Threshold 作为阈值；WarmUp表示使用预热方式计算Token的阈值。
			ControlBehavior:        flow.Reject, //表示流量控制器的控制策略；Reject表示超过阈值直接拒绝，Throttling表示匀速排队。
			Threshold:              10,          //表示流控阈值；如果字段 StatIntervalInMs 是1000(也就是1秒)，那么Threshold就表示QPS，流量控制器也就会依据资源的QPS来做流控。
			StatIntervalInMs:       1000,        //StatIntervalInMs 和 Threshold 这两个字段，这两个字段决定了流量控制器的灵敏度。以 Direct + Reject 的流控策略为例，流量控制器的行为就是在 StatIntervalInMs 周期内，允许的最大请求数量是Threshold。比如如果 StatIntervalInMs 是 10000，Threshold 是10000，那么流量控制器的行为就是控制该资源10s内运行最多10000次访问。
		},
	})
	if err != nil {
   
   
		log.Fatalf("初始化sentinel加载限流规则失败:%v", err)
	}

	//最终的限流实现通过这个方法实现
	e, b := sentinel.Entry("rule1", sentinel.WithTrafficType(base.Inbound))
	if b != nil {
   
   
		log.Println("限流了")
	} else {
   
   
		log.Println("未限流")
		e.Exit()
	}
}

• 上面我们看到，是通过Entry来计数的，接下来我们通过for循环来，一秒内发送20个计数看看什么样

	for i