一文搞懂微服务限流熔断

一文搞懂微服务限流熔断

一、为什么需要限流熔断？

大家有没有遇到过这种情况：商场举办促销活动，大量顾客同时涌入导致秩序混乱，甚至发生踩踏事件。这时候商场通常会采取限流措施，控制进入的人数，保证安全。

在互联网系统中，也会遇到类似的情况。比如电商平台的秒杀活动，大量用户同时发起请求，服务器可能会因为承受不住这么大的压力而崩溃。这时候就需要用到限流技术，控制请求的数量。

还有一种情况，当某个服务出现故障时，如果不及时处理，可能会导致整个系统的崩溃。这就好比电路中的保险丝，当电流过大时会自动熔断，保护整个电路。在微服务中，我们也需要这样的"保险丝"，这就是熔断技术。

二、什么是限流？

1. 概念解释

限流就是限制流量，通过对并发访问或请求进行限速（如每秒最多处理100个请求），或在一个时间窗口内限制请求总量（如每分钟最多处理5000个请求），从而保护系统。通俗来讲，就是给系统设置一个"阀门"，防止过多请求把系统"冲垮"。

2. 常见限流算法

（1）计数器算法（最简单但有缺陷）

原理：在固定时间窗口内统计请求数量，超过阈值则拒绝后续请求。
示例：设置1分钟窗口，阈值100次。1分钟内超过100次请求时，后续请求被拒绝，1分钟后重置计数器。

缺点：窗口切换时可能出现双倍流量（如前一个窗口最后1秒和后一个窗口第1秒各来100次请求，实际2秒内处理200次，超过预期）。

（2）滑动窗口算法（优化临界问题）

原理：将大时间窗口分成多个小窗口（如1分钟分成6个10秒小窗口），统计当前所有小窗口的请求总和。
示例：每个小窗口独立计数，滑动时丢弃最旧的小窗口数据，实时计算当前窗口总和。

优点：更精确统计流量，平滑处理窗口边界的突发请求。

（3）令牌桶算法（支持突发流量）

原理：系统以固定速率生成令牌（如每秒10个），存入令牌桶（容量100）。每个请求需获取1个令牌才能处理，桶空时拒绝请求。

示例：突发100个请求时，若桶中有100个令牌，可一次性处理；后续请求需等令牌生成。

优点：允许短时突发流量，适用于秒杀等场景。

（4）漏桶算法（流量平滑器）

原理：请求先进入漏桶（容量100），漏桶以固定速率（如每秒10次）处理请求，桶满时丢弃新请求。
示例：无论请求多快，始终以每秒10次的速度处理，多余请求直接拒绝。

优点：流量绝对平滑，适合对稳定性要求极高的场景（如金融交易）。

三、什么是熔断？

1. 概念解释

熔断是服务的"保险丝"。当某个服务频繁出错（如超时、异常），熔断机制会暂时切断对它的调用，直接返回预设的降级结果（如"服务繁忙，请稍后再试"），避免故障扩散拖垮整个系统。

2. 熔断的工作原理（状态机模型）

熔断有三种状态，通过状态切换实现故障自愈：

• 关闭态：正常调用服务，统计错误率。若10秒内50%请求失败且总请求≥3次，触发熔断。
• 打开态：拒绝所有请求，返回降级结果，启动休眠计时器（如5秒）。
• 半开态：休眠期结束后，允许少量请求试探服务是否恢复。若成功，关闭熔断；若失败，重新打开。

3. 限流 vs 熔断 核心对比表

维度	限流（Rate Limiting）	熔断（Circuit Breaker）
目的	预防系统过载，控制并发请求量在合理范围	故障隔离，防止单个服务故障拖垮整个系统
触发条件	流量达到阈值（如QPS超过200、并发线程数超过50）	服务错误率超过阈值（如50%请求失败）或持续超时
处理方式	拒绝多余请求（直接返回错误）或排队等待（漏桶算法）	暂时切断服务调用，返回预设的降级结果（如缓存数据、默认值）
关注重点	流量控制，保护系统资源（CPU、内存、网络带宽）	服务可用性，避免级联失败
典型场景	秒杀活动、接口防刷、API限流	微服务调用超时、依赖服务频繁异常
实现方式	基于计数器、令牌桶、漏桶等算法	基于状态机（关闭/打开/半开状态）
作用时机	事前预防（在请求到达时判断是否放行）	事后容错（在服务调用失败后触发）
示例	限制某个接口每秒最多处理1000个请求	当用户服务调用超时率超过30%时，熔断该服务调用10秒

四、Sentinel和Hystrix介绍（两大主流框架）

1. Sentinel（阿里巴巴出品，限流更强）

定位：分布式系统的流量防卫兵，专注流量控制、熔断降级、系统负载保护。

核心特点：

• 轻量级：基于信号量隔离，资源消耗低，适合高并发场景。
• 丰富限流模式：支持QPS限流、并发线程数限流、黑白名单等。
• 实时监控：提供控制台查看流量、熔断次数、响应时间等指标。
• 生态友好：完美集成Spring Cloud、Dubbo，支持动态规则配置（如从Nacos获取限流规则）。

2. Hystrix（Netflix开源，熔断经典）

定位：容错库，通过隔离和熔断防止级联故障，提升系统弹性。

核心特点：

• 线程池隔离：为每个服务分配独立线程池，避免单个服务耗尽所有线程。
• 断路器：基于错误率自动熔断，支持自定义降级逻辑（如返回缓存数据）。
• 监控仪表盘：可查看服务调用成功率、平均耗时等指标。
• 已进入维护模式：Netflix不再更新，适合存量系统，新项目建议选Sentinel。

五、使用示例（代码级对比）

1. Sentinel限流示例（限制QPS≤2）

import com.alibaba.csp.sentinel.Entry;
import com.alibaba.csp.sentinel.SphU;
// ... 其他导入

public class SentinelExample {
    public static void main(String[] args) {
        FlowRuleManager.loadRules(initFlowRules());
        
        while (true) {
            try (Entry entry = SphU.entry("orderService")) {
                System.out.println("处理订单请求");
            } catch (BlockException e) {
                System.out.println("请求被限流！当前QPS超过阈值");
            }
            try { Thread.sleep(100); } catch (InterruptedException e) { }
        }
    }

    private static List<FlowRule> initFlowRules() {
        FlowRule rule = new FlowRule();
        rule.setResource("orderService"); 
        rule.setGrade(FlowRule.Grade.QPS); 
        rule.setCount(2); 
        return new ArrayList<>(){{ add(rule); }};
    }
}

2. Hystrix熔断示例（模拟50%请求失败，触发熔断）

import com.netflix.hystrix.HystrixCommand;
// ... 其他导入

public class HystrixExample {
    public static void main(String[] args) {
        for (int i = 0; i < 10; i++) {
            String result = new OrderCommand().execute();
            System.out.println("结果：" + result);
            try { Thread.sleep(500); } catch (InterruptedException e) { }
        }
    }

    static class OrderCommand extends HystrixCommand<String> {
        public OrderCommand() {
            super(Setter.withGroupKey(HystrixCommandGroupKey.Factory.asKey("OrderService"))
                .andCommandPropertiesDefaults(
                    HystrixCommandProperties.Setter()
                        .withCircuitBreakerEnabled(true) 
                        .withCircuitBreakerErrorThresholdPercentage(50) 
                        .withCircuitBreakerRequestVolumeThreshold(3) 
                ));
        }

        @Override
        protected String run() throws Exception {
            if (Math.random() > 0.5) throw new RuntimeException("服务超时");
            return "订单处理成功";
        }

        @Override
        protected String getFallback() {
            return "降级处理：返回订单缓存数据"; 
        }
    }
}

六、Sentinel vs Hystrix 对比（选谁？看表格！）

特性	Sentinel	Hystrix
核心定位	流量控制（限流为主）+ 熔断	容错（熔断为主）+ 线程隔离
隔离方式	信号量隔离（轻量，适合高并发）	线程池隔离（资源消耗大，隔离更彻底）
限流能力	强（支持QPS、并发线程、关联限流等）	弱（仅支持简单并发线程限流）
熔断策略	支持异常率、响应时间双维度	仅基于异常率
实时监控	控制台功能强大（可动态调整规则）	基础监控，需配合Turbine等工具
生态集成	Spring Cloud/Dubbo/Redis全面支持	主要集成Spring Cloud
社区活跃度	活跃（阿里持续更新）	停更（2018年后无大版本更新）
学习成本	低（API简单，文档详细）	中（线程池、信号量等概念较复杂）

七、如何选择框架？（3分钟决策法）

1. 优先选Sentinel：

   • 如果你需要 强大的限流功能（如秒杀、接口防刷）。
   • 项目使用 Dubbo或Spring Cloud Alibaba 生态。
   • 希望 动态调整规则（通过控制台实时修改限流阈值）。

2. 选Hystrix的场景：

   • 维护老旧项目，且已有Hystrix集成。
   • 更关注 线程级隔离（防止单个服务拖垮整个应用的线程池）。

八、总结

通过限流熔断，我们为系统装上了"安全阀"：

• 限流防止"请求洪水"冲垮系统，确保核心功能可用；
• 熔断避免"单点故障"扩散，实现故障自愈。

选择框架时，结合业务场景（限流为主选Sentinel，熔断为主且旧项目选Hystrix），搭配控制台监控，就能让系统更健壮！