流量管理 - 处理故障
Envoy提供了一套开箱即用, 选择加入的故障恢复功能，可以在应用程序中受益。功能包括：
- 超时
- 带超时预算有限重试以及重试之间的可变抖动
- 并发连接数和上游服务请求数限制
- 对负载均衡池的每个成员进行主动（定期）运行健康检查
- 细粒度熔断器（被动健康检查）- 适用于负载均衡池中的每个实例
这些功能可以通过Istio的流量管理规则在运行时进行动态配置。
重试之间的抖动使重试对重载的上游服务的影响最小化，而超时预算确保主叫服务在可预测的时间范围内获得响应（成功/失败）。
主动和被动健康检查（上述4和5）的组合最大限度地减少了在负载平衡池中访问不健康实例的机会。当与平台级健康检查（例如由Kubernetes或Mesos支持的检查）相结合时，应用程序可以确保将不健康的pod/container/VM快速地从服务网格中去除，从而最小化请求失败和延迟产生影响。
总之，这些功能使得服务网格能够容忍故障节点，并防止本地化的故障级联不稳定到其他节点。
微调
Istio的流量管理规则允许运维人员为每个服务/版本设置故障恢复的全局默认值。然而，服务的消费者也可以通过特殊的HTTP头提供的请求级别值覆盖超时和重试的默认值。使用Envoy代理实现，header分别是”x-envoy-upstream-rq-timeout-ms”和”x-envoy-max-retries”。
FAQ
在Istio中运行应用程序是否仍需要处理故障？
是。Istio可以提高网格中服务的可靠性和可用性。但是，应用程序仍然需要处理故障（错误）并采取适当的回退操作。例如，当负载均衡池中的所有实例都失败时，Envoy将返回HTTP 503。应用程序有责任实施用于处理来自上游服务的HTTP 503错误代码所需的任何回退逻辑。
Envoy的故障恢复功能是否会破坏已经使用容错库（例如Hystrix）的应用程序？
Envoy对应用程序是完全透明的。在进行服务调用时，由Envoy返回的故障响应与上游服务返回的故障响应不会被区分开来。
同时使用应用级库和Envoy时，怎样处理故障？
假如对同一个目的服务给出两个故障恢复策略（例如，两次超时设置——一个在Envoy中设置，另一个在应用程序库中设置），当故障发生时，两个限制都将被触发。例如，如果应用程序为服务的API调用设置了5秒的超时时间，而运维人员配置了10秒的超时时间，那幺应用程序的超时将会首先启动。同样，如果Envoy的熔断器在应用熔断器之前触发，对该服务的API调用将从Envoy获得503错误。