• 【译文连载】 理解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。 

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

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

  • 相关阅读:
    PHP深入浅出之命名空间(Namespace)的使用详解
    函数func_get_args详解
    验证码封装类
    PHP中SESSION自定义会话管理器
    网页开发常见问题总结
    mysql远程连接只显示部分数据库问题
    认识和学习bash
    IPv6地址格式示例及IPv6与IPv4的区别分析
    用HTTP核心模块配置一个静态Web服务器
    Nginx服务项的基本配置
  • 原文地址:https://www.cnblogs.com/sammyliu/p/12397689.html
Copyright © 2020-2023  润新知