标签：Dubbo 上线 服务 压测 测试 崩溃 MSE Cloud
前言
简介： 只有了解风险，才能及时应对，保障服务高可用。
不久前，也就是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 还提供了注册配置中心托管、微服务治理等功能，欢迎体验。
如果文章对你有帮助，麻烦伸出发财小手点个赞，感谢您的支持，你的点赞是我持续更新的动力。
最后：福利
技术行业，一定要提升技术功底，丰富自动化项目实战经验，这对于你未来几年职业规划，以及测试技术掌握的深度非常有帮助。
金九银十面试季，跳槽季，整理面试题已经成了我多年的习惯！下面有我近几年的收集和整理，整体是围绕着【软件测试】来进行整理的，主体内容包含：python自动化测试专属视频、Python自动化详细资料、全套面试题等知识内容。
对于软件测试的的朋友来说应该是最全面最完整的面试备战仓库，为了更好地整理每个模块，我也参考了很多网上的优质博文和项目，力求不漏掉每一个知识点，很多朋友靠着这些内容进行复习，拿到了BATJ等大厂的offer，这个仓库也已经帮助了很多的软件测试的学习者，希望也能帮助到你！
愿你我相遇，皆有所获！ 欢迎关注微信公众号：【伤心的辣条】 免费领取一份216页软件测试工程师面试宝典文档资料。以及相对应的视频学习教程免费分享！
标签：Dubbo,上线,服务,压测,测试,崩溃,MSE,Cloud 来源： https://www.cnblogs.com/cshuangxi/p/14304973.html
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。