【重试】经验总结

一、微服务架构下，为什么需要重试

　　在微服务架构中，一个完整的服务被拆分成多个小的服务，小服务之间通过rpc进行调用，不可避免会出现暂时性的错误，包括网络抖动、访问资源超时、因gc或瞬时流量过大等原因导致的服务暂时不可用等等。这些错误都属于暂时性的，并且可以自己修复，通常重新请求一遍即可解决问题。由此看出，合理的重试确实可以提高服务的稳定性。

二、现状分析

情况一：

　　无重试，下游服务的稳定性直接决定了上游服务的稳定性，且对网络抖动等暂时性错误也容错性较低。

情况二：

　　用for循环进行重试。

func Retry(tryTimes int, sleep time.Duration, callback func() (map[string]interface{}, error)) map[string]interface{} {
    for i := 1; i <= tryTimes; i++ {
        ret, err := callback()
        if err == nil {
            return ret
        }
        if i == tryTimes {
            panic(fmt.Sprintf("error info: %s", err.Error()))
            return nil
        }
        time.Sleep(sleep)
    }
    return nil
}

情况三：

func Retry(attempts int, sleep time.Duration, fn func() error) error {
    if err := fn(); err != nil {
        if s, ok := err.(stop); ok {
            return s.error
        }

        if attempts--; attempts > 0 {
            logger.Warnf("retry func error: %s. attemps #%d after %s.", err.Error(), attempts, sleep)
            time.Sleep(sleep)
            return Retry(attempts, 2*sleep, fn)
        }
        return err
    }
    return nil
}

type stop struct {
    error
}

func NoRetryError(err error) stop {
    return stop{err}
}

为什么有些代码不重试？——指数增长问题

　　在很多代码中，会看到基本上都没有重试逻辑，大家为什么不写重试逻辑呢？主要是因为重试有放大故障的风险。

　　举个例子，重试会增加下游服务的负担。假设A服务调用B服务，重试次数设置为R(包含首次请求)，当B服务高负载时很可能调用失败，这时A服务调用失败会重试调用B，B服务的被调用量快速增大，最坏情况下会放大到R倍，很容易让B服务的负载继续升高，直到B服务挂掉。更可怕的是，重试还会存在链路放大的效应。如下图所示：

　　假设现在的场景是ServiceA调用ServiceB，ServiceB又调用ServiceC。如果ServiceB调用ServiceC重试3次都失败了，这是ServiceB会给ServiceA返回失败。但是ServiceA也有重试逻辑，这样算起来，ServiceC就会被重试调用了9次，实际的调用量是指数级增长。假设正常访问量是x，整个链路一共有y层，每层的重试次数是R，那么最大访问量是x*R^(y-1)。这种指数级增长的效应很可怕，可能会导致链路上很多服务被打挂，从而导致整个服务雪崩。

　　另外，写重试逻辑也会比较麻烦，在一些不得不重试的场景下(如调用第三方服务经常失败)，我们可能只是写一个简单的for循环来实现重试逻辑，这样既不安全又不灵活，还降低了代码的可读性。并且每次调整都需要重新部署，重新上线。

退避算法

　　对于一些暂时性的错误，如网络抖动等，可能立即重试还是会失败，通常等待一小会儿再重试的话成功率会较高，决定多久之后再重试的方法叫做退避算法。主要的退避算法有以下几种：​

　　线性退避：每次等待固定时间后重试​

　　随机退避：在一定范围内等待一个随机时间后重试​

　　指数退避：连续重试时，每次等待时间都是前一次的倍数​

　　综合退避：如线性退避 + 随机抖动 或者 指数退避 + 随机抖动

三、如何合理地重试

　　谷歌的SRE的第254页是这样描述的：

　　1、上游对下游的重试次数最多是 3 次；理论上 3 次没成功继续重试的概率很低。

　　2、重试的次数最多占成功次数的 10%，也就是说如果成功调用的 QPS 是 100，那么最多能重试 10 次，下游最多承受平常 1.1 倍的 QPS。这能防止下游出问题，上游暴力重试效果不好，而且还可能造成雪崩。

　　3、需要防止重试次数指数增长的问题。

　　下面介绍一些go的常用重试代码库。

Retry-go：https://github.com/giantswarm/retry-go

Options

type retryOptions struct {​ 
    Timeout         time.Duration         // 超时​ 
    MaxTries        int                   // 重试次数​
 ​   Checker         func(err error) bool  // 判断是否重试​ 
    Sleep           time.Duration         // 间隔​ 
    AfterRetry      func(err error)       // 每次Retry后调用​ ​   
    AfterRetryLimit func(err error)       // 最后一次Retry后执行（如果未失败不执行）​ 
}​ 
​// Defaults:​
​//  Timeout = 15 seconds​ 
​//  MaxRetries = 5​ 
​//  Checker = errgo.Any​ 
//  Sleep = No sleep

特点：

• 只支持线性退避算法。
• 可以定义超时时间。
• 可以在每次重试后执行自定义的逻辑，例如打印日志等。

go-resty

　　先看下go-resty在发送HTTP请求时，申请重试的实现：

// Execute method performs the HTTP request with given HTTP method and URL
// for current `Request`.
//         resp, err := client.R().Execute(resty.GET, "http://httpbin.org/get")
func (r *Request) Execute(method, url string) (*Response, error) {
    var addrs []*net.SRV
    var resp *Response
    var err error

    if r.isMultiPart && !(method == MethodPost || method == MethodPut || method == MethodPatch) {
        return nil, fmt.Errorf("multipart content is not allowed in HTTP verb [%v]", method)
    }

    if r.SRV != nil {
        _, addrs, err = net.LookupSRV(r.SRV.Service, "tcp", r.SRV.Domain)
        if err != nil {
            return nil, err
        }
    }

    r.Method = method
    r.URL = r.selectAddr(addrs, url, 0)

    if r.client.RetryCount == 0 {
        resp, err = r.client.execute(r)
        return resp, unwrapNoRetryErr(err)
    }

    attempt := 0
    err = Backoff(
        func() (*Response, error) {
            attempt++

            r.URL = r.selectAddr(addrs, url, attempt)

            resp, err = r.client.execute(r)
            if err != nil {
                r.client.log.Errorf("%v, Attempt %v", err, attempt)
            }

            return resp, err
        },
        Retries(r.client.RetryCount),
        WaitTime(r.client.RetryWaitTime),
        MaxWaitTime(r.client.RetryMaxWaitTime),
        RetryConditions(r.client.RetryConditions),
    )

    return resp, unwrapNoRetryErr(err)
}

重试流程：

　　梳理 Execute(method, url) 在申请时的重试流程：

　　1、如果没有设置重试次数，执行 r.client.execute(r) ：间接申请 Request ， 返回 Response 和 error

　　2、如果 r.client.RetryCount 不等于0 ，执行 Backoff() 函数

　　3、Backoff() 办法接管一个解决函数参数，依据重试策略， 进行 attempt 次网络申请， 同时接管 Retries()、WaitTime()等函数参数

Backoff函数

　　重点看下 Backoff() 函数做了什么动作，代码如下：

// Backoff retries with increasing timeout duration up until X amount of retries
// (Default is 3 attempts, Override with option Retries(n))
func Backoff(operation func() (*Response, error), options ...Option) error {
    // Defaults
    opts := Options{
        maxRetries:      defaultMaxRetries,
        waitTime:        defaultWaitTime,
        maxWaitTime:     defaultMaxWaitTime,
        retryConditions: []RetryConditionFunc{},
    }

    for _, o := range options {
        o(&opts)
    }

    var (
        resp *Response
        err  error
    )

    for attempt := 0; attempt <= opts.maxRetries; attempt++ {
        resp, err = operation()
        ctx := context.Background()
        if resp != nil && resp.Request.ctx != nil {
            ctx = resp.Request.ctx
        }
        if ctx.Err() != nil {
            return err
        }

        err1 := unwrapNoRetryErr(err)           // raw error, it used for return users callback.
        needsRetry := err != nil && err == err1 // retry on a few operation errors by default

        for _, condition := range opts.retryConditions {
            needsRetry = condition(resp, err1)
            if needsRetry {
                break
            }
        }

        if !needsRetry {
            return err
        }

        waitTime, err2 := sleepDuration(resp, opts.waitTime, opts.maxWaitTime, attempt)
        if err2 != nil {
            if err == nil {
                err = err2
            }
            return err
        }

        select {
        case <-time.After(waitTime):
        case <-ctx.Done():
            return ctx.Err()
        }
    }

    return err
}

　　梳理 Backoff() 函数的流程：

　　1、Backoff() 接管 处理函数 和 可选的 Option 函数（retry optione） 作为参数

　　2、默认策略3次重试， 通过 步骤一 预设的 Options, 自定义重试策略

　　3、设置申请的 repsonse 和 error 变量

　　4、开始进行 opts.maxRetries 次 HTTP 申请。

一个简略的 Demo

func getInfo() {
    request := client.DefaultClient().
        NewRestyRequest(ctx, "", client.RequestOptions{
            MaxTries:      3,
            RetryWaitTime: 500 * time.Millisecond,
            RetryConditionFunc: func(response *resty.Response) (b bool, err error) {
                if !response.IsSuccess() {
                    return true, nil
                }
                return
            },
        }).SetAuthToken(args.Token)
    resp, err := request.Get(url)
    if err != nil {
        logger.Error(ctx, err)
    return 
    }

    body := resp.Body()
    if resp.StatusCode() != 200 {
    logger.Error(ctx, fmt.Sprintf("Request keycloak access token failed, messages:%s, body:%s","message", resp.Status(),string(body))),
        )
    return 
    }
  ...
}

　　依据以上梳理的 go-resty 的申请流程， 因为 RetryCount 大于0，所以会进行重试机制，重试次数为3。而后 request.Get(url) 进入到 Backoff() 流程，此时重试的边界条件是： !response.IsSuccess(), 直到请求成功。