Use Cases

Nantian Gateway的架构适用于多种不同的部署模式。本页介绍网关发挥独特价值的实际场景。

AI 网关：集中式 AI 流量管理

部署大语言模型和 AI API 的组织面临一系列传统 API 网关无法解决的问题：多提供商格式、基于 token 的计费、提示词级别安全以及模型 A/B 测试。

Nantian Gateway内置的 AI 网关模块在代理层处理这些问题。

多提供商协议适配

AI 提供商使用不同的 API 格式。OpenAI、Anthropic 和 Ollama 各自拥有独立的请求和响应模式。Nantian Gateway规范化这些差异，让您的应用使用一种格式通信，而网关则将其转换为各后端期望的格式。

apiVersion: gateway.nantian.dev/v1alpha1
kind: AIService
metadata:
  name: openai-gpt4o
spec:
  provider: openai
  format: openai
  model: gpt-4o
  auth:
    type: bearer
    secret: openai-api-key
    key: token
    header: Authorization
  timeout: 60s

应用将请求发送到统一的网关端点。网关根据请求的模型路由到正确的提供商，透明地处理协议转换。

基于 Token 的速率限制

AI API 按 token 数量计费，而非按请求次数计费。一次包含 10,000 个 token 的提示词请求，其费用等同于一百次各含 100 个 token 的请求。传统的基于请求次数的速率限制完全无法应对这种情况。

Nantian Gateway的 TokenPolicy CRD 基于实际 token 使用量来执行限制：

apiVersion: gateway.nantian.dev/v1alpha1
kind: TokenPolicy
metadata:
  name: team-quotas
spec:
  targetRefs:
    - group: gateway.networking.k8s.io
      kind: HTTPRoute
      name: ai-route
  tokensPerMinute: 100000
  tokensPerHour: 5000000
  requestsPerMinute: 1000
  scope: route
  burst: 1.5
  onLimit: reject

网关在每个请求和响应中统计 token 数量，在超标流量到达提供商之前就将其拒绝。这可以防止意外账单，并为团队提供可预测的成本边界。

PII 脱敏与安全

将敏感数据发送到外部 AI 提供商会带来合规风险。Nantian Gateway可以在提示词离开您的网络之前脱敏其中的个人身份信息。脱敏在代理层完成，因此无需额外的独立服务。

A/B 测试模型部署

当上线新的模型版本或比较不同提供商时，您需要分流流量并对比结果。Nantian Gateway支持在 AI 后端之间按百分比分流流量，使用与常规 HTTP 流量相同的路由原语：

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: model-ab-test
spec:
  rules:
    - matches:
        - path:
            type: PathPrefix
            value: /v1/chat
      backendRefs:
        - name: model-v1
          port: 8080
          weight: 90
        - name: model-v2
          port: 8080
          weight: 10

提示

AI 网关模块在 Rust 数据面内部运行，而非作为 sidecar 或独立服务。这意味着 AI 流量无需额外的网络跳转，也无需管理额外的部署。

Kubernetes Ingress 与边缘路由

最常见的部署模式：Nantian Gateway位于 Kubernetes 集群的边缘，将外部流量路由到内部服务。

标准 Gateway API 配置

由于Nantian Gateway实现了 Gateway API 规范，您的路由配置与任何兼容实现看起来完全一致：

apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: public-gateway
spec:
  gatewayClassName: nantian
  listeners:
    - name: http
      port: 80
      protocol: HTTP
    - name: https
      port: 443
      protocol: HTTPS
      tls:
        mode: Terminate
        certificateRefs:
          - name: wildcard-tls
---
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: app-routing
spec:
  parentRefs:
    - name: public-gateway
  rules:
    - matches:
        - path:
            type: PathPrefix
            value: /api
      backendRefs:
        - name: api-service
          port: 8080
    - matches:
        - path:
            type: PathPrefix
            value: /
      backendRefs:
        - name: frontend-service
          port: 3000

此模式适用于所有标准 HTTP 工作负载：REST API、gRPC 服务、WebSocket 连接以及静态文件服务。

TLS 全覆盖

Nantian Gateway在同一监听器上支持 TLS 终止、透传和混合模式。您可以为大多数路由终止 TLS，同时将加密连接透传给自行处理证书验证的后端：

listeners:
  - name: mixed-tls
    port: 443
    protocol: TLS
    tls:
      mode: Passthrough
    allowedRoutes:
      namespaces:
        from: All

结合用于上游 TLS 和 SAN 验证的 BackendTLSPolicy，您即可获得无间隙的端到端加密。

多协议代理

并非所有工作负载都使用 HTTP。数据库、消息队列、游戏服务器和遗留协议需要 TCP 或 UDP 代理。Nantian Gateway能在同一网关上并行处理这些协议和 HTTP 流量。

TCP 与 UDP 路由

apiVersion: gateway.networking.k8s.io/v1alpha3
kind: TCPRoute
metadata:
  name: postgres-route
spec:
  parentRefs:
    - name: public-gateway
  rules:
    - backendRefs:
        - name: postgres-primary
          port: 5432
---
apiVersion: gateway.networking.k8s.io/v1alpha2
kind: UDPRoute
metadata:
  name: dns-route
spec:
  parentRefs:
    - name: public-gateway
  rules:
    - backendRefs:
        - name: coredns
          port: 53

gRPC 方法级路由

gRPC 服务受益于方法级路由，Nantian Gateway通过带命名路由规则的 GRPCRoute 提供此支持：

apiVersion: gateway.networking.k8s.io/v1
kind: GRPCRoute
metadata:
  name: grpc-service-routing
spec:
  parentRefs:
    - name: public-gateway
  rules:
    - matches:
        - method:
            service: users.v1.UserService
            method: GetUser
      backendRefs:
        - name: user-service-read
          port: 9090
    - matches:
        - method:
            service: users.v1.UserService
            method: UpdateUser
      backendRefs:
        - name: user-service-write
          port: 9090

这样您可以将读写操作路由到不同的后端、为每个方法应用不同的速率限制，或将特定的 RPC 调用导向灰度部署。

无 Sidecar 的服务网格

Nantian Gateway实现了 Gateway API Mesh 模型，无需在每个 Pod 中注入 sidecar 即可提供网格能力。

工作原理

网格模型不采用每个 Pod 一个 sidecar 的方式，而是使用共享网关代理来处理服务间流量。这减少了资源消耗（无每个 Pod 的代理开销），消除了 sidecar 生命周期顺序问题，并简化了调试过程。

apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: mesh-gateway
spec:
  gatewayClassName: nantian-mesh
  listeners:
    - name: mesh-http
      port: 8080
      protocol: HTTP
---
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: service-a-to-service-b
spec:
  parentRefs:
    - name: mesh-gateway
      kind: Gateway
      group: gateway.networking.k8s.io
  rules:
    - matches:
        - path:
            type: PathPrefix
            value: /
      backendRefs:
        - name: service-b
          port: 8080
      filters:
        - type: RequestHeaderModifier
          requestHeaderModifier:
            add:
              - name: X-Routed-By
                value: nantian-mesh

何时使用此模式

无 sidecar 的网格模型适用于以下场景：

• 您在资源受限的环境中运行，每个 Pod 的代理会消耗过多的 CPU 和内存
• 您拥有大量短生命周期的 Pod（批处理任务、无服务器函数），sidecar 注入会引入不可接受的启动延迟
• 您需要网格功能（请求头修改、流量拆分、重定向），但不想引入完整的网格控制面复杂度
• 您已经在使用Nantian Gateway作为 ingress 网关，并希望将其扩展到东西向流量

警告

无 sidecar 的网格模型不提供每个 Pod 的 mTLS 或基于 SPIFFE 的身份认证。如果您需要这些功能，可考虑使用 Istio 或 Linkerd 作为网格层，Nantian Gateway作为 ingress。

Wasm 驱动的自定义扩展

当内置过滤器不够用时，Nantian Gateway的 Wasm 插件系统让您能够在代理层注入自定义逻辑。

Wasm 插件用例

自定义认证：根据内部身份提供商验证 JWT、根据自定义数据库检查 API 密钥，或实现不符合任何标准的请求签名。

请求转换：重塑 JSON 载荷、在 API 版本之间进行转换，或在转发到后端之前使用内部服务的数据丰富请求。

自定义可观测性：以适配您可观测性技术栈的格式输出指标或链路数据、根据自定义条件采样请求，或记录现有工具所期望的结构化日志数据。

合规与治理：通过检查请求内容强制执行数据驻留规则、阻止发往禁止域名的请求，或注入合规请求头。

插件生命周期

Wasm 插件以 .wasm 二进制文件形式分发，并通过 WasmPlugin CRD 进行管理：

apiVersion: gateway.nantian.dev/v1alpha1
kind: WasmPlugin
metadata:
  name: custom-auth
spec:
  wasm:
    url: https://example.com/plugins/custom-auth.wasm
  hooks:
    - onRequest
  targetRefs:
    - group: gateway.networking.k8s.io
      kind: HTTPRoute
      name: payment-service

插件在数据面的 wasmtime 运行时中运行，可以访问用于日志、指标和 HTTP 分发的宿主函数。插件被沙箱化，除非明确授予权限，否则无法访问宿主文件系统或网络。

SDK 与开发

Nantian Gateway附带一个 Wasm SDK（Rust crate: ntgw-wasm-sdk），为插件开发提供类型化绑定。您用 Rust 编写插件，编译到 wasm32-wasi，然后通过 CRD 部署。

高性能边缘与可观测性

对于延迟敏感的工作负载，Nantian Gateway的 Rust 数据面提供了可预测的性能和低尾部延迟。结合可观测性技术栈，您能全面洞察网关行为。

关键指标

网关对外暴露的 Prometheus 指标涵盖：

• 每个路由和后端的请求速率、延迟（p50/p90/p99）和错误率
• TLS 握手时长和证书到期时间
• xDS 配置陈旧度和更新延迟
• AI 网关 token 用量和速率限制状态
• Wasm 插件执行时间和错误计数

生产部署模式

典型的生产部署包含：

• 两个或更多控制面副本，通过 Leader 选举实现高可用
• 多个数据面副本，位于类型为 LoadBalancer 的 Kubernetes Service 之后
• 基于 CPU 和内存对数据面进行 水平 Pod 自动扩缩容 (HPA)
• Prometheus 同时抓取控制面和数据面的指标端点
• Grafana 仪表盘用于集群级可见性
• Alertmanager 规则用于监控网关健康、TLS 到期和错误率阈值

完整过程请参阅生产安装指南。

组合用例

Nantian Gateway的优势在于这些用例可以组合使用。单个部署可以：

• 作为主要的 Kubernetes ingress 网关
• 将 AI 流量路由到多个提供商并施加基于 token 的速率限制
• 代理到数据库和消息队列的 TCP 连接
• 运行 Wasm 插件进行自定义认证和请求转换
• 将 Prometheus 指标暴露给您现有的可观测性技术栈

您无需为 HTTP、AI 和 TCP 流量部署单独的网关。一个Nantian Gateway部署即可处理所有这些流量，通过相同的 Gateway API 资源进行配置，并通过同一个仪表盘进行管理。

下一步

• 快速开始：5 分钟部署
• AI 网关功能指南
• Wasm 插件功能指南
• 生产部署指南