微服务核心理论 - 微服务治理之重试

作者简介:大家好,我是smart哥,前中兴通讯、美团架构师,现某互联网公司CTO

联系qq:184480602,加我进群,大家一起学习,一起进步,一起对抗互联网寒冬

学习必须往深处挖,挖的越深,基础越扎实!

阶段1、深入多线程

阶段2、深入多线程设计模式

阶段3、深入juc源码解析


阶段4、深入jdk其余源码解析


阶段5、深入jvm源码解析

码哥源码部分

码哥讲源码-原理源码篇【2024年最新大厂关于线程池使用的场景题】

码哥讲源码【炸雷啦!炸雷啦!黄光头他终于跑路啦!】

码哥讲源码-【jvm课程前置知识及c/c++调试环境搭建】

​​​​​​码哥讲源码-原理源码篇【揭秘join方法的唤醒本质上决定于jvm的底层析构函数】

码哥源码-原理源码篇【Doug Lea为什么要将成员变量赋值给局部变量后再操作?】

码哥讲源码【你水不是你的错,但是你胡说八道就是你不对了!】

码哥讲源码【谁再说Spring不支持多线程事务,你给我抽他!】

终结B站没人能讲清楚红黑树的历史,不服等你来踢馆!

打脸系列【020-3小时讲解MESI协议和volatile之间的关系,那些将x86下的验证结果当作最终结果的水货们请闭嘴】

1 背景

在复杂的互联网场景中,不可避免的会出现请求失败的情况。
从程序的的响应结果来看,一般是Response返回5xx状态的错误;从用户的角度去看,一般是请求结果不符合预期,即操作失败(如转账失败、下单失败、信息获取不到等)。
偶发的不可避免的5xx请求错误,产生的原因有很多种,比如:

  • 网络延迟或者抖动

  • 服务器资源不足(CPU、内存走高、连接池满)

  • 服务器故障

  • 符合某些特定条件下的服务程序bug(大都非必现)

2 系统稳定性等级划分

大部分服务容忍低频、偶发的5xx错误,并使用可用性级别来衡量系统的健壮性,级别系数越高,健壮性越好,如下:

等级描述故障时长(年)可用行等级
基本可用性87.6h99%
较高可用8.8h99.9%
非常高的可用性(大部分故障可自动恢复)52m99.99%
极高可用性5m99.999%

对于强系统可靠性、强结果预期性 要求的系统,如转账、下单、付款,即使微小的可用性降级也是不可接受,用户强烈需要接收到正确的结果。
可以想想你付款的时候发现付款失败有多么惊慌,订外卖的时候获取信息失败有多么沮丧,这些都是用户痛点。

3 异常的治理手段

3.1 采用异常重试实现故障恢复

通过上面的故障原因分析我们知道,排除了必现的程序逻辑错误,大部分环境导致的错误是可以通过重试进行恢复的。
治理的手段主要是采用 异常重试 来实现的,通过重试负载到健康实例上(实例越多重试成功率越高),降低用户感知到的故障频率。

执行过程说明

  • 这边以示例服务 Svc-A 向 Svc-B 发起访问为例子。
  • 第1次执行失败之后,根据策略,间隔25ms之后发起第2次请求。
  • 会看到有两条日志,日志的trace_id 一致,说明他是同一个调用过程(1个调用过程,包含2次请求,首发1次与重试1次)
  • 请求方为同一个实例 Svc-A-Instance1,说明请求发起方一致。
  • 被请求方发生了变动,说明调度到新的实例(Svc-B-Instance1 到 Svc-B-Instance2)。
  • 返回正常的 200 。

因为我们的负载均衡模式默认是RR,所以实例越多,实际上重试成功的概率会越高。比如有50个实例,其中一个实例出故障,导致执行返回5xx,那么第二次请求的时候一般来说会有 49/50 的成功概率。如下图:

3.2 策略实现(Service Mesh方案)

注释比较清晰了,这边就不解释了。

    # VirtualService
    apiVersion: networking.istio.io/v1beta1
    kind: VirtualService
    metadata:
      name: xx-svc-b-vs
      namespace: kube-ns-xx
    spec:
      hosts:
      - svc_b.google.com # 治理发往 svc-b 服务的流量
      http:
      - match:  # 匹配条件的流量进行治理
        - uri:
            prefix: /v1.0/userinfo   # 匹配路由前缀为 /v1.0/userinfo 的,比如 /v1.0/userinfo/1305015
        retries:
          attempts: 1  # 重试一次
          perTryTimeout: 1s  # 首次调用和每次重试的超时时间
          retryOn: 5xx  # 重试触发的条件
        timeout: 2.5s  #  请求整体超时时间为2.5s,无论重试多少次,超过该时间就断开。
        route:
        - destination:
            host: svc_b.google.com
          weight: 100
      - route:  # 其他未匹配的流量默认不治理,直接流转
        - destination:
            host: svc_c.google.com
          weight: 100

4 总结

云基础场景下的治理手段各种各样,这边讲解了初级版的异常重试,让用户有一个更优良的使用环境。
后续的章节我们逐一了解下超时保护、故障注入、熔断限流、异常驱逐等高级用法。

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值