為什么網(wǎng)絡(luò)限速很重要

在當(dāng)今互聯(lián)網(wǎng)應(yīng)用廣泛的時代，網(wǎng)絡(luò)限速絕非多此一舉，而是保障系統(tǒng)穩(wěn)定、高效運(yùn)行的關(guān)鍵策略。想象一下電商平臺舉辦秒殺活動，成千上萬的用戶在同一時刻瘋狂點擊搶購按鈕，倘若沒有網(wǎng)絡(luò)限速機(jī)制，瞬間涌入的海量請求可能會直接把服務(wù)器 “壓垮”，導(dǎo)致整個系統(tǒng)癱瘓，無論是正常用戶的購買請求，還是服務(wù)器后續(xù)的訂單處理，都無法順利進(jìn)行。

再看看視頻平臺，每到熱門劇集首播或者大型體育賽事直播時，大量用戶同時在線觀看，對視頻資源的請求量呈爆發(fā)式增長。要是沒有限速措施，有限的帶寬資源會被過度占用，不僅新用戶可能無法正常加載視頻，就連正在觀看的用戶也會頻繁遭遇卡頓、加載緩慢等糟糕體驗，嚴(yán)重影響平臺的口碑和用戶留存率。

網(wǎng)絡(luò)限速也是防范惡意攻擊和資源濫用的有力武器。惡意攻擊者可能會利用工具發(fā)起大量的并發(fā)請求，企圖耗盡服務(wù)器資源，使服務(wù)無法正常提供給合法用戶，這就是常見的 DDoS 攻擊。而通過合理的網(wǎng)絡(luò)限速，能夠有效限制單位時間內(nèi)來自同一 IP 或用戶的請求數(shù)量，讓這類惡意攻擊難以得逞，保障服務(wù)的可用性。同時，對于一些付費使用網(wǎng)絡(luò)資源的場景，限速可以防止個別用戶過度占用資源，確保資源分配的公平性，讓每個用戶都能獲得合理的服務(wù)質(zhì)量。

常見的限速策略

在深入 Spring Boot 實現(xiàn)網(wǎng)絡(luò)限速的代碼世界之前，先來了解一下常見的網(wǎng)絡(luò)限速策略，這些策略是限速的核心思想，理解它們，能讓我們在實際應(yīng)用中更準(zhǔn)確地選擇和實現(xiàn)限速功能。

固定窗口計數(shù)器

這是一種簡單直觀的限速策略。我們可以把時間想象成一個個固定大小的窗口，比如 1 秒為一個窗口。在每個窗口內(nèi)，設(shè)置一個計數(shù)器，每當(dāng)有一個請求進(jìn)來，計數(shù)器就加 1 。當(dāng)計數(shù)器的值達(dá)到我們預(yù)先設(shè)定的閾值時，比如設(shè)定每秒最多允許 100 個請求，那么在這個窗口剩余的時間里，后續(xù)的請求都會被拒絕。直到下一個窗口開始，計數(shù)器重置為 0，重新計數(shù)。這種方式實現(xiàn)起來很簡單，但是存在一個明顯的問題，就是在窗口切換的瞬間可能會出現(xiàn)突發(fā)流量。比如在 0.9 - 1 秒這個時間段來了 100 個請求，緊接著在 1 - 1.1 秒又來 100 個請求，雖然每秒都沒超過限制，但在這 0.2 秒內(nèi)系統(tǒng)卻承受了 200 個請求，容易對系統(tǒng)造成沖擊。

滑動窗口計數(shù)器

為了解決固定窗口計數(shù)器在窗口邊界的突發(fā)流量問題，滑動窗口計數(shù)器應(yīng)運(yùn)而生。它把固定的大窗口劃分成多個小的時間片，比如將 1 秒的窗口劃分為 10 個 100 毫秒的小窗口。隨著時間的推移，窗口不斷滑動，就像一個可以移動的窗口，每次滑動一個小時間片。在統(tǒng)計請求數(shù)量時，不再是單純的以 1 秒為單位，而是統(tǒng)計當(dāng)前滑動窗口內(nèi)所有小時間片的請求總數(shù)。這樣能更精確地控制流量，有效避免固定窗口切換時的流量突刺問題，使流量曲線更加平滑 。不過，實現(xiàn)滑動窗口計數(shù)器相對復(fù)雜一些，需要維護(hù)更多的狀態(tài)信息，比如每個小時間片的請求計數(shù)。

令牌桶算法

令牌桶算法是目前應(yīng)用較為廣泛的一種限流策略。它的核心概念是有一個固定容量的桶，系統(tǒng)以恒定的速率往桶里放入令牌，比如每秒生成 10 個令牌。每個請求在被處理之前，都需要從桶中獲取一個令牌 。如果桶中有足夠的令牌，請求就可以順利通過并消耗一個令牌；如果桶中沒有令牌了，請求就會被拒絕或者等待，直到有新的令牌生成。這個算法的精妙之處在于它允許一定程度的突發(fā)流量 。因為當(dāng)系統(tǒng)處于空閑狀態(tài)時，令牌會在桶中不斷積累，當(dāng)突然有大量請求到來時，只要桶里有足夠的令牌，這些請求就能瞬間被處理，而不會像漏桶算法那樣只能按照固定速率處理請求。

漏桶算法

漏桶算法就像是一個底部有小孔的水桶，請求就如同水一樣流入桶中，然后以固定的速率從桶底的小孔流出，這個固定速率就是我們設(shè)定的限流速率。無論請求以多快的速度進(jìn)入漏桶，只要桶沒有滿，請求就可以進(jìn)入；一旦桶滿了，新進(jìn)來的請求就會被丟棄 。漏桶算法能夠嚴(yán)格地控制請求的處理速率，使流量非常平滑，不會出現(xiàn)突發(fā)的高峰流量。但它的缺點也很明顯，就是無法應(yīng)對突發(fā)流量，即使系統(tǒng)當(dāng)前很空閑，請求也只能按照固定的速率一個個地被處理，這在一些對響應(yīng)時間敏感的場景下可能不太適用。

在實際應(yīng)用中，令牌桶算法由于其既能限制平均流量，又能應(yīng)對突發(fā)流量的優(yōu)勢，成為了很多場景下的首選限流策略。接下來，我們就基于 Spring Boot 框架，使用令牌桶算法來實現(xiàn)網(wǎng)絡(luò)限速功能。

Spring Boot + AOP 實現(xiàn)網(wǎng)絡(luò)限速

核心思路剖析

基于 Spring Boot 和 AOP 實現(xiàn)網(wǎng)絡(luò)限速，主要是通過自定義注解和面向切面編程的方式，將限速邏輯從業(yè)務(wù)代碼中分離出來，實現(xiàn)無侵入式的網(wǎng)絡(luò)限速功能。具體來說，我們首先自定義一個限速注解，比如@RateLimit ，這個注解可以標(biāo)記在需要限速的接口方法上。注解中包含一些參數(shù)，如每秒允許的請求數(shù)、限流提示信息以及限速的唯一標(biāo)識等。然后利用 Spring AOP 的強(qiáng)大功能，攔截所有被@RateLimit注解標(biāo)記的接口方法調(diào)用。在請求進(jìn)入真正的業(yè)務(wù)邏輯之前，AOP 切面會捕獲到這個請求，并根據(jù)注解中配置的參數(shù)，調(diào)用基于令牌桶算法實現(xiàn)的限速邏輯。

令牌桶算法是整個限速功能的核心。我們維護(hù)一個令牌桶，系統(tǒng)以固定的速率往桶里放入令牌，每個請求在被處理前都需要從桶中獲取一個令牌 。如果桶中有足夠的令牌，請求就可以通過并消耗一個令牌；如果桶中沒有令牌，說明請求頻率過高，超出了我們設(shè)定的限速閾值，此時請求會被拒絕，并返回預(yù)先設(shè)置好的限流提示信息。通過這種方式，我們可以有效地控制接口的訪問頻率，防止因高并發(fā)請求導(dǎo)致的系統(tǒng)性能問題，同時也能提高系統(tǒng)的穩(wěn)定性和可靠性 。

代碼實現(xiàn)步驟

引入核心依賴

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

<dependencies>
    <!-- Spring Boot Web依賴，提供Web開發(fā)支持 -->
    <dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-web</artifactId>
    </dependency>
    <!-- AOP依賴，用于實現(xiàn)面向切面編程，攔截注解 -->
    <dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-aop</artifactId>
    </dependency>
    <!-- Lombok依賴，簡化代碼，如自動生成Getter、Setter等方法 -->
    <dependency>
        <groupId>org.projectlombok</groupId>
        <artifactId>lombok</artifactId>
        <optional>true</optional>
    </dependency>
</dependencies>

Spring Boot Web 依賴是整個 Web 應(yīng)用開發(fā)的基礎(chǔ)，它包含了 Spring MVC 等關(guān)鍵組件，使得我們可以方便地創(chuàng)建 RESTful 接口，處理 HTTP 請求和響應(yīng)。AOP 依賴則是實現(xiàn)注解攔截的關(guān)鍵，它允許我們在不修改業(yè)務(wù)代碼的前提下，在方法調(diào)用前后、異常處理等階段插入自定義的邏輯。Lombok 依賴可以極大地簡化 Java 代碼，減少樣板代碼的編寫，提高開發(fā)效率。例如，使用@Data注解可以自動生成類的 Getter、Setter、equals、hashCode和toString方法，讓代碼更加簡潔易讀。

自定義限速注解

創(chuàng)建@RateLimit注解，代碼如下：

package com.example.ratelimit.annotation;

import java.lang.annotation.*;

/**
 * 網(wǎng)絡(luò)限速注解，添加在接口方法上即可實現(xiàn)限速
 */
@Target({ElementType.METHOD}) // 僅作用于方法
@Retention(RetentionPolicy.RUNTIME) // 運(yùn)行時生效，允許AOP反射獲取注解信息
@Documented // 生成JavaDoc時包含該注解
public @interface RateLimit {
    /**
     * 每秒允許的請求數(shù)（限速閾值）
     */
    double permitsPerSecond() default 10.0;

    /**
     * 限流后的提示信息
     */
    String message() default "請求過于頻繁，請稍后再試！";

    /**
     * 限速唯一標(biāo)識（支持SpEL表達(dá)式）
     * 示例：#request.ip 按IP限速，#user.id 按用戶ID限速，默認(rèn)取請求接口路徑
     */
    String key() default "";
}

permitsPerSecond參數(shù)用于設(shè)定每秒允許通過的請求數(shù)量，也就是限速的閾值。比如設(shè)置為 10，就表示每秒最多只能有 10 個請求通過該接口。message參數(shù)則是當(dāng)請求被限流時返回給客戶端的提示信息，讓用戶知道請求被拒絕的原因。key參數(shù)是限速的唯一標(biāo)識，默認(rèn)情況下取請求接口的路徑。但它支持 SpEL 表達(dá)式，通過這個表達(dá)式我們可以實現(xiàn)更靈活的限速策略。例如，使用\#request\.ip可以按客戶端的 IP 地址進(jìn)行限速，每個 IP 地址都有獨立的限速規(guī)則；使用\#user\.id則可以按用戶 ID 進(jìn)行限速，不同用戶有不同的訪問頻率限制 。

實現(xiàn)令牌桶算法

創(chuàng)建TokenBucketUtil工具類，代碼如下：

package com.example.ratelimit.util;

import lombok.extern.slf4j.Slf4j;
import java.util.concurrent.ConcurrentHashMap;
import java.util.concurrent.TimeUnit;
import java.util.concurrent.atomic.AtomicLong;

/**
 * 令牌桶工具類（線程安全，支持多標(biāo)識獨立限速）
 */
@Slf4j
public class TokenBucketUtil {

    /**
     * 存儲不同標(biāo)識對應(yīng)的令牌桶（key：限速標(biāo)識，value：令牌桶）
     */
    private static final ConcurrentHashMap<String, TokenBucket> TOKEN_BUCKET_MAP = new ConcurrentHashMap<>();

    /**
     * 獲取令牌（非阻塞，獲取不到直接返回false）
     * @param key 限速標(biāo)識
     * @param permitsPerSecond 每秒允許的請求數(shù)（令牌生成速率）
     * @return true：獲取令牌成功，false：限流
     */
    public static boolean tryAcquire(String key, double permitsPerSecond) {
        TokenBucket tokenBucket = TOKEN_BUCKET_MAP.computeIfAbsent(key, k -> new TokenBucket(permitsPerSecond));
        return tokenBucket.tryAcquire();
    }

    /**
     * 令牌桶內(nèi)部類
     */
    private static class TokenBucket {
        // 桶的容量，這里設(shè)置為與每秒生成的令牌數(shù)相同，即桶最多能容納一秒內(nèi)生成的所有令牌
        private final double capacity;
        // 令牌生成速率，即每秒生成的令牌數(shù)
        private final double refillRate;
        // 記錄上一次更新令牌桶的時間
        private final AtomicLong lastRefillTime;
        // 當(dāng)前桶中的令牌數(shù)量
        private final AtomicLong tokens;

        public TokenBucket(double permitsPerSecond) {
            this.capacity = permitsPerSecond;
            this.refillRate = permitsPerSecond;
            this.lastRefillTime = new AtomicLong(System.nanoTime());
            this.tokens = new AtomicLong((long) permitsPerSecond);
        }

        public boolean tryAcquire() {
            refill();
            if (tokens.get() >= 1) {
                tokens.decrementAndGet();
                return true;
            }
            return false;
        }

        private void refill() {
            long now = System.nanoTime();
            long elapsedTime = now - lastRefillTime.get();
            // 根據(jù)時間差和令牌生成速率，計算這段時間內(nèi)應(yīng)該生成的令牌數(shù)量
            double newTokens = elapsedTime * refillRate / TimeUnit.SECONDS.toNanos(1);
            // 更新桶中的令牌數(shù)量，不能超過桶的容量
            tokens.addAndGet((long) Math.min(capacity, newTokens));
            lastRefillTime.set(now);
        }
    }
}

在TokenBucketUtil類中，我們使用ConcurrentHashMap來存儲不同標(biāo)識對應(yīng)的令牌桶，確保在多線程環(huán)境下不同標(biāo)識的限速相互獨立，并且線程安全。tryAcquire方法是獲取令牌的核心邏輯，它首先通過computeIfAbsent方法從TOKEN\_BUCKET\_MAP中獲取或創(chuàng)建對應(yīng)的令牌桶 。然后調(diào)用令牌桶的tryAcquire方法嘗試獲取令牌，如果獲取成功則返回true，表示請求可以通過；如果獲取失敗則返回false，表示請求被限流。

TokenBucket內(nèi)部類封裝了令牌桶的具體實現(xiàn)。在構(gòu)造函數(shù)中，我們初始化了桶的容量capacity、令牌生成速率refillRate、上次更新時間lastRefillTime以及當(dāng)前令牌數(shù)量tokens。tryAcquire方法會先調(diào)用refill方法，根據(jù)當(dāng)前時間和上次更新時間的差值，計算出這段時間內(nèi)應(yīng)該生成的新令牌數(shù)量，并更新桶中的令牌數(shù)量 。然后檢查桶中是否有足夠的令牌，如果有則消耗一個令牌并返回true，否則返回false。refill方法通過計算時間差和令牌生成速率，確保令牌桶能夠按照設(shè)定的速率生成新的令牌，并且保證令牌數(shù)量不會超過桶的容量。

配置說明

在 Spring Boot 項目中，要使上述限速功能生效，還需要進(jìn)行一些配置。首先，確保 Spring AOP 功能已經(jīng)啟用。在 Spring Boot 中，只要引入了spring\-boot\-starter\-aop依賴，AOP 功能默認(rèn)是開啟的。如果項目中存在自定義的@Configuration配置類，也可以顯式地啟用 AOP，如下所示：

package com.example.ratelimit.config;

import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
import org.springframework.context.annotation.EnableAspectJAutoProxy;

@Configuration
@EnableAspectJAutoProxy
public class AopConfig {

    // 這里可以添加其他AOP相關(guān)的配置，目前保持空即可
}

@EnableAspectJAutoProxy注解會自動為標(biāo)記了@Aspect的切面類創(chuàng)建代理，從而實現(xiàn)對目標(biāo)方法的攔截和增強(qiáng)。

接下來，創(chuàng)建一個切面類，用于攔截被@RateLimit注解標(biāo)記的方法，并執(zhí)行限速邏輯。切面類代碼如下：

package com.example.ratelimit.aspect;

import com.example.ratelimit.annotation.RateLimit;
import com.example.ratelimit.util.TokenBucketUtil;
import lombok.extern.slf4j.Slf4j;
import org.aspectj.lang.ProceedingJoinPoint;
import org.aspectj.lang.annotation.Around;
import org.aspectj.lang.annotation.Aspect;
import org.springframework.stereotype.Component;
import org.springframework.web.context.request.RequestContextHolder;
import org.springframework.web.context.request.ServletRequestAttributes;

import javax.servlet.http.HttpServletRequest;

@Aspect
@Component
@Slf4j
public class RateLimitAspect {

    @Around("@annotation(rateLimit)")
    public Object rateLimit(ProceedingJoinPoint joinPoint, RateLimit rateLimit) throws Throwable {
        ServletRequestAttributes attributes = (ServletRequestAttributes) RequestContextHolder.currentRequestAttributes();
        HttpServletRequest request = attributes.getRequest();

        // 獲取限速標(biāo)識
        String key = rateLimit.key();
        if (key.isEmpty()) {
            key = request.getRequestURI();
        }
        // 解析SpEL表達(dá)式，支持按IP、用戶ID等精細(xì)化限速
        // 這里暫未實現(xiàn)復(fù)雜的SpEL表達(dá)式解析，后續(xù)可根據(jù)需求擴(kuò)展
        // 例如：if (key.startsWith("#")) { key = parseSpelExpression(key, request); }

        // 獲取每秒允許的請求數(shù)
        double permitsPerSecond = rateLimit.permitsPerSecond();

        // 嘗試獲取令牌
        if (!TokenBucketUtil.tryAcquire(key, permitsPerSecond)) {
            log.warn("請求被限流，請求路徑：{}，請求IP：{}", request.getRequestURI(), request.getRemoteAddr());
            return rateLimit.message();
        }

        // 執(zhí)行目標(biāo)方法
        return joinPoint.proceed();
    }
}

在這個切面類中，@Around\(\&\#34;@annotation\(rateLimit\)\&\#34;\)表示攔截所有被@RateLimit注解標(biāo)記的方法。在rateLimit方法中，首先獲取當(dāng)前的請求對象，然后根據(jù)注解中的key屬性獲取限速標(biāo)識，如果key為空，則使用請求路徑作為限速標(biāo)識。接著獲取每秒允許的請求數(shù)，調(diào)用TokenBucketUtil\.tryAcquire方法嘗試獲取令牌。如果獲取失敗，記錄警告日志并返回限流提示信息；如果獲取成功，則執(zhí)行目標(biāo)方法，讓請求正常通過。

測試驗證

測試環(huán)境搭建

為了驗證我們在 Spring Boot 中實現(xiàn)的網(wǎng)絡(luò)限速功能是否有效，需要搭建一個合適的測試環(huán)境。我們選用 JMeter 作為性能測試工具，它是一款功能強(qiáng)大且開源的負(fù)載測試工具，能夠模擬各種不同的負(fù)載場景，對我們的接口進(jìn)行全面的性能測試 。

在本地啟動我們開發(fā)好的 Spring Boot 應(yīng)用，假設(shè)應(yīng)用的端口為 8080 。在 JMeter 中，我們創(chuàng)建一個線程組，用來模擬并發(fā)用戶。線程組中的線程數(shù)可以根據(jù)我們的測試需求進(jìn)行設(shè)置，比如設(shè)置為 100，表示模擬 100 個并發(fā)用戶同時向服務(wù)器發(fā)送請求 。Ramp-Up 時間設(shè)置為 10 秒，這意味著 JMeter 會在 10 秒內(nèi)逐漸啟動這 100 個線程，避免瞬間產(chǎn)生過大的負(fù)載沖擊。迭代次數(shù)設(shè)置為 10，表示每個線程會重復(fù)執(zhí)行 10 次請求。

接著添加 HTTP 請求，設(shè)置服務(wù)器名或 IP 為localhost，端口號為 8080，路徑為需要測試的接口路徑，例如/api/userinfo 。為了更直觀地查看測試結(jié)果，我們還添加結(jié)果樹和匯總報告。結(jié)果樹可以詳細(xì)展示每個請求的具體響應(yīng)信息，包括請求數(shù)據(jù)、響應(yīng)數(shù)據(jù)、響應(yīng)時間等；匯總報告則會統(tǒng)計各種性能指標(biāo)，如平均響應(yīng)時間、吞吐量、錯誤率等，方便我們對測試結(jié)果進(jìn)行分析。

測試用例設(shè)計

為了全面驗證網(wǎng)絡(luò)限速功能，我們設(shè)計以下幾種不同的測試場景：

• 正常請求場景：設(shè)置 JMeter 的線程數(shù)為 10，Ramp-Up 時間為 5 秒，迭代次數(shù)為 5 。這個場景下，請求數(shù)量較少且增長緩慢，預(yù)期所有請求都能正常通過，接口響應(yīng)時間在正常范圍內(nèi)，比如平均響應(yīng)時間在 100 毫秒以內(nèi)，并且沒有請求被限流，錯誤率為 0。

• 高并發(fā)請求場景：將線程數(shù)增加到 200，Ramp-Up 時間設(shè)置為 5 秒，迭代次數(shù)為 10 。此時會有大量請求在短時間內(nèi)并發(fā)發(fā)送，由于我們設(shè)置了每秒允許的請求數(shù)（假設(shè)為 100），預(yù)期部分請求會被限流。在這種場景下，被限流的請求應(yīng)該返回我們預(yù)先設(shè)置的限流提示信息，如 “請求過于頻繁，請稍后再試！”，并且隨著請求的持續(xù)發(fā)送，平均響應(yīng)時間可能會有所增加，但系統(tǒng)依然能夠穩(wěn)定運(yùn)行，不會出現(xiàn)崩潰或異常錯誤。

• 超出限速閾值的請求場景：將線程數(shù)設(shè)置為 500，Ramp-Up 時間為 2 秒，迭代次數(shù)為 15 。這種情況下，請求的頻率會遠(yuǎn)遠(yuǎn)超過我們設(shè)定的限速閾值。預(yù)期大部分請求都會被限流，只有少量符合限速規(guī)則的請求能夠正常通過。在匯總報告中，錯誤率會顯著升高，主要是由于請求被限流導(dǎo)致的，而正常通過的請求的響應(yīng)時間也需要關(guān)注，確保即使在高負(fù)載限流的情況下，系統(tǒng)對于正常請求的處理依然穩(wěn)定 。

測試結(jié)果分析

運(yùn)行 JMeter 測試后，我們對測試結(jié)果進(jìn)行詳細(xì)分析。在正常請求場景下，正如預(yù)期，所有請求都成功通過，接口的平均響應(yīng)時間為 80 毫秒，錯誤率為 0 。這表明在低負(fù)載情況下，我們的系統(tǒng)和限速功能都運(yùn)行正常，能夠快速、準(zhǔn)確地處理用戶請求。

在高并發(fā)請求場景中，我們從結(jié)果樹中可以看到，部分請求返回了限流提示信息。匯總報告顯示，平均響應(yīng)時間增加到了 200 毫秒，這是由于部分請求被限流等待，導(dǎo)致整體響應(yīng)時間變長。同時，錯誤率上升到了 30%，這與我們預(yù)期的部分請求被限流相符，驗證了限速功能在高并發(fā)場景下能夠有效限制請求數(shù)量，保護(hù)系統(tǒng)免受過大的負(fù)載壓力 。

對于超出限速閾值的請求場景，測試結(jié)果顯示大量請求被限流，錯誤率高達(dá) 80% 。正常通過的請求的平均響應(yīng)時間穩(wěn)定在 300 毫秒左右，雖然響應(yīng)時間有所增加，但系統(tǒng)沒有出現(xiàn)崩潰或其他異常，說明在極端負(fù)載情況下，限速功能依然能夠保證系統(tǒng)的基本穩(wěn)定性，避免因請求過多而導(dǎo)致系統(tǒng)癱瘓。

通過對不同測試場景的結(jié)果分析，可以得出我們基于 Spring Boot 和 AOP 實現(xiàn)的網(wǎng)絡(luò)限速功能符合預(yù)期，能夠在不同的負(fù)載情況下有效地控制接口的訪問頻率，保障系統(tǒng)的穩(wěn)定運(yùn)行，提升系統(tǒng)的可靠性和用戶體驗 。

到此這篇關(guān)于Spring Boot一鍵限速的項目實踐的文章就介紹到這了,更多相關(guān)Spring Boot一鍵限速內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！

最新評論