其他的不变(见上第一篇)
https://blog.csdn.net/baidu_38845827/article/details/113586679
这里先写一下熔点器的知识
借鉴于 https://www.cnblogs.com/phyger/p/14048571.html
熔断器的作用就是防止雪崩 雪崩就是服务间是链式调用,当下游服务挂掉了或者需要等很久,导致上游的请求一直处于等待状态 当发生大量请求的情况下,导致上游一系列服务挂掉 就好像雪崩一样
为了解决雪崩 熔断器出现了
熔断器有三个状态:
具体的就看上面分享的那篇博客吧
三个状态之间的切换图如下
三步走如下:
一 引入Ocelot.Provider.Polly
二. ConfigureServices方法里加入
public virtual void ConfigureServices(IServiceCollection services)
{
services
.AddOcelot()
.AddPolly();
}
三 在ocelot.json里加入如下配置
"QoSOptions": {
"ExceptionsAllowedBeforeBreaking":3, //三次异常或超时后进行熔断
"DurationOfBreak":1000, //熔断1秒后可再次请求 此时熔断器处于 半开状态
"TimeoutValue":5000 //超时时间
}
我的配置文件代码:
{
"ReRoutes": [
{
"UseServiceDiscovery": true,
"DownstreamPathTemplate": "/{url}",
"DownstreamScheme": "http",
//"DownstreamHostAndPorts": [
// {
// "Host": "localhost",
// "Port": 59607
// }
//],
"UpstreamPathTemplate": "/{url}",
"UpstreamHttpMethod": [ "GET", "POST" ],
"LoadBalancerOptions": {
"Type": "RoundRobin"
},
"ServiceName": "hotel_api",
"RateLimitOptions": {
//"ClientWhitelist": [ ], //白名单里的客户端 请求不进行限流
"EnableRateLimiting": true, //开启限流
"Period": "1s",
"PeriodTimespan": 1, // 被限制了5s 后 可以再请求
"Limit": 10 //1s内 最多访问 1 次
},
"QoSOptions": {
"ExceptionsAllowedBeforeBreaking": 3,
"DurationOfBreak": 10000,
"TimeoutValue": 3000
},
"FileCacheOptions": {
"TtlSeconds": 10,
"Region": "hotel_api"
}
}
],
"GlobalConfiguration": {
"ServiceDiscoveryProvider": {
"Scheme": "http",
"Host": "localhost",
"Port": 8500,
"Type": "Consul"
},
"RateLimitOptions": {
"DisableRateLimitHeaders": false,
"QuotaExceededMessage": "To many ya", //被限制后的提示语
"HttpStatusCode": 999 //被限制后的 返回的状态码
}
}
}
经测试 没问题
这里说明一下 超时和异常均会发生熔断 熔断器打开后 当过了DurationOfBreak设定的时间后,此时熔断器是半开状态 可以请求 但是半开状态的第一次请求报异常或超时 则熔断器打开 当半开状态的第一次请求成功 则熔断器关闭
这里小伙伴们可能会有疑问了,熔断器如果一个接口导致熔断器打开 那么这个服务里的其他接口可以被访问吗? 经测试,可以 看来熔断器熔断粒度是到接口级别
这里使用ocelot进行熔断机制的配置绝对不是重点,只是一个知识点 ,重中之重是熔断器的作用以及原理 希望小伙伴们再搜一搜资料把熔断器的作用以及原理弄清楚
完毕