原文链接  译者:carvendy

故障处理

   使者在故障恢复中，提供了一个拆箱即用的集合，可以更方便地在服务中移除应用。特性包括：

1. 超时
2. 限定的重试，在重试之间有超时预计与数值的波动性。
3. 有限的并发连接数和请求的上游服务。
4. 对于负载均衡池里的成员，进行动态（周期性的）健康检查。
5. 细粒度的断路器（通过健康检查）—— 在负载均衡池里每个实例都需要通过。

  这些特性可以通过Istio的流量管理规则，进行动态配置。

  重试的抖动减少了，重试对上游服务的影响。当可能会超时的时候，调用服务会在限定的时间内得到响应(成功或失败)。

  主动和被动组成的健康检查，在负载均衡池里最少（4~5以上）机会访问不健康的实例。当组合使用容器管理级别的健康检查（如：Kubernetes或Mesos），应用可以确定不健康的pod、container、VM,并将其从服务网格中移除，只产生极小的故障和潜在影响。

  同时，这些特性可以让服务网格忍受故障的节点，并避免了来自级联不确定的节点引起局部失败。

好协调

  Istio流量管理规则允许运维人员为失败故障的每一个服务或版本设置全局默认服务或版本。无论如何，服务的消费者可以重写超时和重试，并通过特别的HTTP头信息来提供了请求级别的重写。在使者代理实现下，头部信息分别是“x-envoy-upstream-rq-timeout-ms” 和 “x-envoy-max-retries”。

FAQ

1. 运行在Istio的应用依然要处理失败？

是的，在网格里Istio提供了可靠和可用的服务。无论如何，应用需要处理故障(错误)和采取适当的后备操作。举例子，在负载均衡池里的所有实例有失败的，使者将会返回503状态码。应用的响应就会实现任何后备的逻辑，并需要处理来自下游服务的503错误码。

2. 使者故障恢复特性，将会打破应用程序已经使用失败容忍的类库？(例如：Hystrix)

不是。使者对于应用是完整的、透明的。由使者返回个失败的响应，将不能从中区别下游服务在哪里被唤醒。

3. 当同时使用应用级别的类库和使者代理，要如何处理故障？

对于同一个目的地的服务使用两种故障恢复策略。（例如：两个超时——一个在使者一个在应用类库），这两个限制将会在故障时候被触发。例子，如果应用设置了5秒钟作为一个API响应超时时间，而当运维配置了10秒种，应用的超时将会首先发生。同样地，如果使者断路器在应用断路器之前执行了，那么API响应服务将会从使者中获取到503状态码。