姚俊杰(闻羽)
一、压测需求和目标
1.1 前言
全链路压测在海拍客已经有2~3年的实践。海拍客是一家母婴互联网产业平台，致力于将海内外新的品牌、新的知识、好的消费理念通过全中国母婴店，带给三线以下城市的消费者，帮助消费者完成消费升级。
随着业务的快速发展，我们日常遇到的系统性能压力问题也逐渐出现，甚至经常会因一些突发的营销活动，导致系统性能指标突然暴涨，可能导致我们系统的瘫痪。最近几年，随着系统架构的不断升级，以及电商业务的多样化和各种促销活动，传统性能测试已不能满足现有系统架构的需要。
所以，全链路压测变得越来越基础 ，也越发重要。经历了两年多的全链路压测实践与总结沉淀，通过录制流量回放，模拟大促真实流量，串联线上全部系统，让核心系统流程成倍比的同步放大用户真实流量，海拍客压测平台和全链路压测体系已经能够承担起公司整个后台服务稳定性的重任。
1.2 压测需求和目标
目前公司压测需求一般来源以下几个方面 ：常规划压测、年终大促保障、新系统上线支持、技术升级验证、站点容量规划以及性能瓶颈探测等。
1、常规化压测 ：由于日常需求迭代可能对系统产生的影响，通过定期定时常规化的压测 保障核心业务接口的性能 避免意料之外的故障
2、年终大促保障 ：在大促业务峰值到来前，通过充分的性能压测，确保重大活动等峰值业务稳定性，保障峰值业务不受损。
3、新系统上线支持 ：在新系统上线前，通过执行性能压测能够对系统的负载能力有较为清晰的认知，从而结合预估的潜在用户数量保障系统上线后的用户体验。
4、技术升级验证 ：在系统重构过程中，通过性能压测验证对比，可以有效验证新技术的高效性，指导系统重构。
5、站点容量规划 ：通过性能压测实现对站点精细化的容量规划，指导分布式系统机器资源分配。
6、性能瓶颈探测 ：通过性能压测探测系统中的性能瓶颈点，进行针对性优化，从而提升系统性能。
二、压测流程
2.1 压测平台
主要支持两种压测方式：
1）基于jmeter二次开发的http和dubbo单接口压测
2）线上流量录制回放
两种压测方式支持的功能比较：
流量录制与回放技术的具体实现可参考：
流量录制与回放技术在海拍客的应用
2.2 压测流程
经过几年的实践和演进，海拍客全链路压测流程已非常完整，主要流程如下：
三、业务架构梳理
梳理清楚端到端的请求链路、技术架构、分层结构、模块划分，以及RPC、消息、缓存、数据库等中间件的使用情况，分析潜在的瓶颈点，并针对性的增加监控指标、制定应急预案。
3.1 通过借助平台工具链路抓取pinpoint链路，梳理压测某个应用时同时要关注的上下游依赖
下图是流量从用户入口，到hop网关层、mall2c应用，以及下层依赖的ucenter、icp、crm-core等服务的应用级链路。
3.2 借助dubbo服务框架，查询应用依赖
比如buy应用压测时，需要同时关注下面依赖的其他应用，为后续申请压测标和影子库做准备。
3.3 系统架构需要关注的链路如下：
每个组件都可能产生不同的性能问题：
四、压测场景设计
首先确定压测目标之后，我们开始进入正题。压测场景的设计主要包括：业务场景建模、测试数据准备、压测执行三个关键步骤。下面我们用实战的方式说明每个步骤的常见做法。
4.1 业务场景建模：
- 主要来源于链路分析、业务分析，以便建立的压测模型可以更真实的还原生产环境的压力分布，这点最主要压测负责人对于技术架构和业务场景的理解，
- 由于营销活动的玩法特异，根据需要可适当融合两种压测方， 录制回放与接口回放并行施压的场景 毕竟达到压测目的为第一优先级。
- 流量预估 根据压测目标确定该业务场景下的压测最大流量（预估QPS算法= （录制流量时QPS*当日的GMV÷ 目标的GMV）±流量变化（业务需求迭代可能导致的流量变化）
- 数据预热 是否需要执行缓存预热相关操作等等
4.2 测试数据准备可分为两类：
4.3 压测执行：
1）基础硬件：压测机 ，目前压测平台采用施压机分布式部署，通过压测平台实现并发执行 使压测达到预期的并发量。基本可以达到并发量上万 以及 几十万的并发量
2）压测轮次：主要关注的指标 ：压测目标平均QPS、压测时长、回放倍数=本轮计划压测QPS÷（录制的请求数÷录制时间）
3）被压系统健康度：上下游系统资源情况、接口响应时长、中间件服务是否正常，时刻做好中断压测的准备（压测环境：线上环境）
五、压测执行前事项确认
六、线上实时监控
监控为什么单独拿出来说呢，实际上在整个压测链路中，我暂且给它分为三大块：①方案设计 ②实时监控 ③报告分析与总结。
实时监控有多种：
- 工具本身简单的压测接口维度的数据监控
- 被压应用维度的服务器监控
- 实时监控大盘-hisee（目前我们在这）
6.1 实时监控大盘需要关注的相关指标
观察顺序可以依次按照 从大到小维度 快速浏览一遍，提前发现一些误操作或者异常操作而导致的应用性能异常，然后及时终止压测。
监控维度如下：
监控大盘可以多维度实时查看系统指标，在压测执行过程中能方便的跟踪系统情况，以便随时处理突发情况和调整压测计划。
示例图如下：
6.2 问题排查辅助工具：
- trace调用链路-pinpoint
- 日志平台
七、沉淀与总结
7.1 沉淀：
首先要弄清楚我们需要沉淀些什么 ，哪些沉淀值得参考 且 有指导意义的，例：
- 沉淀一套压测标准化流程
- 沉淀一套保障流程
- 沉淀联合压测下各应用的性能数据：压测环境，QPS、CPU，每台pod所承受的秒级QPS
- 沉淀 性能问题的分析以及排查过程文档
7.2 总结：
那总结又包含哪几块呢，我大概理解：
- 压测结论 结果怎么样是总结的原因之始
- 压测过程 压测准备阶段 、压测执行阶段
- 压测问题汇总 即压测发现的问题亦是我们的成果
- 后续Action 梳理压测流程或压测执行 过程中可优化的事项，指导下次压测；
- 压测方案 回顾压测方案的设计合理性 以及 个业务线数据分析记录
- 预计压测 做计划，把握好每次压测的节奏
结语：
- 经过2年左右的实践与优化，无论是传统单接口压测 亦或是 基于流量回放技术的全链路压测已趋于常规化、标准化，整体的压测技术应用也走在行业前列
- 压测平台很好的赋能了性能测试团队，性能测试团队的 数据统计分析能力、问题排查能力 都得到大幅提升；
- 性能测试团队 也更好的支撑了公司业务系统的稳定性建设，也一步步在完善 各领域的质量保障手段