分享实录 | 将 NGINX 打造成功能强大的 API 网关（上）

news2025/4/28 5:57:36

原文作者：易久平

原文链接：分享实录 | 将 NGINX 打造成功能强大的 API 网关（上）

NGINX 唯一中文官方社区，尽在 nginx.org.cn

大家好，很高兴加入此次 NGINX 深潜之旅。接下来我将给大家分享如何将 NGINX 打造成 API 网关。今天我将从以下两个部分进行分享，第一部分给大家梳理一下什么是 API 网关，第二部分着重给大家分享一下为什么 NGINX 比较适合做 API 网关。

1.什么是 API 网关

上图是 Gartner 在 2022 年发布的调查报告，它展示了 2019 年到 2022 年各企业 API 使用情况变化。目前各企业使用 API 的情况发生了很大变化，无论是自研 API、使用公有云 API，或者是使用合作伙伴 API 的企业都有了很大的增长，最令我们感到惊讶的是，有很多企业预计未来会对外提供自己研发的 API，这说明 API 在经济环境中的发展变得越来越重要。

这也可以理解为现在企业发展已经离不开 API，因为企业数字化转型，导致 API 越来越重要。正是因为数字化转型，我们的应用架构也在不断的发生变化，从单体架构到微服务架构，从微服务架构到无服务架构，也衍生出了 SaaS 、PaaS 等各类公有云平台。

随着数字化转型的进程不断推进，API 在技术演进过程中的角色和形态也在不断发生变化。早期 API 更主要的作用是用来做信息访问，在微服务架构里面，API 的作用更多是为了加速创新，让业务迭代速度更快，更能匹配业务发展的节奏。

现在，API 被赋予了更重要的作用——提升用户体验，尤其是在数字化转型进程中，当越来越多的生活轨迹放到线上后，用户体验变得非常重要，这也导致了 API 无处不在，无论是公有云，私有云，还是边缘云，在不同的环境下都可能有 API 的存在，这也导致 API 的管理变得更加艰难。

无论是什么形式的服务，无论是用什么语言开发的微服务，亦或是单体应用服务，它可能对外提供了一个 API，在其中有可能存在一个 API 网关来承接 API 入口的职责。客户端请求从通过互联网再经过 API 网关，再把请求转发到真正提供 API 行为的业务服务端。

那么 API 网关在这个过程充当什么样的角色？我们可以这样理解，API 网关主要核心职责就是作为 API 对外的统一入口。有了 API 网关，我们可以把某一类业务领域的通用能力上移到 API 网关上。API 网关具体的功能职责如下：

身份验证：验证是否允许客户端访问
访问授权：验证客户端可以访问哪些资源
流量加解密：TLS 卸载、mTLS
流量控制：通过限流限速、限带宽、请求校验、内容改写等来控制通过网关的流量
流量调度：基于请求及客户端按条件匹配或比例路由请求到后端服务
日志记录：创建日志以监控和查看 API 流量
指标监控：对 API 流量做精细化指标监控实时观测运行状态

总结起来，API网关的核心功能主要包括以下几个方面：

对 API 调用进行身份验证：使用 Basic Auth, OAuth 2.0/OIDC, JSON Web Tokens (JWT), 或自有认证方式进行身份认证；
控制资源访问权限：使用 JWT、API Keys 或其他授权方式来管理访问权限；
路由与管理 API 流量：支持内容改写、限流、七层转发等流量路由与控制策略；
保护后端服务：使用 TLS 加密流量、管理 CORS 策略、允许特定请求方法或部署 WAAP；
获取 API 流量的可观测性：自定义日志格式，并导出监控指标到 Prometheus, Grafana, Splunk, Datadog 等；
支持常见协议：API 网关支持 HTTP/2、gRPC、WebSocket 等常见协议。

另外 API 网关除了核心功能需求外，还需要考虑非核心功能需求的情况，比如：

配置灵活：网关配置灵活，可快速支持关键业务场景；
与平台无关：可部署在任何地方 - 在云中、本地或边缘；
DevOps 友好：可轻松集成到现有 CI/CD 流水线中；
流量可见性：访问和导出指标和日志以观测和监控 API 流量。

对于 API 网关每个人都有自己的理解，针对实际应用部署情况，API 网关在某些场景下叫流量网关，某些场景下叫微服务网关或者业务网关，今天的分享更多的是从应用场景来考虑这个问题。

目前来看，API 网关大部分的应用情况可能都围绕以下几种：单体应用、微服务、微服务 BFF、K8s 集群、K8s 集群 KIC。

在选择的时候，除了考虑应用架构的形态以外，还需考虑作为一个 API 网关，或者是所谓流量网关，它到底需要代理什么样的后台应用，它是跨业务系统调度，还是需要跨 K8s 群进行调度，这个时候选择是不一样的。另外还需考虑 API 网关属于哪些团队进行维护，它到底是属于运维团队还是应用团队？

API 网关在某种层面上职责不一样，比如流量网关更多被赋予的是全局稳定和流量调度职责，但是业务网关或者微服务网关注的是某个业务能否更好地对外提供业务服务，当然也存在两者叠加的这种情况。所以今天的分享更多的是针对于 API 网关需要实现某些功能，具体的部署情况需要我们针对实际的业务进行考虑。

2.为什么 NGINX 比较适合做 API 网关

先来看一组数据，目前为止 NGINX 有 4 亿线上部署实例，为 Web Server 的第一位。根据 NGINX 社区调查显示，97% 的用户部署 NGINX 开源版本，但是大家忽略了一点，有 30% 的用户是将 NGINX 作为 API 网关进行部署。

因为 NGINX 提供开源免费版和商业闭源版，从功能层面讲，除了数据面的能力以外，还有控制面和管理面的能力。NGINX 有很多的官方模块和配置指令，同时还有很多的第三方开源模块，这些指令可以作用在不同的领域，有可能放在 HTTP 上下文下面，也可能放在 Server 内，也可能放在 Location 下面。

这么多的指令，再加上不同的上下文，它在排列组合以后可以做出很多的场景。这些场景其实主要包括了以下几种，如：软负载、反向代理、API 网关、 Web 服务缓存，还有安全等等。

NGINX 的性能十分优秀，根据第三方机构 GigaOm 的测试数据显示，NGINX 的延迟和吞吐能力相比于其他的产品有很大的优势。这是因为 NGINX 的源代码结构和优化做的十分不错，多进程架构也十分优秀，官方更倾向于使用原生的 C 语言开发模块和功能，总体来说 NGINX 的性能十分优秀。

众所周知，作为流量入口，API 网关的流量请求，无论是面向客户端的统计，还是面向服务端的统计都十分重要，可能都需要去关注它的稳定性和可观测性。随着版本的更替，NGINX 提供了超过 200 个监控指标，这些监控指标可以通过 Prometheus 式的格式发布并且被采集，使得它们可以通过 Grafana 统一的展示。