最近忙于公司的全链路压测平台调研和技术规划文档输出工作, 参考了全网能搜到的业内大厂的全链路压测方案, 这里做个汇总, 以及将个人认为可以落地的方案做一个关键点整理.
技术链接
滴滴全链路压测解决之道
阿里巴巴的全链路压测
阿里怎么做双 11 全链路压测?
美团全链路压测自动化实践
全链路压测平台在美团中的实践
饿了么全链路压测的探索与实践
饿了么全链路压测平台的实现与原理
有赞全链路压测方案设计与实施详解
京东全链路压测系统 (ForceBot) 架构解密
罗辑思维在全链路压测方面的实践和工作笔记
大厂方案 point 整理
1, 逻辑思维
定位: 保障业务稳定性的核心基础设施;
重要性: 业务知名度高 & 技术团队承受压力大;
核心目标: 服务可用性, 稳定性, 扩展性;
2, 阿里巴巴
流程管理: 有效的方案 + 充足的准备 + 靠谱稳定的平台;
流量识别: 压测流量标记透传落影子库, 同一 API 多次压测, 防止被拦截, 同一 IP, 白名单机制;
系统改造:1. 业务改造: 流量识别, 单一性问题, 限流拦截, 报表剔除, 动态校验;
数据准备: 活动方案确定→业务模型评审→技术架构 & 压测范围 & 数据量级 & 数据形式;
1. 业务模型数据: API & 流量量级 & 配比 & 转化漏斗→业务抽象模型(漏斗比例不变);
2. 基础数据构造: 数据量级 & 真实性(买家 & 卖家, 商户 & 商品, 价格);
系统预热: 缓存准备, 系统 load 准备;
登录准备: 模拟登录场景长链接(用户逐步登录), 保护 user 服务;
压测方式: 0 点脉冲, 系统摸高, 限流降级, 破坏性验证(容灾恢复演练);
京东
场景: 买家, 卖家;
数据: 历史双十一峰值流量作为基础流量, 动态增加并发压力;
流量: 日常流量, 大促流量(主库写压力大);
压测引擎: jmeter/Ngrinder;
测试脚本 / 数据: Git / 本地?
启动模式: 梯度递增, 脉冲, 稳定水位验证;
执行方式: 立刻执行, 定时执行;
测试场景: 压力源, 虚拟用户数, 测试脚本, 执行方式, 启动模式;
压力源: docker 集群, 多组, 无状态(状态检查), 共享资源;
压测数据: 统一存储(ES), 合并计算(jmeter),grafana 展示(需优化);
流量识别, 风控放行;
有赞
流量模型: 流量来自于买家侧, 正常水位 - 突刺 - 回落;
机器成本: 核心链路按量扩容, 卖家侧服务按需扩容, 错峰;
核心链路: 人多 & 链路复杂 & 梳理核心链路→汇总筛选→剔除→确认;
压测策略: 单机单链路基准→单机混合链路容量→全链路压测(水位)→专项预案演练;
流量预估: 监控统计 - QPS, 连接数, IOPS,RT, 缓存命中率, consumer group,topic;
datapool: 基础数据脱敏, 脚本 / 测试数据, 统一提供存储 / 下发 / 分割功能;
影子存储: DB 路由:1. 同 instance 不同 schema(风险大);2. 不同 instance 同 schema(安全性高, 成本高);
Redis 路由:1.key 值加统一前缀;2.Redis-client 做路由;
ES 路由:1.index 统一加前缀, 提供统一 ES client 做数据访问, 由 client 做路由;
应用变更: 微服务, 统一隔离, 流量标透传存储;
流量下发: 数据文件: 按照场景区分(考虑漏斗模型 - 转化);
压测脚本:1. 不同场景的流量配比;2. 每个场景按 URL 从上至下做转化(gatling);
水位检测: 压测过程中,1. 实时采集各应用服务的资源使用情况 + RT+TPS + 成功率;2. 流量干预, 保护生产服务不受影响;
压测实施:1. 基础中间件开发, 路由策略, 框架升级, 压测引擎选型开发调试 - 基础架构;
2. 业务改造升级 + 线下验证(功能验证, 手动点击, 数据落影子库)- 功能测试;
3. 业务改造升级 + 生产验证(功能验证, 手动点击, 数据落影子库)- 功能测试;
4.datapool 准备: 数据生成, 脚本文件切割下发 - 业务开发 & 测试;
5. 小流量下发验证 - 测试域同学;
6. 模拟真实场景压测验证 - 团队协同;
压测方式: 流量递增 / 爬坡(梯度增加, 优化扩容);
链路梳理: 非核心链路 - 去依赖解耦;
长期规划: 轮询化: 线时链路测试机器人, 实时检测;
常规化: 减少人力成本投入;
日常化: 尽可能少熬夜, 白天完成;
图形化: 链路压测规划图形化展示, 与业务结合, 一键完成数据准备工作;
美团
全链路压测思路
系统总体设计
重要程度: 系统稳定性建设中的核心重要位置, 也是最有效的方案;
技术背景: 验证峰值流量下系统服务的伸缩性和稳定性;
验证新上线功能的可用性, 稳定性;
限流, 降级, 熔断, 告警灯故障演练;
线上服务容量评估
技术方案: 获取线上真实流量 - 流量录制 & 流量回放;
快速创建压测环境 - 环境 / 服务隔离, 流量标透传, 灵活伸缩容;
支持多协议类型 - http,tcp,webscoket,rpc,dubbo......
实时监控 & 过载保护;
必备功能: 数据构造, 压测隔离, 场景管理, 动态调整, 实时监控, 压测报告, 分布式......
整体架构: Web 管理端: 数据构造, 环境准备, 任务管理, 场景管理, 压测动态调整, 报表展示;
调度中心: 压测资源调度, 任务分发, 机器资源管理;
压测引擎: 流量构造, 模拟;
监控组件: 实施监控, 压测数据统计, 聚合分析, 展示;
链路梳理: 工具化, 提供自动构建压测入口链路完整的依赖信息, 辅助提效手段;
挡板服务: 配置化手段, 完成外部依赖等相关接口的 Mock 配置, 无需在业务代码中嵌入压测判断逻辑;
数据构造: 流量复制, 存储, 清洗, 解析, 组合展示, 偏移脱敏处理;
链路追踪: 链路匹配分析定位
服务隔离: 大促(业务低谷)& 常规(机器隔离)
数据隔离: 同库不同表(影子表)- 成本低, 风险较高
机器管理: 动态扩容, 灰度升级, 异常摘除
压测引擎: jmeter&nGrinder&gatling
内存优化: 内存管理 & JVM 参数
监控: 秒级监控, 实时展示, 告警, 服务保护
日志: 压测日志采样, 展示
服务治理: 限流熔断降级保护
注意事项: 小步快跑, 及时响应, 项目推广, 开放生态, 基础资源 & 赋能;
饿了么
用例管理: 建立用例, 文件上传, 分类管理;
压测执行: 一键启动, 可指定线程数 & 预热时间 & 测试周期和负载机, 文件切割分发, 分布式执行;
监控数据: TPS,ART,Error% 实时展示;
实时数据持久化 - influxdb, 设置过期时间;
冷数据持久化至 MongoDB;
测试报告: 用例执行完毕, 自动生成测试报告;
集群监控: 压测机使用状态监控, 作为共享资源, 提示用户可用的测试机;
安全保障: 权限管理 & 异常操作限制;
分布式压测实现: 二次开发;
异常干预: 水位超限 & 服务保护 & 阈值告警 & 压测触发失败(形成闭环);
influxdb 轮询: http 请求轮询频次较高, 需优化;
预配置: 提前配置, 时段保留, 节省时间, 提高效率;
服务保护
权限分级: 高峰期禁止直行;
压测干预, 随时手动触发禁止动作, kill 所有压测机上运行的压测进程;
限流熔断: 根据错误率和告警阈值判断, 达到或超过自动熔断;
兜底服务: 系统不可用需要停止测试时, 外部强制停止, 过载保护;
以上内容, 来自各大厂方案的汇总整理, 仅供参考...
来源: https://www.cnblogs.com/imyalost/p/12004026.html