5.3.2 全链路压测与容量评估

当具备完善的监控体系后，就能够对于平台网站做出一定的访问和压力评估，平台网站都会存在自身业务的高峰和低谷，从成本考虑业务肯定不能允许大量资源在低峰期的浪费，更不能接受业务高峰期平台扛不住压力被打垮影响用户体验，所以在这样的背景下平台网站的稳定性工作就离不开全链路压测与容量评估了，本章将重点讲解这部分的内容。

1.明确压测目标

明确压测目标是明确压测粒度、整理业务链路、设计压测模型、压测实践的先决条件。只有明确做事的目标，才能稳准快的对症下药。目前常见的压测目标可分为三类：

•找出系统水位

描述：在系统资源濒临阈值（例如：CPU利用率濒临80%or内存溢出or硬盘使

用率濒临80%）或者资源报警时，QPS以及对应rt为该系统的水位。

场景：一般用于评估业务系统可承受的QPS，从而判断当前系统架构是否可满足

业务需求。若系统性能存在性能瓶颈，则需要进行性能优化。

•判断业务是否可正常运行

描述：在稳定的QPS下判断系统是否存在性能瓶颈，核心or全部业务链路是否可正常运行。

场景：大型运营活动前，基于预估QPS对系统进行压测，提前找出性能瓶颈，保证运营活动正常运行；业务链路核心功能发布前，需要对系统进行压测，避免新功能对系统性能造成影响。

•实现预期QPS目标

描述：压测需要知道平台系统是否能否满足业务的洪峰需求，为了应对业务大促或者平台活动洪峰访问需要实现对应的QPS峰值指标观测，确保各环节水位正常。

2.设计压测模型

压测模型是基于对压测目标、压测粒度、业务链路的理解，在压测实践前进行的压测功能体系化抽象，是压测实践的技术方案。由于不同的业务场景重要性不同，需要满足的可用性、稳定性不同，所以压测模型需要基于具体的业务链路进行具体分析，不可一概而论。压测模型的关键点如下：

•确定压测场景

基于压测目标及业务链路的梳理确定压测场景。例如：同一个业务链路中无上下游依赖的功能接口，可在同一压测场景中通过QPS配比进行压测；同一业务链路中具有上下游依赖的功能接口，开发同学将该部分接口抽象为一个压测接口后，可与其他无依赖关系的业务接口在同一场景中通过QPS配比进行压测；不同的业务链之间无依赖，但多业务链并发访问对整体系统性能存在重要影响，该部分业务链对应的的功能接口可在同一场景中通过QPS配比进行压测；重点接口可在单独场景压测；等等。

•确定压测策略

一般包含 限流策略，降级策略，QPS配比策略等。

3.压测实践

压测的工具目前比较多，本节就PTS压测做简单介绍。

性能测试PTS(Performance1Testing1Service)是具备强大的分布式压测能力的

SaaS压测平台，可模拟海量用户的真实业务场景，全方位验证业务站点的性能、容量和稳定性。PTS旨在简化性能压测本身的工作。PTS目标是将性能压测本身的工作持续简化，使您可以将更多的精力回归到关注业务和性能问题本身。在PTS平台上，您可以用较低的人力和资源成本，构造出最接近真实业务场景的复杂交互式流量，快速衡量系统的业务性能状况，为性能问题定位、容量配比、全链路压测的流量构造提供最好的帮助。进而提升用户体验，促进业务发展，最大程度实现企业的商业价值。

应用业务场景：

《云上业务稳定性保障实践白皮书》——五.行业客户稳定性保障实践——5.3.2 全链路压测与容量评估（2） https://developer.aliyun.com/article/1231900?groupCode=supportservice