“买买买”的节日都过去了，我们聊一聊应对峰值流量的全链路压测

lsekfe

　前言
　　每年的618&双11，对于电商公司来说都是一次大考。为了应对活动当天的瞬时峰值流量，进行全链路压测是很有必要的一项技术工程。
　　而且全链路压测除了对核心链路进行性能问题排查优化之外，还能发现很多日常迭代中累积的小问题，对团队协同作战能力，也是一个很好的提升。
　　演进
　　从去年双11到今年618，我司的全链路压测体系建设，总体来说经历了如下三次演进：

　　从上可看出，生产环境全链路压测的优点还是很多的，总结下来重点是下面几点：
　　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大促。