处理故障

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错误。