Istio的故障注入

一、理解故障注入
　　在一个微服务架构的系统中，为了让系统达到较高的健壮性要求，通常需要对系统做定向错误测试。比如电商中的订单系统、支付系统等若出现故障那将是非常严重的生产事故，因此必须在系统设计前期就考虑多样性的异常故障并对每一种异常设计完善的恢复策略或优雅的回退策略，尽全力规避类似事故的发生，使得当系统发生故障时依然可以正常运作。而在这个过程中，服务故障模拟一直以来是一个非常繁杂的工作，于是在这样的背景下就衍生出了故障注入技术手段，故障注入是用来模拟上游服务请求响应异常行为的一种手段，通过人为模拟上游服务请求的一些故障信息来检测下游服务的故障策略是否能够承受这些故障并进行自我恢复。
　　Istio提供了一种无侵入式的故障注入机制，让开发测试人员在不用调整服务程序的前提下，通过配置即可完成对服务的异常模拟。Istio 1.5仅支持网络层的故障模拟，即支持模拟上游服务的处理时长、服务异常状态、自定义响应状态码等故障信息，暂不支持对于服务主机内存、CPU等信息故障的模拟。它们都是通过配置上游主机的VirtualService来实现的。当我们在VirtualService中配置了故障注入时，上游服务的Envoy代理在拦截到请求之后就会做出相应的响应。目前，Istio提供两种类型的故障注入，abort类型与delay类型。
　　Abort：非必配项，配置一个abort类型的对象。用来注入请求异常类故障。简单来说，就是用来模拟上游对服务返回指定异常码时，当前的服务是否具备处理能力。它对应于Envoy过滤器中的config.filter.http.fault.v2.FaultAbort配置项，当VirtualService资源应用时，Envoy将会为该配置加载到过滤器中并处理接收到的流量。
　　Delay：非必配项，配置一个delay类型的对象。用来注入延时类型故障。通俗一点讲，就是人为模拟上游服务的响应时间，测试在高延迟的情况下，当前的服务是否具备容错容灾的能力。它对应于Envoy过滤器中的config.filter.fault.v2.FaultDelay配置项，同样也是在应用Istio的VirtualService资源时，Envoy将该配置加入到过滤器中。

二、配置故障延迟
1）将jetty用户的登录请求路由至reviews v2版本

➜  kubectl apply -f samples/bookinfo/networking/virtual-service-all-v1.yaml
virtualservice.networking