作者：京东物流 王江波
一、常态化压测建设目的
为什么做常态化压测？
性能问题滞后发现，给大促带来不可控风险。目前日常需求频繁迭代，系统配置的变更、上下游依赖的变化、服务器资源置换等诸多因素均会对系统性能产生一定影响；日常很难做到对所有新项目或需求上线前后都进行压测，这就往往导致了很多性能问题推迟到大促压测期间才被发现。
大促备战压测备战时间紧、任务多，压测备战压力较大，在11.11复盘中，有些部门工时统计中，压测占了较大一部分工作量。而且性能问题相较于其他问题，优化难度大、修复周期长，在大促备战多专项并行资源紧张情况下，频繁的系统调优给整个大促带来不可控的风险因素。
引入常态化压测的手段，通过每周或每月的定期压测行为，持续把控系统性能表现，保证服务稳定性；同时将需求上线引起的性能问题前置暴露，及时定位优化问题；减轻备战压力，提升压测效率。
二、常态化压测实施流程
2.1 常态化压测
2.2 实施策略
通过三步走的方式，由浅入深，逐步在平台技术部落地常态化压测：
第一步 单机试点： 由于初次使用常态化压测，通过隔离单机环境的方式，了解了常态化压测的压测思路、执行流程、压测平台能力支持及风险点摸排；
第二步 集群试点：在履约、基础平台选择星级核心服务，在线上环境试点小集群（2-3台）常态化压测任务执行，从线上业务影响、上下游依赖影响、压测平台能力支持、线上压测风险管控等多方面评估常态化压测在线上集群落地的可行性；
第三步 全面展开： 根据履约、基础平台的线上常态化压测集群实践，推广至全平台技术部，并结合Kit压测工具，建立核心服务性能数据看板，统计汇总压测结果性能报表，使服务性能趋势可视化展现；开通大促压测绿色通道，常态化压测达标的服务，大促压测绿通。
2.3 实施流程
常态化压测接口：优先选择覆盖业务主流程的核心接口，ops-review的核心服务中星级认证的接口。
压测模版任务选择基准：
2）梳理链路依赖接口调用，按照最差下游依赖的承载上限并结合自身接口性能从调用量的角度设立压测模板；
压测频率：链路长复杂接口，建议每天执行；自闭环的系统推荐按照上线频率执行。
压测窗口期： 和产研确认业务低峰期间，指定常态化压测任务的执行时间。
压测环境： 生产环境单机或者小集群进行常态化压测。
压测数据： 建议使用R2录制线上的真实流量作为常态化压测的入参，保证压测结果的有效性。
压测结果： 每次压测结果测试同学值班跟进，对不达标的接口，行云bug持续跟踪，协同研发进行性能分析、问题排查、压测任务维护。
压测工具：forcebot常态化压测及R2
三、常态化计划
•2023-Q2季度推广至平台技术部-配运和交易条线，618大促前平台技术部完成核心0级读服务125个基于jdos3.0的常态化压测建设。
四、基于流量录制的高保真压测
随着业务的不断发展，不仅用户流量、业务场景越来越复杂，服务的调用关系和模块也越来越繁多，数据构造越来越困难，简单的数据集无法模拟线上真实的业务流量，流量配比不真实容易导致压测结果失真。
4.1 流量录制压测
利用R2平台录制线上流量进行压测的基本框架图如下所示：
2、测试人员在泰山平台R2工具管理端创建录制任务，任务启动时下发操作指令到ducc，再通过ducc下发录制指令到线上服务端（线上服务已经开启pfinder并接入R2平台），开始录制线上流量；
4、流量录制完成后，可以在Forcebot压测工具平台创建压测脚本，Forcebot平台已经和R2平台对接，请求R2服务端获取回放流量地址，进行录制流量装载；
4.2 录制压测流量
根据系统架构及压测场景分析，选择需要录制流量的接口及场景。
•而有的应用是多个核心接口，需要混合场景压测，在录制流量时需要同时对多个接口流量进行录制；
① 创建压测流量录制任务：选择入口应用，设置录制任务的名称及文件大小，注意：一般在进行压测流量录制时，建议录制所有场景流量，尽可能地高保真生产实际流量；在创建录制任务时，建议录制文件大小不高于2G；
4.3 压测脚本创建
4.3.1 单接口压测脚本
在脚本管理中创建一个JSF回放脚本，编辑录制信息配置，选择要压测的应用、对应的R2录制流量任务，Forcebot支持在京东私服平台上搜索或者手动上传JSF文件（jar包），平台会自动然后解析jar包中的类和方法，调用jsfOpenApi获取接口别名和直连的ipPort。通过以上方式获取接口服务相关信息，快速搭建jsf接口的环境。选择要压测的接口、jsf别名以及压测的方法后自动会生成压测脚本；生成的脚本中默认关联了选择的R2录制任务中的录制请求，可以直接进行压力测试。
4.3.2 多接口混合压测脚本
在实际生产中，我们的应用往往会提供多个接口，或者同一个接口上会提供不同的方法服务。我们在压测的时候如果仅仅按照单个接口来进行压测，这样的压测数据仅能反应单场景交易下系统本身的性能表现，而实际生产中，尤其是大促时，系统往往在同一时间需要处理多个接口请求，系统资源也是多个接口共享的，所以混合场景压测更能反映系统真实处理能力；
步骤1： 生成标准的JSF回放脚本
在自定义脚本之前，先按照3.3.1所述生成一个标准的JSF回放脚本，以及依赖的lib文件都会自动生成；
步骤2： 生成自定义脚本
其中ipList是指定被压测的服务器ip及端口，如果接口别名下是集群部署，只想要对其中某一台机器进行压测的话，需要指定ip及端口；
⑤ 相同接口不同方法的混合压测脚本创建同理，区别在于同一个接口，别名是一致的，不需要额外再指定其他接口别名；
步骤3： 导入附件jtm.properties
jtm.replay.recent.record.num=1，指定每次压测时都获取绑定周期性流量录制任务最新录制的流量；
4.4 双十一大促高保真压测实践
在本次双11大促，物流promise业务线全面采用R2流量录制的方式进行大促压测，自压测结果更加接近线上接口性能，真实性达到90%以上；为大促资源扩容评估提供了更加精准的数据支撑。同时，通过这次高保真压测，我们发现多个系统性能问题，其中包含极限业务场景下的可用率降低的问题。
五、USF常态化压测实践
forcbot常态化压测工具支持，压测任务复用（支持流量录制压测任务）、可配置性能基线包括响应时间TP99和TPS的和服务器CPU等资源指标设进行性能基线设置，并根据性能基线判断压测是否达标，以及可以设置不达标的压测结果自动创建行云缺陷，进行性能问题跟踪处理。并且还提供压测监控对比数据以及压测结果历史记录，便于对性能结果和问题进行分析，自动发送压测邮件通知，及时同步性能压测结果。
•1、支持压测任务的复用，可使用历史的压测任务，不用单独创建压测任务和脚本，支持jsf、http、自定义的jimdb、jmq以及回放脚本。
•3、可支持流量录制。
•5、可配置压测的是否达标基线（生效：是否将指标用于压测达标率统计；勾选会作为指标之一，不勾选则在达标率计算时不作为统计指标。 达标：勾线生效的指标值同时满足时，压测结果即为达标；反之，有任何一个指标值不满足条件，压测不达标。
5.1 压测物料准备
压测数据：
•录制接口服务是USF3.0线上TOP4的接口，已完成星标治理，达到三星的接口，完成可用率、TP99、以及有降级和限流方案治理。
压测场景： 混合场景设计（模型）
应用部署拓扑图：
压测环境：
•与线上的现数据库、缓存保持一致，均已同步线上数据。
1.线上机器配置 * 实例数60
3.数据库配置：16C64G内存
5.应用服务器配置：4C8G
5.2 压测风险评估
•压测环境选择：
•2）稳定后再复用生产环境的应用和中间件进行常态化压测。
•选择业务低峰期进行压测，结合ump监控USF服务的高峰期一般在白天的上午6-9、9-11、14-17系统使用的高峰期。所以目前任务执行的窗口期是工作日17:40。目前是有人值守的报警信息及时处理，监控应用和数据库相关情况。
•压测上下游链路梳理，确定压测范围、压测量级、压测时间，同步相关方达成共识。
5.3 常态化压测任务创建
5.3.1 压测模版任务选择准则
性能拐点场景或者压到预期值的场景（如CPU60%或者TPS达标），一般建议不要压测系统资源饱和的状态场景。
此处USF我们选用历史的压测任务，是接口满足双十一的吞吐TPS的场景，此时服务器的CPU压力在27%，数据库的CPU在36%。
5.3.2 压测定时任务设置
•常态化压测执行的频率以及执行的时间参考根据代码上线周期和业务的调用低峰时间段综合定制。
1执行模式-RPS模式
并非脚本中所有接口的QPS的和，而是脚本中占比最大的接口对应的压测目标值，如果配置错误会导致过度发压。
2 执行模式-并发数模式
5.3.3 压测基线设置
如果关联的压测任务是混合脚本，那么可以分步骤设置多个接口事务（事务名称默认：forcebot.测试方法名 ）的性能基线。 一般关注的指标平均TPS、TP99、错误数、CPU监控。允许波动的范围，根据接口的实际情况给一定的波动空间。若大于设置的波动范围，并且选中设置提交行云缺陷，就会自动提交行云bug，便于bug跟踪闭环。
1 自定义性能基线设置
•USF的findUserInfo服务设置示例：
•TP99基础值=12ms，允许波动范围50%。（12ms-18ms） 上浮动，时间相关的是向上浮动。
•CPU监控基线值=25%，允许波动范围=20%。（20%～30%）上下 浮动
事务名称： 目前无法自动识别,可以写脚本的中事务名称默认是forcebot.测试方法名，也可以增强脚本使用自定义事务名称就是
TestUtils.transactionBegin("findUserInfo"，即findUserInfo
性能基线设置例如：接口性能tp99在12ms左右，此时基线值设置为12ms，允许波动的范围如果设置为10%，那允许的波动范围就是12ms*10% = 13.2ms，超过13.2ms就认为压测不通过，这显然是不合理的，此时需要根据我们的接口tp99最大接受范围来设置允许波动百分比。
2 多接口性能基线设置
默认事务名称：forcebot.测试方法名
自定义事务名称： 如TestUtils.transactionBegin("findUserInfoByOrgCode";
5.3.4 行云缺陷跟踪
5.3.5 监控定位问题
1 监控数据-TPS
2 监控数据-TP99
3 执行记录对比详情PK
USF相关接口的压测结果，达标和不达标的PK如下：发现是12-04存在一次错误调用，进一步跟踪错误产生原因