限流和缓存是网关中两个很是重要的功能,前者是保障服务更可靠地运行,后者则能够大大提升应用的吞吐能力。Beetlex.Bumblebee微服务网关提供了两个扩展插件来实现这两个功能,分别是BeetleX.Bumblebee.ConcurrentLimits和BeetleX.Bumblebee.Caching。ConcurrentLimits提供IP或不一样Url的并发限流策略,而Caching则能够根据不一样Url来配置不一样的缓存策略。接下来介绍这两个插件的使用和配置。linux
Bumblebee
中使用JWT
须要引用两个插件,分别是Bumblebee.Configuration,BeetleX.Bumblebee.ConcurrentLimits
和BeetleX.Bumblebee.Caching
。加载启动后就能够经过管理工具进行插件配置.git
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或更高版本)github
引用插件后就能够在插件管理查看到这两个插件,大部分插件默认是关闭。json
这是针对一个IP并发请求的限制,它能够限制一个IP每秒并发的数量,若是超出这个数量那这个IP则会被禁止访问一段时间。为了更好的解决实际状况项配置里加入了白名单设置用来排除相关IP或IP范围的限制,接下来经过一个配置来描述这个插件的使用.windows
{ "Limit": 100, "DisabledTime": 100, "CleanTime": 1800, "WhiteList": [ "192.168.1.1/24", "192.168.2.18" ] }
以上配置是对每一个IP每秒并发限制在100次,但排除 "192.168.1.1/24"和"192.168.2.18".接下来看一下测试结果api
以上是使用192.168.2.19
进行两次压测的结果,第一次压测触发了限制,而后99%的请求被拒绝;而后接下来的一次测试的全部请求都被拒绝了。从结果上来看每秒的20万rps都被认为是非法,能够想像这些压力流入到正常服务中会产生有多大的损耗!接下来测试白名单IP缓存
从正常测试来看,上游的服务每秒只能处理4万的rps,因此并发控制是会起到很是好的挡洪效果。服务器
这是针对不一样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万屡次是被拒绝
缓存插件有两部分,分别是写入和读取;当写入开启后读取才能生效。缓存配置只须要配置写入插件便可,读取插件无需配置。
插件能够针对不一样请求的路径来制定缓存策略,制定也很是方便内容以下:
{ "Caches": [ { "Url": "^/jso.*", "TimeOut": 100 }, { "Url": "^/api.*", "TimeOut": 200 } ], "WhiteList": [ "192.168.2.1/24" ] }
这个缓存插件配置简单,只须要针对不一样Url
配置相应的正常和缓存超时时间便可(单位秒);WhiteList
是一个缓存操做的受权白名单。这个缓存的机制是使用.net core的MemoryCache
,若是须要使用Redis
则须要扩展引入,针对密集处理的网关一级缓存仍是在本地内存会高效不少。
为了检测网关层面缓存的效果,因此对插件进行了一个压力测试;为了确保缓存发挥比较大的做用因此这个测试在10Gb网络下面进行(网关服务器则是E3-1230V2的老机器),这样能够更好的突出缓存在没有带宽限制状况达到的应用效果。测试分别是获取不一样大小的数据列表在关闭和开启缓存的不一样差别。
以上是插件显示的并发状况,前面是没有开启缓存并发在4万rps左右,带宽是500Mb上下;但开启缓存后并发达到了20万以上rps(插件走势图最大显示并发只有10万rps),带宽接近3Gb.
以上是插件显示的并发状况,前面是没有开启缓存并发在2万rps左右,带宽是1Gb上下;但开启缓存后并发达到了17万rps(插件走势图最大显示并发只有10万rps),带宽接近8Gb上下.
整体上来讲若是网关缓存开启其收益是很是明显的,这个时候限制服务并发输出的多是出口的带宽。
插件安装后会提供两个接口来删除某个Url对应的缓存,或清除全部缓存;这两个接口的访问权IP必须在白名单中描述否而无权操做。
http://host/__system/bumblebee/cache/remove?url=缓存对应的url
http://host/__system/bumblebee/cache/clean