zoukankan      html  css  js  c++  java
  • 测试开发进阶——Spring cloud——理解——微服务中断路器模式理解(转载)

    假设有3个微服务,并且这3个微服务之间相互同步通信。

    当向微服务1发送一个请求,微服务1将调用微服务2进一步的微服务2会调用微服务3。

    如果所有服务正常的话,请求结果会从微服务3返回给微服务2,然后到微服务1。

    但可能有一些服务不可用。并非所有的服务都是可用的。

    如果微服务3故障了将会发生什么?

    请求将发送到微服务1和微服务2,当请求到微服务3会返回错误。

    现在,微服务2将接收到错误并将错误返回给微服务1,最后客户端接收到一个错误响应。这并不合适,因为客户端不想要接收到错误。

    需要以更合适的方式处理。

    也可能有其他的问题,如果微服务2有重试机制的话为了获得正常响应会向微服务3发送多次重试请求。如

    果微服务2重试5次。当微服务3因负载过重而返回错误的话,重试会导致微服务3返回更多错误。因此这里需要更好的方式处理。

    如何让服务变得更好?

    让我们向这个请求路径中添加断路器。假设我们在每个微服务中都实现了断路器。断路器有3种方式可以实现服务正常响应。

     

    缓存响应

    当请求发送到微服务1,然后发送到微服务2最后到微服务3。现在微服务2知道微服务3出现异常。

    微服务2中的断路器知道微服务3返回错误。断路器会将缓存中的响应返回。这意味着,每当我们从服务接收到错误时,我们可以配置断路器以返回缓存中的响应。

    缓存中的响应是之前请求成功的响应或服务没有故障时缓存的响应。因此,现在当服务失败时,我们实际上会得到缓存的响应。用户可以通过缓存响应接收返回码为200的成功响应。

     

     

    回退机制

    不返回缓存的响应,可以将发送到微服务3的请求重定向到其他类似的服务上进行处理。请求重定向到类似微服务3,就可以从第三方服务获得成功的响应,而不会得到任何错误。

    因此,当实际服务失败时,我们可以使用另一个服务替代故障服务。

     

     

    修复机制

     

    这里当一个请求来临时,微服务断路器保留微服务3的失败次数。在达到给定的失败次数之后,我们可以告诉微服务2上的断路器,停止向微服务3发送请求。

    让它恢复一段时间。

    我们也可以配置恢复时间。

    在此之后,任何针对微服务2的请求都不会调用微服务3,直到定义的时间间隔结束。

    现在我们可以使用缓存响应或回退机制返回响应。可以断开微服务3并让它恢复。

    如何才能恢复?

    • 如果队列中有任何等待的请求,它等待处理并结束。
    • 可以关闭故障服务并部署一个新实例,或者配置启动一个新实例。

     

     

    超过恢复时间后会如何?

    在某个超时后,微服务2将调用微服务3并检查响应如何。

    如果仍然失败,微服务2将继续返回缓存响应或使用回退机制。

    如果请求成功,那么微服务2缓存成功响应,并将响应返回给微服务1,并保持正确的请求路径。

     

     

    线路图

    • Closed:当一切正常,断路器处于关闭状态,所有请求经过服务。当请求失败次数超出阈值时,断路器触发处于Open状态。
    • Open:断路器在不执行函数的情况下对调用返回一个错误。
    • Half-Open:经过一个超时时间后,电路切换到半开状态,以测试潜在问题是否仍然存在。如果在这种半开状态下单个调用失败,断路器将再次触发。如果调用成功,断路器复位到正常关闭状态。


    如果微服务一切正常,断路器就处于Closed状态。

    如果现在微服务3失败,链路与微服务3断开连接,进入Open状态并开始返回缓存响应。

    经过一段延迟之后,再次调用微服务3,并进入半开状态,这实际是检查微服务3是否返回一个成功的响应。

    如果它返回一个成功的响应,可以进入Closed状态,如果仍然返回一个错误,我们可以进入Open状态。这是断路器的整个状态转移过程。

    服务熔断(Hystrix) 

      在微服务架构中通常会有多个服务层调用,基础服务的故障可能会导致级联故障,进而造成整个系统不可用的情况,这种现象被称为服务雪崩效应。

           服务雪崩效应是一种因“服务提供者”的不可用导致“服务消费者”的不可用,并将不可用逐渐放大的过程。

      熔断器的原理很简单,如同电力过载保护器。

           它可以实现快速失败,如果它在一段时间内侦测到许多类似的错误,会强迫其以后的多个调用快速失败,不再访问远程服务器,从而防止应用程序不断地尝试执行可能会失败的操作,使得应用程序继续执行而不用等待修正错误,或者浪费 CPU时间去等到长时间的超时产生。

           熔断器也可以使应用程序能够诊断错误是否已经修正,如果已经修正,应用程序会再次尝试调用操作。

    Hystrix 断路器机制

        断路器很好理解, 当 Hystrix Command 请求后端服务失败数量超过一定比例(默认 50%), 断路器会切换到开路状态(Open). 这时所有请求会直接失败而不会发送到后端服务

                . 断路器保持在开路状态一段时间后(默认 5 秒), 自动切换到半开路状态(HALF-OPEN). 这时会判断下一次请求的返回情况,

                 如果请求成功, 断路器切回闭路状态(CLOSED), 否则重新切换到开路状态(OPEN).

                 Hystrix 的断路器就像我们家庭电路中的保险丝, 一旦后端服务不可用, 断路器会直接切断请求链, 避免发送大量无效请求影响系统吞吐量, 并且断路器有自我检测并恢复的能力。 

  • 相关阅读:
    C语言字母频率统计
    C语言文件操作相关函数
    【蓝桥杯】历届试题 回文数字
    【蓝桥杯】历届试题 蚂蚁感冒
    【蓝桥杯】历届试题 地宫取宝
    【蓝桥杯】历届试题 分糖果
    【蓝桥杯】历届试题 兰顿蚂蚁
    JDK的安装和配置
    【蓝桥杯】历届试题 错误票据
    【蓝桥杯】历届试题 带分数
  • 原文地址:https://www.cnblogs.com/xiaobaibailongma/p/15356831.html
Copyright © 2011-2022 走看看