很多服务网格选型，起点往往是责任归属，然后才轮到基准测试。团队口头上说想要“一套 mesh（服务网格）”，真正想解决的却常常是三类完全不同的事情：

把 2026 年这批主流开源方案按三条路线来看，会清楚很多：

截至 2026-03-11（UTC），三条路线都值得认真看。更有判断价值的问题是：当身份信任、流量策略和事故响应进入长期运维阶段后，你希望复杂度落在哪一层，谁来长期承担这层责任。 一个很快能把问题看清的办法，是直接问：证书过期时谁接凌晨两点的电话，七层规则把某个命名空间的流量打断时谁负责止血，集群网络团队是并非会在不知不觉中变成服务网格团队。很多时候，服务网格的真实架构，会先在这个答案里露出来，早于任何一张性能图。

还有一个很值钱的预筛动作，能帮团队少走很多弯路：如果你眼下真正的问题仍然主要是南北向流量治理、入口标准化，或者只是少数 API 策略，那么最好先停一下，认真验证 Gateway API 加现有网络策略，是否已经能解决 80% 的问题。很多口头上叫“mesh 项目”的东西，实质上更像是一场穿着内部平台外衣的边界治理项目。

图片说明：题图是一张分析型辅助图，把比较重新拉回到真正的问题上：当 pilot（试点）结束后，七层策略、证书负担、网络责任到底该落在哪一层。

试点最容易骗人的地方

一场服务网格 pilot 往往会在最干净的地方成功：一个全新的命名空间、一个集群、一条单纯的证书链，再加几条数量不多的七层规则。这样的试点当然有价值，但它也会把真正的责任成本藏起来。真正的生产疼痛，通常发生在 brownfield（存量）命名空间、跨集群信任和大量例外策略开始累计之后。

所以，一个更像样的 pilot，至少应该刻意包含一次证书轮换演练，以及一个由不同团队共同负责的存量命名空间。否则团队验证到的只是演示路径，而并非运维路径。

1）三条路线各自真正优化的对象

Istio ambient：把四层铺开，把七层按需加上去

Istio 官方文档把 ambient 模式写得很直白：它使用按节点部署的四层代理，再配合可选的、按命名空间部署的七层代理。[1] 其中 ztunnel 用 Rust 编写，职责被刻意限制在三四层：mTLS、身份认证、四层授权、遥测等；真正需要看 HTTP 头、做更细策略和路由时，再交给 waypoint 代理处理。[1]

这个分层很重要，因为它改变了平台团队的操作问题。你不需要一上来就在“所有服务都挂满七层 sidecar”和“完全不上 mesh”之间二选一。ambient 给的是一条分阶段路径：先把四层安全覆盖做起来，再把七层能力挂到那些确实值得付出额外复杂度的命名空间或服务上。[1]

如果你的组织希望服务网格覆盖面广，但并不想让每个工作负载在第一天就背上同样重的七层包袱，这条路线通常会更合适。

Linkerd：把数据面做得更专注，但证书生命周期要正面接手

Linkerd 仍然是轻量 sidecar 路线里表达最清晰的一种。它的数据面由运行在每个服务实例旁边的透明微代理组成，项目的代理本身也是为服务网格场景单独设计的 Rust 组件，并非通用型大代理。[2] 这使得 Linkerd 在初次落地时通常显得直接、干净、学习成本也相对友好。

但 2026 年更值得看的点不在“它够不够轻”，而在剩下的复杂度被移去了哪里。

Linkerd 的自动 mTLS 对日常接入很友好，不过官方文档把生命周期问题写得很明确：默认安装命令生成的 trust anchor（信任根证书）会在 365 天后过期，而工作负载证书会在 24 小时后过期并自动轮换。[3] 这意味着，Linkerd 确实把“第一天把链路加密起来”这件事变得容易，但只要集群是长期运行的，团队迟早还是要把 issuer（签发者）轮换、信任根归属、跨集群信任关系这些问题讲清楚。

如果你的团队更看重“服务到服务安全 + 遥测”这层基础能力，并且愿意把身份信任维护当成平台工程的一部分来做，这条路线通常很有吸引力。

Cilium Service Mesh：把服务网格并入网络平台本体

Cilium 的服务网格文档体现的是另一种中心思想。对 IP、TCP、UDP 这类底层网络处理，Cilium 用的是内核里的 eBPF 数据通路；到了 HTTP、Kafka、gRPC、DNS 这类应用层协议，再交给 Envoy 这样的代理处理。[5] 这一点不只是实现细节，它说明 Cilium 的服务网格故事从一开始就和集群网络故事绑在一起。

它的好处是平台收敛。如果组织已经用 Cilium 承担网络、网络策略和可观测性，再往 ingress（入口流量）、Gateway API、服务网格方向延展时，往往能减少平行控制面的数量。[5][7]

边界也同样清楚。当前文档里，Cilium 的 mutual authentication（双向认证）页面依然明确标着 Beta，而身份体系要依赖 SPIFFE / SPIRE 这套组件与信任流程。[6] 所以这条路线的平台收敛能力很强，但身份平面仍然更适合被当作一个还在演进中的子系统来看，而并非默认已经完全成熟的背景设施。

如果你的平台方向本来就以网络层为中心，希望入口、网关、服务网格能力彼此连成一套，这条路线就很值得优先评估。

2）维护与发布信号：更像风险轮廓，并非冠军榜

仓库热度不等于工程质量，但维护面和发布节奏仍然能提供一些有用信号。

截至 2026-03-11（UTC），GitHub API 快照如下：[8][9][10]

发布形态也能看出不同治理纹理：

这里的边界要守住：这些指标不能直接告诉你延迟、隔离性或策略体验，它们更像是在提示你未来需要跟踪哪一类项目节奏。

3）真正的分水岭：七层能力和身份信任放在哪里

这一层往往最容易被低估。

如果你希望七层能力只挂到真正需要的地方，优先看 Istio ambient

ambient 最强的架构价值在于“按需加料”。底层先由 ztunnel 提供安全覆盖，需要更细的 HTTP 能力时，再上 waypoint 代理。[1] 文档还明确写到，不同 Istio 数据面模式之间可以互操作，这让渐进式接入的成本低很多。[1]

这让 Istio ambient 很适合大型内部平台：并非每个服务都值得承担同一层七层复杂度，但总有一部分核心服务确实需要。

主要风险在于：团队或许低估“哪些服务该挂 waypoint”本身就是一项长期设计工作。一旦例外越来越多，ambient 的简洁感也会被稀释。

如果身份默认值比七层策略广度更重要，优先看 Linkerd

当平台目标相对直接——把服务到服务链路加密、拿到网格级遥测、避免把每一种流量治理都做成一个框架工程——Linkerd 仍然很有说服力。[2][3]

主要风险在于：把“落地轻快”误读成“长期维护也轻松”。信任根仍会过期，证书签发仍要有人管，跨集群信任仍要认真设计。[3][4]

如果你已经以 Cilium 为网络底座，先问自己要的是平台收敛还是网格纯度

Cilium 最强的时候，服务网格决策其实是更大平台决策的一部分。当前文档里，ingress、Gateway API、GAMMA、双向认证、七层流量管理都被放进同一条平台演进线上。[5][7] 现有 Gateway API 文档也明确写到，Cilium 支持 Gateway API v1.4.1 的核心资源，并通过了列出资源的全部 Core conformance tests。[7]

主要风险在于：把“一个平台”自动等同于“更省事”。平台收敛确实能减少某一类重复建设，但责任也会更集中。如果你的身份路径依赖一个仍属 Beta 的双向认证能力，再加上 SPIRE 这套运维对象，本质上是在做一次更尖锐的平台押注。[6]

4）按负载形态给一个决策地图

如果平台团队需要在未来两个季度内做决定，可以用下面这张简化地图。

更适合先选 Istio ambient 的场景

  1. 你希望先把四层安全覆盖铺开，但只有部分服务真正需要七层策略与路由深度。[1]
  2. 你想要一条从“没有 mesh”到“局部七层增强”的渐进路径，而并非一次性把完整 sidecar 体系压到所有工作负载上。[1]
  3. 你的服务层级差异很大，接入节奏必须允许不均匀推进。

更适合先选 Linkerd 的场景

  1. 你重视 sidecar 路线的运维清晰度，也更偏好职责专注的 Rust 代理，而并非更大的通用代理面。[2]
  2. 你希望尽快拿到自动 mTLS，并且团队能够在证书、信任根、签发链这些事情上提前定责。[3]
  3. 你并不要求所有服务都享受最丰富的七层能力。

更适合先选 Cilium 的场景

  1. 你的平台已经以 Cilium 承担网络与策略，服务网格扩展可以复用现成的运维能力，而并非另起一套平行栈。[5]
  2. Gateway API、入口治理与服务网格在战略上本来就绑在一起。[7]
  3. 你可以接受在身份能力上明确区分成熟度边界，而并非默认它与老牌服务网格完全等价。[6]

一场 30 分钟就该问完的架构面试题

如果三家厂商、或者三位内部倡导者都在说“我们需要一套 mesh”，那在比功能矩阵之前，先开一场会把下面五个问题问完：

  1. 谁负责 trust anchor（信任根）、issuer（签发者）轮换，以及跨集群信任？ 这个问题往往最先把“漂亮演示”与“真实平台”分开。
  2. 七层策略究竟应该只出现在少数热点工作负载上，还是预期会逐渐变成常态？ 这个答案通常会把你推向 ambient 式按需挂载、sidecar 默认覆盖，或者网络层收敛路线中的某一边。
  3. 如果集群网络团队明确不愿意顺手变成 mesh 团队，整套方案会先坏在哪里？ 如果答案是“大部分计划都会停住”，那这其实已经是组织结构决策。
  4. 哪些工作负载真的需要 HTTP 级别的路由与策略，哪些只需要加密连通性和身份？ 很多集群最后会发现，自己所谓“全栈 mesh”需求，实际只是“安全传输 + 少量热点七层能力”。
  5. 你真正预设的第一个凌晨两点故障是什么：证书过期、错误的七层规则，还是数据通路复杂度？ 这个答案通常最能暴露哪一家的痛点形状更像你自己的。

如果这五个问题都还答不清，那团队多数时候还没有真正进入服务网格选型阶段，先要解决的是责任定义问题。

5）一个证伪条件和一组观察项

这篇地图的证伪条件：如果你的真实需求只是少量服务的南北向流量治理和基础策略，那么你未必需要一整套服务网格决策，单独做 ingress 或 Gateway API 选型，成本或许更低。

2026 年值得持续观察的点：

  1. 你的服务网格决策，背后是否其实是在做身份平台决策。
  2. “按需挂七层能力”会不会逐渐扩散，最后让几乎所有命名空间都变成特例。
  3. 在第一张证书过期之前，证书与信任根轮换是否已经明确到人。[3]
  4. 平台收敛究竟是在减少运维对象，还是把更多责任压进一个更难替换的底层里。

结语

2026 年的开源服务网格生态已经足够成熟，但真正值得区分的，是复杂度放置方式：

先按责任归属做决定，通常会比先看性能图更接近长期成本的真实位置。

来源

  1. Istio docs — Ambient overview（按节点四层、按命名空间可选七层、ztunnel 职责、模式互操作）
  2. Linkerd docs — Architecture（Rust 代理、sidecar 数据面、injector 模型）
  3. Linkerd docs — Automatic mTLS（默认 365 天信任根、24 小时工作负载证书）
  4. Linkerd docs — Releases and Versions（稳定版制品策略与近期版本）
  5. Cilium docs — Service Mesh overview（eBPF 数据通路、应用层交给 Envoy、平台范围）
  6. Cilium docs — Mutual Authentication（Beta）与 SPIFFE / SPIRE 身份流程
  7. Cilium docs — Gateway API support（v1.4.1 支持与 Core conformance 说明）
  8. GitHub API — istio/istio 仓库元数据与 releases
  9. GitHub API — linkerd/linkerd2 仓库元数据与 releases
  10. GitHub API — cilium/cilium 仓库元数据与 releases