對于服務應用來說支持的并發越高越好，但很多時候資源有限，超負載的并發則會給整體應用帶來更大的危險性（更何況有些并發來源是惡意的）。作為微服務網關應該具有一定的擋洪作用，這樣可以一定程度保障后臺邏輯服務的穩定性。Bumblebee基礎只有請求隊列來對大并發進一個導流控制，對更精準的控制并沒有默認實現；雖然組件基礎不提供持不過可以通過插件的方式來進行一個并發控制處理，接下來通過引入BeetleX.Bumblebee.ConcurrentLimits來實現對IP或Url進行一個并發限制。

引用插件

Bumblebee中使用ConcurrentLimits需要引用兩個插件，分別是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.ConcurrentLimits.UrlConcurrentLimits).Assembly
);

引用插件后就可以在插件管理查看到這兩個插件，插件默認是關閉。??在使用這兩個插件的時候需要進行配置相應的規則才能生效，接下來介紹如何使用這兩個插件.

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萬多次是被拒絕.

---

關注公眾號

?https://github.com/IKende/?

高性能的服務通訊框架?Beetlex（http,rpc,gateway的詳細實現）

總結

以上是生活随笔為你收集整理的Bumblebee微服务网关之并发限制的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。