测试一年多，上线就崩溃！微服务到底应该怎么测试？
简介： 只有了解风险，才能及时应对，保障服务高可用。
不久前，也就是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 还提供了注册配置中心托管、微服务治理等功能，欢迎体验。
作者：中间件小哥
本文为阿里云原创内容，未经允许不得转载
