简介: 只有了解风险,才能及时应对,保障服务高可用。
不久前,也就是11月16日,澳大利亚交易所(Australian Securities Exchange, ASX)上线了一个新的交易系统,但因为出现故障而被迫关闭。这是其 2016 年因硬件故障导致休市后最为严重的一次事故。
测试了一年多,结果上线当天就奔溃
11 月 16 日中午,ASX 发布声明表示当天将休市,于次日正常时间重新开放。交易所给出的关闭的原因是“局限于单个交易指令中交易多种证券(组合交易)的软件问题导致了市场数据不准确。”
ASX 此次升级的系统是由纳斯达克开发的最新一代交易系统,目前在全球广泛使用。为了保障上线后的安全运行,ASX、技术提供商纳斯达克( Nasdaq )、客户和第三方独立专家已经做了一年多的广泛测试,包括四次彩排。
微服务该如何测试?
看完了热闹,也看看咱们自己的系统。随着以 Spring Cloud、Dubbo 为代表的微服务架构的流行,现在很多企业都采用了微服务架构。随着服务越来越多,这些服务该如何测试?如何防范上面说的系统风险呢?
我们来捋一捋线上系统的风险,然后针对对应的风险来做对应的测试计划。以如下架构为例:
一般来说,一个业务系统的风险来自两处:
-
其一是变更带来的风险,比如前面提到的新系统上线,或者我们给上图中的购物车服务修一个 bug 等等。
-
其二是日常风险,比如底层的数据库、主机、网络等软硬件问题。
如图:
首先,对于变更带来的风险,我们可以用如下的测试方式来验证:
开发自测
开发完一个功能后,在提交测试前,开发人员需要尽力确保逻辑正确。比如 IDEA 或者 Postman 等工具都可以在本地测试 HTTP 接口,可以用来测试 Spring Cloud 服务:
对于 Dubbo 服务,由于是基于 tcp 协议的,开发就需要自己手写一个简单的 conumer 来验证下服务的功能:
测试环境验证服务
开发提交测试后,测试人员也需要对服务进行测试,确保该服务能正常工作。此时的测试,一般是在单独的测试环境进行的。
对于 Spring Cloud 服务,测试人员可以在 Postman 等工具上,填写目的 IP、url、参数来发起请求、验证服务:
对于 Dubbo 服务来说,Dubbo Admin 也提供了服务测试功能,能够在页面上发起调用来验证服务:
为了安全考虑,一般测试环境和公网、办公网是隔离的,比如测试环境是阿里云上一个单独的 VPC。在这种情况下,如果需要用 postman 或者 dubbo admin,就需要打通网络,比如专线等等。
如果你的服务接入了阿里云的微服务引擎(Microservice Engine, 下文简称为 MSE),那么就可以直接在 MSE 控制台上发起测试请求,而不用理会网络、权限等问题。
在 MSE 控制台上,点击 微服务治理中心->微服务测试->服务测试 菜单,选择服务、方法后,就可以可在服务测试页面选择调用的节点、填写调用的参数:
可以看到,对于入参中的复杂结构,比如图中的 ProductItem,MSE 的服务测试功能还会生成示例数据,不用测试人员自己去翻代码看如何填写入参了。
填写完成后,就可以点击执行,来执行测试:
MSE 的服务测试功能也支持 Spring Cloud 接口的测试:
整体回归测试
在一个服务发布后,需要测试人员验证下比较重要的产品流程。比如架构图中,从浏览商品到最后下单,中间调用了好几个服务,测试人员需要整体来回归一遍这个功能。
对于简单的场景,在上线不频繁的情况下,可以由测试人员手动完成整个流程,来看看整个业务流程是否正常。如果业务场景过于复杂,或者上线比较频繁,那么就需要自动化测试了。一般来说,各个公司都会自建 CI 系统来完成这种集成测试。
以 Jenkins 为例,需要:
- 搭建 Jenkins,配置好网络等环境
- 创建测试脚本仓库,并添加测试脚本
- 在 Jenkins 中配置 pipeline
- 执行并查看结果
同样,这儿也要处理不同环境中的网络问题,尤其是生产环境中的回归测试,更需要严格控制权限。
作为微服务整体的解决方案,MSE 也提供了自动化回归能力,能够一键完成回归测试。首先,点击 微服务治理中心->微服务测试->服务测试 菜单,新建一个自动化用例。每一步都可以调用一个 Spring Cloud 和 Dubbo 服务,可以添加断言,来验证测试是否通过:
点击“立即执行”后,就在执行历史页面看到自动化回归的结果:
服务巡检
除了变更带来的风险之外,我们还需要应对日常风险,比如数据库、网络等组件出问题的情况。为了应对这些风险,我们需要定时验证下这个服务能不能正常工作。通常,很多公司会使用 CI 系统的定时执行功能来构建一个定时执行的任务,如果任务执行失败,会自动触发告警。
以 Jenkins 为例,除了要搭建 Jenkins、写测试脚本以外,还需要将 Jenkins 的任务设置为定时触发:
比如,我们需要检查商品服务是不是正常,就可以写一个 Jenkins 定时任务来调用商品服务,定时检查商品服务是否正常。当然,如果你的服务接入了 MSE 的话,也可以使用 MSE 提供的服务巡检功能来定时检查服务,如果不能按照预期工作,那么就立刻发告警,通知告警的订阅人。
点击 微服务治理中心->微服务测试->服务巡检 菜单,新建一个巡检任务:
然后在列表点击对应巡检任务的开始按钮,就能开始巡检了:
如果巡检出错了的话,也会有对应的告警出来,以钉钉告警为例:
当然,这儿也支持设置邮件、短信告警。您可以根据服务重要程度来设置不同的告警接收方式。
服务压测
系统的流量是在不断变化的,为了应对可能出现的突发流量,我们需要及时评估系统压力,决定是否扩容。另一方面,代码也是不断在修改的,所以也需要在每次上线前压测下,看下代码性能是不是有明显恶化。在压测方面,Apache JMeter 可以很好的测试 Spring Cloud 服务和 Dubbo 服务。
对于 Spring Cloud 服务,可以利用 JMeter 自带的 HTTP 取样器来压测:
对于 Dubbo 服务的压测,jmeter-plugins-for-apache-dubbo 新增了 Dubbo 取样器,可以用来测试 Dubbo 服务。
只需要在 Dubbo 取样器的配置页面设置 registry、interface、method 等,就可以创建好压测任务了。
创建好压测任务后,通过 jemter 命令行即可执行压测任务,并得到压测结果:
jmeter -n -t ./rest-order-thread-group.jmx -l ./result.txt -e -o ./webreport
最后,如果您的服务已经接入了 MSE,那 MSE 也提供了开箱即用的压测能力。
点击 微服务治理中心->微服务测试->服务压测 菜单,新建一个压测场景,并配置好压测参数:
您也可以在压力配置选项卡上配置压力模型等参数:
配置完成后,可以在对应压测场景的详情页面开始压测。也可以在压测场景的详情页面查看结果,如果你需要更加详细的结果,请点击运行记录的详情按钮。
总结
微服务的测试,不论是自己搭建测试系统、还是通过 MSE 来测试,都是为了应对变更带来的风险和日常风险。只有了解风险,才能及时应对,保障服务高可用。
相比于自建测试系统,阿里云产品 MSE 提供了同样的功能,不仅避免了用户自己处理不同网络互通的问题,而且提供了完善的权限管理功能,确保线上稳定安全运行。除此之外,MSE 还提供了注册配置中心托管、微服务治理等功能,欢迎体验。
作者:中间件小哥
原文链接
本文为阿里云原创内容,未经允许不得转载