1. 明确目标:(1)并发连接数、峰值请求/秒(RPS);(2)响应时延目标(P95,P99);(3)错误率上限。 (2)准备预算与时间窗口。 (3)测试环境应与生产尽量一致,包括数据库规模、缓存策略与CDN配置。
2. 推荐供应商:AWS(EC2+ALB+AutoScaling)、GCP(Compute Engine+Load Balancer)、Azure、DigitalOcean/Vultr作为成本型;建议选择支持自动扩容、弹性公网IP和私有网络的供应商。 (1)如需全球CDN,优先Cloudflare/CloudFront/Fastly。 (2)若追求裸金属性能,可考虑Packet/Equinix Metal或Vultr的Bare Metal。
3. 步骤:(1)在美东/美西建VPC/子网,设置NAT与路由表;(2)创建多个可用区的后端实例组,开启私有子网内部通信;(3)部署公网负载均衡(ALB/GLB),配置目标组与健康检查;(4)开启ELB访问日志与VPC流日志以便分析。
4. 实操:(1)选择CPU/内存比合适的实例(例如CPU密集型选择c系列);(2)创建AMI镜像/快照,预装nginx/uwsgi/redis/监控agent;(3)设置ssh key、安全组仅开放必要端口(80/443/22/监控端口);(4)使用配置管理工具(Ansible/Terraform)实现可复用部署。
5. 关键点:(1)nginx:worker_processes auto, worker_connections 65536, keepalive_timeout 15;(2)应用线程/进程池根据CPU核数与内存调整,设置合理的连接池大小;(3)使用Redis/Memcached做热点缓存;(4)数据库读写分离,开启连接池并建立只读副本。
6. 推荐命令:(1)编辑 /etc/sysctl.conf 添加 net.core.somaxconn=65535 net.ipv4.tcp_tw_reuse=1 net.ipv4.ip_local_port_range="10240 65535" net.netfilter.nf_conntrack_max=262144,执行 sysctl -p;(2)调整 ulimit -n 200000,写入 /etc/security/limits.conf;(3)调大 epoll/线程池配置以应对高并发。
7. 实操:(1)将静态资源上CDN并设置Cache-Control长缓存;(2)启用gzip/brotli与HTTP/2;(3)设置缓存层TTL与灰度排期,测试缓存命中率;(4)对动态接口做边缘缓存或Stale-while-revalidate策略降低源站压力。
8. 步骤:(1)部署Prometheus+Grafana或使用云监控(CloudWatch/Stackdriver);(2)收集指标:CPU/内存/网络/磁盘、请求量、错误率、延迟P50/P95/P99;(3)集中式日志(ELK/EFK)用于追踪错误与慢请求;(4)设置告警阈值并验证告警推送。
9. 推荐工具:k6(脚本化、易并发)、JMeter(功能强)、Locust(Python)、wrk(轻量)。 实操:(1)选k6:写脚本定义场景、虚拟用户、阶段(ramp-up);(2)若需要更大负载,在多个云实例上并行运行k6,并集中收集结果;(3)保证负载发生器不是瓶颈(CPU/网卡监控)。
10. 步骤:(1)编写 script.js,定义 export default function(){ http.get('https://example.com') } 并设置 options 包含 stages;(2)在控制机安装 k6:curl -s https://dl.k6.io/install.sh | bash;(3)分布式运行:在多台机器并发启动 k6 run --vus 1000 --duration 10m script.js;(4)实时监控目标服务与负载机资源。
11. 策略:(1)分阶段:先单节点压测到瓶颈,再横向扩展测试AutoScaling;(2)逐步增加RPS观察系统行为;(3)模拟真实用户:带有登录、搜索、带Cookie的场景;(4)注意清理缓存或重置数据库状态以保证测试一致性。
12. 收集项:(1)请求成功率、错误分类与堆栈;(2)延迟P50/P95/P99随时间曲线;(3)系统资源利用率与Autoscale事件时间线;(4)网络吞吐与丢包。 报告结构:摘要→测试环境→测试用例→步骤与脚本→结果图表→瓶颈分析→优化建议→结论与建议上线方案。
13. 示例步骤:(1)准备3台后端实例+ALB+数据库副本+Redis;(2)配置监控与日志;(3)本地化脚本并在3台负载机上分布式运行k6,先做10分钟稳定试验,再做1小时峰值试验;(4)观察Autoscaling是否按策略扩展并比较扩容前后延迟变化;(5)形成报告并复测验证优化有效性。
14. 注意:(1)分布式压测会产生大量公网流量与计算费用,提前申请预算;(2)在云上压测其他账户资源需遵循云厂商压测政策并提前备案;(3)在公网压测前通知CDN/ISP以免触发防护或封禁。
15. 答:AWS/GCP/Azure在弹性伸缩、全球负载均衡、监控与日志成熟度上更可靠,适合大型站群;DigitalOcean、Vultr、Linode适合成本敏感的中小规模测试;需要裸金属或特殊网络性能时可选Equinix Metal或Packet。
16. 答:在压测前设置CDN绕过或使用特定测试路径并禁用边缘缓存(或在报告中区分缓存命中率),对动态接口使用Cache-Control:no-cache;同时在压测脚本中使用唯一请求头或查询参数以避免缓存命中。
17. 答:关键结论应包含峰值可承载RPS和并发、P95/P99延迟、错误率与错误类型、瓶颈部位(CPU/网络/数据库/连接池)、AutoScaling表现与建议的扩容策略、以及针对发现的问题给出明确优化清单与复测计划。