跳转至

第 15 章　从教学服务器到生产控制平面的边界

你现在已经能构造资源、建立 gRPC 服务、发布 snapshot，并通过真实请求观察路由变化。本章不再增加一个新 API，而是回答另一个问题：这套程序离可以持续服务一群生产代理，还缺少哪些明确能力？前置知识是前面各章的完整链路。目标是能对一个实现作出有依据的评估，知道哪些责任属于库、哪些属于使用库的系统。

go-control-plane 上游 README 把范围说得很清楚：它提供可复用的 xDS API server 和内存配置 cache，不尝试成为适合所有平台的完整控制平面。Envoy Gateway 则在 Kubernetes 与 Gateway API 场景上提供资源观察、翻译、基础设施管理等更高层能力。选择库还是现成控制平面，应从自己的平台需求出发，而不是因为本书几十行代码能启动就认为两者成本相同。

15.1 先写出谁维护期望状态

生产系统必须有可以重建的期望状态来源，例如 Kubernetes API、经过版本管理的配置仓库或业务数据库。控制平面读取它，校验并翻译成 Envoy 资源，再放入 cache。cache 中保存的对象是分发结果；一个内存条目不应成为业务配置唯一且不可恢复的副本。

这要求明确写入规则。若用户通过 API 修改域名，谁检查冲突，谁有权编辑，变化是否留审计记录，翻译失败后旧状态如何呈现？如果两个输入对象同时变化，构造代码是否基于同一代输入视图？这些问题都发生在 NewSnapshot 之前，不能靠对 SetSnapshot 加一层重试解决。

需要区分期望版本、生成版本和各代理确认状态。一份业务修改可以生成多个代理组的不同快照；某组 ACK 了，另一组尚未连接。记录单一全局 success=true 会把这些差异隐藏起来。一个可排查的状态至少能够追溯输入代次、目标组、输出摘要、发布时间和失败原因，并说明有没有覆盖离线代理。

15.2 身份、授权和缓存分组必须连起来

TLS 加密保护传输，mTLS 还可以验证连接双方身份；但“持有有效客户端证书”不等于“可以订阅任何租户的任何资源”。应用应把经过验证的身份与允许报告的 Node、组键和资源范围建立关系。Node.ID 与 metadata 是客户端声明，未经核实不应直接决定权限。

例如租户 A 的证书连接后，把 Node.ID 改成租户 B 正在使用的值。如果服务只是 IDHash 查表，没有请求阶段授权，就可能把 B 的 snapshot 返回给 A。即使不包含私钥，路由、内部域名、后端地址和信任材料也可能属于不应公开的信息。分组键只优化配置共享，不提供安全隔离保证。

SDS 更需要受控的密钥来源、最小访问范围、轮换和撤销策略。不能只保证证书会更新，还要验证更换信任根时的新旧信任过渡、私钥与证书匹配、有效期，以及代理失联时的行为。把 TLS Secret 整个打印到日志或作为公开故障附件，都可能越过本来已经建立的传输保护。

教学实验把宿主端口绑定在 127.0.0.1，管理接口没有设计成多租户产品。若要让远程人员使用，应先明确认证和权限，而不是简单把监听地址改成 0.0.0.0。Envoy admin 的 config_dump 能暴露大量运行配置，也应限制在受控访问范围。

15.3 高可用不只是增加副本

多个 xDS server 能提高连接可用性，但每个副本的配置来源、构造逻辑与版本含义必须一致。如果同一个版本字符串在副本 A 表示 blue、在副本 B 表示 green，代理重连到 B 后可能无法按预期识别内容变化。版本的不可解释性不意味着控制平面可以随意复用它。

常见方案是所有副本从同一持久输入重建相同内容，并采用稳定摘要或统一发布号；也可以由确定的分片或领导者负责某组发布。不同方案各有恢复与扩展成本，不存在靠一个 NewSnapshotCache 参数就能开启的分布式一致性。就绪检查应确认本副本已装载必要状态，而不仅仅是 TCP 端口已经打开。

代理断开后通常可继续使用已有有效配置，但这不是无限期、全功能的保证：新启动代理没有历史配置，过期证书会影响 TLS，TTL 资源可能被移除，后端拓扑仍会变化。因此故障演练要分别验证已有代理、重连代理、新代理和资源过期场景。把“控制平面停了现有请求暂时还能走”作为唯一演练，覆盖面远远不够。

15.4 发布要控制风险，也要定义恢复动作

正式发布可以先向少量代理组提供新配置，观察 ACK/NACK、warming 时间、请求错误率、延迟及业务探测，再逐步扩展。逐组推进降低一次错误影响的范围，但前提是组的定义真实反映流量和权限边界。仅按随机 Node.ID 分组，可能无法覆盖不同 Envoy 版本、地域或协议组合。

恢复方案也要具体。NACK 时旧配置可能仍有效，应用要判断发布修复还是重新发布此前已验证的内容；ACK 后业务出错，则更需要流量指标触发恢复。回滚应产生一份明确输出，并保留审计，而不是盲目把内存指针改回去。此前的内容若依赖已经删除的 Cluster、失效证书或不存在的后端，也未必能直接恢复服务。

对资源依赖较大的修改，应采用有过渡状态的步骤：增加依赖、验证、切换引用、确认收敛、排空并清理。ADS 支持顺序协调，不是跨类型或跨代理事务；Snapshot.Consistent 也没有证明所有业务引用和运行条件正确。这两项局限决定了发布系统仍需要自己的状态与恢复逻辑。

15.5 容量边界来自资源数和变化方式

一个代理组的 snapshot 很小，不代表十万代理组仍然很小。若每个 Node 都保存一份近乎相同的完整资源图，内存可能主要浪费在重复对象上；若共享对象又在发布后原地修改，则引入数据竞争和版本错配。合理共享需要不可变约定，并让分组粒度与配置差异匹配。

高频 EDS 变化还会影响序列化、摘要计算、网络发送与客户端处理。每秒把全量资源都换一个版本，可能制造不必要的广播。可以基于测量选择按类型独立版本、合并短时间内的输入变化、LinearCache 或 Delta，但必须保留正确的删除和重连语义，不能为了节省字节让过期端点永远留在客户端。

gRPC 消息大小、连接数量、同时活动的流、慢客户端和重连风暴，都需要按真实规模测试。单次响应再大也不能靠无限提高消息上限解决所有问题；上游示例中的大并发流参数是示例选择，不是适用于所有机器的容量结论。回调中同步访问慢数据库，或为每个事件启动无界 goroutine，同样会在规模扩大后暴露问题。

15.6 可观测性要沿着数据路径建立

除了进程存活与 CPU、内存，控制平面还需要观察输入积压、翻译耗时、各类型资源数量、快照大小、发布耗时、活动流和 watch 数量、响应与确认延迟、NACK 及错误分组。代理侧则观察 active/warming、连接失败、上游健康与请求结果。两侧通过发布记录关联，才能判断时间花在生成、分发、应用还是业务路径。

指标标签应有可控数量。资源名、Node.ID、域名和 nonce 若不加选择地成为标签，容易带来高基数；原始错误全文也不适合做标签。将有限的结果类别用于指标，把细节放入受控日志与审计，并保证缺失日志时还能通过缓存和代理状态重建基本事实。

还应记录可重复的兼容性组合：Go 根库版本、envoy 消息子模块版本、Envoy 镜像版本与实际启用扩展。生成类型存在某字段，并不能证明每个部署的代理都支持它。升级时应验证新增、删除、NACK、重连、证书轮换和关闭流程，而不是只做一次成功请求。

15.7 用一张责任表评估实现

责任 库提供的基础 应用需要落实的部分
xDS 流与发现接口 handler、watch、响应包装 网络服务、注册、认证、生命周期
配置分发 SnapshotCache、LinearCache 等 输入翻译、分组、版本和发布策略
有限引用检查 Snapshot.Consistent 重复名、额外语义、完整业务依赖
更新反馈 请求和响应回调 ACK 关联、状态持久化、告警与恢复
平台集成 通用 Go API 资源观察、权限、审计和重建来源

这张表不是说每个项目都必须自己实现所有组件。若需求已经符合 Envoy Gateway 的平台模型，使用并扩展它可能更合理；若要支持自有服务注册中心或特殊配置工作流，go-control-plane 则提供了较低层的构件。真正的选择依据是哪些责任你需要掌控，以及团队能否长期维护这些责任。

15.8 练习与参考答案

  1. 给实验服务加一个副本并放到负载均衡后面，就已经解决高可用了吗？
  2. 客户端证书有效，Node.ID 可以任意填写吗？
  3. 一组代理全部 ACK，能否直接删除旧后端并宣告发布完成？

参考答案：第一题没有，还需要一致的持久输入、可重建缓存、版本策略和就绪条件，并验证重连。第二题不应，认证身份必须与允许的 Node/组和资源授权绑定。第三题不充分，还要验证业务效果、引用收敛和连接排空；ACK 并不证明旧连接都已结束，也不证明所有上游条件正常。

本章依据