第 2 章 微服务度量基本概念

微服务有很多优点，但缺点也很明显。本章简要介绍微服务的一些局限， 并揭示度量为什么对微服务如此重要，然后系统全面地从术语、内容、层次、方法选择等角度 剖析度量是什么以及如何做。

2.1 微服务的局限

2.1.1 局限

微服务不是灵丹妙药，有一利必有一弊。

同样的事情，交给一个人做（单体服务）与交给一群人（多个微服务）做，差别巨大:

  • 一个人做的好处是无沟通协调成本，出了问题只需找一个人

  • 一群人做可以群策群力，齐头并进，但沟通协作成本直线上升

微服务的主要局限:

  • 不断增长的微服务数量会导致 信息屏障

  • 必须应对分布式系统固有的各种故障（网络延迟、抖动、丢包等）

  • 问题的发现与诊断更加困难，需要多个团队共同协作

  • 数据一致性 难以保证

  • 服务编排 的复杂性

  • 分布式事务 的处理

2.1.2 解决方案

针对微服务的局限，可以从以下方面来改善:

1. 化繁为简

各司其职，简化对外接口和彼此的交互，把复杂性隐藏封装在内部。

2. 快速迭代

"天下武功，唯快不破":

  • 快速演变

  • 快速伸缩

  • 快速上线

3. 自动化

  • 自动化集成：构建部署流水线 (CI/CD)

  • 自动化测试：单元测试、API 测试、消费者契约测试

  • 自动化运维：度量驱动运维，日常操作全部自动化

4. 容错设计

  • 分流: 负载均衡，将流量合理分派给健康的节点

  • 限流: 根据设定的阈值，限制请求速率

  • 断流: 断路器模式，智能断开或恢复与下游的连接

5. 度量

及时发现问题、修复问题并避免类似问题。度量让你"见微知著"， 不放过任何一个产品线上的问题。

2.2 度量的重要性

"Own your codes on production" -- 掌控你在产品线上的代码

作为软件工程师，不能仅仅交付产品给运维人员就完事了。 你必须深刻了解你的代码在产品线上是怎么运行的，是否和你想的一样。

度量就是你了解产品线运行情况的 眼睛:

  • 没有度量 = 盲人摸象: 你不知道系统的真实状态

  • 有了度量 = 了如指掌: 你可以看到系统的全貌

度量驱动开发 (MDD) 的核心理念:

Plan → Do → Check → Act (PDCA)
  ↑                      │
  └──────────────────────┘

  • Plan: 制定度量计划，确定关键指标

  • Do: 实现度量代码，收集度量数据

  • Check: 分析度量数据，发现问题和趋势

  • Act: 基于度量结果采取行动，持续改进

2.3 度量内容

2.3.1 按度量的目标划分

1. 度量工作 (Measure Your Work)

  • 工作量: 代码行数、提交次数、Sprint 完成率

  • 进度: 里程碑达成率、迭代速率

  • 效率: 构建时间、部署频率、变更前置时间

  • 质量: 代码覆盖率、缺陷密度、代码审查通过率

小技巧

推荐使用 DORA 四个关键指标来度量团队的交付效能:

  1. 部署频率: 组织多久部署一次代码到生产环境

  2. 变更前置时间: 从代码提交到代码在生产环境中成功运行所需时间

  3. 变更失败率: 部署导致生产环境故障的百分比

  4. 服务恢复时间: 从生产环境故障中恢复需要多长时间

2. 度量产品 (Measure Your Production)

  • 健康度: 服务可用性、错误率、响应时间

  • 使用量: QPS、并发连接数、活跃用户数

  • 趋势: 负载变化趋势、资源消耗趋势

  • KPI: 业务关键绩效指标

3. 度量用户 (Measure User Behavior)

  • DAU/MAU: 日活跃/月活跃用户数

  • 用户旅程: 用户在系统中的行为路径

  • 功能使用率: 各功能模块的使用频率

  • 满意度: NPS (净推荐值)、APDEX (应用性能指数)

2.3.2 按度量的层次划分

微服务度量层次

层次

关注点

典型指标

基础设施层

硬件和操作系统

CPU、内存、磁盘、网络

中间件层

数据库、缓存、消息队列

连接池、命中率、队列深度

应用程序层

服务性能和健康

TPS、响应时间、错误率

业务层

业务目标和用户体验

DAU、转化率、收入

基础设施层指标

┌──────────────────────────────────────────────┐
│              System Metrics                   │
├──────────┬──────────┬──────────┬──────────────┤
│   CPU    │  Memory  │   Disk   │   Network    │
│ ──────── │ ──────── │ ──────── │ ──────────── │
│ usage%   │ used/free│ IOPS     │ bandwidth    │
│ load avg │ swap     │ latency  │ packet loss  │
│ iowait   │ cache    │ capacity │ connections  │
└──────────┴──────────┴──────────┴──────────────┘

  • 处理器 (CPU): 使用率、负载均值、上下文切换、中断

  • 内存 (Memory): 使用量、剩余量、交换区使用、缓存命中

  • 磁盘 (Disk): IOPS、读写延迟、容量使用率

  • 网络 (Network): 带宽利用率、丢包率、TCP 连接数

应用程序层指标

  • TPS (每秒事务数): 系统每秒处理的事务量

  • 响应时间: P50、P90、P95、P99 延迟

  • 成功率: 请求成功比例

  • 总次数: 总请求/事务计数

业务层指标

业务层指标因业务而异，但有几个通用指标:

  • 用户满意度 (APDEX): 基于响应时间的用户满意度评分

  • 转化率: 用户完成目标行为的比例

  • 留存率: 用户在一段时间后继续使用的比例

2.4 度量指标与术语

2.4.1 统计学指标

  • 均值 (Mean/Average): 所有样本值的算术平均

  • 中位数 (Median): 将样本排序后的中间值

  • 百分位数 (Percentile): P50、P90、P95、P99 等

  • 标准差 (Standard Deviation): 数据的离散程度

  • 方差 (Variance): 标准差的平方

警告

在度量延迟时，不要使用均值，而应该使用百分位数。 均值会掩盖长尾延迟问题。例如，P99 = 5s 意味着 1% 的请求延迟超过 5 秒， 这可能影响大量用户，但均值可能只有 200ms。

2.4.2 度量类型

常见的度量类型:

度量类型

类型

说明

示例

Gauge (测量值)

某个瞬时值，可增可减

当前 CPU 使用率、活跃连接数

Counter (计数器)

单调递增的累计值

总请求数、总错误数

Meter (速率)

事件在一段时间内的平均速率

每秒请求数、每分钟错误数

Histogram (直方图)

数据流的统计分布

响应时间分布、请求大小分布

Timer (计时器)

持续时间的直方图 + 调用次数的速率

API 调用耗时

2.4.3 度量处理相关术语

  • 采样 (Sampling): 定期获取度量数据的快照

  • 聚合 (Aggregation): 将多个数据点合并为一个（求和、平均等）

  • 降采样 (Downsampling): 降低数据精度以节省存储

  • 时间窗口 (Time Window): 数据聚合的时间范围

  • 标签/维度 (Tag/Dimension): 度量数据的分类维度

  • 基数 (Cardinality): 标签值的种类数量

2.5 度量策略选择

2.5.1 如何做度量

度量的基本步骤:

  1. 确定度量目标: 你想知道什么？要验证什么假设？

  2. 选择关键指标: 不要贪多，聚焦于最重要的指标

  3. 设计采集方案: 在哪里埋点？用什么工具？

  4. 实现度量代码: 编写代码收集度量数据

  5. 聚合与存储: 将度量数据聚合、存储到时序数据库

  6. 展示与分析: 用仪表盘展示，用查询分析

  7. 报警与响应: 设置阈值，自动报警

  8. 持续优化: 基于度量结果不断改进

确定目标 → 选择指标 → 设计方案 → 实现采集
    ↑                                  │
    │                                  ▼
持续优化 ← 报警响应 ← 展示分析 ← 聚合存储

2.5.2 如何选择度量方案

选择度量方案时需要考虑:

  • 数据量: 预估每秒产生的度量数据量

  • 延迟要求: 需要实时还是准实时？

  • 存储周期: 度量数据需要保留多长时间？

  • 查询模式: 主要的查询场景是什么？

  • 成本预算: 基础设施和运维成本

  • 团队技能: 团队对哪些技术栈更熟悉

常见的技术栈选择:

度量技术栈对比

技术栈

特点

适用场景

代表工具

TIG

轻量、灵活

中小规模系统指标

Telegraf + InfluxDB + Grafana

ELKK

全文搜索、日志分析

日志聚合分析

Elasticsearch + Logstash + Kibana + Kafka

Prometheus

Pull 模型、告警集成

云原生环境

Prometheus + Grafana + Alertmanager

OpenTelemetry

统一标准、厂商中立

全栈可观测性

OTel Collector + 后端存储

2.6 本章小结

本章从微服务的局限出发，阐述了度量对于微服务的重要性， 系统地介绍了度量的内容、层次、指标类型和策略选择。

注解

关键要点:

  • 度量是微服务成功的必要条件

  • 度量分为基础设施、中间件、应用、业务四个层次

  • 使用百分位数而非均值来度量延迟

  • USED (Usage, Saturation, Error, Delay) 是核心度量维度

  • 度量驱动开发遵循 PDCA 循环