当前位置: 代码网 > it编程>编程语言>Asp.net > .Net Core微服务网关Ocelot超时、熔断、限流

.Net Core微服务网关Ocelot超时、熔断、限流

2024年05月15日 Asp.net 我要评论
基本概念超时、熔断、限流听起来好像很远,但实际上用在方方面面。很多人可能还搞不懂熔断是做什么,其实可以把熔断理解为一种防护措施。做个假设,在微服务体系下,某个下游服务响应很慢,然后随着时间推移,会有越

基本概念

超时、熔断、限流听起来好像很远,但实际上用在方方面面。很多人可能还搞不懂熔断是做什么,其实可以把熔断理解为一种防护措施。做个假设,在微服务体系下,某个下游服务响应很慢,然后随着时间推移,会有越来越多的请求堆积,从而会导致各种严重后果,单说连接池大量被占用就很要命。更不用说服务之间还要相互调用,你等我10秒,我等你5秒,不仅毫无体验感,高可用也就成了空谈。不如换个思路:与其等10秒返回一个请求失败,不如马上就返回请求失败。这样一来,请求堆不起来,资源也有时间释放或者恢复。这个动作就叫熔断,或者叫短路。有点像家用电路,一旦有漏电直接跳闸,最大程度保障安全。

熔断的概念基本有了,接下来给网关集成。这里需要用到一个叫polly的库。

简单说下它:polly由.net实现,是一个非常优秀的库,主要提供重试、熔断、超时、恢复等功能,当然今天主角不是它,想研究的可以去官方看下:https://github.com/app-vnext/polly

接下来开始集成。首先添加nuget包:

然后注册相关服务:

public void configureservices(iservicecollection services)
        {
            services.addocelot()
                .addpolly()
                .addconsul()
                .addconfigstoredinconsul();
        }

接下来在配置文件添加节点:

"qosoptions": {
    "exceptionsallowedbeforebreaking":3,
    "durationofbreak":10000,
    "timeoutvalue":5000
}
  • exceptionsallowedbeforebreaking:阈值,当转发到下游的服务连续出现的异常次数达到阈值就会触发熔断。必须和durationofbreak一起设置。
  • durationofbreak:熔断持续时间,单位毫秒。必须和exceptionsallowedbeforebreaking一起设置。
  • timeoutvalue:限定时间内未响应的请求直接超时,单位毫秒。可以单独设置
  • tips:ocelot默认超时时间是90秒,90秒啊

然后写一个方法,休眠10秒:

[httpget]
        public iactionresult timeout()
        {
            system.threading.thread.sleep(10000);
            return ok();
        }

超时

准备工作做完了,现在调用timeout方法:

方法是休眠10秒,但是等待5秒左右就主动返回了503,说明超时的设置已经生效。

熔断

当转发到下游某个服务的请求连续出现超时情况时,网关就会判断是否达到阈值,如果是就触发熔断,在此期间的请求统一返回503,熔断时间过了以后恢复正常。按上面配置来看:连续超时3次会触发熔断,熔断持续10秒。我们仍然调用timeout方法,连续3次以后:

没有触发熔断时,只能等过5秒自动超时,很显然现在已经触发了超时,所以在200毫秒就直接返回了结果。熔断期间访问别的方法也会是503:

和开头写的一样,熔断和电路短路跳闸是思路是一样的,就算家里n条线只有1条漏电,那还是会跳闸整个屋子不能用电,这种做法最大程度上保证了程序安全。

限流

假设现在只能承载1万并发,那么过来5万并发会怎么样?一般情况下,只要持续时间稍久一些,服务基本全都挂了。这种情况在生产环境难免会发生,毕竟业务量也无法测算那么精准。所以为了提高可用性,瞬时请求超过最大阈值,其他的全都忽略才能保证服务安全可用。让客户等下一次请求,总好过服务挂了没的请求。

限流也是配置就能实现,在路由中新增下面的节点:

"ratelimitoptions": {
    "clientwhitelist": [],
    "enableratelimiting": true,
    "period": "1s",
    "periodtimespan": 1,
    "limit": 1
}
  1. clientwhitelist:客户端白名单,白名单不受限流规则限制。
  2. enableratelimiting:是否启用限流。
  3. period:周期,单位有s(秒)、m(分)、h(时)、d(天),比如1h
  4. periodtimespan:多少秒后重试。
  5. limit:周期内允许多少个请求。

想要更精细的控制,还可以在global部分添加这些:

"ratelimitoptions": {
  "disableratelimitheaders": false,
  "quotaexceededmessage": "customize tips!",
  "httpstatuscode": 999,
  "clientidheader" : "test"
}
  • disableratelimitheaders:是否禁用x-rate-limit、retry-after标头。
  • quotaexceededmessage:触发限流时返回的消息。
  • httpstatuscode:触发限流时返回的http状态码(一般会写429)。
  • clientidheader:用来识别客户端的标头。
  • tips:disableratelimitheaders中提到的x-rate-limit、retry-after:x-rate-limit——标准时间内允许多少个请求,retry-after——触发限流以后多久可以重试。

接下来修改我的配置:

"ratelimitoptions": {
        "clientwhitelist": [ "myclient" ],
        "enableratelimiting": true,
        "period": "1s",
        "periodtimespan": 10,
        "limit": 1
      }

修改全局配置:

"ratelimitoptions": {
      "disableratelimitheaders": false,
      "quotaexceededmessage": "123123",
      "httpstatuscode": 429,
      "clientidheader": "test"
    }

按配置来看,我设置1秒内最多允许1个请求,超过就触发限流。之后的请求都会返回429和123123,持续10秒。来试试:

等待10秒后再次请求,恢复正常:

白名单

白名单里的客户端是不会受到限流限制的。按照配置添加请求头,就可以被白名单识别:

请求时添加这个请求头,无论怎么刷都不会被限流。

超时、熔断、限流的必要性和好处是不言而喻的,但是上生产一定要注意配置的合理性,充分综合业务场景和需要才是王道,毕竟技术如果不解决问题那就毫无意义。

以上就是本文的全部内容,希望对大家的学习有所帮助,也希望大家多多支持代码网。

(0)

相关文章:

版权声明:本文内容由互联网用户贡献,该文观点仅代表作者本人。本站仅提供信息存储服务,不拥有所有权,不承担相关法律责任。 如发现本站有涉嫌抄袭侵权/违法违规的内容, 请发送邮件至 2386932994@qq.com 举报,一经查实将立刻删除。

发表评论

验证码:
Copyright © 2017-2025  代码网 保留所有权利. 粤ICP备2024248653号
站长QQ:2386932994 | 联系邮箱:2386932994@qq.com