sentinel-extension：一个Sentinel的扩展模块，主要是实现了规则的动态更新和持久化。另外热点参数限流也在这里实现的，除此之外注解的相关实现也是在这个模块中。sentinel-adapter：一个适配器的扩展，通过适配器可以很方便的为其他框架进行Sentinel的集成。Sentinel规则持久化：Sentinel的所有规则都是内存存储，重启后所有规则都会丢失。在生产环境下，我们必须确保这些规则的持久化，避免丢失。规则是否能持久化，取决于规则管理模式，Sentinel支持三种规则管理模式：push模式实现最为复杂，依赖于nacos，并且需要改在Sentinel控制台。
在SpringBoot项目中整合Sentinel，首先在pom文件中添加相应的依赖，并在application.properties文件中配置Sentinel的dashboard服务器地址等参数。接着，在需要控制的业务接口上添加Sentinel注解，并定义异常返回提示及BlockException。通过访问接口测试流控效果，实现初步集成。为了实现流控规则的持久化。Sentinel的授权规则和持久化功能为微服务提供了双重保护。首先，授权规则类似于服务网关的延伸，它在服务端口暴露时，通过监控请求来源，确保只有从预设的白名单（如网关）来的请求才能访问内部服务，有效防止了非授权用户绕过网关的直接访问，从而加强了微服务的安全性。规则分为基本的白名单和黑名单控制。
Sentinel是一个强大的流量控制和熔断管理工具，它用于监控和保护应用程序中的关键资源。为了提供更持久和可靠的管理，配置持久化是一个关键需求。通过与Nacos集成，Sentinel能够实现配置的实时同步，确保在服务更新或重启时，流量控制策略能够无缝延续。配置持久化涉及配置文件的存储。此外，Sentinel支持动态规则，包括手动API定义和数据源驱动的规则更新，如拉模式（文件操作）和推模式（持久化存储）。通过Nacos作为数据源的例子，可以看到规则持久化和实时更新的实现过程。总结来说，Sentinel不仅提供了基础的限流和熔断功能，还通过灵活的规则管理和实时监控，提升了服务的稳定性和可管理性。
而sentinelFlushConfig()则会利用rewriteConfig(),针对具体的配置项,分别进行重写,最终将Sentinel所有的状态持久化到了配置文件中。如下所示,在rewriteConfig()中,可以看到非常多的重写类型,这些重写类型都是与redis的各个配置选项一一对应的:当然,我们只需要找到其中关于maxclients的重写即可,所以在该函数中。a)一主一从:用于主节点故障转移从节点,当主节点的“写”命令并发高且需要持久化,可以只在从节点开启AOF(主节点不需要),这样即保证了数据的安全性,也避免持久化对主节点的影响b)一主多从:针对“读”较多的场景,“读”由多个从节点来分担,但节点越多,主节点同步到多节点的次数也越多,影响带宽。
感谢您的来访，获取更多精彩文章请收藏本站。
暂无评论内容