Comparison

选择 Kubernetes 网关需要在架构、性能、功能覆盖度和运维复杂度之间做出权衡。本页将 Nantian Gateway 与四个知名替代方案进行对比，帮助你了解各自适用的场景。

Comparison Matrix

Feature	Nantian Gateway	Envoy Gateway	Istio	Contour	NGINX Gateway
Gateway API target	v1.5.1	v1.2.x	v1.2.x (via Gateway API)	v1.1.x	v1.2.x
Declared features	54	~40	~30 (Gateway API)	~30	~35
Control plane	Go	Go	Go	Go	Go
Data plane	Rust	C++ (Envoy)	C++ (Envoy)	C++ (Envoy)	C (NGINX)
Config protocol	gRPC/xDS	gRPC/xDS	gRPC/xDS	gRPC/xDS	Custom
AI gateway 🧪	Built-in	No	No	No	No
Wasm runtime 🧪	wasmtime	wasmtime (proxy-wasm)	wasmtime (proxy-wasm)	wasmtime (proxy-wasm)	No
Service mesh	Yes (Gateway API Mesh)	No	Yes (core)	No	No
TCP/UDP/TLS	Yes	Yes	Yes	Yes	Yes
gRPC routing	Yes (named rules)	Yes	Yes	Limited	Yes
Dashboard	Next.js admin	No built-in	Kiali	No built-in	No built-in
HA config	PDBs, anti-affinity	HPA, PDB	HPA, PDB	HPA, PDB	Manual
License	Apache 2.0	Apache 2.0	Apache 2.0	Apache 2.0	Apache 2.0
Hosted by	Independent	CNCF	CNCF	CNCF	NGINX/F5

Nantian Gateway vs Envoy Gateway

Envoy Gateway 是一个 CNCF 项目，使用 Envoy 作为数据面提供 Kubernetes 原生网关。它成熟、文档完善，拥有广泛的社区支持。

Nantian Gateway 的不同之处：

最直观的区别在于数据面语言。Envoy 使用 C++ 编写，拥有数十年验证过的性能和完善的生态系统。Nantian Gateway 的 Rust 数据面旨在提供相近的性能，同时具有强大的内存安全保证。对于需要审计或扩展代理本身的团队来说，这一点更为重要。

Nantian Gateway 还在数据面中直接集成了 AI 网关模块。使用 Envoy Gateway 时，你需要在网关旁边额外部署一个独立的 AI 代理（如 LiteLLM 或 AI Gateway），这会增加运维复杂度和额外的网络跳数。Nantian Gateway 在同一个处理 HTTP 流量的代理内部完成 AI 供应商路由、Token 计数、速率限制和 PII 遮蔽。

在 Gateway API 覆盖度方面，Nantian Gateway 针对 v1.5.1 规范声明了 54 项功能，而 Envoy Gateway 面向 v1.2.x 约 40 项功能。Nantian Gateway 还支持 Gateway API Mesh 资源，而 Envoy Gateway 不支持。

两个项目都使用 gRPC/xDS 进行配置分发，因此控制面架构相似。两者都通过 wasmtime 支持 Wasm 插件。

Nantian Gateway vs Istio

Istio 是 Kubernetes 生态中部署最广泛的服务网格。它是一个功能全面的网格平台，基于 Envoy sidecar 构建，提供流量管理、安全和可观测性能力。

Nantian Gateway 的不同之处：

Istio 以网格为主，网关为辅。其网关功能作为更大网格架构的一个组件存在，需要注入 sidecar。Nantian Gateway 以网关为主，网格支持作为扩展。如果你需要一个具有 mTLS、细粒度授权策略和分布式追踪的完整网格，Istio 是正确的选择。如果你需要一个高性能的入口网关并附带可选的网格功能，Nantian Gateway 是更轻量的选择。

Nantian Gateway 通过 Gateway API Mesh 模型实现网格，不需要 sidecar。这种方式避免了 sidecar 注入、Pod 生命周期顺序管理以及每个 Pod 一个 sidecar 带来的额外资源分配等运维考量。

Nantian Gateway 的 AI 网关和仪表盘功能是其与 Istio 定位差异的体现。Istio 的可观测性更全面（Jaeger 追踪、Kiali 可视化），而 Nantian Gateway 的 Prometheus 和 Grafana 集成已覆盖大多数团队所需的网关级指标。

Nantian Gateway vs Contour

Contour 是一个 CNCF 入口控制器，在 Envoy 之上提供 Gateway API 实现。它以简洁性和与 Contour ingress route 模型的紧密集成而闻名。

Nantian Gateway 的不同之处：

Contour 使用 Envoy，因此同样面临数据面的权衡。Nantian Gateway 的 Rust 代理则是同一问题的不同解法。

功能覆盖度是一个显著的差异。Nantian Gateway 支持带有命名路由规则的 gRPC 路由、TLS 混合模式（同一监听器上同时支持透传和终止），以及更丰富的重定向状态码和 HTTP 匹配特性。Contour 的 Gateway API 支持更为保守。

Nantian Gateway 额外提供了 AI 网关功能、Wasm 插件系统和网格支持。如果你的需求是简单的 HTTP 路由加 TLS 终止，Contour 在简洁性上表现优异。Nantian Gateway 面向需要多协议路由、AI 流量管理和单一代理可扩展性的团队。

Nantian Gateway vs NGINX Gateway Fabric

NGINX Gateway Fabric 是 F5 旗下 NGINX 团队的 Kubernetes Gateway API 实现。它使用 NGINX 作为数据面，这是全球部署最广泛的 Web 服务器和反向代理。

Nantian Gateway 的不同之处：

NGINX Gateway Fabric 受益于 NGINX 庞大的安装基础和生态系统。其数据面是一个久经考验、广为人知的 C 代码库。Nantian Gateway 的 Rust 数据面较新，生产验证较少，但提供了内存安全和现代并发模型。

功能差距是最大的差异化因素。NGINX Gateway Fabric 支持 Gateway API 功能的一个子集，专注于最常见的 HTTP 路由模式。Nantian Gateway 覆盖了更广泛的规范范围，包括 gRPC 路由、UDP 路由、TLS 混合模式、网格资源以及更细粒度的匹配和重定向选项。

Nantian Gateway 带来了 AI 网关能力、Wasm 插件系统和内置仪表盘——这些都是其超出 NGINX Gateway Fabric 范围的额外能力。如果你需要 AI 流量管理或代理层面的自定义插件逻辑，Nantian Gateway 提供了集成化的解决方案。

When to Choose Nantian Gateway

Nantian Gateway 非常适合以下场景：

你需要全面的 Gateway API 覆盖（v1.5.1, 54 项功能），并希望紧跟上游规范
你正在运行 AI 工作负载，希望用单一代理同时处理 API 流量和 AI 供应商路由/速率限制
你希望通过 Kubernetes CRD 管理的 Wasm 插件实现自定义代理逻辑
你偏好 Rust 数据面的内存安全和并发特性
你需要内置的管理仪表盘来进行网关运维
你希望通过 Gateway API 网格模型获得无需 sidecar 的网格功能

When to Consider Alternatives

其他网关可能更适合以下场景：

你需要具有 mTLS、SPIFFE 身份和深度追踪的完整服务网格（Istio）
你需要久经考验的代理，拥有最丰富的运维知识库（Envoy Gateway、NGINX Gateway）
合规性要求你需要 CNCF 孵化或毕业状态（Envoy Gateway、Istio、Contour）
你运行的是简单部署，路由需求极少，希望运维负担最小（NGINX Gateway Fabric）