[dashboard/1.8] feat: 新增基于Nacos的规则持久化支持

[Serein-K]

What changes were made?

• 新增 Nacos 持久化规则配置支持

Why are these changes needed?

• 当前 Sentinel Dashboard 无法保存用户配置的规则，重启sentinel之后又得重新配置，于是想到了关于用nacos持久化的问题，

How to verify these changes?

1. 先在nacos中创建一个命名空间 sentinel-namespace
2. 将Sentinel Dashboard服务注册到了nacos中 ，在服务列表可以看到这个服务名 sentinel-dashboard-service
3. 在Sentinel Dashboard增加配置的时候，nacos会在命名空间 sentinel-namespace的配置列表看到相应的配置，比如说，对应Sentinel Dashboard来说注册上来的服务名叫做hello，然后再Sentinel Dashboard中新添了流控规则，则在nacos中就会有这样的文件名hello-flow-rules，里面有数据
4. 把Sentinel Dashboard服务关了，再重启，发现配置文件没有丢失（其实就是在控制层的时候，会去读一个nacos中相应的配置文件，把数据渲染上去，之后增删改操作都会去nacos中改相应的内容）

[CLAassistant]

All committers have signed the CLA.

[corleonePeng]

官方是不是不维护了啊？

[Copilot]

Pull Request Overview

This PR adds Nacos-based rule persistence support to the Sentinel Dashboard, addressing the issue where rules are lost after dashboard restarts. The implementation includes both rule providers and publishers for various rule types, along with configuration for Nacos service discovery.

• Integration of Nacos as a persistence layer for Sentinel rules
• Support for multiple rule types (flow, degrade, authority, system, param flow, cluster flow)
• Modified controllers to use Nacos providers/publishers instead of direct client communication
• Added service discovery registration to Nacos

Reviewed Changes

Copilot reviewed 31 out of 31 changed files in this pull request and generated 8 comments.

Show a summary per file

File	Description
pom.xml	Added Spring Cloud and Nacos dependencies
application.properties	Added Nacos discovery configuration
DashboardApplication.java	Enabled discovery client for Nacos registration
NacosConfig.java	Configuration bean for Nacos ConfigService
*RuleNacosProvider.java	Rule providers for reading from Nacos
*RuleNacosPublisher.java	Rule publishers for writing to Nacos
Various controllers	Modified to use Nacos providers/publishers and import optimizations

Comments suppressed due to low confidence (1)

sentinel-dashboard/src/main/java/com/alibaba/csp/sentinel/dashboard/controller/DegradeController.java:158

• The publishRulesToNacos call should be wrapped in a try-catch block to handle exceptions properly and avoid breaking the rule delete operation.

            publishRulesToNacos(oldEntity.getApp());

[Copilot]

[nitpick] Use StringUtil.isNotBlank() for consistency with other parts of the codebase instead of null check and isEmpty().

Suggested change

	if (namespace != null && !namespace.isEmpty()) {
	if (StringUtils.isNotBlank(namespace)) {

[Copilot]

Method throws generic Exception. Consider catching and wrapping with a more specific exception or logging the error instead of propagating.

Suggested change

	private void publishRulesToNacos(String app) throws Exception {
	private void publishRulesToNacos(String app) {

[Copilot]

Method throws generic Exception. Consider catching and wrapping with a more specific exception or logging the error instead of propagating.

Suggested change

	private void publishRulesToNacos(String app) throws Exception {
	List<ParamFlowRuleEntity> rules = repository.findAllByApp(app);
	rulePublisher.publish(app, rules);
	private void publishRulesToNacos(String app) {
	try {
	List<ParamFlowRuleEntity> rules = repository.findAllByApp(app);
	rulePublisher.publish(app, rules);
	} catch (Exception e) {
	logger.error("Error publishing parameter flow rules to Nacos for app: {}", app, e);
	throw new RuntimeException("Failed to publish parameter flow rules to Nacos for app: " + app, e);
	}

[Copilot]

Method throws generic Exception. Consider catching and wrapping with a more specific exception or logging the error instead of propagating.

Suggested change

	private void publishRulesToNacos(String app) throws Exception {
	List<FlowRuleEntity> rules = repository.findAllByApp(app);
	rulePublisher.publish(app, rules);
	private void publishRulesToNacos(String app) {
	try {
	List<FlowRuleEntity> rules = repository.findAllByApp(app);
	rulePublisher.publish(app, rules);
	} catch (Exception e) {
	logger.error("Error publishing rules to Nacos for app: {}", app, e);
	throw new RuntimeException("Failed to publish rules to Nacos for app: " + app, e);
	}

[Copilot]

Method throws generic Exception. Consider catching and wrapping with a more specific exception or logging the error instead of propagating.

Suggested change

	private void publishRulesToNacos(String app) throws Exception {
	List<DegradeRuleEntity> rules = repository.findAllByApp(app);
	rulePublisher.publish(app, rules);
	private void publishRulesToNacos(String app) {
	try {
	List<DegradeRuleEntity> rules = repository.findAllByApp(app);
	rulePublisher.publish(app, rules);
	} catch (Exception e) {
	logger.error("Failed to publish degrade rules to Nacos for app: {}", app, e);
	throw new RuntimeException("Failed to publish degrade rules to Nacos for app: " + app, e);
	}

[Copilot]

Method throws generic Exception. Consider catching and wrapping with a more specific exception or logging the error instead of propagating.

Suggested change

	private void publishRulesToNacos(String app) throws Exception {
	List<AuthorityRuleEntity> rules = repository.findAllByApp(app);
	rulePublisher.publish(app, rules);
	private void publishRulesToNacos(String app) {
	try {
	List<AuthorityRuleEntity> rules = repository.findAllByApp(app);
	rulePublisher.publish(app, rules);
	} catch (Exception e) {
	logger.error("Failed to publish authority rules to Nacos for app: {}", app, e);
	throw new RuntimeException("Failed to publish authority rules to Nacos for app: " + app, e);
	}

[Copilot]

The publishRulesToNacos call should be wrapped in a try-catch block to handle exceptions properly and avoid breaking the rule save operation.

[Copilot]

The publishRulesToNacos call should be wrapped in a try-catch block to handle exceptions properly and avoid breaking the rule update operation.

[LearningGp]

Should we consider add nacos-discovery?

[LearningGp]

This type of comment seems unnecessary - we can safely remove it to keep the code concise. (the same applies to other similar comments below)