一个内部服务需要从计费服务中获取用户数据——此时，每一毫秒都至关重要。通过面向公众的边缘网关路由这些内部流量，会迫使您的请求离开私有网络，穿过外部防火墙，并产生不必要的序列化开销。这条路径很容易给单次依赖调用增加 30 毫秒的延迟。
内部服务之间的通信需要与边缘路由不同的架构方法。在边缘端，您需要公开的开发者门户、针对外部客户端的复杂限流以及繁重的 OAuth2 验证。而在内部，您需要的是低延迟、原生服务发现和极低的运维摩擦。
为内部微服务选择合适的 API 网关，取决于您的团队能承受多少运维开销，以及您对极致性能的需求。
内部微服务路由的挑战：自托管与托管
平台架构师在设计内部路由时面临着一个根本性的选择——是在靠近服务的地方部署和管理自托管网关，还是将基础设施外包给托管云服务。
自托管网关运行在您的私有网络内部——通常作为 Kubernetes 集群中的 sidecar 或 Ingress 控制器。这种部署模式使流量保持在本地，从而将延迟降至最低。它还让您能够完全控制路由规则、请求头操作以及与 Consul 或 Etcd 等工具的服务发现集成。然而，您的团队必须管理底层的虚拟机、扩缩容策略和升级。
托管云网关作为外部服务运行。它们几乎不需要维护，并且会自动扩容以应对流量高峰。权衡之处在于延迟和成本。每个内部请求都必须传输到云服务商的网关端点，然后再返回到您的虚拟私有云（VPC）中。这种额外的网络跳跃引入了延迟，可能会降低链式微服务调用的性能。
Kong：凭借丰富插件生态实现的高性能
Kong 是一 open-source 网关，基于 Nginx Web 服务器和 OpenResty Web 平台构建。由于继承了 Nginx 的事件驱动架构，Kong 在高吞吐量、低延迟路由方面表现优异。
[Internal Request] ---> [Kong Gateway (Nginx/OpenResty)] ---> [Target Microservice]
|
[Lua Plugins] (Auth, Rate Limiting, Logging)
Kong 使用 Lua 进行扩展。如果您需要修改请求头、注入身份验证令牌或将请求记录到 Prometheus，只需应用一个插件即可。开源版本 Kong Gateway OSS 包含了丰富的社区插件。对于基于角色的访问控制（RBAC）和多区域部署等高级企业功能，团队则需要过渡到 Kong Enterprise。
管理 Kong 需要管理其配置状态。您可以在传统的数据库模式下运行 Kong，这需要 PostgreSQL 数据库来存储路由配置。或者，您也可以在无数据库（DB-less）模式下运行 Kong。在无数据库模式下，您可以在声明式的 YAML 文件中编写配置，并将其直接应用到网关的内存中。这种方法在 GitOps 工作流和 Kubernetes 环境中运行良好，但这也意味着您无法使用某些需要动态数据库存储的插件。
Tyk：开箱即用、功能完备的 Go 原生网关
Tyk 是一款完全用 Go 语言编写的开源 API 网关。与依赖模块化插件架构来实现核心功能的 Kong 不同，Tyk 直接在其核心引擎中内置了限流、分析和服务虚拟化功能。
由于 Tyk 是用 Go 编写的，它对已有 Go 技术积累的团队很有吸引力。开发人员可以使用 Tyk 基于 gRPC 的插件协处理器，用 Go、Python、JavaScript 或 Lua 编写自定义插件。
Tyk 需要 Redis 才能运行。它使用 Redis 进行会话存储、限流计数器和缓存。虽然这种数据库依赖增加了一个需要管理的运维组件，但 Redis 允许 Tyk 以可预测的低延迟处理海量流量。Tyk 的开源版本功能非常强大，提供了与付费企业版相同的网关引擎——不过企业版增加了一个管理控制平面和仪表盘。
云原生选项：AWS API Gateway 与平台托管服务
如果您的基础设施完全运行在公有云中，那么像 AWS API Gateway、Azure API Management 或 Google Cloud Apigee 这样的托管选项是非常容易获取的。
AWS API Gateway 与其他 AWS 服务直接集成。您可以将传入的 API 调用直接路由到 AWS Lambda 函数、SQS 队列或内部应用程序负载均衡器（ALB），而无需编写自定义集成代码。安全管理通过 AWS 身份与访问管理（IAM）策略进行，这简化了访问控制。
然而，云托管网关也带来了性能上的权衡：
- 冷启动： 如果您与无服务器后端集成，初始请求可能需要几秒钟才能解析。
- 网络跳跃： 流量通常必须离开您的私有子网以到达网关的公共端点，然后再路由回您的私有网络。
- 供应商锁定： 配置与云服务商的专有 API 和部署工具绑定。
对于高吞吐量的内部微服务，这些因素可能会使云原生选项不如自托管替代方案合适。
决策框架：按团队规模和运维预算进行选择
要选择合适的网关，请根据您的性能要求评估团队管理基础设施的能力。
小型初创团队（1 到 10 名开发人员）
如果您的团队规模较小，请优先考虑低运维开销。使用云服务商的托管网关（例如 AWS API Gateway）来快速运行您的服务。在这种规模下，易于设置和零维护的模式超过了轻微的延迟损失。
中型平台团队（10 到 50 名开发人员）
随着服务网格的增长，云网关的成本会随着请求量呈线性增长。在这一阶段，自托管在经济和运维上都变得可行。
让我们来看一个实际的成本对比：
- 托管方案（示例）： 一个中型应用每天处理 100,000,000 次内部请求。以云网关每百万次请求 3.50 美元的示例价格计算，仅路由成本就达到每天 350 美元——或者每月大约 10,500 美元。
- 自托管方案（示例）： 同一个团队在他们现有的 Kubernetes 集群上部署 Kong 或 Tyk。他们运行三个小型计算实例以实现高可用性，计算资源的总成本为每月 150 美元。
自托管选项节省了大量预算——但它需要平台团队每月花几个小时来管理更新、监控 Redis 或 PostgreSQL，并配置部署流水线。
企业级平台团队（50 名以上开发人员）
对于具有严格合规性和亚毫秒级延迟要求的大型组织，自托管网关几乎总是必不可少的。这些团队通常在混合或多区域配置中部署 Kong 或 Tyk，以将流量完全保留在本地数据中心或 VPC 内。
| 选择标准 | Kong | Tyk | AWS API Gateway |
|---|---|---|---|
| 主要语言 | Lua / C | Go | 专有 |
| 数据库依赖 | PostgreSQL 或 无数据库 | Redis | 无（托管） |
| 扩展性 | Lua 插件 | Go, Python, gRPC | AWS 集成 |
| 延迟特性 | 亚毫秒级 | 低（微秒级） | 中等（网络跳跃） |
| 最佳适用场景 | 高性能 Nginx 环境 | 偏好开箱即用功能的 Go 技术栈团队 | 无服务器和纯 AWS 架构 |
在 StackMatch 上评估您的 API 基础设施选项
选择合适的 API 网关是一项关键的架构决策，会影响系统的延迟、成本和运维复杂性。您可以在 StackMatch 上探索更多选项并深入对比这些工具。StackMatch 提供了精选的工具列表、直观的对比页面，以及基于易用性、价格透明度和集成度的编辑评分，帮助平台工程师找到最适合其特定技术栈的方案。
常见问题
在内部路由方面，Kong 比 AWS API Gateway 更快吗？
是的，Kong 的延迟通常明显低于 AWS API Gateway。因为 Kong 运行在 Nginx 上，并且可以部署在靠近微服务的私有 VPC 内，从而避免了与 AWS 完全托管服务相关的网络跳跃和冷启动。
我可以在没有数据库的情况下运行 Tyk 吗？
Tyk 需要 Redis 进行缓存、限流和会话存储。虽然在没有 Redis 的情况下您无法完全无状态地运行它，但与依赖关系型数据库的网关相比，这种架构使 Tyk 能够以极低的延迟处理高吞吐量的流量。
团队应该在什么时候从云原生网关过渡到自托管网关？
团队通常在云原生网关的账单随 API 调用量呈线性增长，或者广域网路由增加的延迟影响到内部微服务性能时进行过渡。如果您的内部服务需要低于 10 毫秒的响应时间，通常需要在 Kubernetes 上自托管 Kong 或 Tyk。
Kong 和 Tyk 如何处理 gRPC 和 GraphQL？
两款网关都支持 gRPC 和 GraphQL 路由，但处理方式不同。Kong 使用插件进行 gRPC 转码和 GraphQL 模式验证，而 Tyk 则提供原生的 GraphQL 引擎功能，开箱即用即可将多个模式合并为单个图。