微服务测试之性能测试

背景

传统性能测试更多的是以事务为核心，更多的是由单个或者多个事务构成业务场景进行压测。全链路压测指完全引入相关联的系统，尽量真实模拟线上硬件环境，更多的是以请求为核心，完全模拟真实请求流量，通过引流等方式进行场景的模拟进行压测，更多的适用于业务链路较长的交易。全链路一直是性能测试中的难点，其包含系统越多测试难度就越大，系统架构中每增加一层的监控内容就会给分析带来几何倍数的难度。因此，微服务架构下的性能测试的重要性就不言而喻了。

微服务架构下为什么做全链路压测

微服务系统系统间调用关系复杂，当出现业务流量暴涨的情况从CDN、网关接入、前端、缓存、中间件、后端服务、数据库整个交易链路都会面临巨大的访问压力，此时业务系统除了收到自身的影响还会依赖其他关联系统的情况，如果某一点出现问题，系统会累加问题并影响到其他其他系统，到时候是哪个系统出问题谁也说不出清楚，比如当某系统MQ开始出现积压，下游系统处理能就可能会变慢，当MQ吃掉内存并造成宕机，整个链路交易都会停止。

微服务架构下全链路压测的难点

如果在测试环境进行全链路压测，最大难点在于无法评估用户从客户端登录到完成交易的整个链路中，系统能的最大承载能力是多少。如果无法承载生成中的流量造成系统宕机，就会有灾难性的后果。所以在测试环境进行全链路要结合历史生成流量，并合理做出业务增长预估，如果能满足此流量可以判定为生产环境满足性能要求。当然，这只是权宜之计，如果在生产环境做全链路压测不会出现此情况。

另外，全链路压测涉及的微服务模块多，开发组多，各组开发人员又各负责自己的模块，因为版本升级块，业务层架构变化也快，很难能了解清楚最新的架构，如果漏掉一个系统的调用关系，分析就会变得非常困难。

软件的版本控制问题，因为版本升级快，造成测试环境与生成环境代码版本不一致，数据库表结构和索引不一致的情况。这种情况会造成测试结果不准确，重复测试。多系统更难控制此情况。

微服务架构下如何开展全链路测试

开展全链路压测，除了传统性能测试的需求调研、环境准备、脚本开发、数据预埋、场景设计、场景执行、应用监控分析、瓶颈定位、瓶颈修复、回归测试、结果整理、输出报告等环节外还要加入分析需压测业务场