Envoy Gateway会成为网关现有格局的冲击者吗？| 专访Envoy创始人

2022 年 5 月份，新项目 Envoy Gateway 正式开源。这是 Envoy 家族的一项新计划，背后汇集了一组基于 Envoy 的流行 Ingress 提供商，包括 VMware（由 Contour 维护者代表）、Tetrate（领先的 Istio 贡献者）和 Ambassador（Emissary 的维护者），共同构建 Kubernetes 网关 API 参考实现。Envoy Gateway 旨在通过开发一个统一的、规范的实现来修复基于 Envoy 的 Ingress 控制器的碎片化问题，该实现将托管在 Project Envoy 下。

Envoy Gateway 希望给 Envoy 生态带来什么变化？Envoy 上手难度高的问题有解吗？Envoy 未来更长远的目标是什么？带着这些问题，InfoQ 采访了 Envoy 创始人 Matt Klein，我们也围绕 Envoy 的核心设计理念和运作模式做了一些探讨。

Envoy 项目有一点不同于大部分开源项目，它没有常规意义上的发展路线图、完全由社区驱动，不属于任何单个商业实体，也不存在任何对应的商业版本。这一点吸引了大量寻求技术中立性的潜在用户，但同时也难免让人心生疑问，这会不会导致 Envoy 项目发展缺少强有力的引导或不够稳定？虽然据 Matt 介绍，Envoy 生态已经相当繁荣，但我们也看到，目前采用 Envoy 的主要还是大型企业，在打造网关的实践中选型 Envoy 的国内企业仍属于小众。

本文出自 InfoQ 特别策划的专题《Envoy 当道？云原生时代的下一代网关选型和实践》，希望能帮助你更好地理解 Envoy 和 Envoy Gateway。

从技术角度来看，Envoy 社区长久以来想做的就是开发一款工具，让它作为不同类型架构和系统的构建基础。在 Matt 看来，Envoy 的核心技术理念实际上是围绕可扩展性展开的。社区所做的一切都是为了让系统更具可扩展性，比如尽可能提供健壮且定义明确的 API、清晰的说明文档等。开源项目本身提供大量开箱即用的功能，同时也会保留扩展能力以支持部分用户满足他们的特定使用场景需求，即使大部分人可能用不上。这样一来，人们可以根据自己的需求，通过不同方式对 Envoy 做出扩展，很多扩展场景都超出了社区的意料，也让 Envoy 取得了超出预期的成功。

Envoy 的目标并不是打造一套最易用的解决方案，而是想为人们提供可以构成不同解决方案的构建单元，借此对接服务网格、边缘负载均衡、内部负载均衡等各类使用场景。

实际上，Envoy 从来不是一个很容易上手的软件。Matt 坦言，很多人会觉得 Envoy 很复杂、很难理解、配置太多，这些说法都没错，但他更认为，纵观整个行业，没有哪种无需配置的简单工具能够同时满足多种不同使用场景的需求。Envoy 的目标是帮助他人解决自己的问题，而不是让所有人都满意。

在 Matt 看来，Envoy 不可能适用于所有场景，也不可能适合每一位开发者。因此社区才会围绕 Envoy 建立起丰富的产品组合和初创项目生态系统，并把这一切都分层置于顶部。就如同瑞士军刀式工具，人们可以在它之上构建起更多不同解决方案。

新开源的 Envoy Gateway 项目，已经代表着社区的明确态度：大家正在想办法解决 Envoy 上手难的问题。但这个解法不是改变 Envoy，而是以 Envoy 为基础再做一些分层，用这种方式降低使用门槛，让人们能够轻松上手。

Envoy Gateway 项目的真正意义就在于，可以在 Envoy 之上构建起简化层，用以满足某些更简单的使用场景需求，比如降低在 API Gateway（又称“南北向网关”）场景使用 Envoy 的门槛。Envoy Gateway 为此提供了一个更简易的入门解决方案，能够让用户更快速、更轻松地用上 Envoy。在用户用上 Envoy Gateway 之后，可能就不需要其他东西了；但也有一种可能是未来用户的需求发生变化，而 Envoy Gateway 无法满足他们更进一步的需求，这时候用户可能需要更复杂的 Envoy 功能集，而整个 Envoy 项目生态系统都将能为他们所用，用户可以回过头去尝试使用原始的 Envoy、去使用更加强大的 XDS API。而这才是 Envoy 社区实现进一步推广项目、扩大受众这一目标的思路。

遵循着将 Envoy 打造成“构建单元”的核心理念，自 2016 年开源以来，Envoy 社区一直在不断产出新功能。刚开源时 Envoy 的核心功能，如今只是所有功能集中的一小部分。不过在 Matt 看来，Envoy 项目的关键里程碑主要体现在社区整体的发展成熟和项目的广泛延伸，而不会落在特定某项功能上。

如今 Envoy 已经七岁了，不再属于初创项目，甚至可以说已经“步入中年”，就像成熟产品一样，Envoy 项目的发展脚步也开始放慢。现在 Envoy 已经积累起太多用户，不能变得太快、不能颠覆得太快，否则大家会不高兴的。

对于 Envoy 未来的发展，Matt 表示很难明确定义出一份发展路线图（Roadmap），核心还是坚持为云原生架构提供构件单元。他倒是很想拿出一份神奇的功能清单，但确实没有。这一点也是 Envoy 区别于其他大部分开源项目的特殊之处。

Envoy 没有一套常规意义上的发展路线图，它是一个真正由社区驱动的开源项目，背后没有一家公司在推动、没有需要达成的产品目标，也没有产品经理和路线图的引导。Envoy 项目由所有参与者共同推动，唯一的目标就是让它能够满足最终用户——那些在 Envoy 之上构建产品的公司们的需求。Envoy 所实现的功能，一定是那些公司所关心的功能。

Envoy官网上展示的基于Envoy的开源项目和商业化产品

Envoy 社区完全开放，不存在对应的商业版本，所以用户不用担心部分高级功能会被锁死在商业版当中。同时，Envoy 不属于任何单个商业实体，虽然 Envoy 最初诞生于 Lyft，但 Lyft 并不直接靠 Envoy 赚钱，并将 Envoy 捐赠给了 CNCF。

早在 2017 年，也就是 Envoy 刚刚开源一年的时候，Matt 就发文公开表示，自己不会创办 Envoy 平台公司，并对原因做了非常详细的解释。其中比较核心的一点是，在 Matt 看来，与 Docker、Kubernetes、Mesos、NGINX 等类似，“服务网格”Envoy 不容易转化为 SaaS 产品。如果要提供即开即用的“服务网格”Envoy 解决方案，本质上相当于要提供完整的 PaaS 产品，包括编排和部署的支持，而这等同于直接与主要云提供商竞争。如果不提供完整的 PaaS 产品，那最终业务可能是围绕现有的 PaaS 解决方案提供服务和支持（打包、工具、可观测性等）。无论哪种方式，都不会是一条好走的路，并且这些业务模式也并非 Matt 兴趣所在。

事实上，Envoy 背后没有商业实体这一事实对许多潜在用户来说极具吸引力（尽管肯定不是全部），因为这让 Envoy 社区能做出不受企业利益影响的技术优先决策。

Envoy Gateway 项目的开源也是社区自发推动、顺理成章的结果。正如 Matt 在推特上分享的，“它的诞生并非自上而下的设计，而是自下而上的推动。”

由于 Envoy 的使用确实需要一定的技术积累，直到现在依然有不少用户在选择 Kubernetes Ingress 或者其他类型 Ingress 时，还会寻求其他技术。大家要么被迫寻找一家供应商来提供解决方案，要么就得投入大量时间精力深入学习 Envoy。正因为如此，市面上出现了一些相互竞争的 Ingress 解决方案。比如说 Emissary Ambassador，比如说 Contour，还有很多独立的 Ingress 选项。但 Matt 认为，这些项目的开发者之间其实达成了一种共识，就是只要能够以 Envoy 之名把 Ingress 解决方案统一起来，就能真正吸引到人们的支持和使用。

这更多是一个水到渠成的结果，只要能让更多人选择使用 Envoy，供应商自然就会加入进来，然后建立起更高层级的增值解决方案。于是社区积极出动，与不同供应商广泛讨论，大家逐渐意识到参与进来的好处，最终有了 Envoy Gateway 的诞生。

Envoy Gateway 开源后在国内也引起了很多开发者的关注，其中有一个问题是大家关注的焦点：为什么 Envoy Gateway 不首选 Istio 而是新建控制面？以后是否会支持 Istio 一键迁移？

对此，Matt 回应称目前相关讨论和工作还在进行当中，暂时无法给出明确的答案。他本人其实并不反对使用 Istio 作为控制平面，但 Istio 是一款非常复杂的软件，Istio 社区可能也在想办法做简化。“有一点是可以肯定的，我们没法让每个人都开心，有些人用过 Istio 后还想继续用，但有些人试过之后就再也不想碰了。总之，大家都会做尝试，看看到底是不是那个自己需要的正确答案。”

Envoy 自开源以来取得了惊人的成功，远超出 Matt 当初的想象，他之前从来没想过 Envoy 会像现在这么成功、这么普及。在最初决定开源 Envoy 的时候，Matt 的梦想其实很简单，就是能再吸引到一家愿意使用它的公司，只要这样就知足了，因为这意味着他创造出了其他人愿意实际使用的东西。如今，Matt 觉得自己当初的想法有些“好笑”：“问题已经不再是有没有人用 Envoy，而是还有谁不用 Envoy”。

不过 Matt 坦言，Envoy 的普及之路还很漫长。目前采用 Envoy 的主要还是大型企业，已经没多少大型企业能拒绝 Envoy 了，但 Envoy 在长尾分布的那条尾巴上还没什么动静。很多公司还在使用 Nginx proxy 之类的解决方案，但 Matt 认为这也正是 Envoy 的机遇所在。

虽然 Nginx proxy 等解决方案也都是很出色的软件，但 Matt 认为“它们在市场上的寿命只剩 10 到 15 年了。”Envoy 和 Nginx 的诞生相差了 10-15 年，在这期间，基础设施发生了非常多变化。Nginx 和 Nginx proxy 诞生时的基础设施更趋于静态，因此它长期保持一种更为传统的配置方式，即在磁盘上保存一个配置文件，在需要的时候重新加载。而 Envoy 从创建之初就考虑到在动态环境下灵活运行，其获取和配置的机制更能适应越来越动态化的现代基础设施。Matt 认为这是两者之间最大的区别。

在他看来，如今 Envoy 已经开始引导 Nginx 和 Nginx proxy 的发展方向了。虽然目前 Nginx 确实还有不少用户和实际使用案例，但未来它们肯定会被逐渐替代掉，当然还需要花一些时间。

此外，Matt 认为，随着时间推移，在未来 10 到 15 年里，人们会更多关注服务器列表和函数式平台。相比之下，无论是 Kubernetes 还是 Envoy，最终都会慢慢不再是大家关注的焦点，尤其对于普通开发者来说更是如此。

Matt 表示：“正常来讲，像 Envoy 和 Kubernetes 这样的项目在进入第十个年头之后，都会慢慢失去存在感。到时候人们应该更多转向函数式代码部署平台了。当然，我始终认为未来 Envoy 很有可能变得更加无处不在，但无处不在其实有两层含义，一是技术被广泛使用，另一层则是人们压根意识不到他们正在使用这个技术。（正是这种存在感的消失，让技术真正变得无处不在。）就像整个世界都运行在 Linux 之上，但大多数人都感受不到 Linux。我觉得未来 Kubernetes 和 Envoy 也会走上类似的道路。”

在这次对话中，我们能切实感受到 Matt 对于 Envoy 未来发展的信心十足。但对于如何选择网关方案，Matt 不止一次强调：他绝不会按头安利，宣扬什么每个人都应该选择 Envoy。

在他看来，每个人应该选择能满足需求的最简单的技术，只要原本的解决方案仍然可行，就没必要做任何改变。如果一家公司正在使用 Nginx 而且效果不错，那最好别做任何改变。除非他们遇到了某个特定的、Nginx 没办法解决的问题，比如可观测性问题、比如开源 Nginx 无法提供某些功能，那 Envoy 也许会是个不错的选项。首先还是要搞清楚自己需要解决的问题是什么。

“不妨先从单体式架构开始，从最简单的云服务开始，从 AWS Lambda 开始，从小处入手。随着项目的发展，情况会变得更复杂。总之，别追赶潮流，只追赶问题。核心只有一个：明确要解决什么问题，然后找到最简单的解决办法。”