除了帮助您引导网格周围的通信之外，Istio还提供了可选的故障恢复和故障注入功能，您可以在运行时动态配置这些功能。使用这些特性可以帮助您的应用程序可靠地运行，确保服务网格能够容忍故障节点，并防止局部故障级联到其他节点。

1. 超时

超时是envoy代理应该等待来自给定服务的答复的时间量，以确保服务不会无限期地等待答复，并确保调用在可预测的时间范围内成功或失败。HTTP请求的默认超时时间是15秒，这意味着如果服务在15秒内没有响应，调用将失败。

对于某些应用程序和服务，Istio的缺省超时可能不太合适。例如，超时太长可能导致等待失败服务的响应的延迟过大，而超时太短可能导致在等待涉及多个服务的操作返回时调用不必要地失败。为了找到并使用您的最佳超时设置，Istio允许您使用虚拟服务轻松地在每个服务的基础上动态调整超时，而不必编辑您的服务代码。这是一个指定10秒超时的虚拟服务.

  1. apiVersion: networking.istio.io/v1alpha3
  2. kind: VirtualService
  3. metadata:
  4.   name: ratings
  5. spec:
  6.   hosts:
  7.   - ratings
  8.   http:
  9.   - route:
  10.     - destination:
  11.         host: ratings
  12.         subset: v1
  13.     timeout: 10s

2. 重试

重试设置指定如果初始调用失败，envoy代理尝试连接到服务的最大次数。重试可以提高服务可用性和应用程序性能，方法是确保调用不会因为临时过载的服务或网络等临时问题而永久失败。重试之间的间隔(25ms+)是可变的，并由Istio自动确定，从而防止被调用的服务被请求淹没。默认情况下，在第一次失败后，Envoy代理不会尝试重新连接到服务。

与超时一样，Istio的默认重试行为可能不适合您的应用程序在延迟(对失败的服务进行过多的重试会降低速度)或可用性方面的需求。与超时一样，您可以在虚拟服务中根据每个服务调整重试设置，而不必修改服务代码。您还可以通过添加每次重试超时来进一步细化重试行为，指定每次重试尝试成功连接到服务时需要等待的时间量。下面的示例最多配置3次重试以连接到此服务子集:

  1. apiVersion: networking.istio.io/v1alpha3
  2. kind: VirtualService
  3. metadata:
  4.   name: ratings
  5. spec:
  6.   hosts:
  7.   - ratings
  8.   http:
  9.   - route:
  10.     - destination:
  11.         host: ratings
  12.         subset: v1
  13.     retries:
  14.       attempts: 3
  15.       perTryTimeout: 2s

3. 断路器

断路器是Istio为创建弹性的基于微服务的应用程序提供的另一个有用的机制。在断路器中，您设置对服务中单个主机的调用的限制，例如并发连接的数量或对该主机的调用失败的次数。一旦达到这个限制，断路器“跳闸”并停止与主机的进一步连接。使用断路器模式能够快速故障，而不是客户端试图连接到过载或故障主机。

由于断路器适用于负载平衡池中的“真实”网状目的地，所以您可以在目的地规则中配置断路器阈值，并将设置应用于服务中的每个主机。下面的示例将v1子集的reviews service工作负载的并发连接数量限制为100:

  1. apiVersion: networking.istio.io/v1alpha3
  2. kind: DestinationRule
  3. metadata:
  4.   name: reviews
  5. spec:
  6.   host: reviews
  7.   subsets:
  8.   - name: v1
  9.     labels:
  10.       version: v1
  11.     trafficPolicy:
  12.       connectionPool:
  13.         tcp:
  14.           maxConnections: 100

更多关于断路器的参考链接：参考链接

4. 故障注入

在配置了网络(包括故障恢复策略)之后，可以使用Istio的故障注入机制测试整个应用程序的故障恢复能力。故障注入是一种将错误引入系统的测试方法，以确保系统能够承受并从错误状态中恢复。使用故障注入对于确保故障恢复策略不是不兼容或限制太多非常有用，这可能导致关键服务不可用。

与其他在网络层引入错误(如延迟数据包或杀死吊舱)的机制不同，Istio允许在应用层注入错误。这使您可以注入更多相关的失败，例如HTTP错误代码。

可以注入两种类型的错误，都是在虚拟服务中配置的。

  • 延迟： 延迟就是时间失败。它们模拟增加的网络延迟或过载的上游服务。

  • 终止： 中止是崩溃失败。他们模仿上游服务的失败。中止通常以HTTP错误代码或TCP连接失败的形式出现。

例如，这个虚拟服务每1000个请求中就有1个请求延迟5秒。

  1. apiVersion: networking.istio.io/v1alpha3
  2. kind: VirtualService
  3. metadata:
  4.   name: ratings
  5. spec:
  6.   hosts:
  7.   - ratings
  8.   http:
  9.   - fault:
  10.       delay:
  11.         percentage:
  12.           value: 0.1
  13.         fixedDelay: 5s
  14.     route:
  15.     - destination:
  16.         host: ratings
  17.         subset: v1

更多故障注入参考：链接