BeetleX服務網關之限流和緩存

限流和緩存是網關中兩個非常重要的功能，前者是保障服務更可靠地運行，后者則可以大大提高應用的吞吐能力。Beetlex.Bumblebee微服務網關提供了兩個擴展插件來實現這兩個功能，分別是BeetleX.Bumblebee.ConcurrentLimits和BeetleX.Bumblebee.Caching。ConcurrentLimits提供IP或不同Url的並發限流策略，而Caching則可以根據不同Url來配置不同的緩存策略。接下來介紹這兩個插件的使用和配置。

引用插件

Bumblebee中使用JWT需要引用兩個插件，分別是Bumblebee.Configuration,BeetleX.Bumblebee.ConcurrentLimits和BeetleX.Bumblebee.Caching。加載啟動后就可以通過管理工具進行插件配置.

            g = new Gateway();
            g.HttpOptions(
                o =>
                {
                    o.Port = 80;
                    o.LogToConsole = true;
                    o.LogLevel = BeetleX.EventArgs.LogType.Error;
                });
            g.Open();
            g.LoadPlugin(
                typeof(Bumblebee.Configuration.Management).Assembly,
                typeof(Bumblebee.Caching.default_request_cached_reader).Assembly,
typeof(Bumblebee.ConcurrentLimits.UrlConcurrentLimits).Assembly
               );

以上只是代碼引用插件，建議直接下載運行版本：https://github.com/IKende/Bumblebee/blob/master/bin/ (支持windows/linux .net core 2.1或更高版本)

引用插件后就可以在插件管理查看到這兩個插件，大部分插件默認是關閉。

限流配置

default_ip_concurrent_limits

這是針對一個IP並發請求的限制，它可以限制一個IP每秒並發的數量，如果超出這個數量那這個IP則會被禁止訪問一段時間。為了更好的解決實際情況項配置里加入了白名單設置用來排除相關IP或IP范圍的限制,接下來通過一個配置來描述這個插件的使用.

{
    "Limit": 100,
    "DisabledTime": 100,
    "CleanTime": 1800,
    "WhiteList": [
        "192.168.1.1/24",
        "192.168.2.18"
    ]
}

• Limit 每秒最大並發數
• DisabledTime 禁用時間，當IP訪問超過每秒並發數時禁止請求的時間，單位秒
• CleanTime每隔一段時間清除在限制表沒有活躍的IP，單位秒
• WhiteList 白明單，在這個白名單里的IP不被限制

以上配置是對每個IP每秒並發限制在100次，但排除 "192.168.1.1/24"和"192.168.2.18".接下來看一下測試結果

以上是使用192.168.2.19進行兩次壓測的結果，第一次壓測觸發了限制，然后99%的請求被拒絕；然后接下來的一次測試的所有請求都被拒絕了。從結果上來看每秒的20萬rps都被認為是非法，可以想像這些壓力流入到正常服務中會產生有多大的損耗！接下來測試白名單IP

 

從正常測試來看，上游的服務每秒只能處理4萬的rps,所以並發控制是會起到非常好的擋洪效果。

default_url_concurrent_limits

這是針對不同Url制定不同並發限制的插件，在一個服務中難免有些API需要處理復雜的邏輯而占用大量的資源，如果這些接口的並發過量可能對整個服務的資源使用受到影響。通過這個插件可以限制某些API的並發數量，從而控制其它對整體資源的影響。下面看一下簡單的示例配置

{
    "UrlLimits": [
        {
            "Url": "^/jso.*",
            "Rps": 300
        },
        {
            "Url": "^/emp.*",
            "Rps": 100
        }
    ],
    "CleanTime": 1800
}

以上配置兩組Url並發限制，限制秒請求量分別是300和100.配置完成后設置生產看一下壓測結果

• /Json

並發限制是每秒300測試了5秒多，有1800個請求是成功能的，其他99萬多次是被拒絕

• /Employee/2

並發限制是每秒100測試了5秒多，有600個請求是成功能的，其他99萬多次是被拒絕

緩存配置 

緩存插件有兩部分，分別是寫入和讀取；當寫入開啟后讀取才能生效。緩存配置只需要配置寫入插件即可，讀取插件無需配置。

default_request_cache_writer

插件可以針對不同請求的路徑來制定緩存策略，制定也非常方便內容如下:

{
    "Caches": [
        {
            "Url": "^/jso.*",
            "TimeOut": 100
        },
        {
            "Url": "^/api.*",
            "TimeOut": 200
        }
    ],
    "WhiteList": [
        "192.168.2.1/24"
    ]
}

這個緩存插件配置簡單，只需要針對不同Url配置相應的正常和緩存超時時間即可(單位秒)；WhiteList是一個緩存操作的授權白名單。這個緩存的機制是使用.net core的MemoryCache，如果需要使用Redis則需要擴展引入，針對密集處理的網關一級緩存還是在本地內存會高效很多。

測試

為了檢測網關層面緩存的效果，所以對插件進行了一個壓力測試；為了確保緩存發揮比較大的作用所以這個測試在10Gb網絡下面進行(網關服務器則是E3-1230V2的老機器)，這樣可以更好的突出緩存在沒有帶寬限制情況達到的應用效果。測試分別是獲取不同大小的數據列表在關閉和開啟緩存的不同差異。

http://192.168.2.18/customers/5

 以上是插件顯示的並發情況，前面是沒有開啟緩存並發在4萬rps左右，帶寬是500Mb上下；但開啟緩存后並發達到了20萬以上rps(插件走勢圖最大顯示並發只有10萬rps),帶寬接近3Gb.

http://192.168.2.18/customers/20

 

以上是插件顯示的並發情況，前面是沒有開啟緩存並發在2萬rps左右，帶寬是1Gb上下；但開啟緩存后並發達到了17萬rps(插件走勢圖最大顯示並發只有10萬rps),帶寬接近8Gb上下.

總體上來說如果網關緩存開啟其收益是非常明顯的，這個時候限制服務並發輸出的可能是出口的帶寬。

緩存操作

插件安裝后會提供兩個接口來刪除某個Url對應的緩存，或清除所有緩存；這兩個接口的訪問權IP必須在白名單中描述否而無權操作。

• http://host/__system/bumblebee/cache/remove?url=緩存對應的url
• http://host/__system/bumblebee/cache/clean