sentinel开源限流方案—企业级二次开发方案

存在的问题
思索
2.1 需要引入zk、nacos中间件吗
2.2 配置更新采用推模式还是拉模式
-2.2.1 拉模式（不推荐）
-2.2.2 推模式（不推荐）
最终方案

sentinel开源的限流方案的代码，实际上是个半成品。需要在其上进行二次开发。

1. 存在的问题

sentinel的限流方案是没有问题的，需要改造的是：

限流规则的持久化；
监控数据的持久化；

监控数据不使用sentinel提供的控制台页面，而是借助promethues+grafana调用client暴露出来的metric接口，来进行持久化和显示。

下面就描述：如何实现配置规则的持久化。

1. sentinel官方给出的方案

官方思路.png

问题：

单机模式下，只能针对每个ip配置规则，若一个集群有1000台机器，要配置1000次，肯定不行。解决方案：提供集群维度的配置，即集群内的机器均使用这一个配置。
dashboard的数据存储在内存中。解决方案：需要将数据持久化。
dashboard去client拉取配置。解决方案：dashboard作为控制台，不应该再去client读取配置，而是dashboard存储配置，所以在client启动后，需要将dashboard数据同步到client。
当配置被修改后，又借助nacos实现的动态刷新，sentinel又引入了nacos，配置比较重。解决方案：使用http轻量级来完成配置的动态同步。
dashboard不支持水平扩展，即不支持高可用，因为client要向dashboard发送心跳，dashboard若是单机版，将ip列表存储到内存，当配置被修改，通过循环的方式通知client。当dashboard部署集群时，那么ip列表存储需要分布式缓存。思考：需要dashboard作为注册中心吗？

2. 思索

2.1 需要引入zk、nacos中间件吗

感觉是不需要的，sentinel作为一个限流的基建，不应该太“重”，为了实现配置的更新，引入复杂的中间件，感觉有些得不偿失。

2.2 配置更新采用推模式还是拉模式

即需要考虑方案没有问题，也需要考虑到dashboard性能。

2.2.1 拉模式（不推荐）

考虑到实际生产中，sentinel的限流规则不会经常变更，若是client采用拉模式的话。

缺点：

client会产生很多无用的http请求，因为配置很久更新一次。
当client机器很多的情况下，dashboard端需要处理大量的连接，dashboard压力大。
client每次拉取全量数据，对client性能也有问题。

优点：

无需记录client的ip，即不需要实现注册中心式的复杂逻辑。dashboard无需关注client的存活状态，client来拿数据，就将数据全量的给client传递下去。

拉模式实现.png

2.2.2 推模式（不推荐）

考虑到项目使用多个注册中心eureka、consul等。

当微服务中某个服务配置发送变化；
sentinel的dashboard去微服务的注册中心拉取该服务ip列表；
轮询ip列表，下发更新配置信息；

该思路的核心理念是：dashboard只作为配置中心，注册中心交由专业的去做。

推模式实现.png

核心问题：当微服务中某个服务重启后，sentinel-dashboard如何感知，且将配置同步到client端？

该问题没法解决，那么推模式也就无法实现。

3. 最终方案

推模式和拉模式均存在缺陷，那么实现推拉结合的方式呢？

最终方案.png