Spring Boot一键限速：守护你的接口“高速路”

Spring Boot一键限速：守护你的接口“高速路”

为什么网络限速很重要

在当今互联网应用广泛的时代，网络限速绝非多此一举，而是保障系统稳定、高效运行的关键策略。想象一下电商平台举办秒杀活动，成千上万的用户在同一时刻疯狂点击抢购按钮，倘若没有网络限速机制，瞬间涌入的海量请求可能会直接把服务器 “压垮”，导致整个系统瘫痪，无论是正常用户的购买请求，还是服务器后续的订单处理，都无法顺利进行。

再看看视频平台，每到热门剧集首播或者大型体育赛事直播时，大量用户同时在线观看，对视频资源的请求量呈爆发式增长。要是没有限速措施，有限的带宽资源会被过度占用，不仅新用户可能无法正常加载视频，就连正在观看的用户也会频繁遭遇卡顿、加载缓慢等糟糕体验，严重影响平台的口碑和用户留存率。

网络限速也是防范恶意攻击和资源滥用的有力武器。恶意攻击者可能会利用工具发起大量的并发请求，企图耗尽服务器资源，使服务无法正常提供给合法用户，这就是常见的 DDoS 攻击。而通过合理的网络限速，能够有效限制单位时间内来自同一 IP 或用户的请求数量，让这类恶意攻击难以得逞，保障服务的可用性。同时，对于一些付费使用网络资源的场景，限速可以防止个别用户过度占用资源，确保资源分配的公平性，让每个用户都能获得合理的服务质量。

常见的限速策略

在深入 Spring Boot 实现网络限速的代码世界之前，先来了解一下常见的网络限速策略，这些策略是限速的核心思想，理解它们，能让我们在实际应用中更准确地选择和实现限速功能。

固定窗口计数器

这是一种简单直观的限速策略。我们可以把时间想象成一个个固定大小的窗口，比如 1 秒为一个窗口。在每个窗口内，设置一个计数器，每当有一个请求进来，计数器就加 1 。当计数器的值达到我们预先设定的阈值时，比如设定每秒最多允许 100 个请求，那么在这个窗口剩余的时间里，后续的请求都会被拒绝。直到下一个窗口开始，计数器重置为 0，重新计数。这种方式实现起来很简单，但是存在一个明显的问题，就是在窗口切换的瞬间可能会出现突发流量。比如在 0.9 - 1 秒这个时间段来了 100 个请求，紧接着在 1 - 1.1 秒又来 100 个请求，虽然每秒都没超过限制，但在这 0.2 秒内系统却承受了 200 个请求，容易对系统造成冲击。

滑动窗口计数器

为了解决固定窗口计数器在窗口边界的突发流量问题，滑动窗口计数器应运而生。它把固定的大窗口划分成多个小的时间片，比如将 1 秒的窗口划分为 10 个 100 毫秒的小窗口。随着时间的推移，窗口不断滑动，就像一个可以移动的窗口，每次滑动一个小时间片。在统计请求数量时，不再是单纯的以 1 秒为单位，而是统计当前滑动窗口内所有小时间片的请求总数。这样能更精确地控制流量，有效避免固定窗口切换时的流量突刺问题，使流量曲线更加平滑 。不过，实现滑动窗口计数器相对复杂一些，需要维护更多的状态信息，比如每个小时间片的请求计数。

令牌桶算法

令牌桶算法是目前应用较为广泛的一种限流策略。它的核心概念是有一个固定容量的桶，系统以恒定的速率往桶里放入令牌，比如每秒生成 10 个令牌。每个请求在被处理之前，都需要从桶中获取一个令牌 。如果桶中有足够的令牌，请求就可以顺利通过并消耗一个令牌；如果桶中没有令牌了，请求就会被拒绝或者等待，直到有新的令牌生成。这个算法的精妙之处在于它允许一定程度的突发流量 。因为当系统处于空闲状态时，令牌会在桶中不断积累，当突然有大量请求到来时，只要桶里有足够的令牌，这些请求就能瞬间被处理，而不会像漏桶算法那样只能按照固定速率处理请求。

漏桶算法

漏桶算法就像是一个底部有小孔的水桶，请求就如同水一样流入桶中，然后以固定的速率从桶底的小孔流出，这个固定速率就是我们设定的限流速率。无论请求以多快的速度进入漏桶，只要桶没有满，请求就可以进入；一旦桶满了，新进来的请求就会被丢弃 。漏桶算法能够严格地控制请求的处理速率，使流量非常平滑，不会出现突发的高峰流量。但它的缺点也很明显，就是无法应对突发流量，即使系统当前很空闲，请求也只能按照固定的速率一个个地被处理，这在一些对响应时间敏感的场景下可能不太适用。

在实际应用中，令牌桶算法由于其既能限制平均流量，又能应对突发流量的优势，成为了很多场景下的首选限流策略。接下来，我们就基于 Spring Boot 框架，使用令牌桶算法来实现网络限速功能。

Spring Boot + AOP 实现网络限速

核心思路剖析

基于 Spring Boot 和 AOP 实现网络限速，主要是通过自定义注解和面向切面编程的方式，将限速逻辑从业务代码中分离出来，实现无侵入式的网络限速功能。具体来说，我们首先自定义一个限速注解，比如@RateLimit ，这个注解可以标记在需要限速的接口方法上。注解中包含一些参数，如每秒允许的请求数、限流提示信息以及限速的唯一标识等。然后利用 Spring AOP 的强大功能，拦截所有被@RateLimit注解标记的接口方法调用。在请求进入真正的业务逻辑之前，AOP 切面会捕获到这个请求，并根据注解中配置的参数，调用基于令牌桶算法实现的限速逻辑。

令牌桶算法是整个限速功能的核心。我们维护一个令牌桶，系统以固定的速率往桶里放入令牌，每个请求在被处理前都需要从桶中获取一个令牌 。如果桶中有足够的令牌，请求就可以通过并消耗一个令牌；如果桶中没有令牌，说明请求频率过高，超出了我们设定的限速阈值，此时请求会被拒绝，并返回预先设置好的限流提示信息。通过这种方式，我们可以有效地控制接口的访问频率，防止因高并发请求导致的系统性能问题，同时也能提高系统的稳定性和可靠性 。

代码实现步骤

引入核心依赖

在pom\.xml文件中引入以下依赖：

1<dependencies>
2    <!-- Spring Boot Web依赖，提供Web开发支持 -->
3    <dependency>
4        <groupId>org.springframework.boot</groupId>
5        <artifactId>spring-boot-starter-web</artifactId>
6    </dependency>
7    <!-- AOP依赖，用于实现面向切面编程，拦截注解 -->
8    <dependency>
9        <groupId>org.springframework.boot</groupId>
10        <artifactId>spring-boot-starter-aop</artifactId>
11    </dependency>
12    <!-- Lombok依赖，简化代码，如自动生成Getter、Setter等方法 -->
13    <dependency>
14        <groupId>org.projectlombok</groupId>
15        <artifactId>lombok</artifactId>
16        <optional>true</optional>
17    </dependency>
18</dependencies>
19

Spring Boot Web 依赖是整个 Web 应用开发的基础，它包含了 Spring MVC 等关键组件，使得我们可以方便地创建 RESTful 接口，处理 HTTP 请求和响应。AOP 依赖则是实现注解拦截的关键，它允许我们在不修改业务代码的前提下，在方法调用前后、异常处理等阶段插入自定义的逻辑。Lombok 依赖可以极大地简化 Java 代码，减少样板代码的编写，提高开发效率。例如，使用@Data注解可以自动生成类的 Getter、Setter、equals、hashCode和[toString](function toString() { [native code] })方法，让代码更加简洁易读。

自定义限速注解

创建@RateLimit注解，代码如下：

1package com.example.ratelimit.annotation;
2
3import java.lang.annotation.*;
4
5/**
6 * 网络限速注解，添加在接口方法上即可实现限速
7 */
8@Target({ElementType.METHOD}) // 仅作用于方法
9@Retention(RetentionPolicy.RUNTIME) // 运行时生效，允许AOP反射获取注解信息
10@Documented // 生成JavaDoc时包含该注解
11public @interface RateLimit {
12    /**
13     * 每秒允许的请求数（限速阈值）
14     */
15    double permitsPerSecond() default 10.0;
16
17    /**
18     * 限流后的提示信息
19     */
20    String message() default "请求过于频繁，请稍后再试！";
21
22    /**
23     * 限速唯一标识（支持SpEL表达式）
24     * 示例：#request.ip 按IP限速，#user.id 按用户ID限速，默认取请求接口路径
25     */
26    String key() default "";
27}
28

permitsPerSecond参数用于设定每秒允许通过的请求数量，也就是限速的阈值。比如设置为 10，就表示每秒最多只能有 10 个请求通过该接口。message参数则是当请求被限流时返回给客户端的提示信息，让用户知道请求被拒绝的原因。key参数是限速的唯一标识，默认情况下取请求接口的路径。但它支持 SpEL 表达式，通过这个表达式我们可以实现更灵活的限速策略。例如，使用\#request\.ip可以按客户端的 IP 地址进行限速，每个 IP 地址都有独立的限速规则；使用\#user\.id则可以按用户 ID 进行限速，不同用户有不同的访问频率限制 。

实现令牌桶算法

创建TokenBucketUtil工具类，代码如下：

1package com.example.ratelimit.util;
2
3import lombok.extern.slf4j.Slf4j;
4import java.util.concurrent.ConcurrentHashMap;
5import java.util.concurrent.TimeUnit;
6import java.util.concurrent.atomic.AtomicLong;
7
8/**
9 * 令牌桶工具类（线程安全，支持多标识独立限速）
10 */
11@Slf4j
12public class TokenBucketUtil {
13
14    /**
15     * 存储不同标识对应的令牌桶（key：限速标识，value：令牌桶）
16     */
17    private static final ConcurrentHashMap<String, TokenBucket> TOKEN_BUCKET_MAP = new ConcurrentHashMap<>();
18
19    /**
20     * 获取令牌（非阻塞，获取不到直接返回false）
21     * @param key 限速标识
22     * @param permitsPerSecond 每秒允许的请求数（令牌生成速率）
23     * @return true：获取令牌成功，false：限流
24     */
25    public static boolean tryAcquire(String key, double permitsPerSecond) {
26        TokenBucket tokenBucket = TOKEN_BUCKET_MAP.computeIfAbsent(key, k -> new TokenBucket(permitsPerSecond));
27        return tokenBucket.tryAcquire();
28    }
29
30    /**
31     * 令牌桶内部类
32     */
33    private static class TokenBucket {
34        // 桶的容量，这里设置为与每秒生成的令牌数相同，即桶最多能容纳一秒内生成的所有令牌
35        private final double capacity;
36        // 令牌生成速率，即每秒生成的令牌数
37        private final double refillRate;
38        // 记录上一次更新令牌桶的时间
39        private final AtomicLong lastRefillTime;
40        // 当前桶中的令牌数量
41        private final AtomicLong tokens;
42
43        public TokenBucket(double permitsPerSecond) {
44            this.capacity = permitsPerSecond;
45            this.refillRate = permitsPerSecond;
46            this.lastRefillTime = new AtomicLong(System.nanoTime());
47            this.tokens = new AtomicLong((long) permitsPerSecond);
48        }
49
50        public boolean tryAcquire() {
51            refill();
52            if (tokens.get() >= 1) {
53                tokens.decrementAndGet();
54                return true;
55            }
56            return false;
57        }
58
59        private void refill() {
60            long now = System.nanoTime();
61            long elapsedTime = now - lastRefillTime.get();
62            // 根据时间差和令牌生成速率，计算这段时间内应该生成的令牌数量
63            double newTokens = elapsedTime * refillRate / TimeUnit.SECONDS.toNanos(1);
64            // 更新桶中的令牌数量，不能超过桶的容量
65            tokens.addAndGet((long) Math.min(capacity, newTokens));
66            lastRefillTime.set(now);
67        }
68    }
69}
70

在TokenBucketUtil类中，我们使用ConcurrentHashMap来存储不同标识对应的令牌桶，确保在多线程环境下不同标识的限速相互独立，并且线程安全。tryAcquire方法是获取令牌的核心逻辑，它首先通过computeIfAbsent方法从TOKEN\_BUCKET\_MAP中获取或创建对应的令牌桶 。然后调用令牌桶的tryAcquire方法尝试获取令牌，如果获取成功则返回true，表示请求可以通过；如果获取失败则返回false，表示请求被限流。

TokenBucket内部类封装了令牌桶的具体实现。在构造函数中，我们初始化了桶的容量capacity、令牌生成速率refillRate、上次更新时间lastRefillTime以及当前令牌数量tokens。tryAcquire方法会先调用refill方法，根据当前时间和上次更新时间的差值，计算出这段时间内应该生成的新令牌数量，并更新桶中的令牌数量 。然后检查桶中是否有足够的令牌，如果有则消耗一个令牌并返回true，否则返回false。refill方法通过计算时间差和令牌生成速率，确保令牌桶能够按照设定的速率生成新的令牌，并且保证令牌数量不会超过桶的容量。

配置说明

在 Spring Boot 项目中，要使上述限速功能生效，还需要进行一些配置。首先，确保 Spring AOP 功能已经启用。在 Spring Boot 中，只要引入了spring\-boot\-starter\-aop依赖，AOP 功能默认是开启的。如果项目中存在自定义的@Configuration配置类，也可以显式地启用 AOP，如下所示：

1package com.example.ratelimit.config;
2
3import org.springframework.context.annotation.Bean;
4import org.springframework.context.annotation.Configuration;
5import org.springframework.context.annotation.EnableAspectJAutoProxy;
6
7@Configuration
8@EnableAspectJAutoProxy
9public class AopConfig {
10
11    // 这里可以添加其他AOP相关的配置，目前保持空即可
12}
13

@EnableAspectJAutoProxy注解会自动为标记了@Aspect的切面类创建代理，从而实现对目标方法的拦截和增强。

接下来，创建一个切面类，用于拦截被@RateLimit注解标记的方法，并执行限速逻辑。切面类代码如下：

1package com.example.ratelimit.aspect;
2
3import com.example.ratelimit.annotation.RateLimit;
4import com.example.ratelimit.util.TokenBucketUtil;
5import lombok.extern.slf4j.Slf4j;
6import org.aspectj.lang.ProceedingJoinPoint;
7import org.aspectj.lang.annotation.Around;
8import org.aspectj.lang.annotation.Aspect;
9import org.springframework.stereotype.Component;
10import org.springframework.web.context.request.RequestContextHolder;
11import org.springframework.web.context.request.ServletRequestAttributes;
12
13import javax.servlet.http.HttpServletRequest;
14
15@Aspect
16@Component
17@Slf4j
18public class RateLimitAspect {
19
20    @Around("@annotation(rateLimit)")
21    public Object rateLimit(ProceedingJoinPoint joinPoint, RateLimit rateLimit) throws Throwable {
22        ServletRequestAttributes attributes = (ServletRequestAttributes) RequestContextHolder.currentRequestAttributes();
23        HttpServletRequest request = attributes.getRequest();
24
25        // 获取限速标识
26        String key = rateLimit.key();
27        if (key.isEmpty()) {
28            key = request.getRequestURI();
29        }
30        // 解析SpEL表达式，支持按IP、用户ID等精细化限速
31        // 这里暂未实现复杂的SpEL表达式解析，后续可根据需求扩展
32        // 例如：if (key.startsWith("#")) { key = parseSpelExpression(key, request); }
33
34        // 获取每秒允许的请求数
35        double permitsPerSecond = rateLimit.permitsPerSecond();
36
37        // 尝试获取令牌
38        if (!TokenBucketUtil.tryAcquire(key, permitsPerSecond)) {
39            log.warn("请求被限流，请求路径：{}，请求IP：{}", request.getRequestURI(), request.getRemoteAddr());
40            return rateLimit.message();
41        }
42
43        // 执行目标方法
44        return joinPoint.proceed();
45    }
46}
47

在这个切面类中，@Around\(\&\#34;@annotation\(rateLimit\)\&\#34;\)表示拦截所有被@RateLimit注解标记的方法。在rateLimit方法中，首先获取当前的请求对象，然后根据注解中的key属性获取限速标识，如果key为空，则使用请求路径作为限速标识。接着获取每秒允许的请求数，调用TokenBucketUtil\.tryAcquire方法尝试获取令牌。如果获取失败，记录警告日志并返回限流提示信息；如果获取成功，则执行目标方法，让请求正常通过。

测试验证

测试环境搭建

为了验证我们在 Spring Boot 中实现的网络限速功能是否有效，需要搭建一个合适的测试环境。我们选用 JMeter 作为性能测试工具，它是一款功能强大且开源的负载测试工具，能够模拟各种不同的负载场景，对我们的接口进行全面的性能测试 。

在本地启动我们开发好的 Spring Boot 应用，假设应用的端口为 8080 。在 JMeter 中，我们创建一个线程组，用来模拟并发用户。线程组中的线程数可以根据我们的测试需求进行设置，比如设置为 100，表示模拟 100 个并发用户同时向服务器发送请求 。Ramp-Up 时间设置为 10 秒，这意味着 JMeter 会在 10 秒内逐渐启动这 100 个线程，避免瞬间产生过大的负载冲击。迭代次数设置为 10，表示每个线程会重复执行 10 次请求。

接着添加 HTTP 请求，设置服务器名或 IP 为localhost，端口号为 8080，路径为需要测试的接口路径，例如/api/userinfo 。为了更直观地查看测试结果，我们还添加结果树和汇总报告。结果树可以详细展示每个请求的具体响应信息，包括请求数据、响应数据、响应时间等；汇总报告则会统计各种性能指标，如平均响应时间、吞吐量、错误率等，方便我们对测试结果进行分析。

测试用例设计

为了全面验证网络限速功能，我们设计以下几种不同的测试场景：

• 正常请求场景：设置 JMeter 的线程数为 10，Ramp-Up 时间为 5 秒，迭代次数为 5 。这个场景下，请求数量较少且增长缓慢，预期所有请求都能正常通过，接口响应时间在正常范围内，比如平均响应时间在 100 毫秒以内，并且没有请求被限流，错误率为 0。
• 高并发请求场景：将线程数增加到 200，Ramp-Up 时间设置为 5 秒，迭代次数为 10 。此时会有大量请求在短时间内并发发送，由于我们设置了每秒允许的请求数（假设为 100），预期部分请求会被限流。在这种场景下，被限流的请求应该返回我们预先设置的限流提示信息，如 “请求过于频繁，请稍后再试！”，并且随着请求的持续发送，平均响应时间可能会有所增加，但系统依然能够稳定运行，不会出现崩溃或异常错误。
• 超出限速阈值的请求场景：将线程数设置为 500，Ramp-Up 时间为 2 秒，迭代次数为 15 。这种情况下，请求的频率会远远超过我们设定的限速阈值。预期大部分请求都会被限流，只有少量符合限速规则的请求能够正常通过。在汇总报告中，错误率会显著升高，主要是由于请求被限流导致的，而正常通过的请求的响应时间也需要关注，确保即使在高负载限流的情况下，系统对于正常请求的处理依然稳定 。

测试结果分析

运行 JMeter 测试后，我们对测试结果进行详细分析。在正常请求场景下，正如预期，所有请求都成功通过，接口的平均响应时间为 80 毫秒，错误率为 0 。这表明在低负载情况下，我们的系统和限速功能都运行正常，能够快速、准确地处理用户请求。

在高并发请求场景中，我们从结果树中可以看到，部分请求返回了限流提示信息。汇总报告显示，平均响应时间增加到了 200 毫秒，这是由于部分请求被限流等待，导致整体响应时间变长。同时，错误率上升到了 30%，这与我们预期的部分请求被限流相符，验证了限速功能在高并发场景下能够有效限制请求数量，保护系统免受过大的负载压力 。

对于超出限速阈值的请求场景，测试结果显示大量请求被限流，错误率高达 80% 。正常通过的请求的平均响应时间稳定在 300 毫秒左右，虽然响应时间有所增加，但系统没有出现崩溃或其他异常，说明在极端负载情况下，限速功能依然能够保证系统的基本稳定性，避免因请求过多而导致系统瘫痪。

通过对不同测试场景的结果分析，可以得出我们基于 Spring Boot 和 AOP 实现的网络限速功能符合预期，能够在不同的负载情况下有效地控制接口的访问频率，保障系统的稳定运行，提升系统的可靠性和用户体验 。

《Spring Boot一键限速：守护你的接口“高速路”》 是转载文章，点击查看原文。