7.2 服务网格与API版本演进

7.2 服务网格与 API 版本演进

本节摘要：服务网格用 sidecar 代理把第 5 章的治理四件套收编进基础设施——mTLS 自动化、重试熔断下沉、流量观测统一，业务代码回归纯粹。本节讲 sidecar 模式的工作机制、治理收编的清单与残留（业务侧仍要做的事），然后转向时间维度：proto 契约的版本演进策略（字段级兼容规则、包级版本化、废弃流程），最后展望 HTTP/3 与 AI 负载下 gRPC 的走向。

本节目标

阅读完本节，你应当能够：

1. 解释 sidecar 模式的工作机制与流量路径；
2. 列出网格收编的治理项与业务侧的残留职责；
3. 设计 proto 的包级版本化与废弃流程；
4. 评估自己团队引入网格的收益与成本；
5. 说清 HTTP/3 与 AI 推理负载对 gRPC 的演进意义。

一、sidecar 模式：治理的"水电煤"化

第 5 章的治理四件套（拦截器、发现与均衡、弹性、安全）都装在应用进程里，由各语言 SDK 实现。服务网格把这些能力从进程里搬出来：每个服务实例旁部署一个代理进程（sidecar，边车），进出流量都经过它，治理逻辑在边车里执行。

数据平面与控制平面的分工：边车们是数据平面（执行流量处理），控制平面（以各网格产品实现）负责把人写的策略（路由规则、重试配置、mTLS 模式）翻译下发到每个边车。运维在控制平面改一条规则，全集群的行为同步变化——治理从"每个服务的代码配置"变成"整个集群的基础设施配置"。

gRPC 与网格的关系天然亲和：主流数据平面（Envoy 系）对 gRPC 的支持是一等公民（5.2 节提过 xDS 本身就是 gRPC 流），流量统计、健康协议、mTLS 体系都能直接对接。

二、治理收编清单：网格替你做了什么

对照第 5 章四件套，逐项看清网格的收编程度：

收编的实质收益有三条。一致性：策略一处声明全局生效，不存在"某个服务忘了配重试预算"。语言无关：治理能力不再依赖各语言 SDK 的成熟度，异构栈一碗水端平。业务纯粹：业务代码里的治理样板退场（5.1 节的八股进一步减少），新服务的接入成本降到"部署时带上边车"。

残留职责也要认清，网格不是全托管：业务侧的超时预算语义（deadline 传播仍是 gRPC 调用元数据的职责）、方法级授权的数据归属判断（5.4 节第 4 层）、以及边车与应用之间的一跳开销（同机回环通信，毫秒内但非零——超低延迟场景要实测权衡）。

引入时机的判断：服务数几十以内、语言统一时，应用内治理（第 5 章方案）足够；服务上百、异构严重、专职平台团队存在时，网格的基础设施化收益开始超过它的运维复杂度。网格不是演进终点而是规模产物——没有规模硬上，是拿大炮打蚊子还喂不饱炮。

三、时间维度：契约的版本演进

第 5 章解决了"今天稳定"，版本演进解决"五年后还不烂"。proto 契约的演进策略分三层，从细到粗：

第一层，字段级兼容。2.2 节的兼容规则表是地基：新增字段天然兼容、删除用 reserved 锁坑、编号与线型永不动。这一层保证同一个 API 版本内的平滑演进——绝大多数日常变更应该停在这层解决。纪律回顾：改语义（同一字段含义变化）看似兼容实则破坏，要按破坏性变更处理。

第二层，包级版本化。语义确实要变、且无法用新字段表达时，开新版本：包名从 orders.v1 变 orders.v2（2.1 节埋的伏笔兑现）。新旧版本长期并存——服务同时注册两套（或者新版本网关转译兼容旧版），消费方按自己的节奏迁移。

第三层，废弃与退役流程。旧版本的退场要有仪式感：先标注废弃（proto 注释、发布说明、契约库的醒目标记）、给消费方迁移指引与期限、用观测数据监控旧版调用量（6.2 节的指标按方法名天然支持按版本拆分）、归零后移除。没有退役机制的版本化会积累成"五六个版本并存、谁也不敢删"的考古现场。

把这套流程再具体化一步，一个可直接套用的版本退役时间表：公告期（废弃声明发布，至少一个迭代周期）→观察期（监控旧版调用方清单，逐个沟通迁移进度，对滞留方提供技术支持）→熔断预告期（旧版开始返回带废弃提示的附加元数据，给还没动的团队最后的可观测信号）→下线期（旧版本方法返回 UNIMPLEMENTED，注意这已是破坏性动作，前面三步都是为了让它发生时不伤人）。整套流程的关键是每一步都有数据支撑——谁还在用、用了多少、迁移到哪了，全部来自 6.2 节的观测体系，而不是靠群里喊话。

同样值得制度化的还有新版本的准入评审：什么时候才有资格开 v2？建议的门槛是——至少三个以上的消费方提出过无法用字段级兼容满足的需求、新旧映射关系可以清晰文档化、有团队认领双版本的维护期。把开新版本的冲动关进流程的笼子，契约库才不会膨胀成版本动物园。

四、向未来看：两条演进线

HTTP/3 与 QUIC。3.1 节留的尾巴：HTTP/2 没解决的 TCP 层队头阻塞，QUIC 在传输层解决了——流之间真正互不拖累，弱网与移动场景的连接迁移（换网络不断流）也是红利。gRPC 对 HTTP/3 传输的支持在主流语言里逐步落地（部分已实验可用），落地节奏取决于生态里代理、负载均衡器对 HTTP/3 的普及度。对使用者的建议：不必等待，当前体系按 HTTP/2 设计依然正确——gRPC 的应用层协议不绑死传输版本，升级是基础设施层的渐进替换。

AI 与高性能负载。模型推理服务化是 gRPC 增长最快的场景之一（第 1 章的四类场景之一）：推理请求与张量数据的传输、流式生成（大模型逐 token 输出与服务端流天然契合）、批处理调度都对低延迟高吞吐通信有硬需求。配套的生态位（推理服务框架的 gRPC 接口、GPU 集群的通信模式）在持续深化，"服务化 AI"的基础通信层，gRPC 的位置短期看不到替代者。

⚠️ 常见坑：把"上了网格"当成治理问题的终结。网格收编的是流量层的治理，deadline 语义、幂等设计、业务级授权、契约纪律依然是应用侧的功课——这些做不好，网格只是把一个混乱的系统装修得整齐。

💡 关键直觉：判断一项能力该放应用层还是基础设施层，看两点——它是不是所有服务都要（普适性）、它与业务语义是否无关（通用性）。两者都高就适合下沉成基础设施，mTLS 与负载均衡如此演进成了网格；deadline 语义带着业务判断，留在应用层。

常见问题

问：边车会拖慢多少性能？
同机回环一跳，增加亚毫秒到低毫秒级延迟，多数业务无感。超低延迟（如行情系统微秒级预算）场景要实测决策，这类场景也确实常选择绕开边车直连。

问：网格与应用内治理能混用吗？
过渡期必然混用（部分服务进网格、部分未进），要点是同一治理项只在一处生效——比如重试要么边车做要么应用做，两边都开就是 5.3 节的事故配置。

问：proto 文件的 git 仓库该怎么组织版本？
契约仓库按包路径组织，版本演进体现在包名（v1、v2 目录），仓库的分支不承担 API 版本语义——主干上多版本并存，比多分支并行好维护得多。

问：怎么防止"契约库变成考古现场"？
把两个数据挂到治理看板上：每个版本的活跃调用方数量、每个版本的周调用量。任何版本满足"活跃调用方为零"超过一个迭代周期，就进入退役流程。版本堆积的本质是"没人看数据"——数字摆出来，堆积自然会被清理。

温故知新

• 网格把治理收编成基础设施：边车做数据平面、控制平面统一策略，一致性、语言无关、业务纯粹是三大收益。
• 收编有残留：deadline 语义、方法级授权、幂等设计仍是应用侧功课；边车一跳开销在超低延迟场景要实测。
• 网格是规模产物：服务上百、异构严重、有平台团队时收益才盖过复杂度。
• 契约演进三层策略：字段级兼容覆盖九成日常、包级版本化应对语义变更、废弃退役靠数据驱动收敛。
• 版本化的失败形态是版本考古现场：没有退役机制的并存比破坏性变更更慢性地腐蚀体系；治理看板上挂"版本活跃调用方与周调用量"两项数据，堆积自然会被清理。
• HTTP/3 是传输层渐进替换，不必等待；AI 推理负载是 gRPC 最坚实的增长场景。

全书到此收束。回头看第 1 章那张全景图：契约、传输、架构、治理、观测、生态——六条线你都已走完。接下来的事在键盘上而不在书页里：挑一个服务，把这份认知变成运行中的系统。