Sentinel动态数据源架构设计理念与改造实践是怎么样的

今天想和大家聊聊Sentinel动态数据源架构的设计理念和转型实践，可能很多人都不太了解。为了让你更好地理解，边肖为你总结了以下内容，希望你能从这篇文章中有所收获。

在引入集群限流之前，需要掌握动态数据源的配置方式，根据Sentinel提供的官方代码提出整体架构思路，最后给出实际指导。

Tips:本文主要分为三个部分：动态数据源架构设计理念，从官方实例中寻找转换思路，基于SpringBoot转换方案详细分析Sentienl NL动态数据源的转换方案，既解决了问题本身，又体现了作者研究一个问题的思路和方法。

1、架构设计理念

在Sentinel中有以下角色：管理后台、限流熔断规则数据源、应用程序。

1)管理后台。

管理后台主要用于可视化配置限流规则和熔断规则，其操作界面截图如下：

2)限流熔断规则数据源用于存储限流熔断规则的数据容器。在Sentinel中，动态数据源的概念是相对应的，动态数据源包含两层含义：

数据容器

数据容器是指存储保险丝、限流等规则配置的数据库，如关系数据库、Zookeeper等。在实际生产过程中，需要选择支持持久化功能的数据库，否则程序一重启，配置规则就会丢失，这显然是不可接受的。

动态的

“动态”一词主要强调配置规则的变化可以动态及时生效，引入Sentinel限流SDK的应用可以动态感知配置规则的变化，无需重启即可立即生效。哨兵目前支持阿波罗、执政官、etcd、nacos、redis、spring-clould-config、zookeeper等。

3)应用。

如果想通过Sentinel提供的限流熔断功能来保护应用，需要参考Sentinel的相关SDK，根据收集到的调用信息判断是否符合限流规则。

后台管理系统、动态数据源和应用程序之间的关系如下：

00-10，从官方文档中可以清楚的知道，官方后台管理系统sentinel-dashboard只支持在内存中存储限流、熔断等限流配置规则，一旦后台管理系统重启，所有配置的熔断规则都会丢失，因此在生产实践中需要对sentinel-dashboard进行一定程度的修改，并引入Zookeeper等动态数据源持久存储限流配置。

有了以上的架构设计理念，为我们的转型提供了方向，那么具体如何转型呢？首先，让我们看看官方的演示程序。下图显示了官方示例代码：

接下来，我们将介绍如何基于zookeeper构建Sentinel动态数据源。2.1限流熔断器等定期存放。

先看看ZookeeperConfigSender。这个类的主要功能是将配置写入zookeeper。关键代码截图如下：

这门课的测试目的很简单。首先，限流规则被持久化到zookeeper中，其作用与sentinel-dashboard一致。因此，这个类给我们的后台管理系统带来了很大的启发，那就是可以通过zookeeper存储哨兵限流规则。从演示示例中，我们可以看到Zookeeper中限流规则的目录结构，路径为/{groupId}/{dat。

aid} ，该节点的 value 值存储 json 字符串，存储所有的限流规则。

实践指导,通常基于 zookeeper 的开发，主要是规划好目录结构，关于 Sentinel，我对给出一个初步的目录规划。

在 zookeeper 中创建一个根节点，例如 /sentienl 用来表示限流相关的根目录。

• groupId 通常为一个独立的应用名称，例如应用的 appId，例如示例中的 provider-demo。

• dataId 通常为配置类型，例如限流规则、熔断规则、热点规则等类别，例如限流规则使用 /flowRule ，熔断规则使用 /degradeRule，其 value 值使用 json 存储，将该应用下的所有限流规则用一个 json 对象表示，其存储格式类似于 [{},{}]。

2.2 客户端动态感知配置

实现存储规则的配置存储后接下来是需要客户端能动态感知规则的变化，从而是配置规则实时生效。

我们依然先来看一下官方示例，其核心代码如图所示：

 

 

• 创建 ZookeeperDataSource，每一个 ZookeeperDataSource 负责监听一个节点。

• 需要调用 FlowRuleManager 的 register2Property 方法将数据源关联的数据注册到 FlowRuleManager 中，方便 Sentinel 内核根据数据源中存储的限流熔断等规则进行工作。

客户端在启动的时候会调用 FlowRuleManager 相关方法加载限流相关的配置，那如果配置规则发生变化后，客户端如何动态感知呢？其关键就在于 ZookeeperDataSource 的实现中，其实现关键点如下：

 

3、动态数据源实现方案

从官方的示例中我们不难发现，引入 Zookeeper 数据源主要有两个步骤：将数据存储在Zookeeper中以及在客户端监听ZK从而实时生效两个步骤。

sentinel 官方提供了默认的后台管理系统实现：sentinel-dashboard，但其缺点非常明显：基于内存存储，无法用于实际生产过程。大家可能会向后台管理系统将配置信息存储在内存中，那接入的客户端如何从 sentinel-dashboard 的内存中获取配置信息呢，这是因为 sentinel-dashboard 里提供了简单的机器发现，并且内置了 sentinel 客户端之间、sentinel 客户端与 sentinel-dashboard 之间的通讯协议，具体由 sentinel-transport 模块实现，目前提供了基于 http 与 netty 的实现方式，故能将 sentinel-dashboard 内存中的配置信息推送到客户端，从而使客户端根据配置进行限流与熔断。

接下来回答本文的重点部分，基于 sentinel-dashboard 如何引入 zookeeper 等动态数据源呢？

3.1 将配置规则存储在Zookeeper中

首先我们可以顺着 sentinel-dashboard 的提供的控制器，寻找其后台入口，改造目标也很明确，就是将数据持久化到 zookeeper中，例如增加流控规则的后台处理入口为：

 

只需要从这里开始改造，将其配置持久化到数据库中和 zookeeper中即可。
 将数据存储在 zookeeper 中，其关键是设计好各个项目如何有组织有条理的在 zookeeper 中进行组织。
 我给出如下设计方案：

 

 

3.2 Sentinel 客户端规则加载封装

目前大部分项目都是基于 SpringBoot，故本文给出基于 SpringBoot 进行的客户端加载实现思路。

利用 SpringBoot 的事件机制，在 Spring 容器初始化后，开始加载 zookeeper 中的配置，其实现思路是读取 zookeeper 中的 /sentinel 下所有的子节点，然后并依次遍历其子节点(appid),然后依次读取 flow（限流）、degrade(熔断)等配置，并调用 Sentinel 的 相关API完成加载，其伪代码如下：

 

其主要关键点如下：

• 基于 Spring ApplicationReadyEvent 事件，实现限流规则的加载。

• 创建 ZookeeperDataSource 创建动态数据源。
  并调用 Sentinel 提供的相关 API 完成限流规则的加载。

看完上述内容，你们对Sentinel动态数据源架构设计理念与改造实践是怎么样的有进一步的了解吗？如果还想了解更多知识或者相关内容，请关注行业资讯频道，感谢大家的支持。