适用场景

Nantian Gateway 的架构决定了它适合几种不同的部署模式。本页走一走真实世界的场景，看看这个网关在哪些地方能发挥特别的价值。

AI 网关：统一 AI 流量管理

当团队开始用大语言模型和 AI API 时，会遇到一套传统 API 网关应付不了的问题：多提供方格式不统一、按 token 计费、提示词安全防护、模型 A/B 测试，等等。

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

多提供方协议适配

不同的 AI 提供方用不同的 API 格式。OpenAI、Anthropic、Ollama 各有各的请求和响应结构。Nantian Gateway 把这些差异做了一层归一化，你的应用只需要用一种格式发请求，网关负责翻译成各个后端认的格式。

apiVersion: gateway.nantian.io/v1alpha1
kind: AIService
metadata:
  name: llm-routing
spec:
  backends:
    - name: openai-gpt4
      provider: openai
      endpoint: https://api.openai.com/v1
      models:
        - gpt-4
        - gpt-4-turbo
    - name: anthropic-claude
      provider: anthropic
      endpoint: https://api.anthropic.com
      models:
        - claude-3-opus
        - claude-3-sonnet
    - name: ollama-local
      provider: ollama
      endpoint: http://ollama.internal:11434
      models:
        - llama3
        - mistral

应用只往一个网关地址发请求。网关根据请求指定的模型路由到对应的提供方，协议转换在后台透明完成。

按 Token 限流

AI API 按 token 数量收费，不是按请求数量计费。一个 10000 token 的提示词请求和一百个 100 token 的请求花费是一样的。如果按请求数做限流，完全对不上真正的成本结构。

Nantian Gateway 的 TokenPolicy CRD 按实际 token 使用量来限制：

apiVersion: gateway.nantian.io/v1alpha1
kind: TokenPolicy
metadata:
  name: team-quotas
spec:
  rules:
    - selector:
        team: engineering
      limit:
        tokensPerMinute: 100000
        tokensPerDay: 5000000
    - selector:
        team: marketing
      limit:
        tokensPerMinute: 50000
        tokensPerDay: 2000000

网关在每次请求和响应时统计 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 入口和边缘路由

最常见的部署模式：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

配上 BackendTLSPolicy 做上游 TLS 和 SAN 校验，可以实现没有断点的端到端加密。

多协议代理

不是所有负载都说 HTTP。数据库、消息队列、游戏服务器和存量协议需要 TCP 或 UDP 代理。Nantian Gateway 在同一个网关里同时处理这些流量。

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。

工作原理

替代 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（批处理任务、Serverless 函数），Sidecar 注入带来的启动延迟不可接受
• 你只需要网格的基础能力（请求头修改、流量拆分、重定向），不想引入完整的网格控制面
• 你已经在用 Nantian Gateway 做入口网关，想把它延伸到东西向流量

警告

无 Sidecar 的网格模型不提供每个 Pod 的 mTLS 或 SPIFFE 身份体系。如果你需要这些，可以考虑 Istio 或 Linkerd 做网格层，再用 Nantian Gateway 做入口。

Wasm 自定义扩展

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

Wasm 插件的应用场景

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

请求转换：重塑 JSON 载荷，做 API 版本转换，或者在转发到后端之前从内部服务取数据充实请求。

自定义可观测性：按你自己的可观测性栈格式输出指标或链路数据，按自定义条件采样，或者输出结构化日志对接现有工具。

合规和治理：检查请求内容中的敏感字段，实施数据驻留规则，或者在代理层推行特定的数据分类策略。

Wasm 插件通过 WasmPlugin CRD 管理，可以绑定到特定监听器或路由上：

apiVersion: gateway.nantian.io/v1alpha1
kind: WasmPlugin
metadata:
  name: custom-auth
spec:
  plugin: custom-auth.wasm
  phase: onRequestHeaders
  targetRefs:
    - kind: HTTPRoute
      name: secure-api