进击中的云原生网关：APISIX 如何支持云原生应用

云几乎给每项基础设施都带来了变革，网关也不例外。由于各企业技术栈、性能需求、成本预算等不同，企业找到适合自己的网关产品也非易事。另一方面，虽然 NGINX 及其生态已经相对成熟，但随着 Kubernetes Gateway API 的推出，新一轮网关标准定义的争论再次掀起。

我们在 4 月份邀请了网关领域的资深专家，每周一晚 8 点做客《极客有约》直播间，与大家一起聊聊云原生网关的现状与发展趋势。4 月 7 日，我们邀请到了 API7.ai 联合创始人 & CEO，Apache APISIX PMC 主席温铭，与大家一起聊聊进击中的云原生网关。以下内容根据直播内容整理，点击链接可直接观看回放内容。

云原生对网关的影响

InfoQ：温铭老师是网关领域的资深开发者之一。首先想请温铭老师先给我们介绍下网关在过去 20 年中的演进过程。

温铭：对于开发者来说最熟悉的网关是 NGINX，因为它已经存在很长时间了。当我们刚开始接触计算机时，我们经常听到的是 LAMP（即 Linux + Apache + MySQL + PHP）。在早期 1998、1999 年左右，Web 服务器主要使用 Apache，后来由于性能方面的考虑，如并发挑战（如 C10K、C100K 等），大家开始使用 NGINX。如今，NGINX 已成为互联网的重要基础组件，处理着近 2/3 的互联网流量。

随着技术的发展，从单体架构转向微服务架构和从裸金属虚拟机到云上，我们面临的挑战不仅仅是高并发和性能问题，更多的是如何实现快速弹性扩缩容、优秀的集群管理和便捷的二次开发。然而，由于 NGINX 的能力无法满足这些需求，且自 NGINX 被 F5 收购后，其开源社区的活跃度有所下降，特别是其核心开发者大多在俄罗斯，受到国际形势的变化也可能会受到一些影响。

因此，基于 NGINX 的一些新的 API 网关开始出现，例如 Kong和 APISIX，使用 OpenResty 的 Lua 脚本能力来解决 NGINX 遇到的一些挑战。此外，还有一些微服务东西向流量管理产品，开始扩展其南北向流量管理能力（如网关和 API 等），以满足不断增长的需求。

随着技术的不断演进和需求的增长，现在有很多不同的网关产品，有基于 NGINX 的，有基于 Envoy 的，还有很多新的基于 Golang 的网关产品。在 CNCF 的全景图中，API 网关领域列举了很多这样的产品。

InfoQ：云原生给网关提出了新的要求，具体体现在哪些方面？

温铭：云原生网关的要求主要有三点。

第一点是能够实现动态配置的生效，而不需要重启服务。这是因为在现在的环境下，服务的变更可能非常频繁，每秒甚至可能会有几百个变更。在这种情况下，重启 NGINX 是不现实的。

第二点是能够实现集群化管理，也就是能够方便地修改一个地方，然后所有的控制流量 API 网关都能够生效。这需要能够分离控制平面（Control Plane）和数据平面（Data Plane），并且能够在控制平面独立管理所有的数据平面。

第三点是需要能够快速简单地进行二次开发。由于网关控制着所有的流量，因此需要针对不同的系统和协议进行二次开发，以满足各种需求。

现在主流的 API 网关都在这三个方面上做了非常多的尝试。

InfoQ：您刚才提到，类似于 CNCF 全景图中展示的开源产品中最近涌现了很多新的网关产品。那么，这些新产品应该如何分类和区分呢？它们在哪些场景下比较适用？

温铭：在我看来，选择适合你的 API 网关产品要考虑多个维度。

第一个区分的维度是技术栈。例如，像 NGINX 和 APISIX 都是基于 NGINX 技术栈开发的。如果你的公司已经有很多 NGINX 服务，那么使用 APISIX 的迁移成本会更低，工程师也更容易上手。另外就是看基于哪种语言和技术栈开发，例如 Tyk 和 Traefik 等是基于 Golang 开发的，如果你的技术栈都是 Golang 的话，选择这些也是个好选择。还有像 Envoy，它是用 C++从头开始编写的，如果你熟悉 C++并且想要写自定义插件，那么 Envoy 也是一个不错的选择。所以第一个维度就是选择适合你公司技术栈和工程师的产品。

第二个要考虑的维度是开源项目所属的基金会。像 APISIX 属于 Apache 软件基金会，而 Envoy 属于 CNCF 云原生基金会，还有其他像 Kong、Traefik 这样的商业公司控制的开源项目。对于大型公司，特别是 API 网关是关键的组件，需要考虑知识产权和项目的可持续性，考虑基金会项目的许可证是否会改变以及社区的活跃度。

第三个维度是性能，特别是对于一些流量特别大的企业来说。除了考虑前面两个维度，还需要考虑性能和延迟是否能够满足高并发、低延迟的业务场景的需求。如果只有 APISIX 或 Envoy 可以满足需求，那么还是需要招聘或者培训人员来满足业务需求。

综上所述，选择适合你的 API 网关产品需要考虑多个维度，例如技术栈、开源项目所属的基金会、性能和延迟等。没有一个开源项目能够通杀所有场景，需要根据公司的技术栈和需求来选择适合的产品。

InfoQ：技术栈是企业在选择时网关产品首要考虑的因素吗？

温铭：不同行业对 API 网关的选择有所不同。例如，对于金融行业，稳定性是首要考虑因素，因此他们更倾向于使用经过长期验证的技术  。如果他们需要选择一个 API 网关，像 APISIX 或 Kong 是更好的选择，因为它们的迁移成本较低，底层稳定性也足够强。稳定性和安全性是金融行业的关键关注点。而对于互联网公司来说，尝试新技术和参与热门产品可能更为重要。因此，他们可能更愿意尝试新的 API 网关技术，即使这意味着冒更高的风险。对于这些公司，创新和前瞻性更为重要。

APISIX 源起

InfoQ：回到 APISIX，请给大家介绍一下它的起源故事和设计理念。

温铭：APISIX 并不是一个完全从零开始的开源项目。虽然我们从 2019 年开始编写了 APISIX 的代码，但实际上，我们在 2014 年和 2015 年就已经开始与开源项 OpenResty 及其社区在中国进行了密切的互动。我们组织了很多 OpenResty 的大会，为这个项目做出了很多贡献。因此，我们对 NGINX、OpenResty 以及大家如何使用它们都有非常深入的了解。当我们在 2019 年决定创业时，我们看到了上述 OpenResty 和 NGINX 的一些痛点，觉得有机会从零开始做出一个很好的开源项目。

当 APISIX 有了一个雏形之后，我们就考虑如何让 APISIX 成为一个真正广泛使用的开源项目。我们考虑了很多条件，最终决定将其成为一个基金会项目，从长远来看这是一个更能实现我们最初理想的方法。因此，我们在 2019 年 6 月份开源了 APISIX，并在 2019 年 10 月份将该项目捐赠给了 Apache 软件基金会，成为其孵化器项目。

InfoQ：APISIX 整个研发过程大概用了多长时间？这个期间主要攻克了哪些技术痛点？

温铭：针对 APISIX，可以将其发展历程分为三个阶段。

在第一阶段，主要关注性能优化，从 2019 年到 2020 年期间进行了许多性能上的改进和设计，其中核心是使用了一个叫做 Radix Tree 的前缀树匹配算法来快速查找客户端请求所属的路由规则。此外，还对 APISIX 一些核心插件进行了性能优化。

第二阶段的重点是提高稳定性，解决在第一年中出现的一些稳定性问题，确保产品足够稳定。

第三阶段则着眼于生态发展，将 API 网关与各种不同的组件和产品进行集成，以适应用户不断增长的需求。

总的来说，这三个阶段分别为 APISIX 打下了良好的性能基础、夯实了稳定性，并最终在生态上得到了发展。

社区问题：项目名字为什么是 APISIX？有什么特殊含义吗？

温铭：起名其实是件难事。我们当时尝试了许多名字，但发现它们都已被注册商标。与大多数开源项目不同，我们想为 APISIX 选择一个不太常见的名字，以确保可以全球注册商标。因为我们的初衷是将其商业化，商标对我们非常重要。因此，在未开源之前，我们花费了很长时间选择名称，并决定创造一个新词以确保可以全球注册商标。

由于 APISIX 是一个与 API 相关的项目，我们希望人们一看到就知道它与 API 有关。因此，我们将前三个单词选择为 API。而为什么选择“SIX”呢？因为我们希望 API 网关项目能让大家的 API 顺畅地运行，所以我们选择了一个寓意“666”的名称——APISIX。

APISIX 自身如何

InfoQ：产品方面，APISIX 使用了 Lua 这种脚本语言作为加载方式。那么，使用 Lua 作为加载方式有哪些优点和缺点呢？在性能和安全方面是否存在一些问题呢？

温铭：关于 Lua 作为加载方式的优劣，我认为它的优点在于性能。虽然 Lua 是一种脚本语言，但实际上在 NGINX 中它是通过 LuaJIT（即时编译）方式实现的，它是一个经过编译的虚拟机，因此它的性能非常高，与 C 相差无几。当然，这也取决于你的调优能力。写 Lua 代码需要非常小心，因为你很容易写出一个性能一般的插件，但是如果你能够调优得很好，它也可以达到很高的性能水平。Lua 作为一种语言非常精妙，整个 LuaJIT 的代码量并不多，但是它却是一个完备的语言。

不过，LuaJIT 也有一些缺点。其中一个缺点是它的作者是一个半退休状态的人，虽然 Lua 没有太多的 bug，但是也没有太多的新功能增加。此外，Lua 在编程语言中也算是一个小众的语言，可能不会排在前十。如果你学了 Lua，除了写一些游戏脚本、防火墙规则等，其他领域可能用得不太多。相比之下，像 Golang、Java 和 C 语言则可以应用于很多领域。因此， 除了提供原生的 Lua 插件之外，APISIX 也提供了其他方式，例如使用 Golang、Python、Java 或者 WebAssembly 等来编写 APISIX 的插件。

InfoQ：APISIX 今年完成对 Wasm 的支持，相比其他插件有什么优势吗？

温铭：就优势而言，它支持多种语言进行编写，例如 APISIX 插件，同时它的性能相较于使用类似于 Golang、Python 或 Java 等本地 RPC 通信方式编写插件要更高，因为它可以像原生的 LUA 一样嵌入到 NGINX 中。然而，与在 Envoy 中使用 Wasm 编写插件类似的一个缺点是，它的完整性和稳定性还不够，这在服务端的一些复杂场景（如 API、网关）中会有很多坑。尽管人们对此技术非常热衷，但在实际生产中，使用 Wasm 仍然存在许多问题。

社区问题：现在版本的 APISIX 能否在云上不使用独立 etcd，而完全使用云的发现能力来部署？

温铭：这个问题有多种解决方案。我们在开源项目中推荐使用 etcd。在 APISIX 中，CP 使用 etcd 来存储各种配置，但使用本地 YAML 文件之类的方式来管理 APISIX。在这种情况下，可以将 etcd 组件移除，只使用本地的 YAML 文件来管理 API 配置。

在我们的商业云产品中，我们会使用自己编写的组件来替换 etcd，并且在开源社区中也有一些其他的尝试，例如一些用户可能会使用像 MySQL、TiDB、Postgre 等关系型数据库来替换 etcd 组件。

社区问题：Admin API 和 Dashboard 都是直接写 etcd，而且据说数据结构不太兼容，有统一的想法吗？

温铭：这是一个历史遗留问题。APISIX 的 Admin API 直接写入了 etcd 中，在我们的 APISIX Dashboard 控制台的开源项目中，我们还有另外一个名为 Admin API 的项目。在这个领域里面我们缺乏统一性。在我们以前的规划中，我们计划将 Admin API 和 Manager API 统一到 Admin API 上，并取代 Manager API。但在开源社区中，我们尚未真正地实现这个计划。因此，当 APISIX 版本升级时，Dashboard 项目就会滞后或不够完善。

InfoQ：大家对 APISIX 插件生态也非常感兴趣。目前 APISIX 已经支持了近百个插件，那如何管理插件生态？

温铭：我们的核心插件主要是在 APISIX 的初始阶段打下了基础，例如限流、限速和身份认证等插件。这些插件是我们搭建 APISIX 时最基础的部分。后来，我们接入了一些其他的插件，例如 SkyWalking、普罗米修斯、Elasticsearch，以及阿里云、腾讯云和 AWS 等服务。

很多这样的插件都是由开源社区的用户做出的贡献。我们没有碰到过用户在生产环境中遇到的那么多、那么复杂的场景，因此我们需要为插件打下基础，并做一些示范来告诉用户如何编写插件。随着时间的推移，越来越多的开源社区用户在他们的生产环境中遇到了新场景，需要编写新的插件，并将这些插件贡献给上游社区。这正是开源的好处所在：只要你搭建好架子并提供插件机制，其他人就可以方便地为你做贡献，从而不断完善你的生态系统。

InfoQ：开发者自己写插件的难度如何？

温铭：使用 Lua 编写插件非常简单，例如限流、限速这样常见的插件只需要大约 70～80 行的 Lua 代码即可完成。其中大约一半的代码都是模板类的东西，用来定义插件的输入输出。因此，这种插件的难度并不大。但是，由于 APISIX 本身是一个基础中间件，因此如果你想为开源社区贡献一个插件，需要非常完善的测试案例和详细的文档。因为只有经过充分测试的代码和详细文档，开源社区才有能力去维护它。

如何支持云原生应用

InfoQ：现在随着云原生技术的发展，微服务的规模越来越庞大，这给网关带来了哪些新的挑战？

温铭：我认为这些挑战会带来一些影响。首先，微服务数量的增加会对网关的性能和可靠性提出更高的要求。以前只有几十个 API，现在可能有几千个、上万个微服务需要管理，这就需要网关能够进行更加精细的服务熔断、健康检查、监控和安全保护等方面的管理。如果管理得不好，用户出现问题时就会很难定位和发现。其次，随着云原生的发展，使用的开源项目也越来越多，涉及的生态系统也越来越庞大，这就需要网关能够与各种开源项目进行良好的对接，同时也需要具备更高的可扩展性和二次开发能力。

我认为对于一些核心的 APISIX 维护者而言，我们更注重的是插件的灵活性。这种灵活性不仅仅体现在插件机制的可调整性上，而且也表现在 APISIX 插件即插即用的特性上。这意味着当我新增一个插件时，我无需重启服务即可使用它。同样地，如果我需要修改一个已有的限流、限速插件的代码，通常情况下我必须重启服务以使新代码生效。然而，在 APISIX 中，这个过程是通过热更新实现的，即使插件代码发生变化，也可以不用重启服务即时更新生效。因此，APISIX 充分考虑到了用户在不停机的情况下如何更新代码，并实现了许多底层“黑科技”的功能。

社区问题：APISIX 和公有云 API 网关的使用场景有何不同？虽然现在有很多网关产品，但许多人可能并不清楚它们之间的差异。

温铭：确实，很多企业在选型时会问我们和公有云的 API 网关有何不同，其实我们并不是竞争关系，而是互补的。对于流量较小、服务都在 AWS 上的企业，公有云的网关可能是一个很好的选择，因为它提供了开箱即用的全家桶，易于配置和使用。但是对于有多云、混合云需求的企业，以及需要进行定制化开发的企业，公有云的网关可能无法满足需求。开源的 APISIX 项目可以为这些企业提供灵活的定制化开发，同时避免了供应商绑定的问题。所以说，我们能够面对的那一组用户的需求是不一样的，需要根据实际情况来选择。

社区问题：APISIX 有标签路由能力吗？

温铭：APISIX 具备强大的流量管理能力，例如产品灰度发布和流量路由，其中流量标签功能可以通过在请求头中添加标签来管理流量。此外，APISIX 还提供了名为 Workflow 的插件，可以更定义复杂的流量管理策略。虽然 APISIX 的企业版中包含了一个标签路由组件，但这个组件还没有开源。然而，实现这个功能并不复杂，只需要编写一个判断条件并添加一个 header 头。这些功能都是 APISIX 技术的组合，将来可能会考虑将它们开源。

社区问题：Lua 是一个缺少调试工具的语言，APISIX 的开发过程中是否因此困扰过？

温铭：我没有困扰过。实际上，主要原因是我之前用 Python、PHP 以及 C 编程时都有很方便的动态调试工具，可以设置断点，逐步调试代码并查看内存中的值。这些工具非常便捷。但是当我开始使用 NGINX、APISIX 时，发现这些工具都不再可用，只能使用最原始的“打日志”方法。

然而，我并不认为这是一件坏事。至少在我们公司和 APISIX 社区中，许多东西都是通过测试驱动开发的方式实现的。也就是说，当我们编写插件时，必须有完善的测试案例来保证。在测试过程中，如果发现了一个 bug，就需要通过测试案例来重现该 bug，并在关键位置“打日志”来查找问题并修复 bug。一旦修复完毕，测试案例能够通过，就说明该 bug 已经被修复。

另外，Lua 编程相对简单，没有像面向对象编程那样复杂嵌套的结构。在 APISIX 中，插件如限流和限速插件并不复杂，核心代码只有几行，因此也不需要太复杂的调试工具。当然，如果遇到一些关键代码出现 bug，例如 OpenResty 或 NGINX 核心代码，那么可能需要使用 coredump 来调试。

综上所述，对于基于 NGINX 和 APISIX 的工程师来说，通常需要查看日志并采用测试驱动开发的方式进行调试。虽然社区中也有一些动态调试插件和工具可供使用，但至少对我来说，我更喜欢使用日志来调试。

InfoQ：K8s Ingress 现在也比较受到关注，那么 APISIX 如何和它进行结合的？Apache APISIX Ingress Controller 与 K8s 社区版的 Ingress 存在哪些差异？

温铭：Kubernetes 官方的 Ingress Controller 是一个众多公司和开源社区共同贡献的项目，其中包括我们公司。该项目目前全球有三个维护者，其中一个主要维护者是我们公司的同事。因此，我们也在积极地参与维护 Kubernetes 的 Ingress Controller 项目。

这个项目非常实用，能够让用户方便地将之前使用的 NGINX 迁移到 Kubernetes 中的 Ingress 中进行流量控制。在实现动态控制方面，该项目进行了一些权衡，增加了 Lua 脚本功能，但它仍然存在一些限制，比如不能动态添加 location 等内容。与之不同的是，APISIX 的目标是基于 APISIX 实现 Kubernetes 的 Ingress，因此我们可以将之前提到的极致动态能力带到 Ingress 中。这是一个显著的区别。

另外一个区别在于，Kubernetes 官方 Ingress 项目的维护力量相对不足，随着最初的作者退休，现在更多地处于冻结新功能状态，除了修复 bug 之外，几乎没有新功能的添加。

社区问题：后续 APISIX 会主推 Wasm Proxy 来开发插件吗？对 Gateway API 后续有什么计划吗？

温铭：我们现在已经有 Proxy Wasm 这样一种方式，但是它仍然存在一些不够成熟的地方，包括整个 Wasm 生态系统和二次开发，这些方面都还需要进一步发展。不过，这个技术正在快速迭代和演进中，从长远来看，在未来的 3～5 内，它有望成为一种非常好的手段。我们会继续关注它的发展。我们已经在 NGINX 中成功嵌入了 Wasm，这是一个好的基础。接下来，我们需要思考如何在这个基础上实现一些异步通信、与 Lua 插件更好地配合以及充分发挥 Rust、Golang 等插件的能力，等等。这些问题都可以随着时间和更多的开发资源的投入而得到解决。

对于 Gateway API 的支持，APISIX 对 Gateway API 的支持已经算是比较完善的了，现在应该还没有一个 API Gateway 是提供完全支持的，甚至像 Kong、Envoy 也都没有完整支持南北向的 API。像 APISIX 的 Ingress controller 也在不断地做一些支持，大家可以关注一下。对于 APISIX 这个开源项目来说，我们计划推出自己的一套标准，类似 APISIX Gateway API，通过定义这样的标准，我们希望能够更好地发挥 APISIX 自身的优势，包括很多其他组件没有的动态能力。

社区问题：APISIX 跟 OpenResty 的最大区别在哪？

温铭：实际上 OpenResty 是基于 NGINX 开发的，在 NGINX 之上使用了 LuaJIT 的能力，使得 NGINX 具备了动态性。APISIX 是一个 API 网关产品，它在 OpenResty 的基础上封装了近 100 个插件。这样一层一层地发展下来，形成了一个生态系统。这也是开源项目的优点之一，很多开源项目是在其他开源项目的基础上发展起来的，就像雨林生态系统一样，非常健康。有人负责底层，有人往上加层，还有一些厂商在 APISIX 之上又加了一层。整个系统是分层次的，彼此促进而非竞争。APISIX 并不会直接开发 cdn 或者其他系统，但你可以在它的基础上寻找你需要的组件。如果你发现了 bug，可以反馈给 APISIX，APISIX 会将其反馈给 OpenResty，这样整个生态系统就会不断扩大。但我们也担心一些公司不断向下扩张，最终导致整个生态系统崩溃。

InfoQ：如果企业已经广泛应用了云原生技术，那在 APISIX 和社区产品以及其他云原生社区产品之间，如何进行选择呢？

温铭：这要取决于用户的需求。如果用户没有对动态位置、动态证书或动态插件等方面有强烈的需求，那么 Kubernetes Ingress 应该足够满足需求。虽然它目前并没有处于活跃的开发状态，但它已经被众多社区用户使用，是一个经受住时间考验的开源项目。因此，是否需要选择 Kubernetes Ingress 还要考虑用户的具体需求，是否感到它已经解决了自己的痛点。如果用户认为开源社区 Kubernetes Ingress 已经无法满足自己的需求，那么可以考虑使用 APISIX。

InfoQ：动态支持具体是怎么实现呢？为什么 APISIX 要做这个事情？

温铭：这个点很有意思，虽然它偏技术。Lua 是一个脚本语言，脚本语言其实是一个双刃剑，它的缺点是效率不如 C 或 Golang 这样的静态语言，但是它的好处是可以在运行时动态修改代码，即在内存中修改代码。这是很多静态语言所做不到的特性。因此，APISIX 使用 Lua 插件的优点就在于，它可以在运行时动态替换代码。

例如，如果我的一个插件代码返回的默认值是 4，但我想将其更改为 401，我只需要在内存中替换这段代码即可，而整个 API 进程无需重启。这是动态语言的优势，它可以在运行时动态地进行代码替换。如果将这个优势发挥到极致，可以实现很多有趣的特性。例如，在一些客户端调试时，如果线上出现了一个 bug，服务重启可能会导致 bug 无法定位，但是通过编写 Lua 代码，在内存中动态捕获数据就可以轻松解决这个问题。总的来说，如果运用得当，动态语言可以实现很多有趣的特性。

InfoQ：多云、混合云场景下的 API 管理非常难，APISIX 对此主要做了哪些事情来帮助用户？

温铭：在多云和混合云环境下进行 API 管理是非常具有挑战性的。开源项目并不一定能够提供统一的 API 管理能力，因为很多开源项目并没有公开这些功能。在涉及到多云、混合云管理时，必然需要涉及到多集群、多租户和各种身份认证等问题。在这种情况下，很难找到能够满足企业级需求的开源项目。通常情况下，需要寻找相应的企业级产品或云服务产品来解决这些问题。

InfoQ：APISIX 计划在未来进行哪些性能方面的优化，或者增加哪些新功能呢？

温铭：对我们而言，APISIX 的内核部分已经趋于稳定。现在，我们的重点是在生态集成方面做更多的工作。这是第一个部分。第二个部分则是在多云、混合云场景下使用 APISIX 时，就仅限于能够使用的状态，但并不方便使用。我们的目标除了生态集成之外，就是逐步改进 APISIX 的易用性。这是我们第四个阶段的主要目标，前三个阶段分别是性能、稳定性和生态。

社区问题：APISIX 现在支持哪些服务发现组件？

温铭：目前，主流的服务发现组件如 Nicos、Consul 和 Eureka 都已经实现支持了，但实际上还需要一些完善和改进。现在我们的支持分为两个方面：一方面是在数据平面上实现服务发现，即在用户请求到达时进行服务发现；另一方面是在控制平面上进行服务发现。我们的子项目 APISIX Seed 可以控制平面上进行服务发现。虽然社区已经贡献了一些高级的服务发现特性，但是如果需要身份认证等高级功能的话，可能目前的支持还不够完善。

开源社区与商业化

InfoQ：刚才多次提到了社区对 APISIX 项目的贡献。作为一个全球化社区，APISIX 如何进行运营管理？

温铭：其实总结起来最重要的经验是尽可能交更多的朋友。我们不应该把开发者仅仅看作是提交代码的工程师、销售线索等，而是要把他们当做朋友，让他们和社区一起成长。我们经常会和他们见面聚餐，寄送周边礼物等等，这些看似随机的行为实际上都是在播种，将我们的项目宣传给更多的人。尽管这些行为看似无法预测，但是我们做了很多之后，社区的影响就越来越深入。当然，每个开源项目都有其独特的文化和性格，有些项目可能不太喜欢低质量的问题，有些项目可能不愿意接受外部的贡献，因此需要我们了解和适应不同项目的调性。

InfoQ：您会怎么概括 APISIX 社群的调性呢？

温铭：我认为 APISIX 社区对于新手来说非常友好。有问题时，官方通常会及时回复，虽然不能保证回答所有问题，但对于新手还是非常友好的。如果您想在 OpenResty 和 NGINX 上精进，那么 APISIX 是一个很好的项目。您可以接触到国内顶尖的开发者，他们可以为你的代码进行审查并指导你的设计。这也是开源社区的魅力之一，可以通过这种方式与全球顶尖的开发者直接沟通。

InfoQ：开源社区也会有相应的商业模式。您可以介绍一下目前 APISIX 的商业模式吗？

温铭：实际上，大多数开源商业化公司都有三种商业模式。

第一种是商业支持，就像红帽公司一样。如果你使用开源项目并将其应用于非常关键的组件上，你可能会担心在出现问题时没有人提供支持，可以购买商业版本并获得商业支持。

第二种是企业级产品，其特点与开源产品略有不同。开源项目可能只开发了核心功能，而一些企业级功能，例如多云、混合云、安全特性、多集群和多租户等功能，可能会放在企业版中。

第三种商业模式是云版本，可以帮助你降低版本的维护、升级以及各种安全等问题的成本。如果你需要雇佣三四个人来维护一个网关，而这些人的工资又非常高昂，那么你可以选择购买云产品。

基本上所有的开源商业化公司都采用这三种商业模式。

InfoQ：APISIX 在商业化这几年里有什么经验可以分享吗？

温铭：我认为开源和商业是两个不同的话题。当你真正试图商业化时，开源项目并不能直接帮助你，你不能期望开源项目做得好就一定能做好商业。然而，如果开源项目没做好，你也不能指望基于它做商业化公司能成功。因此，我们通常认为开源有三个不同的阶段。

在第一个阶段，你必须把开源项目做好，最好成为行业标准或者至少成为该领域的领导者，就像 APISIX 一样，我们已经成为国内该领域的第一。

第二个阶段，你需要有很多用户案例，这些用户案例需要在技术上有创新，比较深入地使用你的开源项目。

第三个阶段，你需要选择商业化的路线并看看用户是否愿意购买你的产品或服务。

在不同的阶段，你需要考虑的因素也不同。因此，不能说在商业化公司中，开源项目就不重要了。你需要看看处在哪个阶段，如果你处于第一个阶段，应该把重点放在做好开源项目，否则公司肯定不能长期发展。但是，如果已经到了第三个阶段，你的精力还都在开源上，而没有在商业化上，那么也很难持续地做好开源项目。开源和商业化是不同维度的话题，需要根据阶段和具体情景来考虑。

社区问题： 如何参与 APISIX 的社区贡献？

温铭：参与 APISIX 开源社区非常简单。由于 APISIX 是一个 Apache 项目，因此在 GitHub 上搜索，找到 Apache 下面的 APISIX，按照入门文档进行一两行命令的操作，即可启动 APISIX。启动后，可以检查这些功能是否对你的工作有帮助，并提供反馈或问题。这就表示你已经参与了 APISIX 的开源社区。对于开源项目而言，贡献不仅限于代码，文档和提供有价值的反馈也是一种贡献。例如，你可以在公司内部编写幻灯片来介绍 APISIX 项目和其用途，这也是一种贡献。

社区问题：APISIX 是如何保持强劲性能的呢？

温铭：我认为 APISIX 首先具有一个很好的基础，因为在最初的基础打磨阶段，我们花费了相当长的时间。至于性能方面，我认为没有什么特别好的方法，只需要每隔几个月在发布大版本的时候，做一次性能回归，查看一些常见路径下的性能是否有所下降，如果有下降，就需要找出导致下降的原因。通常情况下，APISIX 的性能下降是由于一些组合场景下的代码没有进行充分优化导致。

InfoQ：目前在网关领域，大家都在竞争。您如何看待云原生网关未来领域的发展？目前还有哪些挑战需要克服？

温铭：我认为这是一个好现象。在数据库领域，已经有几百个甚至更多的产品在竞争。API 和网关领域并没有像那样激烈，目前只有 20-30 家左右的竞争者，这意味着还存在一些机会。至于谁能脱颖而出，很难说。

我们需要回归到几个要点，首先，开源项目是否足够好？其次，用户案例是否充足？是否有一些实际的企业在使用项目并提供反馈？第三，公司是否能够长期持续运营？对于开源项目来说，通常需要两三年时间才能开始获得回报。如果没有撑到最终收获的那一天，也不能算是一个成功的开源项目。我认为这是一个多方面综合考虑的问题，就目前来看，机会还是非常多的。

InfoQ：技术上大家现在需要聚焦攻克哪些问题？

温铭：如果只是针对 API 网关本身的而言，实际上已经没有太多大问题了。更多的则是关于 API 网关这一位置比较特别，因为它处于一个流量出入口的位置，所以关键点就在于能否有效地帮助用户管理好南北东西方向的流量，并且与各种用户系统快速简便地接入。另外，能否在安全和可观测性方面比其他同类产品更深入，使得产品更加易用，这些都是非常重要的因素。在这些问题上，很多时候都需要进行一些细节方面的打磨。