01
为什么要进行链路级的压测，单机、单系统压测为何不可达成目标？ 线上容量 ≠ 单机容量 * 数量：线上运行环境是复杂多变的，即使配置相同的机器也不能保证性能的完全一致，并且，除机器本身性能外，线上容量还受制于机器间的网络通信、资源争夺、数据库交互、集群管理、缓存效率、负载不均等等多方面的影响，任何一点都有触发性能瓶颈的可能，从而不能单纯的只通过单机 * 数量去评估线上容量。 单系统无法体现用户角度的性能：用户请求是链路级的，而链路中各个系统的容量规划往往不对齐的。受不同的用户场景，用户来源，路由策略等影响，流量在链路上的分布情况不是一成不变的，整个链路上的瓶颈点非常不易发现和预测。因此需要进行全链路的多地域多来源的测试，并构建各种流量参数比例的流量场景模拟不同业务场景的用户行为等。 基于线上环境 or 测试环境进行链路级压测？ 线上压测更准确：线上环境更加复杂，测试环境无法保证搭建效果与线上一致，任意一个配置的不一致都可能导致容量的差异，而无法体现真实用户使用效果，且搭建可用于链路级压测的测试环境资源需求量巨大，可行性不高。 对线上环境进行压测的风险如何规避？ 例如防止压测数据污染线上数据，污染缓存，干扰线上指标统计，误触线上的熔断降级，避免没做好准备的外部依赖方被压测打挂等等。
02
梳理播放链路拓扑
识别链路系统，明确核心链路，协作目标更聚焦 识别链路风险，明确对用户的影响，包括用户数据、业务指标、监控数据等 识别技术依赖，明确业务系统和基础平台的改造、升级目标，寻找最折中方案，降低不确定性的同时，工作量最低 识别关键数据，便于压测场景（即压测词表）的构造
推动各系统研发梳理各自业务内拓扑文档 与研发脑暴梳理结果，分析关键性能影响点、挖掘问题及风险 基于文档绘制交互拓扑图
明确压测核心链路：播放、会员权益系统、会员权益监控系统等 识别脏数据风险：数据统计的影响等 明确压测工具需求： 流量控制：拦截统计消息 数据隔离：支持mysql、redis等的影子库、影子表，规避线上写入脏数据 流量监控：QPS、响应耗时、CPU、内存、中间件监控、上游服务监控等 明确核心性能影响因素： 片源时长、付费类型、会员身份 明确核心场景： 春晚：免费超长视频（历史峰值占比50%，非真实数据） 热剧：付费视频（付费流量历史峰值占比60%，非真实数据）
定制流量更贴近性能目标：单url不具代表性，且链路不全，不利于性能影响点的分析；录制流量在特定场景下有一定意义，比如春晚流量等，但由于难以分析出各场景比例，比如不同时长片源占比，付费片源占比，难以精准判断性能影响点，从而无法有效说明压测目标及效果
明确压测目标
压测链路：播放、会员、用户链路 压测环境：线上各机房+全网 压测场景：春晚（>4h超长视频占比50%，非真实数据）、热剧（付费流量占比60%，非真实数据） 容量目标：不低于历史峰值n倍容量目标
压测工具调研
施压能力（LoadMaker）： 单机房高压QPS的发压能力：可针对施压集群进行扩容 单机房亿级词表的调度能力（根据施压QPS+时长制定）：多任务并发实现 梯度增压、暂停增压能力：用于压测过程观测，及时止损 链路控制（Rover）： 流量控制：拦截数据统计：支持，Rover平台配置即可，同时构造测试设备双重规避 数据隔离：支持影子库、影子表，规避写入脏数据：不支持场景可通过构造测试账号规避 流量监控：QPS、响应耗时、CPU、内存、中间件监控、上游服务监控等：支持，并结合业务自身监控观测数据更全面 工具性能（Rover agent）： 对服务性能0/低影响 施压入口（LoadMaker）： 支持外网网关：一期优先使用内网网关
构造压测场景
测试数据入库：测试账号、测试设备ID、视频信息（时长、付费类型等） 明确不同维度下的属性比例： 词表生成-支持不同属性占比的配置化生成方案： 交叉组合：支持多层属性的组合，可灵活配置不同属性及下一级属性的占比配置
词表生成耗时过长：亿级词表单机模式已无法满足效率需求，评估单纯通过优化生成脚本已无法有效提升效率
词表生成容器化：依托内部jenkins服务，基于iks进行容器化部署，实现多容器并行生成词表，大大提高效率
压测方案及规划
根据关键时间节点进行时间倒排，保证压测前各项准备事务全部ready 制定压测场景规划，明确压测时间点、各业务负责人、紧急预案，为尽可能规避对用户的影响，大QPS压测需控制在低峰时段，并提前进行邮件审批和周知
制定压测实施checklist，尽可能详尽说明每一步操作和确认项，避免遗漏 压测前一天进行一轮线下验证，确认施压能力、环境连通性，保证压测顺利实施
CPU、内存占比：<=70% 响应耗时：根据业务而定 请求错误率：0.01% 业务错误率：0.01%
压测执行
压测checklist
施压策略： 明确并发数及步调时间：提前与研发沟通确认，并可在执行过程中调整优化 阶梯施压：缓慢增压、流量突袭 实时反馈观测结果，如有问题，随时暂停或停止施压，及时止损 压测执行过程中数据观测： Rover平台观测压测流量：QPS、耗时、CPU、内存、上游服务QPS 各业务内部监控平台观测整体流量：QPS、耗时、CPU、内存、上游服务QPS、业务错误率、降级/熔断等灾备流量、缓存命中率等 数据库/中间件性能监控 分析观测数据，评估链路容量 容量评估：应用、数据库、中间件，最终QPS是否达成，瓶颈在哪里 灾备能力评估：降级、熔断策略，阈值是否合理，在多大QPS下触发了灾备策略，是否仍有优化空间 给出压测结论及待解决问题
03
播放链路首次线上压测，且实现对真实用户0影响 完成历史峰值n倍QPS下播放各系统服务的容量评估 协同各业务完成7次扩容、5次灾备策略优化、4次性能问题修复等等 支撑春晚、热剧期间大流量下播放不出故障
04
本文由高可用架构转载。技术原创及架构实践文章，欢迎通过公众号菜单「联系我们」进行投稿
