共计 7285 个字符，预计需要花费 19 分钟才能阅读完成。
作者：京东物流 王江波
一、常态化压测建设目标
为什么做常态化压测？
目前面临次要问题，性能问题滞后发现，给大促带来不可控危险。目前日常需要频繁迭代，系统配置的变更、上下游依赖的变动、服务器资源置换等诸多因素均会对系统性能产生肯定影响；日常很难做到对所有新我的项目或需要上线前后都进行压测，这就往往导致了很多性能问题推延到大促压测期间才被发现。
大促备战压测备战工夫紧、工作多，压测备战压力较大， 在 11.11 复盘中，有些部门工时统计中，压测占了较大一部分工作量。而且性能问题相较于其余问题，优化难度大、修复周期长，在大促备战多专项并行资源缓和状况下，频繁的零碎调优给整个大促带来不可控的危险因素。
基于此，引入常态化压测的伎俩 ，通过每周或每月的定期压测行为，继续把控系统性能体现，保障服务稳定性；同时将需要上线引起的 性能问题前置裸露 ， 及时定位优化问题；加重备战压力，晋升压测效率。
二、常态化压测施行流程
2.1 常态化压测
常态化压测是依照肯定周期或特定触发条件而进行的自动化压测行为，通过在单容器 / 集群的周期性压测，从而达到监控性能指标变动、及时发现服务性能衰减危险的指标。
2.2 施行策略
通过三步走的形式，由浅入深，逐渐在平台技术部落地常态化压测：
第一步 单机试点： 因为首次应用常态化压测，通过 隔离单机环境的形式，理解了常态化压测的压测思路、执行流程、压测平台能力反对及危险点摸排；
第二步 集群试点：在履约、根底平台抉择星级外围服务， 在线上环境试点 小集群（2- 3 台）常态化压测 工作执行，从线上业务影响、上下游依赖影响、压测平台能力反对、线上压测危险管控等多方面评估常态化压测 在线上集群落 地的可行性；
第三步 全面开展： 依据履约、根底平台的线上常态化压测集群实际，推广至全平台技术部 ， 并联合 Kit 压测工具，建设外围服务性能数据看板，统计汇总压测后果性能报表，使服务性能趋势可视化展示；开明大促压测绿色通道，常态化压测达标的服务，大促压测绿通。
2.3 施行流程
常态化压测接口：优先选择笼罩业务主流程的外围接口，ops-review 的外围服务中星级认证的接口。
压测模版工作抉择基准：
1）依据大促生产峰值流量模型联合服务器资源应用状况设置压测模版工作；
2）梳理链路依赖接口调用，依照最差上游依赖的承载下限并联合本身接口性能从调用量的角度设立压测模板；
3）对于没有上游依赖的服务，依照零碎本身最佳解决能力，从吞吐量或 cpu 角度设立压测模版；
压测频率：链路长简单接口，倡议每天执行；自闭环的零碎 举荐依照上线频率执行。
压测窗口期： 和产研确认业务低峰期间，指定常态化压测工作的执行工夫。
压测环境： 生产环境单机或者小集群进行常态化压测。
压测数据： 倡议应用 R2 录制线上的实在流量 作为常态化压测的入参，保障压测后果的有效性。
压测后果： 每次压测后果测试同学值班跟进，对不达标的接口，行云 bug 继续跟踪，协同研发进行性能剖析、问题排查、压测工作保护。
压测工具：forcebot常态化压测及R2
三、常态化打算
•2023-Q1 在履约、根底进行常态化压测试点，造成最佳实际，并进行技术赋能分享。
•2023-Q2 季度推广至 平台技术部 - 配运和交易条线，618 大促前平台技术部实现外围 0 级读服务 125 个 基于 jdos3.0 的常态化压测建设。
四、基于流量录制的高保真压测
双十一大促刚过，在大促备战时很重要的一个环节是对各大外围服务零碎进行压测，以保证系统在大促期间的稳定性，同时依据压测后果为大促扩容提供数据反对。那么如何进行高保真压测，使压测后果更靠近于线上真实性能体现？在整个压测过程中，压测数据的筹备是其中十分重要的环节，很大水平上决定了压测后果是否实在牢靠；
随着业务的一直倒退，不仅用户流量、业务场景越来越简单，服务的调用关系和模块也越来越繁多，数据结构越来越艰难，简略的数据集无奈模仿线上实在的业务流量，流量配比不实在容易导致压测后果失真。
目前各大公司进行模块级压测或者全链路压测根本都是采纳流量录制的形式，先对录制的流量进行存储，而后对流量进行编辑、过滤后通过压测引擎向被测服务发压；本章联合 Forcebot 压测平台，具体介绍如何应用 R2 平台录制线上流量进行高保真压测。
4.1 流量录制压测
利用 R2 平台录制线上流量进行压测的根本框架图如下所示：
1、用户拜访线上服务，产生基于用户的实在流量；
2、测试人员在泰山平台 R2 工具治理端创立录制工作，工作启动时下发操作指令到 ducc，再通过 ducc 下发录制指令到线上服务端（线上服务曾经开启 pfinder 并接入 R2 平台），开始录制线上流量；
3、录制的流量会上报至 R2 工具端，并且将采纳数据进行存储；
4、流量录制实现后，能够在 Forcebot 压测工具平台创立压测脚本，Forcebot 平台曾经和 R2 平台对接，申请 R2 服务端获取回放流量地址，进行录制流量装载；
5、Forcebot 平台获取到流量后，即能够失常通过压力机向被测服务发压，执行压测工作。
4.2 录制压测流量
依据零碎架构及压测场景剖析，抉择须要录制流量的接口及场景。
•若压测时仅思考单个接口，那么录制单个接口流量即可；
•而有的利用是多个外围接口，须要混合场景压测，在录制流量时须要同时对多个接口流量进行录制；
•当然，你也能够在录制工作中设置仅录制申请或响应合乎某种特定业务场景的流量；
① 创立压测流量录制工作：抉择入口利用，设置录制工作的名称及文件大小，留神：个别在进行压测流量录制时，倡议录制所有场景流量，尽可能地高保真生产理论流量；在创立录制工作时，倡议录制文件大小不高于 2G；
流量录制策略蕴含了手动录制、定时录制及周期性录制。在进行常态化压测时，为了防止流量过于老旧与以后生产流量偏差较大，能够在 R2 平台上创立一个周期录制流量的工作，按天或按周录制一遍生产流量，以保障压测数据的即时性。
② 抉择要录制的起始服务，能够抉择多个接口同时录制，平台会展现出接口调用链路，能够针对调用链路上的服务或中间件等同时开启录制，而后抉择录制的实例，设置后工作之后就能够开始执行录制。
流量录制实现后，即可在 forcebot 压测平台创立压测脚本；
4.3 压测脚本创立
4.3.1 单接口压测脚本
在脚本治理中创立一个 JSF 回放脚本，编辑录制信息配置，抉择要压测的利用、对应的 R2 录制流量工作，Forcebot 反对在京东私服平台上搜寻或者手动上传 JSF 文件（jar 包），平台会主动而后解析 jar 包中的类和办法，调用 jsfOpenApi 获取接口别名和直连的 ipPort。通过以上形式获取接口服务相干信息，疾速搭建 jsf 接口的环境。抉择要压测的接口、jsf 别名以及压测的办法后主动会生成压测脚本；生成的脚本中默认关联了抉择的 R2 录制工作中的录制申请，能够间接进行压力测试。
如下图所示，你能够进行内网环境校验，能够校验脚本是否能失常获取到流量并向对应接口发动了理论申请，这也是压测前的必要步骤，验证脚本通过之后进行保留，就主动生成了相应的脚本及 lib 文件；如果是单接口场景压测，到这里就能够应用该脚本去创立压测工作了。
值得注意的是，这种形式生成的脚本是不可编辑的，须要编辑脚本得自定义创立脚本；到这里，聪慧的你肯定想到了，这里页面仅能抉择一个接口的其中一个办法，如果想要对同一个接口的不同办法或不同接口进行混合压测应该怎么办呢？不要焦急，答案曾经在路上了。。
4.3.2 多接口混合压测脚本
在理论生产中，咱们的利用往往会提供多个接口，或者同一个接口上会提供不同的办法服务。咱们在压测的时候如果仅仅依照单个接口来进行压测，这样的压测数据仅能反馈单场景交易下零碎自身的性能体现，而理论生产中，尤其是大促时，零碎往往在同一时间须要解决多个接口申请，系统资源也是多个接口共享的，所以混合场景压测更能反映零碎实在解决能力；
在进行混合压测前，须要首先明确各个接口场景在同一时间段内的调用量比例是多少，在创立压测脚本的时候，须要依据这个比例来设置每个压测场景下压力申请占比 rate；
步骤 1：生成规范的 JSF 回放脚本
在自定义脚本之前，先依照 3.3.1 所述生成一个规范的 JSF 回放脚本，以及依赖的 lib 文件都会主动生成；
步骤 2：生成自定义脚本
在步骤 1 中生成的默认脚本是不可编辑的，能够查看代码时生成自定义脚本，而后对自定义的脚本进行编辑。
① 首先定义接口门路及其办法，对应不同接口的别名，而后是依据不同的接口进行流量加载；
其中 ipList 是指定被压测的服务器 ip 及端口，如果接口别名下是集群部署，只想要对其中某一台机器进行压测的话，须要指定 ip 及端口；
② 针对不同的接口创立回放事务，此处接口门路、接口的加载流量、接口别名等都须要一一对应。rate 为该脚本中波及的多个接口的调用量比例，比方接口 1：接口 2：接口 3 =7:8:5（可参考大促或日常调用峰值期间各接口的调用量比例），则须要在 testCase 中设置相应的压力比。
③ 因为多接口波及接口门路、流量源以及接口别名各不相同，须要将默认的无参 doReplay 办法，批改为传参办法
④ 脚本批改实现后点击保留
⑤ 雷同接口不同办法的混合压测脚本创立同理，区别在于同一个接口，别名是统一的，不须要额定再指定其余接口别名；
步骤 3：导入附件 jtm.properties
在步骤 2 中自定义脚本编辑实现后，进行校验执行时还无奈胜利，因为脚本还短少流量录制回放的附件文档。保留脚本后，返回上一级目录，将步骤 1 中生成的规范 groovy 脚本中的附件 jtm.properties 下载到本地，而后再将该附件文档上传到咱们自定义的脚本中，并批改脚本的附件文档。在附件文档开端增加
jtm.replay.recent.record.num=1，指定每次压测时都获取绑定周期性流量录制工作最新录制的流量；
4.4 双十一大促高保真压测实际
有了 R2 流量录制平台提供的便捷，让获取线上流量不再成为难事，能够帮忙咱们疾速的实现压测数据的筹备，同时压测流量高保真还原理论业务场景。
在本次双 11 大促，物流 promise 业务线全面采纳 R2 流量录制的形式进行大促压测，自压测后果更加靠近线上接口性能，真实性达到 90% 以上；为大促资源扩容评估提供了更加精准的数据撑持。同时，通过这次高保真压测，咱们发现多个零碎性能问题，其中蕴含极限业务场景下的可用率升高的问题。
下图为采纳 R2 流量录制压测、军演压测与双十一大促开门红的性能比照。
五、USF 常态化压测实际
基于 focebot 的常态化压测能力，抉择 USF 抉择 3 星外围服务进行常态化压测实际，抉择 TOP4 外围接口，应用 R2 的录制线上流量，依据大促的流量模型进行的混合场景常态化压测，继续监控 USF 的外围接口的性能状况。
forcbot 常态化压测工具反对，压测工作复用（反对流量录制压测工作）、可配置性能基线包含响应工夫 TP99 和 TPS 的和服务器 CPU 等资源指标设进行性能基线设置，并依据性能基线判断压测是否达标，以及能够设置不达标的压测后果主动创立行云缺点，进行性能问题跟踪解决。并且还提供压测监控比照数据以及压测后果历史记录，便于对性能后果和问题进行剖析，主动发送压测邮件告诉，及时同步性能压测后果。
目前 forcebot 的常态化压测反对以下性能：
•1、反对压测工作的复用，可应用历史的压测工作，不必独自创立压测工作和脚本，反对 jsf、http、自定义的 jimdb、jmq 以及回放脚本。
•2、可配置定时执行工作，灵便执行工夫。
•3、可反对流量录制。
•4、可主动创立行云缺点
•5、可配置压测的是否达标基线（失效：是否将指标用于压测达标率统计；勾选会作为指标之一，不勾选则在达标率计算时不作为统计指标。达标：勾线失效的指标值同时满足时，压测后果即为达标；反之，有任何一个指标值不满足条件，压测不达标。
以下为基于 USF 进行的常态化压测。
5.1 压测物料筹备
压测数据：
•抉择业务高峰期 14：00-16:00 录制线上 10% 对应 6 台机器流量，录制【公共集群】入参 1G。（后续会思考多个集群）
•录制接口服务是 USF3.0 线上 TOP4 的接口，已实现星标治理，达到三星的接口，实现可用率、TP99、以及有降级和限流计划治理。
压测场景： 混合场景设计（模型）
利用部署拓扑图：
压测环境：
压测环境目前是与线上同配置的单实例的 UAT 环境。
•与线上的现数据库、缓存保持一致，均已同步线上数据。
•压测环境数据库的配置和缓存服务的配置与线上保持一致。
1. 线上机器配置 * 实例数 60
2. 应用服务器配置：4C8G
3. 数据库配置：16C64G 内存
4. 压测机器配置
5. 应用服务器配置：4C8G
6. 数据库配置：16C64G 内存
5.2 压测危险评估
•压测环境抉择：
•1）先在同配置的 UAT 环境常态化压测，依据性能后果一直调整性能基线
•2）稳固后再复用生产环境的利用和中间件进行常态化压测。
•工作执行窗口：
•抉择业务低峰期进行压测，联合 ump 监控 USF 服务的高峰期个别在白天的上午 6 -9、9-11、14-17 零碎应用的高峰期。所以目前工作执行的窗口期是工作日 17:40。目前是有人值守的报警信息及时处理，监控利用和数据库相干状况。
•压测链路同步：
•压测上下游链路梳理，确定压测范畴、压测量级、压测工夫，同步相干方达成共识。
5.3 常态化压测工作创立
5.3.1 压测模版工作抉择准则
•复用历史的压测工作（模版工作），间接创立常态化压测工作。理论选用历史的压测工作场景时，倡议依据零碎的理论状况来抉择，个别能够抉择 性能拐点场景或者压到预期值的场景（如 CPU60% 或者 TPS 达标），个别倡议不要压测系统资源饱和的状态场景。
•示例：此处 USF 咱们选用历史的压测工作，是接口满足双十一的吞吐 TPS 的场景，此时服务器的 CPU 压力在 27%，数据库的 CPU 在 36%。
模版工作抉择：
查看工作，能够看到该场景下的执行的脚本，发压相干设置并发线程数、执行的模式（并发模式和 RPS 模式）、执行工夫，可依据须要进行肯定的调整。
5.3.2 压测定时工作设置
•能够通过周期或者 Cron 表达式指定执行周期，usf 此处应用 Cron：0 40 17 ? 每天下午 5 点 40 执行。并在此处设置指标线程数和执行时长。（这个会笼罩压测工作中的线程数和执行时长）。
•常态化压测执行的频率以及执行的工夫参考依据 代码上线周期和业务的调用低峰时间段 综合定制。
1)执行模式 -RPS 模式
绑定的是压测工作是 RPS，那么咱们创立的常态化压测工作也是 RPS 模式。指标 QPS 设置，并非脚本中所有接口的 QPS 的和 ，而是 脚本中占比最大的接口对应的压测目标值，如果配置谬误会导致适度发压。
2) 执行模式 - 并发数模式
绑定的压测工作是并发模式，那么咱们创立的常态化压测工作是并发执行模式。指标线程数设置。
5.3.3 压测基线设置
•依据压测工作对应的压测场景，依据事务名称（接口办法）设置正当的压测基线，如果关联的压测工作是混合脚本，那么能够分步骤设置多个接口事务（事务名称默认：forcebot. 测试方法名）的性能基线。 个别关注的指标均匀 TPS、TP99、谬误数、CPU 监控。容许稳定的范畴，依据接口的理论状况给肯定的稳定空间。若大于设置的稳定范畴，并且选中设置提交行云缺点，就会主动提交行云 bug，便于 bug 跟踪闭环。
•基线指标设置留神点：如果基线值特地低的状况，那容许的稳定范畴百分比须要设置的比拟大才能够，否则很小的稳定都会被认为压测不通过。基线稳定范畴，具体接口具体分析，研发和测试达成共识，
1) 自定义性能基线设置
•USF 的 findUserInfo 服务设置示例：
•TPS 基准值 =2700，容许稳定范畴 10%。（2430-2970）高低浮动
•TP99 根底值 =12ms，容许稳定范畴 50%。（12ms-18ms）上浮动，工夫相干的是向上浮动。
•谬误数基准值 =0，容许稳定范畴 0。
•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 行云缺点跟踪
对于不满足性能基线设置各项指标值，常态化压测后果就为不达标，若该工作配置开启了主动创立行云缺点，就会对不达标的执行后果主动提交行云缺点，这样能够保障 bug 生命周期各阶段可追溯，保障问题及时处理解决。
5.3.5 监控定位问题
能够查看一段时间该服务的性能趋势，如果接口性能稳定较大，须要进一步排查接口性能降落的起因。
1) 监控数据 -TPS
2) 监控数据 -TP99
3) 执行记录比照详情 PK
执行记录中，有脚本版本和，是否达标以及 bug 详情。选中达标和不达标的后果，进行 PK 比照，比照项中有 TPS、TP99、Error Per Second 等指标。
USF 相干接口的压测后果，达标和不达标的 PK 如下：发现是 12-04 存在一次谬误调用，进一步跟踪谬误产生起因
5.3.6 邮件发送压测后果
设置接管人邮箱，将邮件抄送给研发和测试相干人，压测后果邮件中会提供压测数据汇总显示，如果压测后果中某一项指标不达标时（超出设定值及稳定范畴）时，则此次工作视为不达标。联合监控信息以及执行时间段的日志与研发独特定位问题或者是性能基线指标的调整。
邮件如下：
作者：京东物流 刘江波
