2. 服务画像基础：服务画像的定义、关键维度与数据采集
在构建弹性伸缩SLA体系之前，必须回答一个核心问题：我们到底在伸缩什么？ 传统监控仅关注CPU和内存，而云原生环境下的服务具有高度动态、多依赖、行为复杂的特征。服务画像（Service Profiling）正是为了解决这一认知鸿沟而提出的方法论——它是对服务运行态特征的结构化建模，是定义弹性伸缩SLA的“数字底座”。
2.1 服务画像的定义
服务画像是指通过多维度数据采集与特征提取，对服务在特定时间窗口内的资源需求模式、流量特征、依赖关系和运行时行为进行抽象建模的过程。其输出是一个可量化的、随时间演进的“服务特征向量”，用于指导弹性策略的制定与SLA阈值的校准。
核心认知： 服务画像不是静态的元数据登记，而是持续更新的运行时快照。每一次弹性伸缩决策，本质上都是将当前服务画像与历史画像进行匹配，从而预测下一步的资源需求。
服务画像与传统的“服务拓扑”或“CMDB”有本质区别：
| 对比维度 | 传统CMDB/服务拓扑 | 服务画像 |
|---|---|---|
| 数据性质 | 静态配置、人工维护 | 动态运行时、自动采集 |
| 更新频率 | 天/周级 | 分钟/秒级 |
| 核心用途 | 故障定位、资产盘点 | 弹性伸缩、容量规划、SLA定义 |
| 维度丰富度 | IP、端口、版本、负责人 | 资源、流量、依赖、行为、成本 |
| 时间敏感性 | 无时间维度 | 强时间窗口（滑动窗口聚合） |
2.2 关键维度：资源、流量、依赖、行为
服务画像由四个核心维度构成，每个维度下包含若干可采集、可量化的指标项。这四个维度共同决定了弹性伸缩SLA的“感知边界”。
2.2.1 资源维度（Resource）
描述服务对基础设施资源的实际消耗与预留情况。这是弹性伸缩最直接的输入信号。
- 计算资源： CPU使用率（均值/P99）、内存使用量、GC暂停时间（Java）、线程池活跃度。
- 存储资源： 磁盘IOPS、吞吐量、缓存命中率、本地临时存储使用量。
- 网络资源： 网络入/出带宽、连接数、连接建立速率、丢包率。
2.2.2 流量维度（Traffic）
描述服务接收和发出的请求特征。流量是触发弹性伸缩的“第一推动力”。
- 请求量： QPS（每秒查询数）、RPS（每秒请求数）、并发连接数。
- 请求特征： 请求体大小分布、响应体大小分布、请求方法分布（GET/POST/PUT）。
- 流量模式： 周期性（日/周峰谷）、突发性（秒级毛刺）、趋势性（长期增长）。
2.2.3 依赖维度（Dependency）
描述服务与上下游组件之间的调用关系与健康状态。依赖的抖动会直接放大弹性伸缩的误判风险。
- 上游依赖： 网关/负载均衡器状态、客户端SDK版本、调用超时配置。
- 下游依赖： 数据库连接池水位、缓存集群延迟、消息队列堆积量、外部API可用性。
- 依赖拓扑： 调用链深度、扇出系数、关键路径识别。
2.2.4 行为维度（Behavior）
描述服务在运行过程中的内部状态变化与异常表现。行为维度是判断“是否需要立即伸缩”的关键依据。
- 启动行为： 冷启动耗时、预热期资源消耗曲线、就绪检查通过时间。
- 伸缩行为： 扩容/缩容响应时间、新实例流量接入速率、优雅下线完成时间。
- 异常行为： 错误率（5xx/4xx）、熔断触发次数、降级策略生效比例、重试风暴检测。
实践要点： 在定义弹性伸缩SLA时，依赖维度和行为维度往往比资源维度更具决定性。例如：数据库连接池打满导致的请求排队，单纯扩容应用实例无法解决问题，反而可能加剧依赖压力。服务画像必须包含依赖健康度评分，作为弹性伸缩的“刹车信号”。
2.3 画像数据的采集来源
服务画像的数据不能依赖单一来源，必须建立多层级、多协议的采集体系。根据数据产生的层级，可以将采集来源分为以下四类：
| 采集层级 | 典型工具/协议 | 采集内容 | 采集频率 |
|---|---|---|---|
| 基础设施层 | Prometheus Node Exporter、cAdvisor、云厂商监控Agent | CPU、内存、磁盘、网络、容器级资源 | 10s - 30s |
| 平台/中间件层 | Kubernetes Metrics Server、Kube-state-metrics、Istio/Envoy指标 | Pod状态、HPA指标、Sidecar代理指标、服务网格遥测 | 15s - 60s |
| 应用层 | Micrometer / OpenTelemetry SDK、JMX Exporter、自定义埋点 | QPS、延迟分布、错误率、线程池状态、缓存命中率 | 5s - 15s（高精度） |
| 业务/日志层 | ELK/Loki、Jaeger/Zipkin、业务指标平台 | 调用链追踪、业务成功/失败率、用户行为日志 | 分钟级（离线聚合） |
常见陷阱： 很多团队只采集基础设施层和应用层的指标，忽略了平台/中间件层的依赖数据。例如：Kubernetes HPA仅依赖CPU指标进行伸缩，当服务因数据库连接池耗尽而变慢时，CPU可能反而下降（请求被阻塞），导致HPA误判为“负载降低”而缩容，形成恶性循环。服务画像必须包含中间件依赖的健康信号。
2.4 画像数据的采集架构
为了支撑弹性伸缩SLA的实时计算，画像数据的采集架构需要满足低延迟、高可靠、可回溯三个要求。以下是一个推荐的采集架构设计：
2.5 画像数据的质量要求
低质量的服务画像会导致弹性伸缩SLA产生“垃圾进、垃圾出”的后果。在采集阶段必须建立以下质量约束：
- 完整性： 每个画像维度至少有一个可采集的指标，不允许出现“维度空洞”。例如：如果无法采集应用层QPS，则必须通过流量镜像或网关日志进行补充。
- 时效性： 画像数据的采集延迟不应超过弹性伸缩决策周期的1/3。例如：如果HPA评估周期为15秒，则画像数据采集延迟应控制在5秒以内。
- 一致性： 同一服务的多个数据源之间，时间戳必须对齐到相同的精度（推荐毫秒级），避免因时间偏差导致画像特征失真。
- 可回溯性： 画像数据必须保留至少30天的历史窗口，用于SLA基线校准和弹性策略的离线仿真验证。
最佳实践： 在采集层引入“画像健康度探针”，定期检查每个维度的数据质量。例如：如果某个服务的“依赖维度”连续3个采集周期无数据，则自动标记该服务画像为“不完整”，并触发告警。弹性伸缩SLA应拒绝基于不完整画像的自动决策。