开源浪潮下，Apache APISIX 如何成为全球最活跃 API 网关

白泽平，Apache APISIX PMC 成员，目前主要在 APISIX 和周边项目 APISIX Dashboard 上进行相关贡献。本文整理自阿里云「中间件开发者 Meetup」中的议题分享。

Apache APISIX 是一个高性能的、动态的、实时的 API 网关，它是基于 NGINX 和 OpenResty 进行实现的。

作为一个脱胎于 NGINX 和 OpenResty 的软件，APISIX 天然继承了 NGINX 的性能和 OpenResty 的灵活性，因此，APISIX 的性能在一众 API 网关中都是数一数二的。

细数 Apache APISIX 优势

架构取长补短

具体来说，像 NGINX + Linux epoll 提供了高性能的网络 IO 基础设施，这些是 C 语言实现的，是静态的。而 OpenResty 则集成了 LuaJIT，它基于 NGINX 提供的生命周期钩子进行扩展，允许用户通过 Lua 代码对 NGINX 进行编程。而 LuaJIT 本身，得益于优秀的 JIT 实现，它可以在运行时对代码进行 JIT 编译，当热路径上的内容被编译为机器码后，性能将可以与原生 C 语言相比。

当然，除了 NGINX 与 OpenResty 的天然特性优势外，APISIX 本身也为性能进行了多处优化。比如没有复用 NGINX 的 location 来处理路由匹配，而是使用了基数树的方式。目前其他很多 API 网关还在使用遍历的方式处理路由，而 APISIX 则不会出现遍历方式的严重性能衰退，在路由很多时（这里指达到数千量级），它也可以提供基本平稳的匹配速度。

同时，APISIX 也在动态性能层面进行了一些操作。

相信使用过 NGINX 做服务部署的朋友一定记得，如果你修改了 NGINX 的配置文件，即使只是添加了一个 location，也必须要通过 NGINX reload 指令来应用配置，甚至有时还需要重启。这种情况对于内部应用场景来说还可以接受，但是对线上应用来进行这种操作时，可能会造成客户端连接的中断，这就影响很大。

而在 APISIX 中，上述配置操作过程都是完全动态的，location 可以动态配置，upstream 和 SSL 证书这些全部都可以动态配置。这主要得益于 APISIX 使用了 etcd 作为配置中心，通过 etcd watch 机制实现了动态的更新其配置，从而不需要依赖 reload 和重启。

除此之外，像是以往需要 NGINX 修改配置才可以设置的 gzip 和缓存等，也可以动态地在单一路由的维度中进行启用。

如上是 APISIX 体系的架构图，底层就是刚刚提到的 NGINX + Lua 环境，再向上是 APISIX 的核心模块，它包括路由、上游等相关能力，还有一些常用功能的封装。这个核心模块也是插件框架的入口，用户在类似路由等组件中配置路由时，将被合并在此调用执行。

APISIX 在核心模块中提供了很多开箱即用的功能，比如负载均衡、动态上游、灰度发布、服务熔断、身份认证、可观测性、服务发现、限流限速和日志收集等功能。

APISIX 中的很多功能都是通过插件方式进行实现的，目前 APISIX 的插件已接近 80 个，未来还在持续扩展增加中。提到插件，不得不说 APISIX 提供的插件运行时是一个非常易于开发的插件框架，用户可以轻而易举地使用 Lua 编写自己的插件，来实现特定业务功能。如果实在不具备 Lua 的开发维护能力也可以使用外部 Plugin Runner（APISIX 多语言插件） 或者 WASM 开发插件。

开源活跃开放

APISIX 是 Apache 软件基金会旗下的顶级开源项目，它使用了 Apache License v2 开源协议，对商业使用与二次开发都比较友好。

同时 APISIX 社区也一直保持着活跃，包括但不限于产品技术本身的活跃（比如近一个月内有 70+ commit，处理了 70+ issue 等），还有社区活动和一些内容分享上的全球布道等。

Apache Way 的理念，指导着每一个 Apache 基金会开源项目，即「社区>代码」。社区的建设至关重要，重要性甚至超过项目代码本身。回过头来我们看，为什么 APISIX 社区可以如此活跃？

• 社区开放，欢迎任何有意义的讨论（比如问题报告、新功能等）。除此之外，无论项目维护者身份如何、来自什么公司，大家都采用同样的方式参与社区。所有讨论都在邮件列表内进行，未经邮件列表讨论的事项，就是不存在的；全部开发工作也都是公开的，任何事项都有痕迹。

• 经常与其他社区进行项目合作。 比如 APISIX 的很多插件都是与其他项目或者服务的集成，像 Casbin 社区参与到 APISIX 项目中，贡献了 casbin 权限管理和 casdoor 身份认证插件。

• 通过各种渠道吸引新的贡献者参与社区比如 APISIX 项目已连续多年参与 Google GSoC 计划和国内开源供应链点亮计划等活动，吸引国内外对开源项目感兴趣的学生来参与其中，增加学生们对开源社区的经验。

周边项目齐开花

上文我们提到的都是 APISIX 项目本身的一些内容。但其实，基于 APISIX 这个云原生 API 网关，也衍生出了很多周边项目。

通过使用 APISIX Ingress Controller，用户可以将 Kubernetes Ingress 资源和 APISIX 自定义的 CRD 资源提取出来，进而为 APISIX 配置路由、上游或插件等。它将自动根据 K8s Service 生成上游，并与路由进行关联，提供了一种在 K8s 中的声明式 API 的实现路径。

除此之外，APISIX 还提供自己的开源控制台实现——APISIX Dashboard，它提供了 APISIX 中最常用功能的可视化配置能力，可直接在界面上修改即可完成 API 的配置上下线。这与 APISIX Ingress Controller 提供的代码即配置的思路有所不同，前者注重配置的灵活性，而后者注重规则定义的确定性。

同时在当前最热门的服务网格领域，APISIX 也在尝试交出自己的答卷。APISIX 的服务网格项目 Amesh 现已经开源，目前的方案使用 Istio 作为控制面实现，与 Envoy 一样通过 xDS 协议与 Istio 通信，并将通信规则转换为 APISIX 中的路由与上游配置。从而替换了 Istio + Envoy 组合中 Envoy 的流量网关角色。

APISIX 如何应对应用发展

现代应用系统架构已经经过多次发展，从单体应用、多单体应用+企业服务总线的 SOA 到现在的多微服务架构演化。

当单体应用迭代到微服务后，微服务本身具有一定规模后，单纯的微服务并不足以解决生产上面临的问题。其伴随的一个显著特征就是，服务的数量在大幅增长，各个服务间的调用关系也变得更加复杂。

因此，在不同的阶段其实大家都面临着很多不同的技术选型。比如服务层面，我们可以用到像是 Apache、NGINX、HAProxy 这样的反向代理工具。进入到微服务时代我们又会用到像 NGINX 或是一些更加现代化的动态 API 管理工具，这里又会因为技术栈的不同扩展出更多的产品。比如在 Java 语言侧选择 Zuul 或者 Spring Cloud Gateway 这样的组件，在 Kubernetes 部署又会有 Ingress 等选择。更进一步到服务网格架构中，又会产生 Istio + Envoy/MOSN 这种选择。

各种技术手段浩如烟海，如何根据当前企业、团队的状况选择最合适的架构对架构师的能力带来很大的挑战。

除了整体架构上的选择，随着团队的扩大和业务场景的复杂，对于开发者而言，需要了解和考虑的东西越来越多。这种情况下，各种各样的流量比如 HTTP/TLS、gRPC、四层的 TCP/UDP、中间件的调用（比如 Redis 缓存）等等，对它们进行统一的管理正是当下应用发展阶段所面临的困境。

APISIX 作为云原生 API 网关，为许多企业提供了一个更优的选择。在应对各种不同场景时，APISIX 有着一些流量代理的用法。比如我们可以将 APISIX 作为一个 LB 来处理对外服务的负载均衡问题，同时也可以将其用作 API 网关来解决微服务的暴露与调用，利用 APISIX Ingress Controller 还可以解决容器中的 API 管理难题。

可以看到，使用 APISIX 可以为你在不同阶段提供一个统一的、全流量的处理方式。那这种方式能为用户带来哪些收益呢？

• 对于研发人员来说，如果一个人掌握了 APISIX 这套体系的技术，他就可以很轻松地完成企业团队中各种不同领域的工作，比如在 API 网关或者 Ingress Controller 这种流量管理的落地场景。

• 对于运维人员来说，使用 APISIX 后无论是后续维护现有环境还是切换到新的技术栈上，你都可以直接使用同一种工具和方法进行直接管理，而无需再投入学习和时间成本。同时作为开源产品，学习之后还可以作为自身的技术积累复用到其他工作中，可谓是一举多得。

• 对于公司来说，选用 APISIX 的架构不仅仅可以满足现有需求，还为将来的技术演进预留下空间。比如当下是为了满足作为 LB 的需求，如果之后公司技术发展，将来也可以无缝过渡到 API 网关或者容器平台乃至服务网格等领域。

展望：与 OpenSergo 的未来计划

我们在上文中也提到了与其他社区的积极合作。在之前，OpenSergo 在 APISIX 社区项目仓库的 issue 中曾发起讨论，希望可以通过社区合作的方式，协商建立一个用于流量控制的统一标准，这引起了一部分社区成员的兴趣。之后在一次 APISIX 社区的中文 Weekly Meeting 中，OpenSergo 社区的伙伴也为大家介绍了这一项目的愿景、思路和价值。

作为一个开放且包容的开源社区，APISIX 是非常欢迎这种社区间合作的，通过项目协同可以发挥出各自项目更大的价值。

具体来说，由于 OpenSergo 项目标准的表现形式主要为 Kubernetes CRD， 其用于云原生的容器环境中，因此可以优先考虑将它与 APISIX Ingress Controller 项目进行集成，为其增加 OpenSergo 的配置解析和处理模块，将原始配置转换为 APISIX 的内置速率限制插件等。

这种做法有助于使用 Kubernetes 的用户来增强其流量控制能力，并与其他各种上下游生态进行集成，比如 RPC 框架。对于不使用 Kubernetes 的用户，在目前产品现状下，还缺少一个桥梁去完成 CRD 到 APISIX 插件的配置转换。

因此，我们也有参考彼此产品的一些未来规划。比如 OpenSergo 的文档中提到，它们将发布专门的 SDK 供数据面组件调用以集成至 OpenSergo。如果有了 SDK 或是其他形式的接口，在接下来的日子里，有望看到 OpenSergo 与 APISIX 的集成项目。

最后，作为开源活跃项目，APISIX 社区也非常欢迎有兴趣的伙伴来提交这些功能的实现，帮助项目的集成成为现实。相信通过开源间的合作，彼此项目都可以取得更大的成就。