几十个微服务的接口怎么管？API 网关三种方案对比

系统拆成微服务之后，一个尴尬的问题浮出水面：每个服务都要自己处理认证鉴权、限流熔断、日志埋点、跨域、协议转换，同一套横切逻辑在几十个服务里重复写了几十遍。前端更崩溃：调一个页面要直连七八个服务地址。API 网关就是为这个而生的——所有流量从一道门进出，公共能力收敛在门上。

核心矛盾是：横切能力散落在每个服务里，改一次策略要全公司发版。 落地网关有三条主流路线：Nginx/OpenResty 自建、开源 API 网关、云厂商托管网关，掌控力和运维成本各不相同。

方案一：Nginx/OpenResty 自建

原理： 基于 Nginx 做反向代理，用 Lua 脚本（OpenResty）实现鉴权、限流、灰度等逻辑，配置和脚本全部自己维护。

优点：

• 性能天花板最高，C10K 级别的转发能力久经考验
• 零许可成本，机器资源占用极小
• 逻辑完全自己掌控，没有任何框架约束

缺点：

• Lua 脚本维护门槛高，写得动的人少，愿意接手的人更少
• 配置即代码但缺乏管理界面，路由多了以后靠文本配置管理很原始
• 动态化能力弱：改路由要 reload，服务发现要自己动手接

适用场景： 服务数量少、流量模型简单、团队里有 OpenResty 高手的场景。严格说它更像"反向代理+"，不是完整意义的 API 网关。

方案二：开源 API 网关

原理： 部署成熟的开源网关（Kong、APISIX、Higress 这类），自带插件体系：认证、限流、熔断、日志、灰度开箱即用，通过管理 API 或控制台动态配置，天然对接服务发现。

优点：

• 功能完整度高：几十种官方插件覆盖网关的常见需求
• 动态配置：路由、插件热更新，不用重启 reload
• 云原生友好：Kubernetes Ingress、服务网格生态都有成熟集成

缺点：

• 要自己运维：网关本身是核心基础设施，高可用、扩缩容、版本升级都是活
• 插件的默认行为未必贴合业务，深度定制还是要写插件（Lua/Go）
• 管控面（Admin API）的安全要做好，网关被控等于门户大开

适用场景： 微服务架构成型、有专职平台运维团队的中大型技术组织。是当前私有化部署的主流选择。

方案三：云厂商托管网关

原理： 直接使用云厂商的 API 网关服务（如腾讯云 API 网关），按调用量付费，路由、鉴权、限流、监控全托管，与云上的函数、容器、负载均衡打通。

优点：

• 零运维：不用养网关集群，可用性由云平台兜底
• 开箱即用：和云监控、云日志、云安全产品天然集成
• 弹性伸缩：流量波峰自动扩，不用预留容量

缺点：

• 按调用量计费，大流量下成本可能超过自建
• 深度定制能力受平台限制，特殊鉴权、复杂编排未必支持
• 厂商绑定：配置和生态长在一家云上，迁移有成本

适用场景： 业务跑在单一云上、团队小、不想养基础设施的公司，以及 Serverless 架构的默认搭档。

按组织规模对号入座

常见的组合是分层：南北向流量（外部用户进出）用云托管网关，东西向流量（服务间调用）用开源网关或服务网格，各管一段。

落地前必做的三件事

第一件：先把公共能力清单列出来。 认证、限流、灰度、日志、监控，哪些收敛到网关、哪些留在服务里，边界要定清楚。什么都往网关塞，网关会变成新的巨石。

第二件：网关本身的高可用先于业务上线。 网关是所有流量的咽喉，它挂了等于全站挂。多实例、健康检查、降级预案，必须在承载业务流量之前就位。

第三件：路由和插件配置要代码化管理。 无论是开源网关的声明式配置还是云网关的导出文件，进版本库、走评审、可回滚。靠控制台手点的网关配置，出事故时连"谁改了什么"都查不到。

写在最后

API 网关的选型，核心是看"你要为这道门投多少运维"。没平台团队就选托管，有平台能力就开源自建，流量简单就别折腾。网关的价值不在转发流量，在于让认证、限流、灰度这些能力只有一份实现——这份"只有一份"才是微服务架构能长期演进的前提。