本篇文章参考【Micro In Action(七)：熔断与限流】

https://medium.com/@dche423/m…

@dche423 写的太好了，这里仅做局部摘录介绍

熔断

go micro 封装了 hystrix-go，gobreaker，都在 plugins 下

上面是 hystrix 的例子

import (
    ...
    "github.com/micro/go-plugins/wrapper/breaker/hystrix/v2"
    ...
)
func main(){
    ...
    // New Service
    service := micro.NewService(micro.Name("com.foo.breaker.example"),
        micro.WrapClient(hystrix.NewClientWrapper()),
    )
    // Initialise service
    service.Init()
    ...
}

他的默认值超时工夫是 1000 毫秒，最大并发数是 10

    // DefaultTimeout is how long to wait for command to complete, in milliseconds
    DefaultTimeout = 1000
    // DefaultMaxConcurrent is how many commands of the same type can run at the same time
    DefaultMaxConcurrent = 10

其余参数请见官网，https://github.com/afex/hystr…

如果须要批改其余参数，能够在服务 service.init()后设置

import (
    ...
    hystrixGo "github.com/afex/hystrix-go/hystrix"
    "github.com/micro/go-plugins/wrapper/breaker/hystrix/v2"
    ...
)
func main(){
    ...
    // New Service
    service := micro.NewService(micro.Name("com.foo.breaker.example"),
        micro.WrapClient(hystrix.NewClientWrapper()),
    )
    // Initialise service
    service.Init()
    hystrix.DefaultMaxConcurrent = 3//change concurrrent to 3
    hystrix.DefaultTimeout = 200 //change timeout to 200 milliseconds
    ...
}

DefaultMaxConcurrent 限度的是 hystrix 中的 command

看看插件中是怎么定义的 Call

func (c *clientWrapper) Call(ctx context.Context, req client.Request, rsp interface{}, opts ...client.CallOption) error {return hystrix.Do(req.Service()+"."+req.Endpoint(), func() error {return c.Client.Call(ctx, req, rsp, opts...)
    }, nil)
}

都是 return 的 hystrix.Do(), 他的参数没有蕴含节点信息，这意味着对于同一个服务，部署单个还是多个节点对于熔断来说是没有区别的，所有节点都共享一组限度

事实我的项目中，不同服务的负载能力是不同的，go micro 能够为不同的服务设置不同的熔断限度

hystrix.ConfigureCommand("com.serviceA.methodFoo",
    hystrix.CommandConfig{
        MaxConcurrentRequests: 50,
        Timeout:               10,
    })
hystrix.ConfigureCommand("com.serviceB.methodBar",
    hystrix.CommandConfig{Timeout: 60,})

小结：熔断性能作用于客户端，设置失当阈值当前，它能够保障客户端资源不会被耗尽 —— 哪怕是它所依赖的服务处于不衰弱的状态，也会疾速返回谬误，而不是让调用方长时间期待。

限流

在服务端失效，它的作用是爱护服务器：防止服务器因为客户端的疯狂调用而整体垮掉。

go micro 封装了 2 个限流包 ratelimiter/uber，ratelimiter/ratelimit，都在 plugins 下

这里演示 uber 的 https://github.com/micro/go-p…

package main

import (
    ...
    limiter "github.com/micro/go-plugins/wrapper/ratelimiter/uber/v2"
    ...
)

func main() {
    const QPS = 100
    // New Service
    service := micro.NewService(micro.Name("com.foo.srv.hello"),
        micro.Version("latest"),
        micro.WrapHandler(limiter.NewHandlerWrapper(QPS)),
    )

    ...
}

默认 QPS 下限为 100。这个限度由此服务的所有 handler 所有 method 共享。换句话说，此限度的作用域是服务级别的。

其余设置和熔断的设置相似，具体应用请见官网的文档。

总结：

熔断的出发点是爱护客户端，不被内部服务的问题所连累，永远疾速响应（哪怕失去一个谬误，也好于长时间期待）。永远防止资源的适度耗费。

限流的出发点是爱护服务器。只解决本人能力之内的流量，实现过载爱护。当流量超过设定限度时立刻返回谬误。

go micro 剖析系列文章
go micro server 启动剖析
go micro client
go micro broker
go micro cmd
go micro config
go micro store
go micro registry
go micro router
go micro runtime
go micro transport
go micro web
go micro registry 插件 consul
go micro plugin
go micro jwt 网关鉴权
go micro 链路追踪
go micro 熔断与限流
go micro wrapper 中间件
go micro metrics 接入 Prometheus、Grafana