前言
每年的618&双11，对于电商公司来说都是一次大考。为了应对活动当天的瞬时峰值流量，进行全链路压测是很有必要的一项技术工程。
而且全链路压测除了对核心链路进行性能问题排查优化之外，还能发现很多日常迭代中累积的小问题，对团队协同作战能力，也是一个很好的提升。
演进
从去年双11到今年618，我司的全链路压测体系建设，总体来说经历了如下三次演进：
|
时间节点 |
环境 |
压测方式 |
优点 |
缺点 |
|
19年双11 |
1:1等比环境 |
Jmeter分布式压测 |
1）完全生产等比环境 2）不用担心造成生产脏写 3）不用担心影响正常生产业务 |
1）环境成本高昂 2）联调部署麻烦耗时 2）无法真实模拟生产环境 |
|
核心系统重构 |
混部环境 |
Jmeter分布式压测 流量标+影子库+Mock |
1）重构服务可以视为生产服务 2）部分业务走生产环境(灰度验证) 3）压测团队精力更加专注&谨慎 |
1）环境复杂，问题排查困难 2）可能会对生产造成脏写 3）时间紧张，需要做更多取舍 |
|
20年618 |
生产环境 |
Jmeter分布式压测 流量标+影子库+Mock |
1）环境成本几乎为0 2）完全真实环境，请求流转更真实 3）团队协同能力快速提升 |
1）需要更精细的前期梳理 2）只能流量低峰压测（通宵） 3）无法做到流量&机器隔离 |
从上可看出，生产环境全链路压测的优点还是很多的，总结下来重点是下面几点：
1）大幅度节省环境成本；
2）完全真实请求场景；
3）快速发现存在问题；
4）推动技术建设落地；
5）团队协同能力提升；
6）故障响应处理提效；
准备工作
1、链路梳理
1-业务场景
业务场景的梳理，主要目的是识别核心链路+场景模型；
2-上下依赖
根据核心链路+场景模型的梳理，分析出它们的上下游依赖（强弱依赖、MQ、job）；
3-接口文档
随着业务版本迭代，涉及到接口逻辑变更，信息无法做到及时更新。如果无法提前进行梳理，在服务联调过程中容易出现各种莫名其妙的问题。
4-流量配比
流量配比是个很玄学的问题！
真实的用户请求走哪些链路，各自占比多少？不同的业务场景，日常和周末、大促相比，占比又是多少？
这些数据都是实时变化的，我们能做的，只有针对性的评估计算出一个大体范围，并留有一定冗余空间。
2、模型梳理
1-压测范围
其实压测范围和核心链路梳理很类似，不过范围界定更多的是从业务角度来划分。对电商公司来说，核心的业务永远是商品、库存、订单、支付！
2-压测模型
压测模型，以我个人经验，主要可以从如下几个维度去划分：
1）单机单接口基准（接口级别）
单机单接口的压测，可以通过梯度增加请求的方式，观察接口随着请求的增加，其性能表现&资源损耗的变化。
2）单机混合链路场景（服务级别）
单机混合场景，大多还是通过梯度增加请求的方式，观察服务级别的性能表现，重点关注3个指标：
①.安全水位（CPU50%）
②.告警水位（CPU70%）
③.最大水位（CPU≥90%&Load5≥150%）
3）全链路压测场景（生产集群）
针对生产集群的全链路压测，需要涉及的压测模型较多，一般有如下几种：
①.梯度增加模型：主要为了探测集群模式下系统的最大吞吐量（也避免压垮服务，造成事故）
②.固定并发模型：验证系统长期处于负载下的稳定性；
③.脉冲并发模型：探测系统的健壮性、验证限流熔断等服务保护措施的正确性&可用性；
④.超卖验证模型：对电商业务来说，主要针对一些限时抢购&秒杀的场景；一般这种场景，会涉及到分布式锁、
缓存、数据一致性等技术点；玩不好的话，容易造成客诉、资损、甚至服务异常宕机！
3-流量模型
出于保密原则，流量模型请参考我之前的博客：全链路压测第一次实践
4-压测方案
做完前期的准备工作，建议输出一份压测方案，核心就一句话：任务拆解，设定里程碑！
3、资源准备
1-ECS预购
一般大促前夕，云服务资源都会比较紧张，因此需要进行预购。资源预购需要注意如下几点：
1）保持和生产服务同规格配置，尽可能在同一可用区；
2）预购数量可以根据生产现有服务数量&一轮压测结果&预期指标进行评估，留有一定备用机器；
2-DB升配
大促期间流量会比较高，因此可以提前对核心业务DB进行一定规格的升配，后续根据压测优化结果调整。
3-SLB扩容
目前阿里云SLB，单个最大支持5W的QPS。为了满足峰值流量冲击及预期指标，需要提前对其进行扩容。
4、专项梳理
1-压测check项
由于压测是在生产环境开展，因此在压测开始前，要针对相关服务的Mock配置、影子库表、流量标传递、测试用户数据预热等相关项进行确认排查，确保压测抱回导致脏写。
2-定时job统计
由于部分业务是通过定时job去调度执行的，为了避免压测时job调度对服务的性能影响，因此需要专门梳理相关的定时job等任务，针对性的进行临时关闭或者调度策略调整。
3-降级开关梳理
为了应对活动当天的峰值流量，可以对一些弱依赖或者非关键业务进行降级操作，比如"小红点"、"SQL校验"、
"退款到账时间"、商品推荐等。
PS：建议将相关的降级操作都通过配置或者开发的方式来处理，便于一键启停，降低操作难度。
4-稳定性预案
稳定性预案一般分为如下几种：
1）应用级别：如降级、熔断；
2）系统级别：日志归档、网关防爬、风控；
3）定时任务：常见的定时job如批处理，定时获取数据；
4）缓存预热：如商品信息、费率信息；
5）异常处理：针对一些异常情况，如优惠券不可用、地址信息获取失败（18年淘宝）；
优化提效
1、压测方式
目前生产全链路采用的是基于jmeter的分布式压测，但jmeter本身的分布式压测会将压测数据由slave上报给master，这样会带来一定的性能损耗。
针对这点我们将压测数据写入influxDB，然后由grafana进行查询，做聚合计算并展示。由于分布式压测需要将测试数据同步到对应的压测机上，
针对这个问题我们开发了一键上传，压测一键启停的功能，这样既提高了并发调整的效率，对于异常场景，也能做到尽快的流量熔断保护功能。
2、后端优化
1）通讯协议升级：服务内部调用由http升级为dubbo的RPC调用；
2）监控采样频次：降低了监控数据采样率，由100%降低到10%；
3）数据缓存：针对部分非实时强一致性数据，进行了缓存操作；
4）JVM参数：针对JVM启动参数，设置Xms和Xmx保持一致，减少扩堆动作；
5）线程优化：经过多轮压测对比，最终评估得到结果，undertow的work_threads修改为16N；
3、前端优化
CDN、静态资源、大图压缩、资源内置；
监控建设
监控体系建设是一个长期的过程，针对大促，我们主要优化了如下几点：
1-实时拓扑图
2-决策系统：核心链路监控大盘若干
3-监控大盘：业务域监控大盘
这样更便于在也测和大促时及时发现和排查问题。
其他专项
1-规格自检升级：mq、db、redis、slb、es、MongoDB；
2-数据库巡检：索引、慢SQL、连接数、proxy层check、负载check；
3-架构图梳理：机房、可用区、业务集群分布、slb、网络升级、slb；
4-安全专项：防爬、防DDoS；
针对大促，运维团队也对相关的服务资源进行了规格巡检和升配扩容，保障618大促。