基于Sentinel的高可用限流系统HASentinel设计及实现

注：

当前博客中的内容不是最新的内容，最新的博客内容请查看有道笔记中记录的内容：

https://note.youdao.com/ynoteshare1/index.html?id=f2f88ed8e33ada01e8c44ed5d8b3ac5f&type=note

因为内容比较多，确实不方便搬运，需要详细了解的，请移步。

该项目的源代码也已经完全开源了，详情请查码云开源项目HASentinel：

https://gitee.com/laofeng/hasentinel

一、背景说明

1、为什么要限流

拿旅游景点举个示例，每个旅游景点通常都会有最大的接待量，不可能无限制的放游客进入，比如故宫每天只卖八万张票，超过八万的游客，无法买票进入，因为如果超过八万人，景点的工作人员可能就忙不过来，过于拥挤的景点也会影响游客的体验和心情，并且还会有安全隐患；只卖N张票，这就是一种限流的手段。

软件架构中的服务限流也是类似，也是当系统资源不够的时候，已经不足以应对大量的请求，为了保证服务还能够正常运行，那么按照规则，系统会把多余的请求直接拒绝掉，以达到限流的效果；大家应用都有参与过双11，当天晚上的客服系统通常都是不让访问的，当用户访问的时候会提示“为了更好的提供服务...请于XX时间后再次访问”等，这个就是被限流了，也是为了确保用主要业务，如商品浏览、购物车、下单、付款等业务可以更顺利，减少由于其它非重要系统对主系统的影响。

2、Sentinel的主要特点

多样化的流量控制 
熔断降级 
系统负载保护 
实时监控和控制台

3、默认的架构

其默认的架构很简单，应用的注册和监控数据，都是保存在Sentinel的内存中的，不能够直接使用于生产。不过也正因为其简单，方便大家体验，才会受到这么多用户的欢迎，并且其提供了许多的扩展点给用户，大家可以根据自己的应用场景去设计。

二、架构设计

设计原则：

1）高可用

2）高可扩展

3）高性能

4）支持高并发

三、具体实现

1、sentinel-dashboard的修改

1）修改Metric的存储

将Metric数据由默认存储到内存中，修改为存储到外部Influxdb集群中，Influxdb集群理论上支持任意多个Influxdb实例，sentinel-dashboard会根据app对存储进行sharding，然后将数据存储到指定的Influxdb实例中，application.properties 中增加类似如下Influxdb的配置：

#Influxdb理论上可以上多个，以英文的逗号分隔不同Influxdb的URL influxdb.url=http://localhost:8086,
http://localhost:18086 
#目前要求所有Influxdb都使用相同的用户名和密码 
influxdb.username=admin 
influxdb.password=admin

2）修改限流配置的存储

将限流配置由默认存储到内存中，修改为存储到外部的Zookeeper中，application.properties 中增加类似如下Influxdb的配置：

dynamic.rules.source.type = zookeeper 
zookeeper.config.connectString = 127.0.0.1:2181 
zookeeper.config.sessionTimeout = 30000 
zookeeper.config.connectionTimeout = 10000

注：ZK中需要建立以下节点用于存储规则：

/SENTINEL-GROUP/APP-MACHINES 
/SENTINEL-GROUP/AUTHORITY-RULES 
/SENTINEL-GROUP/DEGRADE-RULES 
/SENTINEL-GROUP/FLOW-RULES 
/SENTINEL-GROUP/HOT-RULES 
/SENTINEL-GROUP/SYSTEM-RULES

3）修改应用Metric的获取方式

默认情况下，sentinel-dashbord会定时通过线程的方式到应用端获取Metric的数据，其架构如下所示：

这种架构会受限于sentinel-dashbord的任务的处理能力，总会有一个上限，当应用达到几百个、几千个的时候，sentinel-dashbord的Metric处理能力就会受收非常大的影响，并且sentinel-dashbord本身会存在单点的风险。

为了增强sentinel-dashbord的处理能力，规避其单点风险，将Metric的获取方式修改为应用主动上报的方式，架构如下所示：

说明：

• 默认架构中的Sentinel Dashboard，其只负责维护连接到其本身的应用，包括从这些连上来的应用中获取Metric数据、往应用推送或从应用中拉取限流配置、检测应用是否健康等，其负担着整体调控的作用，由于保存部分数据在内存中，因而其本身是有状态的，且本身存在着不可扩展的瓶颈；默认情况下，限流配置都是保存到应用App中，存在着重启应用就丢失败的风险。新的架构为高可用的架构，Sentinel Dashboard中不保存数据，所有的限流配置数据都保存在ZK中，其除了对客户端APP做健康检查这一操作以下，不会主动与客户端APP产生任何交互，且其本身不保存任何数据，因面登陆任何一台Sentinel Dashboard，对可以整个集群进行操作，即使有Sentinel Dashboard挂掉，也不会影响到数据的收集和报表的查询。
• Metric数据默认是保存到Sentinel Dashboard内存中的，不便于长期保存，也不方便和其它第三方图报展示平台对接，修改为将Metric数据保存到Influxdb集群中，Influxdb集群为多个Influxdb实例组成的，使用app做为Hash key，根据一定的Hash规则将数据分布存储到不同的Influxdb中。

这种架构不会由于应用的增多导致sentinel-dashbord成为瓶颈，因为sentinel-dashbord也是可以水平扩展的，并且Metric是保存在Influxdb的集群中，因而在任何一台Sentinel控制台上都可以查看到所有应用相同的Metric数据。

4）修改应用“机器列表”的存储

应用“机器列表”的存储默认是保存在内存中，但是在布署多个Sentinel控制台的情况下，保存在内存中的应用机器列表只能够展示连接到当前Se