跳转到内容
Nantian Gateway

分离式平面架构

Nantian Gateway 采用分离式平面架构，控制面和数据面作为独立进程通过 gRPC 通信。这种设计是网关运行和扩展方式的基础。

为什么采用分离式平面？

Section titled “为什么采用分离式平面？”

许多网关实现将代理直接嵌入控制器进程中。这简化了部署，但带来了运维约束：

  • 扩缩容耦合 — 扩展控制面以处理更多 Kubernetes 资源时，数据面也随之扩展，即使没有必要
  • 故障域重叠 — 控制面崩溃可能导致代理同时宕机
  • 资源竞争 — 管理工作负载与数据路径工作负载争夺 CPU 和内存

分离式平面架构将这些关注点分离。控制面专注于配置管理和转换，数据面专注于请求处理。每个平面可以独立扩展、监控和调试。

架构概览

Section titled “架构概览”
┌─────────────────────────────────────────────────────────────┐
│                      Kubernetes 集群                         │
│                                                              │
│  ┌──────────────────┐       ┌─────────────────────────────┐ │
│  │   控制面 (Go)     │       │      数据面 (Rust)           │ │
│  │                   │       │                              │ │
│  │  • 监听 K8s API   │ gRPC  │  ┌─────────────────────────┐│ │
│  │  • 转换 CRD       │◄─────►│  │   代理运行时             ││ │
│  │  • 推送配置       │ xDS   │  │  • TLS 终止              ││ │
│  │  • Admin API      │       │  │  • HTTP 路由             ││ │
│  │  • Web 仪表盘     │       │  │  • 速率限制              ││ │
│  └──────────────────┘       │  │  • AI 网关               ││ │
│                              │  │  • Wasm 扩展             ││ │
│                              │  └─────────────────────────┘│ │
│                              │                              │ │
│                              │  ┌─────────────────────────┐│ │
│                              │  │   xDS 客户端             ││ │
│                              │  │  • 接收配置              ││ │
│                              │  │  • 应用快照              ││ │
│                              │  │  • 健康上报              ││ │
│                              │  └─────────────────────────┘│ │
│                              └─────────────────────────────┘ │
│                                                              │
│                         ┌──────────┐                         │
│                         │ 后端服务   │                         │
│                         └──────────┘                         │
└─────────────────────────────────────────────────────────────┘

控制面（Go）

Section titled “控制面（Go）”

控制面使用 Go 语言编写，以 Kubernetes Deployment 方式运行。它承担以下职责：

  1. 监听 Kubernetes API — 监控 Gateway API 资源（Gateway、HTTPRoute 等）和 Nantian Gateway 自定义资源（AIService、TokenPolicy、WasmPlugin、BackendLBPolicy）
  2. 转换配置 — 将 Kubernetes 资源转换为数据面可理解的内部配置模型
  3. 通过 xDS 推送配置 — 通过 gRPC 双向流将配置快照传输到已连接的数据面实例
  4. 提供 Admin API — 提供用于运维查询和管理的 HTTP API
  5. 托管 Web 仪表盘 — 提供基于 Next.js 的管理界面，用于监控和配置

控制面以高可用副本集方式部署。当控制面发生故障时，现有数据面实例继续使用当前配置运行，但新的配置变更在控制面恢复之前不会被应用。

数据面（Rust）

Section titled “数据面（Rust）”

数据面使用 Rust 语言编写，以独立 Deployment 方式运行。每个实例处理实际的请求路径：

  1. 接收配置 — 建立到控制面的 gRPC 连接并接收配置快照
  2. 应用配置 — 原子性地激活接收到的配置，确保路由行为一致
  3. 处理请求 — 终止 TLS、路由 HTTP 和 gRPC 流量、应用速率限制、转换请求头，并将请求转发到后端服务
  4. 运行 AI 网关 — 在代理内部处理 AI 提供商协议适配、Token 计数和 PII 脱敏
  5. 上报健康状态 — 将指标和健康状态发送回控制面

数据面专为高吞吐量设计。Rust 的内存安全保证和零成本抽象提供了与 C++ 代理相当的性能，同时降低了内存相关漏洞的风险。

xDS 通信

Section titled “xDS 通信”

控制面和数据面通过 gRPC 双向流 使用 xDS 协议 进行通信。该协议定义了配置如何序列化、版本化和传递。

xDS 通信的关键特性：

  • 双向 — 数据面可以向控制面发送确认和健康报告
  • 增量 — 仅传输变更的配置，减少带宽消耗
  • 版本化 — 每个配置快照都有版本号，数据面可以检测并拒绝过期更新
  • 原子性 — 配置快照原子性地应用，防止部分配置状态

当数据面实例连接时，它会收到完整的当前配置快照。后续变更以增量方式传递。如果连接中断，数据面会重新连接并接收最新快照。

独立扩缩容

Section titled “独立扩缩容”

分离式平面设计允许每个平面根据自身需求进行扩缩容：

关注点控制面数据面
扩缩容触发条件Kubernetes 资源数量请求吞吐量
典型副本数2（高可用）2+（取决于负载）
资源特征配置转换消耗 CPU流量消耗网络和 CPU
故障影响无法应用新配置无法处理流量

这种分离意味着需要扩展数据面的流量高峰不会影响控制面，而大量 Kubernetes 资源对控制面造成的负载也不会影响请求处理。

下一步

Section titled “下一步”