对于服务应用来说支持的并发越高越好，但很多时候资源有限，超负载的并发则会给整体应用带来更大的危险性（更何况有些并发来源是恶意的）。作为微服务网关应该具有一定的挡洪作用，这样可以一定程度保障后台逻辑服务的稳定性。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的详细实现）