ASP.NET Core Web API 介面限流

0611163發表於2023-03-09
ASP.NETWebAPI

一. 前言

ASP.NET Core Web API 介面限流、限制介面併發數量，我也不知道自己寫的有沒有問題，拋磚引玉。

二. 需求

  1. 寫了一個介面，引數可以傳多個人員，也可以傳單個人員，時間範圍限制最長一個月。簡單來說，當傳單個人員時，介面耗時很短，當傳多個人員時，一般人員會較多，介面耗時較長，一般耗時幾秒。
  2. 當傳多個人員時，併發量高時，介面的耗時就很長了，比如100個使用者併發請求，耗時可長達幾十秒，甚至1分鐘。
  3. 所以需求是，當傳單個人員時，不限制。當傳多個人員時，限制併發數量。如果併發使用者數少於限制數，那麼所有使用者都能成功。如果併發使用者數，超出限制數，那麼超出的使用者請求失敗，並提示"當前進行XXX查詢的使用者太多，請稍後再試"。
  4. 這樣也可以減輕被請求的ES叢集的壓力。

三. 說明

  1. 使用的是.NET6
  2. 我知道有人寫好了RateLimit中介軟體，但我暫時還沒有學會怎麼使用，能否滿足我的需求，所以先自己實現一下。

四. 效果截圖

下面是使用jMeter併發測試時，打的介面日誌：

五. 程式碼

1. RateLimitInterface

介面引數的實體類要繼承該介面

using JsonA = Newtonsoft.Json;
using JsonB = System.Text.Json.Serialization;

namespace Utils
{
    /// <summary>
    /// 限速介面
    /// </summary>
    public interface RateLimitInterface
    {
        /// <summary>
        /// 是否限速
        /// </summary>
        [JsonA.JsonIgnore]
        [JsonB.JsonIgnore]
        bool IsLimit { get; }
    }
}

2. 介面引數實體類

繼承RateLimitInterface介面，並實現IsLimit屬性

public class XxxPostData : RateLimitInterface
{
    ...省略

    /// <summary>
    /// 是否限速
    /// </summary>
    [JsonA.JsonIgnore]
    [JsonB.JsonIgnore]
    public bool IsLimit
    {
        get
        {
            if (peoples.Count > 2) //限速條件，自己定義
            {
                return true;
            }
            return false;
        }
    }
}

3. RateLimitAttribute

作用：標籤打在介面方法上，並設定併發數量

namespace Utils
{
    /// <summary>
    /// 介面限速
    /// </summary>
    public class RateLimitAttribute : Attribute
    {
        private Semaphore _sem;

        public Semaphore Sem
        {
            get
            {
                return _sem;
            }
        }

        public RateLimitAttribute(int limitCount = 1)
        {
            _sem = new Semaphore(limitCount, limitCount);
        }
    }
}

4. 使用RateLimitAttribute

標籤打在介面方法上，並設定併發數量。
伺服器好像是24核的，併發限制為8應該沒問題。

[HttpPost]
[Route("[action]")]
[RateLimit(8)]
public async Task<List<XxxInfo>> Query([FromBody] XxxPostData data)
{
    ...省略
}

5. 限制介面併發量的攔截器RateLimitFilter

/// <summary>
/// 介面限速
/// </summary>
public class RateLimitFilter : ActionFilterAttribute
{
    public override async Task OnActionExecutionAsync(ActionExecutingContext context, ActionExecutionDelegate next)
    {
        Type controllerType = context.Controller.GetType();
        object arg = context.ActionArguments.Values.ToList()[0];
        var rateLimit = context.ActionDescriptor.EndpointMetadata.OfType<RateLimitAttribute>().FirstOrDefault();

        bool isLimit = false; //是否限速
        if (rateLimit != null && arg is RateLimitInterface) //介面方法打了RateLimitAttribute標籤並且引數實體類實現了RateLimitInterface介面時才限速，否則不限速
        {
            RateLimitInterface model = arg as RateLimitInterface;
            if (model.IsLimit) //滿足限速條件
            {
                isLimit = true;
                Semaphore sem = rateLimit.Sem;

                if (sem.WaitOne(0)) //注意：超時時間為0，表示不等待
                {
                    try
                    {
                        await next.Invoke();
                    }
                    catch
                    {
                        throw;
                    }
                    finally
                    {
                        sem.Release();
                    }
                }
                else
                {
                    var routeList = context.RouteData.Values.Values.ToList();
                    routeList.Reverse();
                    var route = string.Join('/', routeList.ConvertAll(a => a.ToString()));
                    var msg = $"當前訪問{route}介面的使用者數太多，請稍後再試";
                    LogUtil.Info(msg);
                    context.Result = new ObjectResult(new ApiResult
                    {
                        code = (int)HttpStatusCode.ServiceUnavailable,
                        message = "當前查詢的使用者太多，請稍後再試。"
                    });
                }
            }
        }

        if (!isLimit)
        {
            await next.Invoke();
        }
    }
}

上述程式碼說明：sem.WaitOne(0)這個超時時間，最好是0，即不等待，否則高併發下會有問題。SemaphoreSlim的非同步wait沒試過。如果超時時間大於0，意味著，高併發下，會有大量的等待，非同步等待也是等待。
SemaphoreSlim短時間是自旋，想象一下一瞬間產生大量自旋會怎麼樣？所以最好不等待，如果要等待，那程式碼還得再研究研究，經過測試才能用。

6. 註冊攔截器

//攔截器
builder.Services.AddMvc(options =>
{
    ...省略

    options.Filters.Add<RateLimitFilter>();
});

六. 使用jMeter進行壓力測試

測試結果：

  1. 被限速的介面，滿足限速條件的呼叫併發量大時，部分使用者成功，部分使用者提示當前查詢的人多請稍後再試。但不影響未滿足限速條件的傳參呼叫，也不影響其它未限速介面的呼叫。
  2. 測試的所有介面、所有查詢引數條件的呼叫，耗時穩定，大量併發時，不會出現介面耗時幾十秒甚至1分鐘的情況。

七. 同時測試三個介面

測試三個介面，一個是觸發限流的A介面，一個是未觸發限流的A介面，一個是未被限流的B介面。

jMeter測試設定

觸發限流的A介面，併發量設定為200：

未觸發限流的A介面以及未被限流的B介面，併發量設定為1：

測試日誌截圖


截圖說明：可以看到被限流介面共1000次呼叫，只有大約40次呼叫是成功的，剩下的返回請稍後再試。


截圖說明：實際上觸發限流的介面，併發量為8，壓力依然很大，會拖慢自身以及其它介面，當觸發限流的介面請求結束時，其它介面訪問速度才正常。

八. 實際情況

  1. 這種介面計算量大，是難以支援高併發的，需要限流。爭取客戶的理解，僅支援少量使用者在同一時間查詢。
  2. 實際上只要使用者錯開幾秒訪問，介面的耗時就很正常。問題是，如何錯開幾秒呢？當使用者看到"請稍後再試"的提示，關閉提示，重新點選查詢，就可以錯開了。如果一次兩次不行，就多點幾次查詢。

九. 後續

  1. 修改為使用SemaphoreSlim類，這樣可以非同步等待
  2. RateLimitAttribute類增加了超時時間屬性

程式碼如下：

1. RateLimitAttribute

/// <summary>
/// 介面限速
/// </summary>
public class RateLimitAttribute : Attribute
{
    private SemaphoreSlim _sem;

    public SemaphoreSlim Sem
    {
        get
        {
            return _sem;
        }
    }

    /// <summary>
    /// 超時時間(單位:毫秒)
    /// </summary>
    private int _timeout;

    /// <summary>
    /// 超時時間(單位:毫秒)
    /// </summary>
    public int Timeout
    {
        get
        {
            return _timeout;
        }
    }

    /// <summary>
    /// 介面限速
    /// </summary>
    /// <param name="limitCount">限制併發數量</param>
    /// <param name="timeout">超時時間(單位:秒)</param>
    public RateLimitAttribute(int limitCount = 1, int timeout = 0)
    {
        _sem = new SemaphoreSlim(limitCount, limitCount);
        _timeout = timeout * 1000;
    }
}

2. RateLimitFilter

/// <summary>
/// 介面限速
/// </summary>
public class RateLimitFilter : ActionFilterAttribute
{
    public override async Task OnActionExecutionAsync(ActionExecutingContext context, ActionExecutionDelegate next)
    {
        Type controllerType = context.Controller.GetType();
        object arg = context.ActionArguments.Values.ToList()[0];
        var rateLimit = context.ActionDescriptor.EndpointMetadata.OfType<RateLimitAttribute>().FirstOrDefault();

        bool isLimit = false;
        if (rateLimit != null && arg is RateLimitInterface)
        {
            RateLimitInterface model = arg as RateLimitInterface;
            if (model.IsLimit) //滿足限速條件
            {
                isLimit = true;
                SemaphoreSlim sem = rateLimit.Sem;

                if (await sem.WaitAsync(rateLimit.Timeout))
                {
                    try
                    {
                        await next.Invoke();
                    }
                    catch
                    {
                        throw;
                    }
                    finally
                    {
                        sem.Release();
                    }
                }
                else
                {
                    var routeList = context.RouteData.Values.Values.ToList();
                    routeList.Reverse();
                    var route = string.Join('/', routeList.ConvertAll(a => a.ToString()));
                    var msg = $"當前訪問{route}介面的使用者數太多，請稍後再試";
                    LogUtil.Info(msg);
                    context.Result = new ObjectResult(new ApiResult
                    {
                        code = (int)HttpStatusCode.ServiceUnavailable,
                        message = "當前查詢的使用者太多，請稍後再試。"
                    });
                }
            }
        }

        if (!isLimit)
        {
            await next.Invoke();
        }
    }
}

效果

  1. 假如設定RateLimit(1, 0)，即併發1，超時時間0，那麼當100個併發請求時，只有1個成功，99個失敗。
  2. 假如介面耗時2秒，設定RateLimit(1, 10)，即併發1，超時時間10秒，那麼當100個併發請求時，會有大約5個成功，95個失敗。第1個成功的介面請求耗時大約2秒，後續成功的4個，請求耗時依次增加。
  3. 當設定了併發量和超時時間後，介面平均一秒鐘能被請求多少次，取決於介面耗時，耗時短的介面平均每秒能被請求的次數多，耗時長的介面平均每秒能被請求的次數少。

相關文章