1. 课程导论：为什么需要服务画像与资源画像？容量压测与水位基线的关系
在微服务架构与云原生环境日益复杂的今天，容量保障工作面临三大核心挑战：流量不可预测、资源争抢隐蔽、故障边界模糊。传统的“拍脑袋定指标”或“全链路压测后凭经验调参”的方式，已无法满足高可用、低成本、快迭代的业务要求。
本课程导论将回答两个根本问题：为什么必须建立服务画像与资源画像？以及容量压测与水位基线之间到底是什么关系？
1.1 容量保障的常见痛点
在引入画像体系之前，大多数团队在容量评估中会遇到以下典型问题：
| 痛点 | 表现 | 后果 |
|---|---|---|
| 黑盒评估 | 不清楚每个服务的真实资源消耗模型 | 压测场景失真，线上容量预估偏差 > 50% |
| 口径混乱 | CPU/内存/IO 的水位阈值靠经验或默认值 | 频繁误告警或漏告警，运维信任度低 |
| 压测与基线脱节 | 压测结果无法直接转化为日常监控基线 | 每次大促前重复压测，无法沉淀资产 |
| 资源浪费 | 过度冗余或频繁扩缩容 | 云成本居高不下，SLA 却未显著提升 |
核心结论：没有画像的容量管理，本质上是“盲人摸象”。服务画像与资源画像，正是将黑盒变为白盒、将经验变为数据的关键基础设施。
1.2 什么是服务画像？什么是资源画像？
这两个概念是整门课程的基石，它们的定义与区别如下：
| 维度 | 服务画像 (Service Profiling) | 资源画像 (Resource Profiling) |
|---|---|---|
| 关注对象 | 业务逻辑单元（API、微服务、中间件） | 物理/虚拟资源（CPU、内存、磁盘、网络） |
| 核心指标 | QPS、RT、错误率、调用链拓扑、依赖关系 | 利用率、饱和度、错误数、分配量、争抢系数 |
| 产出物 | 服务依赖图、性能基线、伸缩策略模板 | 资源规格推荐、水位阈值、装箱比模型 |
| 典型用途 | 压测场景设计、容量预估、限流降级策略 | 资源预算、成本优化、故障域规划 |
简单来说：服务画像回答“业务长什么样”，资源画像回答“机器扛不扛得住”。两者互为输入、缺一不可。
1.3 容量压测与水位基线的关系
容量压测是“体检”，水位基线是“健康标准”。没有基线，压测结果只是一堆孤立的数据；没有压测，基线则缺乏验证依据。它们的关系可以用以下流程概括：
实践要点：在建立闭环时，建议先花 2-3 周完成核心服务的静态画像（依赖、规格、历史监控数据），再基于画像设计压测场景。压测后产出的拐点数据（如 CPU 达到 70% 时 RT 开始抖动）直接写入水位基线配置。切忌跳过画像直接压测，否则容易陷入“压测通过但线上仍出故障”的困境。
1.4 画像体系带来的核心收益
引入服务画像与资源画像后，容量管理将从“被动救火”转变为“主动规划”。具体收益体现在以下四个层面：
- 压测效率提升：画像数据可直接生成压测模型，减少场景设计时间 60% 以上。
- 基线科学化：水位阈值不再依赖“经验值”，而是基于历史分位数 + 压测拐点 + 安全余量计算得出。
- 成本可量化：资源画像帮助识别“超卖”与“浪费”，典型场景下可节省 15%-30% 的云资源开支。
- 故障半径可控：通过服务依赖画像，提前识别单点故障和级联风险，制定精准的限流降级策略。
1.5 本章小结
服务画像与资源画像不是理论概念，而是容量工程落地的第一块基石。它们与容量压测、水位基线共同构成一个持续演进的闭环体系。在后续章节中，我们将逐一拆解：如何构建服务依赖画像？如何提取资源消耗特征？如何设计压测场景？如何制定可执行的水位基线口径？
前置提醒：本课程所有方法均基于生产环境可落地原则。请确保在开始画像之前，你的监控系统至少具备分钟级粒度的 CPU、内存、网络、磁盘 IO 以及应用层 QPS/RT 数据采集能力。如果缺失，请优先补齐可观测性基础设施。