微服务架构像一支交响乐团，每个服务都是独立的乐手。当某个乐手突然失声，需要一种机制防止整场演出崩溃——这就是服务熔断存在的意义。
1.1 服务熔断的定义与重要性
服务熔断本质上是一种故障隔离机制。当某个远程服务调用失败率达到阈值，熔断器会自动“跳闸”，暂时停止对该服务的所有调用。这就像家里的电路保险丝，电流异常时立即切断电源，保护整个电路系统。
我记得去年参与的一个电商项目，支付服务因为第三方接口不稳定经常超时。没有熔断机制时，整个订单流程都会卡住，用户界面一直转圈等待响应。引入熔断后，支付服务不可用时立即返回预设的友好提示，其他功能完全不受影响。
这种设计的重要性体现在三个方面：防止服务雪崩、快速失败保障用户体验、为故障服务提供恢复时间。系统不会因为一个组件的故障而全面崩溃。
1.2 熔断器在微服务架构中的作用
熔断器在微服务中扮演着交通警察的角色。它监控着服务间的每一次调用，当发现某个路口持续拥堵，就会引导车辆绕行。
具体来说，熔断器承担着三重职责： - 实时监控服务调用成功率、响应时间等指标 - 在故障发生时快速切断连接，避免资源耗尽 - 定期探测故障服务是否恢复，适时闭合电路
这种机制确保了系统的弹性。即使部分服务不可用，核心业务流程仍能继续运转，只是某些非核心功能会暂时受限。
1.3 服务熔断与服务降级的区别
很多人容易混淆这两个概念，其实它们解决的是不同维度的问题。
服务熔断关注的是“能不能调用”——当目标服务不可用时，直接阻断调用请求，就像电路跳闸。服务降级则关注“如何优雅地失败”——在服务不可用或资源紧张时，提供备选方案或简化流程。
举个例子，商品详情页需要调用库存服务和推荐服务。如果库存服务宕机，熔断器会阻断所有库存查询请求；而推荐服务不可用时，降级策略可能返回默认的热销商品列表，而不是直接报错。
熔断是“断”与“通”的切换，降级是“全功能”与“精简功能”的切换。它们经常配合使用，共同构建 resilient 的系统。
1.4 熔断器的三种状态机制详解
熔断器的核心是一个状态机，在闭合、断开、半开三种状态间流转，这个设计确实非常巧妙。
闭合状态是默认的正常工作模式。请求畅通无阻地通过，熔断器在后台默默统计失败率。就像平时开着的门，人们自由进出，但保安在计数。
当失败率超过阈值，熔断器进入断开状态。所有请求被立即拒绝，不再尝试调用故障服务。这时门完全关闭，挂着“暂停服务”的牌子。
经过预设的超时时间，熔断器切换到半开状态。它允许少量试探性请求通过，如果这些请求成功，说明服务已恢复，熔断器回归闭合状态；如果仍然失败，则继续保持断开。
这种状态转换确保了系统既能快速隔离故障，又能及时感知服务恢复。我记得第一次实现这个状态机时，那种环环相扣的逻辑美感让人印象深刻——它完美模拟了人类处理问题的智慧：先彻底隔离，再小心试探，最后全面恢复。 @Service public class UserService {
@HystrixCommand(
fallbackMethod = "getUserFallback",
commandProperties = {
@HystrixProperty(name = "execution.isolation.thread.timeoutInMilliseconds", value = "3000"),
@HystrixProperty(name = "circuitBreaker.errorThresholdPercentage", value = "40")
}
)
public User getUserById(Long id) {
// 调用远程用户服务
return userClient.getUser(id);
}
public User getUserFallback(Long id) {
// 返回默认用户或缓存数据
return User.defaultUser();
}
}
