处理故障

Envoy提供了一套开箱即用, 选择加入的故障恢复功能，可以在应用程序中受益。功能包括：

  1. 超时
  2. 带超时预算有限重试与和重试之间的可变抖动
  3. 并发连接数和上游服务请求数限制
  4. 对负载均衡池的每个成员进行主动（定期）运行健康检查
  5. 细粒度熔断器（被动健康检查）- 适用于负载均衡池中的每个实例

这些功能可以通过 Istio的流量管理规则 在运行时进行动态配置。

重试之间的抖动使重试对重载的上游服务的影响最小化，而超时预算确保主叫服务在可预测的时间范围内获得响应（成功/失败）。

主动和被动健康检查（上述4和5）的组合最大限度地减少了在负载平衡池中访问不健康实例的机会。当与平台级健康检查（例如由Kubernetes或Mesos支持的检查）相结合时，应用程序可以确保将不健康的pod/container/VM快速地从服务网格中去除，从而最小化请求失败和对延迟的生影响。

总之，这些功能使得服务网格能够容忍故障节点，并防止本地化的故障级联不稳定到其他节点。

微调

Istio的流量管理规则允许运维人员为每个服务/版本设置故障恢复的全局默认值。然而，服务的消费者也可以通过特殊的HTTP头提供的请求级别值覆盖 超时 和 重试 的默认值。使用Envoy代理实现，header分别是”x-envoy-upstream-rq-timeout-ms”和”x-envoy-max-retries”。

FAQ

  1. 在Istio中运行应用程序是否仍然处理故障？

    是。Istio提高网格中服务的可靠性和可用性。但是，应用程序需要处理故障（错误）并采取适当的回退操作。例如，当负载均衡池中的所有实例都失败时，Envoy将返回HTTP 503.应用程序有责任实施处理来自上游服务的HTTP 503错误代码所需的任何回退逻辑。

  2. Envoy的故障恢复功能是否会破坏已经使用容错库（例如Hystrix）的应用程序？

    Envoy对应用程序是完全透明的。由Envoy返回的故障响应不会与进行呼叫的上游服务返回的故障响应区分开来。

  3. 同时使用应用级库和Envoy时，怎样处理失败？

    为相同目的地的服务给出两个故障恢复策略（例如，两次超时 - 一个在Envoy中设置，另一个在应用程序库中），当故障发生时，两个限制都将被触发。例如，如果应用程序为服务的API调用设置了5秒的超时时间，而运维人员员配置了10秒的超时时间，那么应用程序的超时将会首先启动。同样，如果特使的熔断器在应用熔断器之前触发，服务的API呼叫将从Envoy获得503。