过去十年，IT 领域最大的技术变革就是云原生。诞生于 2013 年的 Docker 拉开了云原生的帷幕，从此裸金属、虚拟机开始被容器所替代，单体架构开始被微服务所替代。但是云原生并不是简单的技术革命，其背后的推动力主要来自互联网产品的快速发展和激烈竞争，云原生相关的技术生逢其时，迅速流行并替代了之前的很多技术组件和方案。

具体到 API 网关在云原生中的挑战，主要来自以下两个方面： 单体架构到微服务的转型 在微服务架构逐渐被开发者认可和落地后，该架构释放了巨大的技术红利：每个微服务可以按照自己的节奏进行升级和发布，不需要担心与其他服务的耦合。产品的迭代因此变得敏捷，每天都可以进行几十次甚至几百次的发布。 但与此同时，微服务的发展也带来了一些副作用，比如： API 和微服务的数量从最初的几十个，增长到几千个，甚至几万个； 出现故障时如何快速定位是哪一个 API 引起的？ 如何保证 API 的安全？ 如何做到服务熔断和服务降级？

API 网关无法独立解决安全性、可观察性、灰度发布等问题。它需要与 Prometheus、Zipkin、Skywalking、Datadog、Okta 等众多开源项目和 SaaS 服务合作，为企业提供更好的解决方案。

动态和集群化管理

容器和 Kubernetes 的普及，让动态成为所有云原生基础组件的标准特性。在 Kubernetes 的环境中，容器在不断的生成和销毁，弹性伸缩成为一个必选项而不是可选项。

想要解决上述这些挑战，均需要依赖于动态。以 NGINX 为代表的第一代 API 网关，动态能力是非常弱的。因为 NGINX 是本地静态配置文件驱动的，所以变更任何配置都需要重启 NGINX 服务才能生效，这在云原生时代是不能被企业接受的。这就是第一代 API 网关的技术痛点之一。

在中国，有一家类似微软 Office 365 的 SaaS 办公软件公司 -- WPS，他们有数百台物理机在运行着 Apache APISIX，有近万核 CPU 在处理来自客户端的 API 请求，每天处理数百亿次 API 请求。

在这个超大规模的 API 网关环境下，开发者不可能去逐个修改每一个 API 网关的配置然后 Reload，他们希望有一个统一的控制台来操作整个集群。可惜的是，第一代 API 网关诞生的年代，并没有这么大的实例规模，也就没有考虑集群管理的需求。