熔断降级

引言：一场真实的雪崩事故 2018年某电商平台的双11大促，凌晨2点，一场噩梦开始了： 2:00 - 商品详情服务的MySQL数据库出现慢查询，响应时间从10ms飙升到5秒 2:02 - 商品服务的Tomcat线程池被耗尽（200个线程全部阻塞在数据库查询上） 2:03 - 订单服务调用商品服务超时，订单服务的线程池也被耗尽 2:04 - 用户服务调用订单服务超时，用户服务也挂了 2:05 - 整个系统瘫痪，首页无法访问，交易全部失败 损失：10分钟内损失订单超过5000万元 这就是微服务雪崩效应的真实案例。 一个数据库的慢查询，像多米诺骨牌一样，导致整个系统崩溃。 今天我们就来学习如何用Sentinel防止这种雪崩的发生。 场景描述：一个典型的调用链路 系统架构 我们有一个典型的微服务架构： 用户请求 ↓ [用户服务 User-Service] ↓ 调用 [订单服务 Order-Service] ↓ 调用 [商品服务 Product-Service] ↓ 查询 [MySQL数据库] 调用关系： 用户服务 → 订单服务：查询用户的订单列表 订单服务 → 商品服务：查询订单中的商品详情 商品服务 → MySQL：查询商品信息 正常流程 用户访问"我的订单"页面 用户服务调用订单服务的/order/list接口 订单服务返回订单ID列表 订单服务调用商品服务的/product/detail接口，批量查询商品信息 商品服务查询MySQL数据库 层层返回，用户看到订单列表 正常情况下的响应时间： 商品服务查询数据库：10ms 订单服务调用商品服务：50ms 用户服务调用订单服务：100ms 用户看到页面：200ms 问题分析：雪崩是如何发生的？ 故障起点：商品服务的数据库慢查询 某天凌晨，商品服务的MySQL数据库出现了慢查询： -- 慢查询：全表扫描，耗时5秒 SELECT * FROM product WHERE category = 'phone' AND price > 5000 ORDER BY sales DESC; 直接影响：商品服务的响应时间从10ms飙升到5秒。 ...

引言：当服务"生病"时 还记得我们在前面学过的限流吗？限流是对流量的主动防御——就像景区设置的日接待量上限，人满了就不让进。 但在微服务世界里，除了流量洪峰，还有另一个更隐蔽的威胁：依赖服务的故障传播。 想象这样一个场景： 你的订单服务依赖商品服务查询商品信息。某天凌晨，商品服务的数据库出现了慢查询问题，导致商品查询接口响应时间从10ms飙升到5秒。 订单服务不知情，继续调用商品服务。每次调用都要等5秒才超时。大量请求线程被阻塞，线程池很快被耗尽。 于是，订单服务也"挂了"。接着，依赖订单服务的购物车服务、支付服务也接连崩溃… 一场雪崩就这样发生了。 这就是微服务架构的阿喀琉斯之踵：故障会沿着调用链传播，一个服务的问题可能导致整个系统瘫痪。 熔断降级就是为了解决这个问题而生的。它的核心思想是： 当依赖服务出现故障时，主动"断开"对它的调用，避免故障传播。就像壮士断腕，牺牲局部，保全整体。 这就是"断臂求生的艺术"。 熔断的本质：防止故障蔓延 什么是熔断？ 熔断（Circuit Breaking）的本质是故障隔离机制。 当系统检测到某个依赖服务出现异常（如响应超时、异常率过高），就主动切断对该服务的调用，快速返回一个"降级结果"（如默认值、缓存数据、友好提示），避免调用方线程被长时间阻塞。 熔断的三个关键要素： 故障检测：持续监控依赖服务的健康状况 快速失败：检测到故障后，快速返回而不是继续等待 自动恢复：故障恢复后，自动恢复正常调用 为什么需要熔断？ 在微服务架构中，服务之间通过网络调用相互依赖，形成了复杂的调用链路。这种架构有一个天然的脆弱性： 单个服务的故障会迅速扩散，导致雪崩效应。 举个例子： 用户服务 → 订单服务 → 商品服务 → 库存服务 ↓ 支付服务 如果库存服务出现故障（如数据库慢查询），会发生： 库存服务：响应变慢，每个请求耗时5秒 商品服务：调用库存服务被阻塞，线程池占满 订单服务：调用商品服务超时，自己的线程池也被占满 用户服务：调用订单服务失败，无法提供服务 整个系统：因为一个小问题而全面瘫痪 熔断的作用就是切断这条传播链： 商品服务检测到库存服务故障，熔断对库存服务的调用 商品服务返回降级结果（如显示"暂时无法查询库存"） 商品服务自身保持正常运行 订单服务、用户服务不受影响 类比：家用电路熔断器 熔断（Circuit Breaker）这个名字来源于我们日常生活中的电路熔断器。 电路熔断器的工作原理 想象你家的配电箱： 正常工作：电流正常，熔断器保持闭合，电路正常供电 过载保护：当电流过大（如同时开太多电器），熔断器检测到异常 自动断开：熔断器立即跳闸，切断电路，避免电线过热引发火灾 手动恢复：排除故障后，可以手动合上开关，恢复供电 软件中的熔断器工作原理完全一样： 电路熔断器 软件熔断器 电流过大 服务响应慢/异常多 自动断开电路 停止调用服务 避免火灾 防止线程耗尽 手动合闸 自动尝试恢复 熔断器状态机：三种状态 Sentinel的熔断器是一个有状态的对象，它有三种状态： 1. 关闭状态（Closed） 这是熔断器的初始状态和正常工作状态。 特征： ...

引子：一次服务雪崩事故 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 服务消费者：发现服务 ...