ServiceMesh 5：异常重试和超时保护提升服务可用性
★ ServiceMesh系列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 Istio策略实现
注释比较清晰了，这边就不解释了。
# VirtualServiceapiVersion: networking.istio.io/v1beta1kind: VirtualServicemetadata:name: xx-svc-b-vsnamespace: kube-ns-xxspec: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: 1004 请求超时的治理手段
4.1 请求超时的主要原因
[*]网络延迟或者抖动或者丢包，从而导致响应时间变长。
[*]容器甚至云主机资源瓶颈情况：如CPU使用率过高、内存使用是否正常、磁盘IO压力情况、网络时延情况等资源使用情况异常，也可能导致响应时间变长。
[*]负载均衡性问题：多实例下分配的流量不均衡，目前看云基础场景，这个情况不多见。
[*]突发洪峰请求：如流不存在非预期的流量，作为主打对内的项目，突发洪峰请求主要还是程序的调用不合理或者程序bug（内存泄露、循环调用、缓存击穿等）。
单个副本，长耗时容易造成队列堆积，对资源损耗很大，快速的释放或者调度开是一个比较好的办法，是一种普遍可接受的降级方案，否则超时阻塞会导致服务长时间不可用。
而且这种影响是水平扩散的，同服务上的其他功能也会被争抢资源。
4.2 Istio的治理手段
4.2.1 超时重试
对服务的核心接口进行细粒度配置，具体接口超时时间应该在 ≥TP 99.9（满足999‰的网络请求所需要的最低耗时）的耗时，可以考虑重试。
4.2.2 超时熔断
通过指定超时时间对请求进行断连，达到降级的目的。避免长时间队列阻塞，导致雪崩沿调用向上传递，造成整个链路崩溃。
4.3 Istio策略实现
关注下方代码中的两个星号 ★ 的属性：
[*]perTryTimeout 指的是首次调用和每次重试的超时时间，超过这个时间，说明请求大概率已经pending住了，则进行重试，争取落到其他健康实例上，更快拿回的结果。
[*]timeout 指的是请求整体超时时间为2.5s，无论重试多少次，超过该时间就断开，这是一种保护策略，避免过度重试或者长时间Pending导致服务恶化甚至雪崩。
# VirtualServiceapiVersion: networking.istio.io/v1beta1kind: VirtualServicemetadata:name: xx-svc-b-vsnamespace: kube-ns-xxspec: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: 1005 总结
本文我们介绍了使用服务网格进行异常重试和超时熔断的治理。Istio提供了丰富的治理能力，后续的章节我们逐一了解下故障注入、熔断限流、异常驱逐等高级用法。
页:
[1]