Nacos

三种方案对比 方案 实时性 高可用 运维成本 适用场景 Nacos 秒级 高 低 推荐，微服务首选 Apollo 秒级 高 中 已使用Apollo的项目 Redis 秒级 高 低 轻量级方案 文件 分钟级 低 高 不推荐生产使用 方案1：Nacos（推荐） 配置 spring: cloud: sentinel: datasource: flow: nacos: server-addr: localhost:8848 dataId: ${spring.application.name}-flow-rules groupId: SENTINEL_GROUP rule-type: flow namespace: dev Nacos中配置规则 [ { "resource": "orderCreate", "limitApp": "default", "grade": 1, "count": 1000, "strategy": 0, "controlBehavior": 0 } ] 优点 与Spring Cloud Alibaba深度集成 支持配置热更新 提供Web控制台 支持灰度发布 支持多环境（namespace） 方案2：Apollo 添加依赖 <dependency> <groupId>com.alibaba.csp</groupId> <artifactId>sentinel-datasource-apollo</artifactId> <version>1.8.6</version> </dependency> 配置 spring: cloud: sentinel: datasource: flow: apollo: namespace-name: application flow-rules-key: sentinel.flow.rules default-flow-rule-value: "[]" rule-type: flow Apollo中配置 Namespace: application Key: sentinel.flow.rules Value: ...

引言：硬编码规则的痛点 在前面的文章中，我们一直使用硬编码的方式配置Sentinel规则： @PostConstruct public void initFlowRule() { List<FlowRule> rules = new ArrayList<>(); FlowRule rule = new FlowRule(); rule.setResource("orderCreate"); rule.setCount(1000); // ← 硬编码在代码中 rules.add(rule); FlowRuleManager.loadRules(rules); } 硬编码规则的问题： 无法动态调整：修改限流阈值需要重新部署 无法统一管理：每个服务都要单独配置 无法应对突发情况：流量激增时无法快速调整 配置不可追溯：不知道谁在什么时候改了配置 解决方案：将规则配置到配置中心（如Nacos、Apollo），实现动态更新。 规则持久化的三种模式 1. 原始模式（内存模式） 特点： 规则存储在内存中 应用重启后规则丢失 Dashboard推送规则，应用无法持久化 问题：无法持久化，生产环境不推荐。 2. Pull模式（定时拉取） 工作流程： 应用启动 ↓ 定时从配置中心拉取规则（如每30秒） ↓ 更新内存中的规则 ↓ 继续定时拉取 优点：实现简单 缺点：实时性差，可能延迟30秒 3. Push模式（推送模式） 工作流程： Dashboard修改规则 ↓ 推送到配置中心（如Nacos） ↓ 配置中心通知所有订阅的应用 ↓ 应用实时更新规则 优点：实时性高（秒级） 缺点：实现复杂 推荐：生产环境使用Push模式 + Nacos。 Nacos配置中心集成（Push模式） 第一步：添加依赖 <!-- Sentinel Nacos数据源 --> <dependency> <groupId>com.alibaba.csp</groupId> <artifactId>sentinel-datasource-nacos</artifactId> <version>1.8.6</version> </dependency> <!-- Nacos客户端 --> <dependency> <groupId>com.alibaba.nacos</groupId> <artifactId>nacos-client</artifactId> <version>2.2.0</version> </dependency> 第二步：配置application.yml spring: application: name: order-service cloud: sentinel: transport: dashboard: localhost:8080 datasource: # 流控规则 flow: nacos: server-addr: localhost:8848 dataId: ${spring.application.name}-flow-rules groupId: SENTINEL_GROUP rule-type: flow data-type: json # 熔断规则 degrade: nacos: server-addr: localhost:8848 dataId: ${spring.application.name}-degrade-rules groupId: SENTINEL_GROUP rule-type: degrade data-type: json # 系统保护规则 system: nacos: server-addr: localhost:8848 dataId: ${spring.application.name}-system-rules groupId: SENTINEL_GROUP rule-type: system data-type: json 第三步：在Nacos中配置规则 登录Nacos控制台（http://localhost:8848/nacos）： ...

引子：一次服务雪崩事故 2020年双11，某电商平台因评论服务故障导致整个系统瘫痪3小时，损失上亿。 故障链路： 用户下单 → 订单服务 → 评论服务（响应慢，20秒超时） → 订单服务线程池耗尽 → 用户服务调用订单服务失败 → 整个系统崩溃 问题根源：缺乏有效的服务治理机制 一、服务注册与发现 1.1 为什么需要服务注册中心？ 问题：微服务架构下，服务IP动态变化 订单服务 → 库存服务（192.168.1.10:8080） 问题： 1. 库存服务重启，IP可能变化 2. 库存服务扩容，新增实例 3. 库存服务下线，需要摘除 解决方案：服务注册中心 订单服务 → 注册中心 → 获取库存服务列表 ↓ [192.168.1.10:8080, 192.168.1.11:8080, 192.168.1.12:8080] 1.2 Nacos服务注册与发现 服务提供者：注册服务 /** * 库存服务：自动注册到Nacos */ @SpringBootApplication @EnableDiscoveryClient public class InventoryServiceApplication { public static void main(String[] args) { SpringApplication.run(InventoryServiceApplication.class, args); } } # application.yml spring: application: name: inventory-service # 服务名 cloud: nacos: discovery: server-addr: 127.0.0.1:8848 namespace: dev group: DEFAULT_GROUP 服务消费者：发现服务 ...