全书目录
本文目录
第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-recommendation
VirtualService定义:
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 tutorial
5.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。
本中文译稿版权由本人所有。水平有限,错误肯定是有的,还请海涵。
感谢您的阅读,欢迎关注我的微信公众号: