【译文连载】 理解Istio服务网格（第五章 混沌测试）
【译文连载】 理解Istio服务网格（第五章 混沌测试）
全书目录
- 第一章 概述
- 第二章 安装
- 第三章 流控
- 第四章 服务弹性
本文目录
第5章 混沌测试................................................................................................. 1
5.1 HTTP错误.................................................................................................... 1
5.2 延迟............................................................................................................ 3
第5章 混沌测试
Netflix发布的一个著名OSS工程“Chaos Monkey”对IT业界产生了很大的影响。Netflix编写代码在生产系统中随机杀掉生产环境中的部分服务，这种做法对人们的心理冲击很大。当大多数团队还在尽力维护系统可用性的时候，自己写代码攻击自己的系统似乎很疯狂。从Chaos Monkey项目诞生开始，一个新的工程名词被创造出来了：混沌工程（Chaos Engineering）。根据混沌工程网站（http://principlesofchaos.org/），“混沌工程是一种针对分布式系统的工程方法，旨在强化生产系统应对突发情况的能力，以增强系统能力”。
在复杂系统中，故障可能会经常出现，但根本目的还在于防止整个系统的灾难性故障。但问题是，如何才能验证你的微服务系统具有足够的弹性呢？你可以注入一些混沌来进行测试验证。在Istio服务网格中，因为istio-proxy会处理所有网络流量，因此，它可以修改服务的返回结果以及响应时间，这使得利用Istio进行混沌测试变得更加容易。Istio很容易地就能插入HTTP错误码和网络延迟这两种常用错误。
5.1 HTTP错误
基于前面章节中的练习，你要确保recommendation服务的v1和v2版本都被部署到环境中了，而且不能产生错误和长时间等待。现在，利用Istio而不是在Java代码中插入错误。
获得recommendation服务的pod：
oc get pods -l app=recommendation -n tutorial
NAME READY STATUS RESTARTS AGE
recommendation-v1-3719512284 2/2 Running 6 18m
recommendation-v2-2815683430 2/2 Running 0 13m确认集群中没有DestionationRules和VirtualService对象：
oc delete virtualservices --all -n tutorial
oc delete destinationrules --all -n tutorial我们使用Istio的DestionationRule和VirtualService来插入一定百分比的错误。本例中，一半的响应会返回HTTP 503错误码。DestionationRule的定义如下：
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
name: recommendation
namespace: tutorial
spec:
host: recommendation
subsets:
- labels:
app: recommendation
name: app-recommendationVirtualService定义：
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: recommendation
namespace: tutorial
spec:
hosts:
- recommendation
http:
- fault:
abort:
httpStatus: 503
percent: 50
route:
- destination:
host: recommendation
subset: app-recommendation应用这两个对象的定义：
oc -n tutorial create -f istiofiles/destination-rule-recommendation.yml
oc -n tutorial create -f istiofiles/virtual-service-recommendation-503.yml测试很简单，只需要用curl访问customer服务端点。要多测试几次，看结果中返回503错误是不是大概占50%。
curl customer-tutorial.$(minishift ip).nip.io
customer => preference => recommendation v1 from '3719512284': 88
curl customer-tutorial.$(minishift ip).nip.io
customer => 503 preference => 503 fault filter abort你还可以检查preference服务是否正确处理了recommendation服务的错误返回。
清理环境，将VirtualService对象删除，但保留DestionationRule对象。
oc delete virtualservices --all -n tutorial5.2 延迟
分布式计算环境中，潜在故障中最隐蔽的不是服务死了，而是服务响应缓慢，这有可能导致服务网络一连串的故障。更重要的是，如果你的服务需要满足一定的SLA，又怎么确认服务延迟不会影响到用户体验呢？
和HTTP错误注入类似，网络延迟注入也使用VirtualService类型。下面的定义向recommendation服务的50%的响应中注入7秒的延迟：
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
creationTimestamp: null
name: recommendation
namespace: tutorial
spec:
hosts:
- recommendation
http:
- fault:
delay:
fixedDelay: 7.000s
percent: 50
route:
- destination:
host: recommendation
subset: app-recommendation应用该对象：
oc -n tutorial create -f istiofiles/virtual-service-recommendation-delay.yml然后，向customer服务端点发送一些请求，查看响应时间。Time命令会输出curl命令收到每个响应经过的时间：
#!/bin/bash
while true
do
time curl customer-tutorial.$(minishift ip).nip.io
sleep .1
done在输出中，你会看到大量的响应有延迟了。如果你在监控recommendation服务v1和v2 pod的日志，你会发现延迟发生在recommendation服务被调用之前。延迟发生在Istio代理中，而不是在实际的服务中：
oc logs recommendation-v2-2815683430 -f -c recommendation在第4章中你学习了如何进行错误处理，本章中，你改变了角色，转而自己向自己的系统中通过Istio VirtualService注入错误。此时，你心里也许突然有了一个关键问题：我怎么知道错误是否发生在业务服务中呢？答案就第6章。
清理环境：
oc delete virtualservice recommendation -n tutorial
oc delete destinationrule recommendation -n tutorial书籍英文版下载链接为 https://developers.redhat.com/books/introducing-istio-service-mesh-microservices/，作者 Burr Sutter 和 Christian Posta。
本中文译稿版权由本人所有。水平有限，错误肯定是有的，还请海涵。