.NET服務治理之限流中間件-FireflySoft.RateLimit

概述

FireflySoft.RateLimit自2021年1月發佈第一個版本以來，經歷了多次升級迭代，目前已經十分穩定，被很多開發者應用到了生產系統中，最新發佈的版本是3.0.0。

• Github：https://github.com/bosima/FireflySoft.RateLimit
• 碼雲：https://gitee.com/bosima/FireflySoft.RateLimit

它的核心是一個基於 .NET Standard 的限流類庫，其內核簡單輕巧，能夠靈活應對各種需求的限流場景。其主要特點包括：

• 多種限流演算法：內置固定視窗、滑動視窗、漏桶、令牌桶四種演算法，方便自定義擴展。
• 多種計數存儲：目前支持記憶體、Redis（含集群）兩種存儲方式。
• 分散式友好：通過Redis存儲支持分散式程式統一計數。
• 限流目標靈活：可以從請求中提取各種數據用於設置限流目標，不僅僅是客戶端IP和Id。
• 支持限流懲罰：可以在客戶端觸發限流後鎖定一段時間不允許其訪問。
• 時間視窗增強：支持到毫秒級別；支持從秒、分鐘、小時、日期等時間周期的自然起始點開始。
• 實時限流跟蹤：當前計數周期內已處理的請求數、剩餘允許請求數，以及計數周期重置的時間。
• 動態更改規則：支持程式運行時動態更改限流規則。
• 自定義錯誤：可以自定義觸發限流後的錯誤碼和錯誤消息。
• 普適性：原則上可以滿足任何需要限流的場景，可用於各種B/S、C/S程式。

基於這個核心又實現了兩個中間件：

• FireflySoft.RateLimit.AspNet：應用於傳統的.NET Framework的Web應用程式。
• FireflySoft.RateLimit.AspNetCore：應用於ASP.NET Core的Web應用程式。

相比使用FireflySoft.RateLimit核心類庫，直接使用這兩個中間件比較方便一些。如果這兩個中間件不能滿足你的需求，比如不是應用在官方的Web框架中，甚至不是Web程式，問題不大，可以基於核心類庫滿足你的限流需求，你要做的只是定義好你要限流的請求，併在觸發限流時執行自己的業務邏輯，限流的演算法如何實現都不需要關心。

這些類庫和中間件都是可以通過Nuget安裝的，搜索 FireflySoft.RateLimit 即可找到。

使用示例

這篇文章以一個ASP.NET Core程式為例，說明FireflySoft.RateLimit的使用方法。

程式的業務需求是：對獲取天氣預報的介面，根據客戶端IP和ClientId進行限流，每個IP每秒鐘1次，每個ClientId每秒鐘3次。ClientId是預先分配給調用方的。根據規則，調用方如果只有1個出口IP，那麼每秒鐘只能訪問1次，如果有多個出口IP，那麼每秒鐘最多訪問3次。

這個示常式序是基於.NET6開發的，當然你用.NET Core 3.1也沒有問題，只是.NET6預設把服務和中間件註冊都放到了Program.cs 中。（建議升級到.NET6，.NET6相比.NET Core 3.1的性能有明顯的提升。）

來看代碼吧，只需要註冊服務和Middleware就可以了。

using FireflySoft.RateLimit.AspNetCore;
using FireflySoft.RateLimit.Core.InProcessAlgorithm;
using FireflySoft.RateLimit.Core.Rule;

var builder = WebApplication.CreateBuilder(args);

...

builder.Services.AddRateLimit(new InProcessFixedWindowAlgorithm(
    new[] {
        new FixedWindowRule()
        {
            ExtractTarget = context =>
            {
                var httpContext= context as HttpContext;

                // Through CDN
                var ip = httpContext!.Request.Headers["Cdn-Src-Ip"].FirstOrDefault();
                if (!string.IsNullOrEmpty(ip))
                    return ip;

                // Through SLB
                ip = httpContext!.Request.Headers["X-Forwarded-For"].FirstOrDefault();
                if (!string.IsNullOrEmpty(ip))
                    return ip;

                ip = httpContext!.Connection.RemoteIpAddress?.ToString();
                return ip??"Anonymous-IP";
            },
            CheckRuleMatching = context =>
            {
                var requestPath = (context as HttpContext)!.Request.Path.Value;
                if (requestPath == "/WeatherForecast/Future")
                {
                    return true;
                }
                return false;
            },
            Name = "ClientIPRule",
            LimitNumber = 3,
            StatWindow = TimeSpan.FromSeconds(1)
        },
        new FixedWindowRule()
        {
            ExtractTarget = context =>
            {
                var httpContext= context as HttpContext;
                var clientID = httpContext!.Request.Headers["X-ClientId"].FirstOrDefault();

                return clientID??"Anonymous-ClientId";
            },
            CheckRuleMatching = context =>
            {
                var requestPath = (context as HttpContext)!.Request.Path.Value;
                if (requestPath == "/WeatherForecast/Future")
                {
                    return true;
                }
                return false;
            },
            Name = "ClientIdRule",
            LimitNumber = 1,
            StatWindow = TimeSpan.FromSeconds(1)
        }
    })
);

...

app.UseRateLimit();

...

粘貼的代碼中只保留了此中間件需要的內容，註冊服務使用 AddRateLimit，使用中間件通過 UseRateLimit。

演算法

AddRateLimit 時需要指定一個限流演算法，示例中是基於本地記憶體的固定視窗演算法，可以根據需要更換為其它演算法，比如可以應對短時突發流量的令牌桶演算法。

對於某種具體的演算法，基於本地記憶體和基於Redis的實現是不同的類，因為為了更好的性能，Redis實現的演算法是通過Lua腳本寫的，它完全運行在Redis服務端。

為了方便使用，將這些演算法的名字列在這裡：

目前一個ASP.NET Core程式中只能使用一種演算法，不知道是否有多種演算法的需求，如有需要可以對FireflySoft.RateLimit.AspNetCore 進行一些改造：

• AddRateLimit時註冊IAlgorithm改為註冊IAlgorithm的解析器，解析器提供一個方法根據某個Key返回IAlgorithm的具體實現。

• RateLimitMiddleware中根據當前請求確定要使用的演算法，然後調用解析器的方法獲取IAlgorithm的具體實現。

規則

創建演算法實例的時候，還需要指定演算法的規則，這裡根據演算法使用的是 FixedWindowRule，對於同一個演算法，進程內實現和Redis實現使用相同的規則。

看一下這裡使用的規則的幾個屬性：

ExtractTarget 設置一個函數，用於從HTTP請求中提取要限流的目標，比如這裡的客戶端IP和客戶端ID，還可以是各種可以從請求中提取或關聯到的東西，比如Http Header中攜帶的用戶Id，或者根據用戶Id查詢到的用戶年齡。

CheckRuleMatching 設置一個函數，返回當前請求是否能匹配到某個限流規則，如果能匹配到，則返回true。比如只對 /api/req 這個路徑限流，那麼只要判斷請求的路徑是它，就返回true，其它路徑都返回false。當然也可以是根據各種可以從請求中提取或關聯到的東西來進行判斷。

Name 限流規則的名字，方便人跟蹤的時候進行區分。

StatWindow 限流的時間視窗。比如需求中的每秒鐘3次，這裡的時間視窗就要設置為1秒。

LimitNumber 限流的次數閾值。比如需求中的每秒鐘3次，這裡的時間視窗就要設置為3，超過3就會被限流。

規則中還有其它幾個屬性，不同演算法的規則也略有不同，這裡就不一一列舉了。感興趣的朋友可以去示例代碼和單元測試中認識它們。

一個演算法中可以添加多個對應演算法的規則，這無疑會比較靈活。

更多使用說明

• ASP.NET Core中使用固定視窗限流
• ASP.NET Core中使用滑動視窗限流
• ASP.NET Core中使用漏桶演算法限流
• ASP.NET Core中使用令牌桶限流
• ASP.NET Core中如何對不同類型的用戶進行區別限流
• 多租戶系統中如何實現分別限流
• .NET6運行時動態更新限流閾值
• 如何使用數組實現滑動視窗
• 限流的非常規用途 – 緩解搶購壓力
• 限流的非正式用途 – 解決重覆提交問題
• 服務限流懲罰是怎麼一回事

以上就是本文的主要內容了，如有問題歡迎留言交流。