原副标题:Envoy Gateway会正式成为交换机原有新格局的压制者吗?| 访谈Envoy创办人
作者 | 蔡芳芳
专访 | 王一鹏、蔡芳芳
新开放源码的 Envoy Gateway 工程项目,能让 Envoy 变得更平易近人吗?
2022 年 5 月份,新工程项目 Envoy Gateway 正式开放源码。这是 Envoy 家族的一项新计划,背后汇聚了几组如前所述 Envoy 的流行 Ingress 服务商,包括 VMware(由 Contour COBOL代表)、Tetrate(领跑的 Istio COBOL)和 Ambassador(Emissary 的COBOL),共同构筑 Kubernetes 交换机 API 参照与此同时实现。Envoy Gateway 意在通过合作开发一个统一的、规范的与此同时实现来复原如前所述 Envoy 的 Ingress 驱动力器的碎片化难题,该与此同时实现将代销在 Project Envoy 下。
Envoy Gateway 期望给 Envoy 自然生态带来甚么变化?Envoy 上手技术难度高的难题求函数吗?Envoy 未来更长远规划的最终目标是甚么?带着这些难题,InfoQ 专访了 Envoy 创办人 Matt Klein,我们也紧紧围绕 Envoy 的核心设计经营理念和运转模式做了一些深入探讨。
Envoy 工程项目有一点有别于大部分开放源码工程项目,它没有常规性意义上的产业发展蓝图、完全由街道社区驱动力,不属于任何人一般而言商业性实体,也不存在任何人对应的商业性版。这一点吸引了大批谋求控制技术隐私权的客户群,但与此同时也不免让民心生疑点,这会不会导致 Envoy 工程项目产业发展缺乏有力的引导或不够稳定?虽然据 Matt 介绍,Envoy 自然生态已经相当繁荣,但我们也看到,目前采用 Envoy 的主要还是大型民营企业,在打造出交换机的实践中THF1 Envoy 的国内民营企业仍属于小众。
责任编辑出自于 InfoQ 特别策画的专题讲座 《Envoy 虽是?云原生植物时代的新一代交换机THF1和实践》,期望能帮助你更好地理解 Envoy 和 Envoy Gateway。
1Envoy 的最终目标不是打造出最功能强大的软件系统
从控制技术角度来看,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 街道社区与此同时实现进一步推广工程项目、扩大受众这一最终目标的思路。
2完全由街道社区驱动力、没有明确的 Roadmap
遵循着将 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 后还想继续用,但有些人试过之后就再也不想碰了。总之,大家都会做尝试,看看到底是不是那个自己需要的正确答案。”
3Envoy 的未来:像 Linux 一样无处不在
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 已经开始引导 Nginx 和 Nginx proxy 的产业发展方向了。虽然目前 Nginx 确实还有不少用户和实际使用案例,但未来它们肯定会被逐渐替代掉,当然还需要花一些时间。
此外,Matt 认为,随着时间推移,在未来 10 到 15 年里,人们会更多关注服务器列表和函数式平台。相比之下,无论是 Kubernetes 还是 Envoy,最终都会慢慢不再是大家关注的焦点,尤其对于普通合作开发者来说更是如此。
Matt 表示:“正常来讲,像 Envoy 和 Kubernetes 这样的工程项目在进入第十个年头之后,都会慢慢失去存在感。到时候人们应该更多转向函数式代码部署平台了。当然,我始终认为未来 Envoy 很有可能变得更加无处不在,但无处不在其实有两层含义,一是控制技术被广泛使用,另一层则是人们压根意识不到他们正在使用这个控制技术。(正是这种存在感的消失,让控制技术真正变得无处不在。)就像整个世界都运行在 Linux 之上,但大多数人都感受不到 Linux。我觉得未来 Kubernetes 和 Envoy 也会走上类似的道路。”
4写在最后
在这次对话中,我们能切实感受到 Matt 对于 Envoy 未来产业发展的信心十足。但对于如何选择交换机方案,Matt 不止一次强调:他绝不会按头安利,宣扬甚么每个人都应该选择 Envoy。
在他看来,每个人应该选择能满足需求的最简单的控制技术,只要原本的软件系统仍然可行,就没必要做任何人改变。如果一家公司正在使用 Nginx 而且效果不错,那最好别做任何人改变。除非他们遇到了某个特定的、Nginx 没办法解决的难题,比如可观测性难题、比如开放源码 Nginx 无法提供更多某些功能,那 Envoy 也许会是个不错的选项。首先还是要搞清楚自己需要解决的难题是甚么。
“不妨先从单体式构架开始,从最简单的云服务开始,从 AWS Lambda 开始,从小处入手。随着工程项目的产业发展,情况会变得更复杂。总之,别追赶潮流,只追赶难题。核心只有一个:明确要解决甚么难题,然后找到最简单的解决办法。”
每天中午都是一次“秒杀”,从 IT 视角看麦当劳中国数字化
对话iPod之父:这不是互联网最坏的年代
“羊了个羊”背后公司清仓式分红10亿元;Meta元宇宙部门今年已亏94亿美元;微软称GitHub年收入10亿美元|Q资讯
全面审查Twitter代码、当场炒掉CEO等众多高管:马斯克正式入主Twitter
活动预告
数据库的兼容性与极致性能是如何打造出的?
如何利用数据库自然生态,打造出符合自身业务的构架?