Software Systems Atlas

中文

English

中文

English

主题

第 7 卷 / 第 6 章 / 第 2 课

6.2 微服务平台的生产基线 ​

微服务平台的目标是把重复、易错的分布式能力做成默认路径，让业务团队不用各自实现服务发现、身份、观测和发布。平台不是把所有流量和决策集中到一个“超级中台”。

四个平面 ​

下面按职责区分四类能力，便于追踪故障和所有权；这不是要求采购四套产品，实际组件也可能承担多种职责。

Data plane ​

承载业务请求和消息：代理、负载均衡、连接、超时、TLS 和流量策略。它在关键路径上，必须有明确延迟与故障预算。

Control plane ​

分发路由、证书、配置和策略。控制面短时不可用时，已有数据面通常应使用最后已知有效配置继续服务。这种独立性有期限：证书会到期、端点会变化，新启动的代理也可能没有可用配置。需要分别测量“已有请求还能服务多久”和“新实例能否加入”，并明确策略撤销和凭据失效后的处理；last-known-good 不是无限延长过期身份。

Management plane ​

部署、扩缩、目录、成本、权限和运维工作流。它决定谁能改变系统。

Observability plane ​

采集 metrics、logs、traces 和事件，并关联到服务、版本、区域和业务结果。普通遥测应使用有界队列、异步导出及明确的丢弃策略，避免收集端故障阻塞业务线程。必须保留的业务审计记录则需要可靠存储和单独的背压处理，不能混进允许丢弃的调试日志。

平台基线能力 ​

能力最小要求
服务身份工作负载身份、短期证书、最小权限
发现与路由稳定名称、readiness、实例排空、zone 感知
RPC 策略deadline、有限重试、幂等保护、最大消息
过载保护并发限制、队列上限、负载削减、隔舱
配置与密钥校验、审计、轮换、last-known-good
可观测性统一资源属性、trace 传播、SLO 指标
发布不可变制品、渐进流量、停止条件、回退
恢复备份、演练、运行手册、事件指挥

中间件名字可以变化，这些运行语义不能缺省。

Service mesh 的边界 ​

Mesh 可以统一 mTLS、连接池、基础路由和遥测，但它不知道业务操作是否幂等、降级是否诚实、结果未知如何查询。

mTLS 验证工作负载身份并保护传输，不会自动判断终端用户能否访问某个租户的订单，这类对象级授权仍需要业务上下文。代理层自动重试必须与应用 SDK 协调；若两层各最多尝试 3 次，故障时一个逻辑调用最多可触发 9 次下游尝试。Sidecar/节点代理还会消耗资源并引入配置传播和版本兼容问题。

配置发布也是生产发布 ​

把调用超时从 200 ms 误改为 200 s，镜像完全没动，等待队列和资源占用却可能先发生变化。超时、重试、路由、限流和证书策略的变更能在不改应用镜像时影响全站。控制面配置需要：

  • schema 和范围验证；
  • dry-run 与冲突检查；
  • 小范围 rollout；
  • 版本、审计和一键回退；
  • 配置生效状态与数据面收敛指标。

控制面“已发送”不等于所有代理“已应用”。以 xDS 为例，还要看版本、ACK/NACK 及资源就绪状态；配置被接受也不证明目标后端可达。回退同样需要观测实际生效，不能只看 Git 已还原。

SLO 沿依赖传播 ​

服务 SLO 不能只看自身进程。拥有一个 API 的团队应知道关键依赖及其错误预算，并为依赖退化定义：快速失败、降级、缓存、异步或容量隔离。

平台可以提供 dependency map 和统一指标，但业务团队仍要定义用户可见成功。HTTP 200 不等于订单正确完成。

进入生产前的演练 ​

  • 实例滚动终止时连接是否排空；
  • 单 zone 故障后容量是否足够；
  • 控制面不可用时数据面是否继续；
  • 身份证书轮换失败时如何恢复；
  • 一个下游变慢时是否出现重试风暴；
  • 消息积压和 DLQ 是否有所有者；
  • 配置错误能否在小流量阶段停止；
  • 备份是否能在目标 RTO 内恢复。

平台成功指标 ​

  • 新服务达到生产基线所需时间；
  • 使用默认路径的服务比例；
  • 发布失败率和恢复时间；
  • 策略例外数量及其所有者；
  • 跨服务事故中平台缺陷占比；
  • 每服务基础成本和资源开销；
  • SLO、身份、备份和运行手册覆盖率。

平台应降低认知负担，而不是用更多 YAML 和隐藏控制面制造新的分布式系统。

参考资料 ​

Built with VitePress | Software Systems Atlas

Copyright 2026 Steven Yang