基于Devops的微服务架构是云时代部署应用的一项热门技术，它把庞大的单个应用程序分解为数十个微服务，使业务更快速地响应市场变化。但是每个微服务有不同的客户需求并且随着微服务增多，无法做1：1验证，传统性能测试模式已不能满足Devops平台的要求。 DevOps中如何系统开展微服务性能测试？

微服务架构下的性能测试挑战

1.微服务3S原则

2.DevOps核心点

单服务流量激增时扩容
调用链条变长，调用关系更加复杂
微服务拆分导致故障点增多

单服务变更性能影响如何评估？
性能瓶颈在各微服务间漂移，如何做好性能测试？
应对突发流量需求，扩容能否解决问题，如何扩容？
服务实例数量众多，如何收集信息，快速定位性能问题？

微服务性能保障解决方案设计

•关键设计1：模块化管理，事务灵活组合与复用

关键设计2：应用与资源一体化编排

在微服务架构下，自动化仍然是提升效率，看护质量的重要手段，每个微服务独立快速迭代上线，更加要求微服务的性能不劣化。

扩容：链路中的某一应用可能出现cpu使用率较高或者连接池资源不够用(rpc、jdbc、redis连接池等)但本身对于拿到连接的请求处理又很快，这一类需要横向扩展资源。
应用逻辑优化：比如存在慢sql、逻辑的不合理如调用db或者redis次数过多、没有做读写分离造成写库压力过大。
超时时间的合理设置：对于应用之间的rpc调用或者应用与其他基础组件之间的调用，均需要设置合理的超时时间，否则过长的等待将造成整个链路的故
缓存的应用：请求尽可能从前端返回，而不是每一个都要让后端应用处理后再返回，减轻后端应用及数据库压力，提高系统吞吐能力。
限流：对于超出承载能力的QPS或并发，可以进行拦截并直接返回提示页面。
降级：对于非核心链路上的应用，允许故障关闭而不影响核心链路。

一个典型的互联网平台：突发事件高流量突发，如瞬间由百级用户增长到万级

对于网络架构复杂的应用，可以拆分压力的入口点，进行分段验证，屏蔽对应网元带来的性能影响，如分别从最外端的CDN入口（1）、中间的ELB（2）、业务层（3）分别做测试，验证复杂网络架构情况下，各网元的瓶颈和影响，系统内部的性能瓶颈如何提升定位效率？

在上线和活动前期通过云性能测试服务进行压力测试，发现部分接口的响应时间比较长，会出现比对失败和响应超时，通过APM的调用链分析，发现有部分SQL语句比较耗时，针对这些SQL查询语句，建立了索引，快速定位问题并迅速解决。

最终经过两轮测试优化后，官网首页访问响应超时与正常返回比提升了43.3%，预约试驾场景响应超时与正常返回比降低到0，提升了100%。

性能瓶颈定位时间，从官网未使用APM时需要1周，缩短到俱乐部使用APM后的0.5天，效率提升90%。

本文转载自华为云产品与解决方案公众号。

原文链接：https://mp.weixin.qq.com/s/WR5YePZeyvaMJu8-LVxCJQ