电商多业务常态化压测总结（下）

lsekfe

选择合适的压测方案
　　选择压测方案前，我们先来看一个案例。
　　正常上班时间，投入在压测的准备阶段的时长：
　　准备压测账号，耗时1小时左右（压测平台不支持生成账号的条件下）
　　梳理压测服务和接口，耗时2-3小时左右
　　准备压测数据，耗时1小时左右
　　准备压测场景和调试压测脚本，耗时1-2小时
　　总共耗时预计在5-7小时不等
　　公司所有业务安排压测时间都是在0点之后才开始，业务正常安排一次压测，需要投入：
　　RD：至少1人 QA：至少1人?压测时长：2-4小时不等
　　第二天上午因人员需要休息，而不能及时到公司上班
　　压测结束之后，梳理压测结果，收集业务日志，以及监控截图和问题记录，大概花费2-3小时。
　　从以上统计结果来看，安排一次压测任务，至少投入RD1人，QA1人，准备阶段花费5-7小时，压测阶段耗时2-4小时不等，梳理压测结果2-3小时，加上第二天上午半天时间，从人力、物力耗费成本是比较多的。
　　方案1：现场压测

以往的压测方案，都是安排相关参与压测的同学，凌晨留守在公司现场支持，也就是跟上述案例一样的方式，通常现场压测时，都很多个压测场景一起压测，整体投入的时间也会相对比较长。但有个非常重要的前提，因为压测环境是生产环境，所以每次压测安排在0点之后，真实的业务场景基本上到那个时候的访问量在很大程度上已经下降下来了，遇到大促活动期间，可能会延长到1-2点之后都有是可能的，为了不影响真实的业务流量，故压测时间要安排得更晚一些
　　优点：
　　1、现场压测结果实时查看，有问题随时可以停止；
　　2、查看异常问题，随时查看日志，并做记录；
　　3、压测服务负责的RD现场排查问题，能快速解决或给解决方案
　　4、压测过程可随时调整并发线程大小，更准确得出服务瓶颈点

缺点：
　　1、投入人力、物力成本高，甚至有可能第二天上午不能及时上班
　　2、压测过程出现依赖服务异常问题，半夜还需要打电话吵醒其他负责人，排查也不能立马解决。
　　3、压测过程投入太重，无法做到随时随时安排压测任务
　　4、有可能存在项目压测间距太长的问题，例如2-3个月才有一次压测
　　方案2：定时压测（无人值守）


准备流程跟现场压测差不多，压测的前置条件是少不了的，准备压测数据，压测场景，以及调试压测脚本，区别的点是，定时压测是无人值守压测，调试好的脚本，设置在凌晨固定的时间自动进行压测，第二天上午上班就可以收集压测结果，并输出压测报告，还有另外的优势是，前置条件准备一次，基本可以支持多次压测，也不用每次都要造压测数据，而且定时压测频次也可以每天凌晨安排进行压测，压测场景也不用太过于集中在一起，同样可以减化梳理服务接口和压测场景的成本
　　采用定时压测的方式，在很大程度上，释放了更多的人力、物力，可以更灵活的安排相关其他事情，不用长时间跟着压测执行
　　优点：
　　1、无需安排相关人员现场值守压测，节约了压测执行时的人力和物力
　　2、安排压测任务比较灵活，日常项目压测，摸底压测，随时能安排
　　3、安排定时压测的场景少，压测频率快
　　缺点：
　　1、一些特殊场景是定时压测无法做到，例如需要在压测的时候更改配置、降级等
　　2、设置并发线程大小比较固定，没法做到自动调整；无法根据压测结果判断得出准确的服务瓶颈点
　　方案3：现场压测+定时压测
　　通过方案1和方案2在业务侧投入的实践情况作对比分析，其中的优缺点也是各异，但想更灵活安排压测，又想更节约人力成本，更想要压测结果不出偏差，最终得出结论是把现场压测和定时压测两者相结合，但是这样有个前提条件，需要在前置准备阶段就要把压测场景做好区分，为什么要这样做？
　　首先，明确现场压测和定时压测的目标是为了解决什么问题，最后得出什么结果。在这个条件下，很快就能区分开来了。
　　【现场压测场景】
　　1、新增项目，通常是有业务指标，但也可能存在一些业务项目需要压测，又没有业务指标的，想要确保项目压测结果符合实际结果，整个过程是需要人工进行多次验证，才能得最终压测结果
　　2、重构项目，这类项目压测，通常是需要做前后压测对比，而且需要分析和对比服务、机器等等多种差异条件，最终得出合理的结果
　　3、验证服务瓶颈的项目，是要把服务压测到极限，或者获取最高TPS/QPS峰值，这种情况下，是需要进行多次调整并发线程，接口参数，服务配置，机器配置等等
　　4、特殊业务场景：例如秒杀，下单，领卷等等，还有些场景需要设置服务配置，如降级，调用量，扩容等，像这类压测场景，就需要现场人为检查和验证，确保数据和配置的正确性
　　【定时压测场景】
　　1、业务验证稳定性，通常只需要验证服务业务响应正常，数据正常即可，设置一定频次进行压测，检查无异常即可，无需投入太多人力去验证
　　2、业务日常巡检，无需设置太高并发压测，不需要投入太多精力去关注，只需确保业务响应正常
　　3、旧服务接口回归，保持跟历史压测条件进行压测即可
　　4、项目摸底压测，设置压测脚本，调试正常后设置定时压测即可，最终得结果分析再确定实际压测方案
　　5、批量重复性操作的接口，设置特定的参数，采用定时压测方式最合适，省时省力
　　6、项目上线后，设置定时压测，快速回归验证服务稳定性
　　……
　　当然能挑选作为压测的场景并不止这些，适合当前压测任务，又能让自己提高效率和质量，得出最准确的结果才是最重要的
　　其次，实际业务安排，优先是保障业务功能的正确性，再去安排功能以外的自动化或者压测任务，通常是不会投入太多人力的，优先考虑最节省人力的方式，定时压测的是最优选择
　　最后，电商背景下的大促活动，每次都要做压测，以往都是要安排现场压测，投入成本实在是太多，那要选择更效率的方式，又要满足这种条件，那就把压测压测场景分开，常规巡检压测和摸底压测都采用定时压测，特殊场景再采用现场压测，既能达到大促压测的条件，又能满足预期的结果
　　方案4：独立的压测环境
　　采用独立压测环境的方案，选择弃用，为什么呢？请看以下分析：
　　1、压测结果不够准确
　　一般来说，保证执行性能压测的环境和生产环境调试一致是执行一次效性能压测的首要准则。有时候，即使是压测环境和生产有很细微的差别，都有可能导致整个压测活动评测出来的结果不够准确
　　2、系统架构搭建困难
　　1）系统逻辑架构
　　从端到端的调用，服务相互依赖调用，各种中间件数据流转，部署整套环境都需要考虑真实业务的流向，会涉及到多个业务系统，单靠一两个人，实现成本太高，难度也很大
　　2）物理架构
　　线下机房，供电系统，内外网访问，云环境等等，需要部署一整套运行系统，需要运维同学提前搭建，是否有多余的机器来投入做压测环境，都是需要申请，甚至可能没有机器可申请
　　3、投入大，产出小
　　为什么是投入大，产出小？在这里大家可以想想，压测周期通常是多久，最多1-2周，日常情况下是几个小时就完事了，这样投入大成本去搭建一套环境，只是用了这次的压测，然后就结束了，只是为了得到一个压测结果，对于业务来说，如果不做这次压测的投入，是不是系统就一定有问题了？对业务成本来说，这是不可行的方式；同样从机器成本上看，每台机器的成本都要花钱的，做压测都是要花钱的，最终压测完只是得到一个结果，而不是换成对应成本，所以，在机器不富余的情况下，这个方案是不作考虑的
　　最终的实践效果
　　通过上述的方案实践和探索，决定放弃方案4，因为投入成本实在太高了。以前只有现场压测的方式，现在多了另外两种选择，根据实际业务需要，又要做到常态化压测的条件，不同的条件，选择不同的压测方式，既能满足业务需求，又能符合团队需要，以下看看这次618压测实际的效果：

压测后的总结
　　1、要达到每天都能安排压测，前提是已经具备各个完善的平台系统做支撑，出现异常自动化熔断处理，超时自动化抛空处理，宕机自动容错恢复等等措施手段
　　2、参与压测人员需要具备一定的性能分析能力，针对压测结果可以给出合理的优化建议
　　3、提高效率的前提，是经历过无数个坑，在填平之后，重新规划走出的新捷径，既能满足且又能减少在以往操作方式上的投入，又能提高现在操作方式产出，还能释放更多的时间和精力
　　4、全链路压测，作为一种大促前必须巡检的手段，但它不是必要的前提，在项目平时做的常态化压测才是有效保障系统长期稳定性的重要手段
　　下一步计划
　　1、结合公司内部流量路由的方式，实现生产数据与压测数据区分，做到正常上班时间也能随时做压测。
　　2、测试结果自动聚合，包含接口压测结果，服务调用链路分析，服务整体流量，服务异常情况，耗时等等。