关于微服务:熔断器在微服务中的使用

在微服务中服务间的互相调用和一栏十分常见。一个上游的服务呈现了问题可能会影响这个调用端的所有申请或者性能。这是咱们不想看到的状况。为了避免被调用服务呈现问题进而导致调用服务呈现问题，所以调用服务须要进行自我爱护，二爱护的罕用伎俩就是熔断。

熔断的原理相似于生存中的保险丝，为了当电路呈现短路或者超负荷的状况产生。达到了某一个条件和阈值之后就会断开。从而保障电路中的电器不受上海。
然而由此也呈现了一个问题，保险丝一旦断开之后就须要手动的更换才能够再次失常工作，然而在运行的我的项目咱们不可能实时的通过人工去干涉。所以熔断机制机制中还须要有检测和判断是否回复熔断。这种判断机制有很多种，能够是 GoogleSre 中的通过胜利和失败的比例得出一个概率。或者通过事件窗口内胜利和失败的数量来判断是否复原。

在数据库中咱们晓得有表锁行锁，粒度较小的锁能让数据不受过多的影响。在熔断中也是一样，咱们熔断的颗粒度能够使一个服务、一个域名、甚至于某一个特定的办法。这些能够依据咱们的业务需要去判断，也不是说粒度越细就越好。

敞开(closed): 敞开状态下没有触发断路爱护，所有的申请都失常通行
关上(open): 当谬误阈值触发之后，就进入开启状态，这个时候所有的流量都会被节流，不运行通行
半关上(half-open): 处于关上状态一段时间之后，会尝试尝试放行一个流量来探测以后 server 端是否能够接管新流量，如果这个没有问题就会进入敞开状态，如果有问题又会回到关上状态

本文不在于介绍熔断本生，次要是记录一下熔断在各个 Go 微服务中的实现和应用。在参考了一些文章和本人实际之后，会从三个方面做介绍。（本文不过多的理解熔断器的实现代码，只是形容它在微服务框架内的应用）

单纯的应用熔断器，不牵扯微服务。（hystrix-go）
熔断在 B 站微服务框架 kratos 中的利用和如何本人实现一个熔断并应用在 Kratos 中。
熔断器在 gozero 中的利用。

熔断器中比拟经典的工夫是 hystrix，go 也有对应的版本：hystrix-go。
先举一个例子：在这个例子中咱们能够看到在 server 这个函数中应用 gin 启动了一个 http 的服务，在前 200ms 的申请都会返回 500 谬误，之后的申请都会返回 200 的 http 状态码。
而后创立了一个熔断器，这个熔断器的 name 为 test，咱们能够设置的时几个参数

Timeout：熔断器的超时工夫
MaxConcurrentRequests：最大并发量
RequestVolumeThreshold：一个统计窗口 10 秒内申请数量，达到这个申请数量后才去判断是否要开启熔断
SleepWindow：熔断器被激活之后，多久能够尝试服务是否可用单位为毫秒
ErrorPercentThreshold：谬误百分比，在窗口工夫内，申请数量和谬误数量的比例如果达到了这个阈值，则会启动熔断器。

客户端代码中，咱们能够看到，会申请 http 服务 20 次，每次申请耗费 100ms。那么依照这个的状况来看钱 2 次的申请客户端返回的时 500 谬误，然而在窗口工夫内并没有打到 20%。所以熔断器并没有开启，等到申请打到 10 次的时候就达到了咱们设置的错误率 20% 这个阈值。这个时候熔断器会被激活，等过了 500 毫秒也就是 5 次申请之后，又会去失常的发出请求。

在这个例子中咱们须要留神的有两点：

之前文中提到的颗粒度的问题，在 hystrix-go 中一个 commandName 就是一个熔断器，是依据创立时候的 name 字段来做辨别的。咱们能够依据不同的业务和维度自定义这个 name，能够是一个域名也能够是一个具体的办法等。这个须要咱们本人用逻辑去实现。

在这个例子中咱们能够发现，当窗口期内错误率达到阈值之后会切断所有的这个 command 下的申请，如果颗粒度不是很细的状况下回导致这个维度下所有的申请都没方法发送胜利。这个问题能够看一下上面的 GoogleSre 的做法。

package main

import (
    "fmt"
    "net/http"
    "time"

    "github.com/afex/hystrix-go/hystrix"
    "github.com/gin-gonic/gin"
    "gopkg.in/resty.v1"
)

func server() {e := gin.Default()
    start := time.Now()
    e.GET("/ping", func(ctx *gin.Context) {if time.Since(start) < 201*time.Millisecond {ctx.String(http.StatusInternalServerError, "pong")
            return
        }
        ctx.String(http.StatusOK, "pong")
    })

    err := e.Run(":8080")
    if err != nil {fmt.Printf("START SERVER OCCUR ERROR, %s", err.Error())
    }
}

func main() {go server()

    hystrix.ConfigureCommand("test", hystrix.CommandConfig{
        // 执行 command 的超时工夫
        Timeout: 10,

        // 最大并发量
        MaxConcurrentRequests: 100,

        // 一个统计窗口 10 秒内申请数量
        // 达到这个申请数量后才去判断是否要开启熔断
        RequestVolumeThreshold: 10,

        // 熔断器被关上后
        // SleepWindow 的工夫就是管制过多久后去尝试服务是否可用了
        // 单位为毫秒
        SleepWindow: 500,

        // 谬误百分比
        // 申请数量大于等于 RequestVolumeThreshold 并且错误率达到这个百分比后就会启动熔断
        ErrorPercentThreshold: 20,
    })

    // 模仿 20 个客户端申请
    for i := 0; i < 20; i++ {_ = hystrix.Do("test", func() error {resp, _ := resty.New().R().Get("http://localhost:8080/ping")
            if resp.IsError() {return fmt.Errorf("err code: %s", resp.Status())
            }
            return nil
        }, func(err error) error {fmt.Println("fallback err:", err)
            return err
        })
        time.Sleep(100 * time.Millisecond)
    }

}

Kratos 是 B 站开源的一套轻量级的 Go 微服务框架，蕴含大量微服务相干框架以及工具。其中蕴含日志、服务注册发现、路由负载平衡当然也蕴含熔断器这个比拟常见的性能。

大多数的微服务框架提供的都是能够自在替换插件的。在 Kratos 中，默认有一套熔断的实现。如果无奈满足你的也无需要的话，你也能够本人实现一套，只有类继承了 CircuitBreaker 这个接口，接口如下：

// CircuitBreaker is a circuit breaker.
type CircuitBreaker interface {Allow() error // 判断申请是否容许发送, 如果返回 error 则示意申请被回绝
  MarkSuccess() // 标记申请胜利
    MarkFailed() // 标记申请失败}

只有实现了上述三个函数，就能够齐全替换 Kratos 原有的熔断逻辑了。

在 Client 申请中应用熔断器：

// http
conn, err := http.NewClient(context.Background(),
    http.WithMiddleware(circuitbreaker.Client(),
    ),
    http.WithEndpoint("127.0.0.1:8000"),
)
// grpc 
conn,err := transgrpc.Dial(context.Background(), 
    grpc.WithMiddleware(circuitbreaker.Client(),
    ),
  grpc.WithEndpoint("127.0.0.1:9000"),
)

max(0, frac{requests – K * accepts}{requests + 1})
算法如上所示，这个公式计算的是申请被抛弃的概率

requests: 一段时间的申请数量
accepts: 胜利的申请数量
K：倍率，K 越小示意越激进，越小示意越容易被抛弃申请
这个算法的益处是不会间接一刀切的抛弃所有申请，而是计算出一个概率来进行判断，当胜利的申请数量越少，K 越小的时候 $requests – K * accepts$ 的值就越大，计算出的概率也就越大，示意这个申请被抛弃的概率越大。

Allow 函数中，通过下面介绍的 GoogleSre 算法。先判断胜利的和总的申请数量，通过概率判断出是否触发熔断。

func (b *sreBreaker) Allow() error {
    // 统计胜利的申请，和总的申请
    success, total := b.summary()

    // 计算以后的成功率
    k := b.k * float64(success)
    if log.V(5) {log.Info("breaker: request: %d, succee: %d, fail: %d", total, success, total-success)
    }
    // 统计申请量和成功率
    // 如果 rps 比拟小，不触发熔断
    // 如果成功率比拟高，不触发熔断，如果 k = 2，那么就是成功率 >= 50% 的时候就不熔断
    if total < b.request || float64(total) < k {if atomic.LoadInt32(&b.state) == StateOpen {atomic.CompareAndSwapInt32(&b.state, StateOpen, StateClosed)
        }
        return nil
    }
    if atomic.LoadInt32(&b.state) == StateClosed {atomic.CompareAndSwapInt32(&b.state, StateClosed, StateOpen)
    }

    // 计算一个概率，当 dr 值越大，那么被抛弃的概率也就越大
    // dr 值是，如果失败率越高或者是 k 值越小，那么它越大
    dr := math.Max(0, (float64(total)-k)/float64(total+1))
    drop := b.trueOnProba(dr)
    if log.V(5) {log.Info("breaker: drop ratio: %f, drop: %t", dr, drop)
    }
    if drop {return ecode.ServiceUnavailable}
    return nil
}

// 通过随机来判断是否须要进行熔断
func (b *sreBreaker) trueOnProba(proba float64) (truth bool) {b.randLock.Lock()
    truth = b.r.Float64() < proba
    b.randLock.Unlock()
    return
}

须要留神的一点是，在 Kratos 中的熔断器应用一个 Group 对象封装的，通过申请的 path 的维度来作为熔断的的维度。比方一次申请是 http://192.168.0.1:8080/hello…，那么这个熔断器的维度就是 helloworld.v1.Greeter/SayHello。每一个这样的 string 都是一个熔断器，其中通过 map 来贮存。咱们能够看一下 group 这个对象的定义

type Group struct {new  func() interface{}
    vals map[string]interface{}
    sync.RWMutex
}

首先咱们须要实现 Kratos 定义熔断器的接口 CircuitBreaker，上面能够看一下最简略的实现，其中没有任何的算法只是单纯的实现：

package mybreak

import (
    "context"
    "github.com/go-kratos/kratos/v2/errors"
    "github.com/go-kratos/kratos/v2/middleware"
)

var ErrNotAllowed = errors.New(503, "MyBreak", "request failed due to circuit breaker triggered")

type MyBreaker struct {Count int}

func NewMyBreaker() *MyBreaker {r := &MyBreaker{Count: 0}
    return r
}

func (mb *MyBreaker) Allow() error {return nil}

func (mb *MyBreaker) MarkSuccess() {}

func (mb *MyBreaker) MarkFailed() {}

func Client() middleware.Middleware {opt := NewMyBreaker()
    return func(handler middleware.Handler) middleware.Handler {return func(ctx context.Context, req interface{}) (interface{}, error) {
            if opt.Count > 10 {return nil, ErrNotAllowed}

            reply, err := handler(ctx, req)
            if err != nil && (errors.IsInternalServer(err) || errors.IsServiceUnavailable(err) || errors.IsGatewayTimeout(err)) {opt.MarkFailed()
            } else {opt.MarkSuccess()
            }
            return reply, err
        }
    }
}

从上述代码中能够看到，咱们只有实现了接口中的三个函数之后。再封装一个中间件之后就能够完满的替换掉 Kratos 中默认实现的熔断器了。再次留神，下面的实现是没有任何逻辑在其中的，只是为了实际替换原有框架中的熔断器。

gozero 也是当初大家比拟关注的一款 go 语言微服务框架，当初 gozero 的 git 星曾经达到 19k。社区也很沉闷，那么在这个微服务框架中必定也会带有熔断器，并且也有本人的默认实现。值的一提的是 gozero 的的熔断器也是基于 googlesre 实现的。
gozero 的熔断器是基于框架中的拦截器实现的。咱们晓得，熔断器次要是用来爱护调用端，调用端在发动申请的时候须要先通过熔断器，而客户端拦截器正好兼具了这个这个性能，所以在 zRPC 框架内熔断器是实现在客户端拦截器内。gozero 的拦截器原理图如下：

具体代码实现为：

func BreakerInterceptor(ctx context.Context, method string, req, reply interface{},
    cc *grpc.ClientConn, invoker grpc.UnaryInvoker, opts ...grpc.CallOption) error {
  // 基于申请办法进行熔断
    breakerName := path.Join(cc.Target(), method)
    return breaker.DoWithAcceptable(breakerName, func() error {
    // 真正发动调用
        return invoker(ctx, method, req, reply, cc, opts...)
    // codes.Acceptable 判断哪种谬误须要退出熔断谬误计数
    }, codes.Acceptable)
}

本文就不过多的形容 gozero 中是如何实现熔断的了，外围就是应用了 Google sre 算法。

我认为在 gozero 中，你能够模拟 gozero 本身的实现做一个实现本人逻辑的熔断器。或者能够利用截断器的性能在 breakerInterceptor 中间接实现比方间接用 hystrix-go 去实现都是能够的。

本文参考：
gozero
go 微服务熔断
Kratos

关于微服务:熔断器在微服务中的使用

熔断

熔断的原理

熔断的颗粒度

熔断器的状态

熔断在微服务中的应用

熔断在 Go 中的应用

Kratos 中熔断器的应用

接口

应用办法

GoogleSre 过载算法

外围函数

如何实现一个自定义的熔断器，并且在 Kratos 中应用

熔断器在 gozero 中的利用

如何在 gozero 中实现本人的熔断机制