署virtualservice我们将为用户 jason 在 reviews:v2 和 ratings 服务之间注入一个 7 秒的延迟注意 reviews:v2 服务对 ratings 服务的调用具有 10 秒的硬编码连接超时。 因此尽管引入了 7 秒的延迟我们仍然期望端到端的流程是没有任何错误的。kubectl apply -f /root/istio-1.24.3/samples/bookinfo/networking/virtual-service-ratings-test-delay.yamlvirtual-service-ratings-test-delay.yaml测试延迟配置通过开发者工具可以看到页面加载用了6.3秒并且页面有错误。正常我们期望 Bookinfo 主页在大约 7 秒钟加载完成并且没有错误故障原理与意义按照预期我们引入的 7 秒延迟不会影响到 reviews 服务因为 reviews 和 ratings 服务间的超时时长为 10 秒。 但是在 productpage 和 reviews 服务之间也有一个 3 秒的硬编码的超时再加上 1 次重试一共 6 秒。 所有productpage 对 reviews 的调用在 6 秒后提前超时并抛出了错误。想象真实公司团队 A 开发 productpage设超时 3 秒团队 B 开发 reviews设超时 10 秒团队 C 开发 ratings。结果就是系统逻辑是 10 秒没问题但上游只给 6 秒系统就炸了在微服务中超时是“逐层传递”的最上层的超时限制是整个调用链的上限。调用链总容忍时间 上游超时 上游重试次数 × 超时时间Istio 在网络层Sidecar 层控制流量可以人为制造延迟、制造错误、改超时、加重试完全不修改微服务代码。相比于传统方法测试延迟改代码、打包镜像、重新部署、回滚istio带来了很大方便Istio 带来的不是流量转发。而是可编程网络控制能力可以不改代码、不重启服务、动态实验、快速回滚只需要kubectl delete virtualservice xxx规则立刻消失服务网格是“把复杂性从代码里剥离出来”。因为在传统模式下重试写在代码、超时写在代码、熔断写在代码、限流写在代码。修改需要开发、测试、发版。而现在全部在网格层完成。运维就能控制如何修复错误增加 productpage 与 reviews 服务之间的超时或降低 reviews 与 ratings 的超时2、注入 HTTP abort 故障部署virtualservice测试微服务弹性的另一种方法是引入HTTP abort故障。 在这个实验中针对用户jason将给 ratings微服务引入一个HTTP abort故障。kubectl apply -f /root/istio-1.24.3/samples/bookinfo/networking/virtual-service-ratings-test-abort.yamlvirtual-service-ratings-test-abort.yaml测试效果jsaon登录后访问页面会看到Ratings service is currently unavailable的提示如左图其他用户或者不登陆会看到V1版本的页面如右图查看kiali