熔断

https://img2020.cnblogs.com/blog/420532/202008/420532-20200828113132885-307758786.png

目录为空，请插入标题（字体左侧）后点击刷新按钮

插件的大致内容

插件代码如下

local _M = {
    version = 0.1,
    priority = 0,
    name = "fuse_plugin",

}

local  config_local = require("core.config_local")
local fuse = require "demo.fuse.url_fuse"

function _M:init_worker(conf)
    ----初始化熔断器
    print("熔断器的初始化")
    fuse:setup(function(this)
        this.LIFETIME = 10
        this.FAILS_LIMIT = 10
        this.REQUEST_TIMEOUT =1
        this.FUSED_DURATION = 10
    end)
end

function _M:access(conf)

    ---运行阶段
    print("熔断器运行access")
    fuse:run_access()
end

function _M:log(conf)
    print("熔断器运行log")
    ---- 日志阶段
    fuse:run_log()
end



return _M

将 fuse_plugin.lua 放入 plugins/third 目录下

在 config.yaml中增加插件项目

plugins:

#path: E:\workspace-lua\luademo\conf #暂时没有用

names:

- "consul_plugin.lua" 暂时屏蔽别的插件 方便专门针对 熔断插件进行压测

\- "fuse_plugin.lua"

修改conf配置

在nginx.conf 我这里是nginx-lua.conf里增加dict

lua_shared_dict fuse_shard_dict 5m;

开始测试

新建location

location /coinsrv {
          proxy_pass http://127.0.0.1:8082/coinsrv;
          #  log_by_lua_file  /Users/zhangzw/Documents/workspace-lua/luademo/src/demo/filter/log_access.lua;

  }

新建模拟超时的java 服务

我们新建一个location 。 代理到我们的java 服务上

有一个接口有几率出现非常长的超时

还有一个接口时都是正常的.

我们希望在第一个接口的超时不要印象第二个接口的访问.

这个java 服务有几率出现超时.我们在controller 的里面 增加 Thread.sleep的操作 ,然后我们去观察 整个服务会不会出现

阻塞的java 代码如下

@GetMapping(value = "normal")

public ResultDTO normal(HttpServletRequest request) {

SessionUser sysUser = this.getUser(request);

return this.getResult(sysUser);

}

@GetMapping(value = "block")

public ResultDTO block(HttpServletRequest request) {

try {

    Thread.*sleep*(10000);

} catch (InterruptedException e) {

    e.printStackTrace();

}

SessionUser sysUser = this.getUser(request);

return this.getResult(sysUser);

}

curl http://127.0.0.1:8082/coinsrv/app/user/block

curl http://127.0.0.1:8082/coinsrv/app/user/normal

写一个测试类进行压测和收集测试结果

然后启动一个线程去发送大量并发,然后确保 normal组的请求都不受影响,都能正常完成,

block组的请求也都能熔断掉,拿到熔断掉结果.

我们设立两组统计数字记录 请求成功的数目

static int normalSuccessCount=0;

static int blockSuccCount=0;

因为我们的熔断策略时1分钟内只允许超时5次,所以程序在一开始的10秒内可能会线程打满导致,normal的接口请求失败,

但是随着10秒后熔断策略开始生效,很快服务将恢复正常

超时时间的设置

这个时间限制,将由网关的超时时间决定

修改nginx.conf 配置

本次实验为了快速试错,我们将超时时间设置为2s

tcp_nodelay on;

client_header_timeout 2;

client_body_timeout 2;

send_timeout 2;

proxy_read_timeout 2; # 秒

主要是上面的黄色部分,加了之后超时时间都变成了2s了

需要设置nginx的超时时间

用postman 进行测试

第一次出现两秒超时

初始化1000个 。 每种类型500个请求

后续 每 2s 发送 1000个

后续 每 2s 发送 1000个

开始测试 最后来统计真正的 请求成功数目

5000个请求

normalSuccessCount204 正常请求的

blockSuccCount0

fuseCount3879 熔断的

normalSuccessCount3949

blockSuccCount0

fuseCount999