• kong网关熔断插件


    Request Termination经常被作为kong的熔断器使用。以下在自建的konga管理界面里进行了测试配置
    在这里插入图片描述

    配置参数如下:

    在这里插入图片描述

    客户端发起请求,可以通过response进行验证,可以看到响应的状态码和报文都能生效。
    在这里插入图片描述
    在这里插入图片描述

    以上配置是基于kong 0.12.3,可以针对consumer、router、global3个不同的范围维度进行配置。

    和之前理解上的熔断器功能相比,整体感觉不够智能。

    熔断器,经常被比喻为家里的保险丝。保险丝应该是在家里电器功率过大时断开以保证用电安全的。而这个插件的使用上,感觉是在知道了系统负载高的情况下再进行熔断,以阻止请求访问到后台服务器。这就好像是在感知家里电器马上负荷过高时提前自己把保险丝熔断了。

    熔断器,应该需要对单位时间内的服务请求进行失败率统计,这个失败可能是超时时间引起或者是异常状态码引起。将熔断器状态分为三种:
    1.闭合状态closed(服务完全正常,请求都可以正常请求)
    2.断开状态open(服务完全关闭,请求全部被阻断)
    3.半打开状态half-open(只开放部分请求访问,如果单位时间内统计正常则进入到闭合状态closed,否则进入断开状态open。

    在这里插入图片描述

    上面对插件的测试中并未发现有类似功能,所以整体评价不够满意。
    因个人能力有限,如发现有不对之处烦请指出更改。

    参考:

    kong插件应用:https://blog.csdn.net/luanpeng825485697/article/details/85326831
    kong官网Request Termination插件:https://docs.konghq.com/hub/kong-inc/request-termination/
    极客时间《深入浅出分布式技术原理》专栏《09 - 雪崩(一):熔断,让故障自适应地恢复》

    资源交流请私信~

  • 相关阅读:
    vue3的ref,reactive的使用和原理解析
    MySQL 行级锁(行锁、临键锁、间隙锁)
    react mobx
    Leetcode 349:两个数组的交集
    恢复出厂设置,手机数据还能“复活”?
    GitHub 开源大厂缓存架构 Redis 优化的文档被警告,900 页全是宝贝
    Linux的进程管理
    死锁产生的条件及其预防
    alsa音频pcm设备之i2c调试
    实验四:面向对象编程实验(2)—封装、继承和包
  • 原文地址:https://blog.csdn.net/wen3qin/article/details/126048102