译文连载 理解Istio服务网格(第五章 混沌测试)

Posted sammyliu

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了译文连载 理解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-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。 

本中文译稿版权由本人所有。水平有限,错误肯定是有的,还请海涵。 

 感谢您的阅读,欢迎关注我的微信公众号:

技术图片

 

以上是关于译文连载 理解Istio服务网格(第五章 混沌测试)的主要内容,如果未能解决你的问题,请参考以下文章

[译文] 应用领域驱动设计, 第五章 - 领域服务

Istio 服务部署

《深入理解Spark-核心思想与源码分析》第五章任务提交与执行

负载测试 kubernetes 服务(使用 istio 服务网格)

istio1.5安装-较之前版本有重大改进

为微服务引入Istio服务网格(上)