处理故障

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秒的超时时间，那么应用程序的超时将会首先启动。同样，如果Envoy的熔断器在应用熔断器之前触发，对该服务的API调用将从Envoy获得503错误。