By Jermine

☰

当你的系统需要同时处理微服务间通信、跨语言调用和大模型请求时，API 网关就不再是一个简单的路由工具，而是整个基础设施的流量枢纽。本文记录了我在进行 gRPC 一致性哈希负载均衡方案选型时，逐步深入对比 APISIX、Kong 和 Envoy 的全过程，希望能为同样面临复杂网关选型的你提供参考。

一、场景与需求

我们的业务同时涉及三块：

  • 微服务间通信：基于 gRPC，多语言异构（Go / Java / Python）
  • 高可用与弹性：需要一致性哈希实现会话保持 / 缓存亲和
  • 新业务探索：需要对接多个 LLM 厂商（OpenAI、Anthropic、Google Vertex AI 等）

因此，我们的网关需要同时具备以下能力：

  1. gRPC 代理：支持 HTTP/2、TLS、重试、超时
  2. 一致性哈希：基于 header / cookie / 调用方的稳定键
  3. 多语言友好：避免客户端实现复杂逻辑
  4. LLM 扩展：Token 限流、多厂商路由、内容安全

二、gRPC 一致性哈希方案概览

在进入具体产品对比之前，先把业界主流的三条路径捋清楚。

方案一：gRPC 客户端 Balancer 插件

  • 方案：grpc-java 内置 ring_hash，grpc-go 使用社区实现（如 authzed/consistent）
  • 优点：轻量，无需独立代理
  • 缺点：客户端异构维护成本高，跨语言一致性难以保证

方案二：独立代理（Envoy / HAProxy / Nginx）

  • 方案：Envoy 提供 Maglev / Ring Hash 负载均衡策略
  • 优点：稳定、成熟、可观测性强
  • 缺点：需要独立部署和维护

方案三：API 网关（APISIX / Kong）

  • 方案：APISIX 原生支持 scheme: grpc + type: chash
  • 优点：同时具备网关治理能力与负载均衡
  • 缺点：网关本身需要运维

我们的结论：在 K8s 环境下，API 网关模式是最优解——既统一了入口，又为后续扩展提供了基础。

三、APISIX vs Kong：第一轮对比

维度 APISIX Kong（开源）
配置存储 etcd（毫秒生效） PostgreSQL（轮询，有延迟）
云原生适配 原生 CRD、Ingress Controller 支持 K8s，但非原生
性能（P99） ~1-3ms 开销 ~2-5ms 开销
插件数量 100+ 内置 ~40 内置
插件开发语言 Lua / Java / Go / Python / Wasm Lua（开源版）
商业版 API7 Kong Enterprise（功能丰富）

结论：APISIX 更适合云原生、动态环境；Kong 更适合传统企业、强依赖 PostgreSQL 和成熟生态的团队。

四、加入 Envoy：三足鼎立

维度 APISIX Kong Envoy
产品定位 高性能网关 企业级 API 管理平台 L4/L7 代理（数据平面）
开箱即用 ✅ 带控制面和 UI ✅ 带控制面和 UI ❌ 需配合 Istio / Envoy Gateway
配置动态性 毫秒级 秒级 / 重载 xDS 协议，毫秒级
性能 高 中 极致（C++）
学习曲线 中 中 高
适用场景 网关 + 网格边缘 API 管理 + 开发者门户 服务网格 + 高性能代理

结论：Envoy 是"四肢"，需要"大脑"（控制面），适合 Service Mesh 场景；APISIX 和 Kong 是完整产品，适合独立部署。

五、LLM 场景：新的变量

当 LLM 流量进入系统，网关的职责又多了一层：

  • 多厂商代理：统一接入 OpenAI / Anthropic / Google / 国产模型
  • Token 感知：基于 token 的限流、成本控制
  • 智能路由：按模型性能 / 成本 / 内容动态选择后端
  • 内容安全：提示词 / 输出的安全审核
  • 缓存亲和（一致性哈希的重要性）：最大化利用 KV 缓存，降低延迟和成本

一致性哈希在 LLM 场景下有了新的意义——把相同前缀的请求路由到同一后端，可以复用 KV Cache，直接降低延迟和推理成本。

LLM 场景下的产品对比

产品 LLM 定位 关键能力
Envoy AI Gateway AI 原生网关 16+ LLM 提供商、MCP 协议、稳定版已发布
APISIX 能力全面的多面手 ai-proxy / ai-proxy-multi / 提示词安全 / token 限流
Kong 传统能力的 AI 延伸 ai-proxy 插件，高级 AI 能力仅限企业版

六、最终选型决策矩阵

flowchart TD
    Start[核心需求是什么？] --> Q1{传统微服务<br/>gRPC + 一致性哈希？}
    Q1 -->|是| APISIX[推荐：APISIX<br/>开箱即用，云原生友好]
    Q1 -->|否| Q2{需要 Service Mesh<br/>统一南北+东西流量？}
    Q2 -->|是| Envoy[推荐：Envoy + Istio<br/>或 Envoy Gateway]
    Q2 -->|否| Q3{需要开发者门户<br/>+ 企业治理？}
    Q3 -->|是| Kong[推荐：Kong 企业版<br/>生态成熟，功能全面]
    Q3 -->|否| Q4{LLM 流量是主要场景？}
    Q4 -->|是| AIGW[推荐：Envoy AI Gateway<br/>AI 原生设计]
    Q4 -->|否| Q5{需要统一管理<br/>传统 API + LLM？}
    Q5 -->|是| APISIX2[推荐：APISIX<br/>一个平台覆盖所有]
    Q5 -->|否| Envoy2[推荐：Envoy<br/>极致性能 + 高度定制]

按需求场景推荐

需求场景 推荐方案 核心理由
传统微服务 + gRPC + 一致性哈希 APISIX 开箱即用，性能优异，云原生友好
微服务 + 未来 Service Mesh Envoy + Istio / Envoy Gateway 统一南北 + 东西流量
API 管理 + 开发者门户 + 企业治理 Kong（企业版） 生态成熟，功能全面
LLM 网关独立建设 Envoy AI Gateway AI 原生设计，社区活跃
统一管理 传统 API + LLM 流量 APISIX 一个平台覆盖所有，插件生态丰富
极致性能 + 高度定制 Envoy C++ 核心，可编程性强

我们的最终选择

我们选择了 Apache APISIX，理由如下：

  1. 生产环境已验证 gRPC + 一致性哈希
  2. 可同时管理传统 API 与 LLM 流量
  3. etcd 架构与 K8s 天然契合，配置毫秒生效
  4. 支持 Java / Go 开发插件，与团队技术栈匹配
  5. 无企业版功能锁定，成本可控

同时，我们将 Envoy AI Gateway 作为独立评估项，为未来 LLM 流量爆发式增长预留演进空间。

七、避坑指南

  1. 一致性哈希的键选择：务必使用 user_id、session_id、consumer 等稳定标识，避免使用 timestamp、random 等易变值
  2. gRPC 路由格式：uri 必须为 /package.Service/Method，如 /helloworld.Greeter/SayHello
  3. TLS 配置：gRPC 加密需配置 scheme: grpcs，并正确挂载证书
  4. LLM Token 限流：注意限流维度是每分钟 / 每 token，而非简单 QPS

八、写在最后

网关选型没有"银弹"，关键是匹配你的场景：

  • gRPC + 高性能 + 云原生 → APISIX
  • Service Mesh + 极致性能 → Envoy
  • 企业 API 管理 + 成熟生态 → Kong
  • LLM 原生流量 → Envoy AI Gateway

如果可能，建议先搭建 POC 验证核心场景（gRPC 转发 + 一致性哈希 + LLM 代理），再结合团队运维能力、技术栈、成本做最终决策。

技术选型的本质，是在约束条件下寻找最优解，而不是在真空中追求完美。