聊聊性能测试环境搭建
昨天知识星球社区的一位同学问了一个问题：性能测试环境必须和生产环境保持1:1配置一致吗？
这个问题其实很有意思，因为问题的点开始向工作最基础的部分靠近了。
我们经常听到各种各样性能测试相关的问题，比如高并发/性能优化/各种性能指标以及压测工具等。
但作为性能测试活动开展的基础：测试环境，却很少有人提及。
这篇文章，我想聊聊关于性能测试环境如何搭建的一些实践经验以及个人的观点。
本文又名：
- 搭建性能测试环境，有哪些需要注意的点？
- 性能测试环境配置，必须和生产保持一致吗？
- 什么情况下性能测试环境可以和生产保持一致？
- 如何搭建性能测试环境，才能在成本和价值间保持平衡？
独立性能环境的重要性
有些同学担心，由于性能测试环境和线上环境配置不一致，会导致线下环境得到的性能结果无法发现足够多的性能问题，无法对线上环境的容量评估/稳定性保障带来足够的参考。其中担心的重点有如下几点：
- 配置不一致，服务的容量无法很好的换算；
- 配置不一致，导致压测时候无法模拟太高的并发；
- 数据量不一致，导致有些性能问题上量后会暴露出来；
其实这些担心不无道理，从技术的角度出发，只有尽可能的和生产保持一致，才能确保测试的结果对生产的稳定性有足够的参考价值，也是保障性能测试交付质量的一个重要因素。
但，性能测试环境和生产保持一致，就真的能避免生产环境不出现性能问题吗？未必！
环境配置高低是决定性能结果的一个影响因素，但不是全部因素。提前测试、提前暴露问题，修复的成本也就越低。
我们常见的性能问题，比如JVM GC/慢SQL/死锁/for 循环/缓存未命中等，都可以在线下的性能环境提前发现。
这些问题的发现和修复与服务器配置并没有直接联系，能够在线下提早用更低的成本解决是一种更优的选择。
大家可以思考下，功能测试的测试环境作用，就能理解独立性能测试环境的作用了。
我们搭建独立的功能测试环境，是为了在项目上线前进行充分的各种维度的验证，尽量保障线上的交付质量。
但绝不是功能测试环境没问题，线上就不会有问题。测试环境我们可以通过功能测试验证/自动化测试回归等手段尽可能发现问题，生产环境同样需要进行回归测试/自动化测试去进行日常的巡检，做到早发现早修复。
原则上bug只要没影响到用户，是不会造成直接的影响和损失的。对于线上的bug，需要的是更完善的监控告警机制和oncall修复流程，在造成更大影响之前修复。
同理，性能测试环境的作用也是这样：在服务线上发布前，尽可能暴露一些存在的性能问题并进行修复验证。线上通过全链路压测/日常巡检/容灾演练/监控告警等手段来保障线上服务的稳定性。
如果没有做线下性能测试的情况下直接在生产上测试，对性能中的异常测试、高可用测试可能无法充分执行；同时，修复性能 bug 也需要功能上的回归，这些都增加了过程管理的复杂度。
因此，搭建独立性能测试环境的重要性主要有如下几点：
- 提前进行性能验证，发现并修复问题；
- 独立的性能测试环境可以避免其他测试动作的影响；
- 提前进行各种手段的性能测试，降低线上出现问题的修复成本；
搭建独立性能环境的几点建议
性能测试其实在日常的工作中不是充分必要的需求，大家不要被业内大厂的高并发高可用之类的概念所迷惑。
绝大多数公司，线上峰值流量可能还不到1w并发，均摊到所有服务集群上，可能一些核心接口的QPS都不会超过10。
而且大多业务是只读的，写或者先读再写的复杂业务场景比较少，升配+扩容+缓存，能解决多数性能问题。
不在大厂，或者业务高速增长的企业，很少有所谓的高并发性能需求。
痛点有时候是技术假设的，站在业务角度和成本角度，并不是痛点。
所谓的高并发，是个伪命题，其实只是你个人所认为的并发高，但其实不高。
当然，搭建独立的性能测试环境，在成本和需求都满足的情况下，可以参考如下几点建议：
- 和生产等比最小化，即1个服务1台机器；
- 如果是云服务，尽量部署在不同可用区；
- 机器配置类型和生产保持一致(cpu类型/几核几G)；
- 如果是云服务，选择按量收费，而不是包年(降低成本)；
- 非核心服务(调用量不大/重要性低)，可以多个服务部署同一个机器；
- 数据量缩小，数据库隔离降配(8C64G的数据库实例足够满足日常压测所需)；
- 该有的链路追踪/基础监控/应用监控等技术设施必须部署，便于问题定位排查；
文末总结
独立性能环境可以支撑服务线上发布前尽可能暴露存在的性能问题并进行修复验证。
线上服务的稳定性保障通过全链路压测/日常巡检/容灾演练/监控告警等手段来保障。
搭建独立的性能测试环境，需要充分评估需求的必须性和硬件成本以及管理维护成本。
性能测试也可以分层，线下环境解决线下的问题，线上稳定性保障用其他手段来解决。
前期的需求评估/技术方案评审就是很好的性能风险评估窗口，性能测试也可以测试左移。
