背景
项目的目标是为客户交付一个ToC的APP，其后端是基于RESTful的微服务架构，同时后端还采用了Protobuf协议来提高传输效率。在最终上线之前，我们需要执行性能测试以确定系统在正常和预期峰值负载条件下的表现，从而识别应用程序的最大运行容量以及存在的瓶颈，并针对性能问题进行优化以提升用户体验。
性能测试是一个较为复杂的任务，包括确定性能测试目标，工具选择，脚本开发，CI集成，结果分析，性能调优等过程，需要QA，Dev，Devops协力合作。本文将对这一系列过程进行详细描述。
为什么选择k6
在得知需要做性能测试后，我们就开始针对性能测试做了一番调研，在阅读了一些性能测试工具对比的文章后，最终挑选了k6，locust和Gatling做了进一步对比，下面是对比的结果。
| 工具 | K6 | Locust | Gatling |
|---|---|---|---|
| 语言 | Javascript | Python | Scala/Java/Kotlin |
| 是否开源 | √ | √ | √ |
| 报告 | √ | √ | √ |
| 支持的协议 | Http/Https/gRPC/WebSockets | Http/Https | Http/JMS/WebSockets |
| record | √ | × | √ |
| 数据导入 | √ | √ | √ |
| 外部依赖 | / | Python | JDK |
| 资源监控 | √ | × | × |
| 扩展性 | √ | × | × |
| TeamCity | √ | √ | √ |
对我们来说，k6的优势在于：
- k6支持TypeScript，由于项目上已经有TypeScript使用经验，因此该工具学习成本相对更少
- k6本身支持metrics的输出，可以满足大部分metrics的需求，有需要还可以进行自定义
- k6官方支持与多种CI工具，数据可视化系统的集成，开箱即用
- Gatling支持Scala/Java/Kotlin，项目上没有使用相关的技术栈，需要和客户申请，成本高于k6
动手写第一个case
有了上面的基础，我们便开始尝试在项目中集成k6，在选了一个简单的API写
