6.2 微服务平台的生产基线

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

四个平面

Data plane

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

Control plane

分发路由、证书、配置和策略。控制面短时不可用时，数据面通常应使用最后已知有效配置继续服务，而不是立刻停摆。

Management plane

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

Observability plane

采集 metrics、logs、traces 和事件，并关联到服务、版本、区域和业务结果。观测链路故障不能反向拖垮业务链路。

平台基线能力

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

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

Service mesh 的边界

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

代理层自动重试必须与应用 SDK 协调；多层重试会放大流量。Sidecar/节点代理还会消耗资源并引入配置传播和版本兼容问题。

配置发布也是生产发布

超时、重试、路由、限流和证书策略的变更能在不改应用镜像时影响全站。控制面配置需要：

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

SLO 沿依赖传播

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

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

进入生产前的演练

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

平台成功指标

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

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

参考资料

• Google, Site Reliability Engineering
• Kubernetes, Services, Load Balancing, and Networking
• OpenTelemetry, Concepts