今天就跟大家聊聊有关Sentinel动态数据源架构设计理念与改造实践是怎么样的，可能很多人都不太了解，为了让大家更加了解，小编给大家总结了以下内容，希望大家根据这篇文章可以有所收获。
创新互联专注于顺河企业网站建设,响应式网站开发,电子商务商城网站建设。顺河网站建设公司,为顺河等地区提供建站服务。全流程按需策划，专业设计，全程项目跟踪，创新互联专业和态度为您提供的服务
在介绍集群限流之前需要首先掌握动态数据源的配置方式，根据 Sentinel 官方提供的代码提出整体架构思路，并最终给出实践指导。
温馨提示：本文主要分为动态数据源架构设计理念、从官方示例寻找改造思路、基于SpringBoot改造方案三个部分来详细剖析 Sentienl 动态数据源的改造方案，循序渐进，不仅解决问题本身，更是反映了作者研究一个问题的思路与方法。
在 Sentinel 中主要有如下几个角色：管理后台、限流熔断规则数据源、应用程序。
1）管理后台
管理后台主要用于可视化配置限流规则、熔断规则，其操作界面截图如下：
用于存储限流熔断规则的数据容器，在 Sentinel 中对应动态数据源这个概念，动态数据源包含两层含义：
数据容器
数据容器指的就是存储熔断、限流等规则配置的数据库，例如关系型数据库、Zookeeper等等，在实际生产过程中需要选用支持持久化功能的数据库，否则程序一重启，配置规则就会丢失，显然是不能接受的。
动态
动态二字主要强调的是配置规则的更改能动态及时生效，引入 Sentinel 限流 SDK 的应用程序在不需要重启的情况下动态感知配置规则发生变化并立即生效。Sentinel 目前对 apollo、consul、etcd、nacos、redis、spring-clould-config、zookeeper 等进行了适配支持。
3）应用程序
希望通过 Sentinel 提供的限流、熔断功能对应用程序加以保护，需要引用 Sentinel 相关的 SDK，根据采集的调用信息判断当前是否符合限流规则。
后台管理系统、动态数据源、应用程序的关系如图所示：
从官方的文档中可以明确获悉 sentinel-dashboard 即官方自带的后台管理系统只支持将限流、熔断等限流配置规则存储在内存中，一旦后台管理系统重启，配置的熔断规则将全部丢失，所以在生产实践过程中需要对 sentinel-dashboard 进行一定的改造，引入动态数据源，例如 Zookeeper，对限流等配置进行持久化存储。
有了上面的架构设计理念为我们的改造提供了方向，那如何具体改造呢？首先我们来看一下官方提供的 Demo 程序。官方提供的示例代码如下图所示：
2.1 限流熔断等规则存储
首先查阅一下 ZookeeperConfigSender，该类主要的作用是将配置写入到 zookeeper 中，其关键代码截图如下：
实践指导,通常基于 zookeeper 的开发，主要是规划好目录结构，关于 Sentinel，我对给出一个初步的目录规划。
在 zookeeper 中创建一个根节点，例如 /sentienl 用来表示限流相关的根目录。
groupId 通常为一个独立的应用名称，例如应用的 appId，例如示例中的 provider-demo。
dataId 通常为配置类型，例如限流规则、熔断规则、热点规则等类别，例如限流规则使用 /flowRule ，熔断规则使用 /degradeRule，其 value 值使用 json 存储，将该应用下的所有限流规则用一个 json 对象表示，其存储格式类似于 [{},{}]。
实现存储规则的配置存储后接下来是需要客户端能动态感知规则的变化，从而是配置规则实时生效。
我们依然先来看一下官方示例，其核心代码如图所示：
创建 ZookeeperDataSource，每一个 ZookeeperDataSource 负责监听一个节点。
需要调用 FlowRuleManager 的 register2Property 方法将数据源关联的数据注册到 FlowRuleManager 中，方便 Sentinel 内核根据数据源中存储的限流熔断等规则进行工作。
客户端在启动的时候会调用 FlowRuleManager 相关方法加载限流相关的配置，那如果配置规则发生变化后，客户端如何动态感知呢？其关键就在于 ZookeeperDataSource 的实现中，其实现关键点如下：
从官方的示例中我们不难发现，引入 Zookeeper 数据源主要有两个步骤：将数据存储在Zookeeper中以及在客户端监听ZK从而实时生效两个步骤。
sentinel 官方提供了默认的后台管理系统实现：sentinel-dashboard，但其缺点非常明显：基于内存存储，无法用于实际生产过程。大家可能会向后台管理系统将配置信息存储在内存中，那接入的客户端如何从 sentinel-dashboard 的内存中获取配置信息呢，这是因为 sentinel-dashboard 里提供了简单的机器发现，并且内置了 sentinel 客户端之间、sentinel 客户端与 sentinel-dashboard 之间的通讯协议，具体由 sentinel-transport 模块实现，目前提供了基于 http 与 netty 的实现方式，故能将 sentinel-dashboard 内存中的配置信息推送到客户端，从而使客户端根据配置进行限流与熔断。
接下来回答本文的重点部分，基于 sentinel-dashboard 如何引入 zookeeper 等动态数据源呢？
首先我们可以顺着 sentinel-dashboard 的提供的控制器，寻找其后台入口，改造目标也很明确，就是将数据持久化到 zookeeper中，例如增加流控规则的后台处理入口为：
目前大部分项目都是基于 SpringBoot，故本文给出基于 SpringBoot 进行的客户端加载实现思路。
利用 SpringBoot 的事件机制，在 Spring 容器初始化后，开始加载 zookeeper 中的配置，其实现思路是读取 zookeeper 中的 /sentinel 下所有的子节点，然后并依次遍历其子节点(appid),然后依次读取 flow（限流）、degrade(熔断)等配置，并调用 Sentinel 的 相关API完成加载，其伪代码如下：
基于 Spring ApplicationReadyEvent 事件，实现限流规则的加载。
创建 ZookeeperDataSource 创建动态数据源。
并调用 Sentinel 提供的相关 API 完成限流规则的加载。
看完上述内容，你们对Sentinel动态数据源架构设计理念与改造实践是怎么样的有进一步的了解吗？如果还想了解更多知识或者相关内容，请关注创新互联行业资讯频道，感谢大家的支持。
