限流和快取是閘道器中兩個非常重要的功能，前者是保障服務更可靠地執行，後者則可以大大提高應用的吞吐能力。Beetlex.Bumblebee微服務閘道器提供了兩個擴充套件外掛來實現這兩個功能，分別是BeetleX.Bumblebee.ConcurrentLimits和BeetleX.Bumblebee.Caching。ConcurrentLimits提供IP或不同Url的併發限流策略，而Caching則可以根據不同Url來配置不同的快取策略。接下來介紹這兩個外掛的使用和配置。

引用外掛

Bumblebee中使用JWT需要引用兩個外掛，分別是Bumblebee.Configuration,BeetleX.Bumblebee.ConcurrentLimits

            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