未来已来|人工智能与数据库融合发展分论坛议程初探 了解详情
写点什么

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

  • 2023-04-21
    北京
  • 本文字数:11287 字

    阅读完需:约 37 分钟

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

6 月 17 日,极客时间《企业级 Agents 开发实战营》正式上线,10 周掌握企业级 Agents 从设计、开发到部署全流程。

云几乎给每项基础设施都带来了变革,网关也不例外。由于各企业技术栈、性能需求、成本预算等不同,企业找到适合自己的网关产品也非易事。另一方面,虽然 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 网关这一位置比较特别,因为它处于一个流量出入口的位置,所以关键点就在于能否有效地帮助用户管理好南北东西方向的流量,并且与各种用户系统快速简便地接入。另外,能否在安全和可观测性方面比其他同类产品更深入,使得产品更加易用,这些都是非常重要的因素。在这些问题上,很多时候都需要进行一些细节方面的打磨。

 

2023-04-21 16:023785

评论

发布
暂无评论
发现更多内容

一致性hash算法的实现

互金从业者X

架构师训练营-作业3

A Matt

一致性哈希算法与实现

俊俊哥

缓存 算法 一致性哈希

第五周感想

数字

架构师0期05周总结

我在终点等你

Python实现二叉树的各种遍历

王坤祥

Python 二叉树

一致性 hash 算法

Geek_zhangjian

技术选型能力反映了架构师的综合水平(第 5 周学习总结)

李德政

极客大学架构师训练营

架构师训练营 - 总结 5

进击的炮灰

【架构师训练营 - week5 -2】总结

早睡早起

架构师训练营 -W5-20200708-学习总结

丁亚宁

第五周作业

qqq

极客大学架构师训练营

第五周总结

qqq

第五周作业

数字

「架构师训练营」作业:第 5 周 一致性 hash 算法

Amy

极客大学架构师训练营 作业 一致性hash 一致性Hash算法 第五周

架构师训练营 - 第五周 - 作业

Anrika

极客大学架构师训练营

第05周 技术选型-01 命题作业

Jaye

架构师训练营第五周作业

张锐

架构师训练营第五周感悟

张锐

架构师训练营 -W5-20200708

丁亚宁

极客大学架构师训练营 一致性hash

一致性哈希算法JAVA版简单验证

L001

架构师0期05周作业

我在终点等你

第五周总结--一致性hash

互金从业者X

week5作业

架构师训练营第五周作业

zongbin

极客大学架构师训练营

架构师训练营-week5-学习总结

晓-Michelle

极客大学架构师训练营

《架构师训练营》第五周总结

【架构师训练营】第 5周作业

花生无翼

极客大学架构师训练营

本周总结

Geek_zhangjian

架构师训练营-week5

强哥

极客大学架构师训练营

Week5

进击中的云原生网关:APISIX 如何支持云原生应用_服务革新_褚杏娟_InfoQ精选文章