本月Lyft宣布将Envoy交给CNCF托管

jopen 6年前
   <p style="text-align: center;"><a href="/misc/goto?guid=4959010988204242977" title="Lyft"><img alt="本月Lyft宣布将Envoy交给CNCF托管" src="https://simg.open-open.com/show/1930b4ad397bd0d7e975584e770d5055.png" /></a></p>    <p>在本月 Lyft 宣布将 Envoy 交给 CNCF 托管后,Envoy 的开发者 <a href="/misc/goto?guid=4959010988323390650">Matt Klein</a> 发表博客,简述了 Envoy 的发展历史以及开源 Envoy 背后的原因。本文最初发布于 <a href="/misc/goto?guid=4959010988434304338">Lyft 官方博客</a>,原文 <a href="/misc/goto?guid=4959010988538588555">Envoy joins the CNCF</a>,经原作者授权由 InfoQ 中文站翻译并分享。</p>    <p>我很高兴与大家分享一个消息,<a href="/misc/goto?guid=4959010988646842521">Envoy</a> 正式加入 Cloud Native Computing Foundation(<a href="/misc/goto?guid=4958999280931149382">CNCF</a>)——<a href="/misc/goto?guid=4959010988797455595">Kubernetes</a> 的家园——成为它的第十一个托管项目。Lyft 于 2016 年 9 月 14 日<a href="/misc/goto?guid=4959010988906244894">宣布</a>了 Envoy 项目,也就是差不多一年前。这是令人难以置信的一年! 在这篇文章中,我将简要叙述该项目的历史,以及我们是如何到达这个重大日子的。</p>    <p><strong>早期历史</strong></p>    <p>我在 2015 年 5 月加入了 Lyft。当时,Lyft 已经开始了从单体(monolith)到基于微服务架构的迁移过程,并部署了 30 多个服务。虽然 Lyft 已经体验到并行和解耦开发的许多优势,但新架构也带来了挑战。首先,Lyft 开发人员面临着这样的现实:网络本质上是不可靠的,当问题发生时,几乎无法确定问题的根源。物理网络?虚拟网络?硬件?应用程序?谁知道?在这一时期,Lyft 的开发人员不愿意将关键功能移出单体,因为他们认为我们基于微服务发展起来的基础设施不太稳定。要让 Lyft 意识到分布式架构的绝对优势,我们必须直接解决微服务网络和可观察性问题。</p>    <p>在 Lyft 之前,我有幸在亚马逊的 EC2 以及 推ter 的大规模分布式网络工作多年。我发现,不同的组织在解决分布式网络问题上存在很大差异。在 推ter,他们使用 Finagle 作为服务间通信的框架,我也看到了它的优势和不足。与此同时,我领导了一个基于 C++ 的新边缘代理开发项目,这个代理至今仍然在为 推ter 的流量提供服务。</p>    <p>我们不可小觑 Finagle 和 <a href="/misc/goto?guid=4958977502680516177">Netflix OSS</a> 套件这样的类库。它们提供了一组丰富的分布式系统网络功能,如服务发现、负载均衡、重试、超时、熔断器、协议转换、统计、日志、跟踪等。所有这些都旨在让网络对程序开发人员透明。然而,基于类库的部署方法在 推ter 上是有问题的,尽管将近 100% 的服务都运行在 JVM 上。由于服务提供者升级和部署缓慢,Finagle 的一次更新可能需要数月才能完成。</p>    <p>我们想复制并扩展 Finagle 的功能,将功能转移到自包含的进程中,这样更容易迭代和部署。Lyft 和许多其他公司一样,也有许多使用不同语言开发的服务,因此进程外代理方式变得尤为重要,这样可以避免在众多不同的类库中重复每个功能。另外,从我在 edge 服务系统方面的工作经验来看,性能——尤其是在最小化尾部延迟方差(tail latency variance)方面——对于分布式网络组件来说是至关重要的。</p>    <p>因此,在调研过现有的开源方案无法满足需求之后,才有了 Envoy。出于性能的考虑,我们选择 C++ 作为实现语言,并于 2015 年 5 月开始开发。初版于 2015 年 9 月初开发完成并部署。最初,Envoy 被用作 Lyft 的边缘代理。经过不断迭代,我们的团队加入了更多功能,并开始将 Envoy 作为我们的边车(sidecar)服务间代理。到 2016 年初夏,Envoy 在 Lyft 全面部署,并被用于所有边缘网络和服务间网络,形成了一个超过一百个服务和每秒传送数百万个请求的网格(mesh)。更为关键的是,Lyft 工程已经进入了一个新阶段:开发人员开始信任 Envoy 提供的网络抽象。关键的功能正在被逐步移出单体,而且他们没有对整个网络的稳定性和可观察性提出任何质疑。</p>    <p><strong>开源</strong></p>    <p>Lyft 的业务几乎完全基于开源技术。没有它,那些我们所知道的和喜爱的打车服务就不可能延续到今天。鉴于在 Envoy 上的大量开发投入,而且我们也了解到,许多其他组织在从单体到微服务架构迁移过程中,也面临着同样的挑战。我们希望能够回馈社区,因为社区促进了我们公司的发展。因此,我们决定开源 Envoy,并围绕它建立社区。</p>    <p>我将不会完整回顾在开源之后的几个月中发生的事情,因为我<a href="/misc/goto?guid=4959010989066244322">已经写过了</a>。我也不会花很多时间来详细讨论为什么我认为 Envoy 在过去一年中已经有了如此巨大的增长(以前的链接帖子有讨论这个,如我<a href="/misc/goto?guid=4959010989187564220">最近发表的关于通用数据面板 API 的帖子</a>)。</p>    <p>我想说的是,在过去一年里,我们对业界的反应感到十分惊讶。Envoy 的大客户数量在持续增长,基于 Envoy 构建的产品数量也在增长。在一年前,我们完全不敢想象 Envoy 会成为现代互联网的基础网络技术。然而,一年之后,这个项目正在向这个目标迈进。</p>    <p><strong>捐赠给 CNCF</strong></p>    <p>在 Envoy 社区难以置信地增长的同时,也面临着很多挑战。维护一个成功的 OSS 项目所带来的考验和困难需要我们投入越来越多的精力去克服,因为这是一个艰难且费力不讨好的工作。在过去 9 个月里,虽然 Google 是一个非凡的合作伙伴(我们现在有好几个 Google 维护者!),但我有时仍然会觉得这个项目受限于我,因时间有限,我无法专注于一些事情上,如市场推广、社区组织、文档、开发人员推广等。因此,我们开始考虑将 Envoy 捐献给基金会,基金会可以帮忙分担维护工作。此外,合适的基金会也将有助于推动 Envoy 与现有托管项目紧密协作。</p>    <p>在经过研究讨论及<a href="/misc/goto?guid=4959010989298965148">正式的申请程序</a>和投票之后,我们在 CNCF 找到了我们的家。Lyft 非常兴奋地提供了一项技术,在我们的大规模增长过程中,这个技术对基础设施的稳定性是至关重要的。我们希望 Envoy 能够帮助到其他组织。CNCF 组建了一个专家团队负责处理各种开源事务,在项目最佳实践方面提供帮助,此外还提供了现有的稳定技术,如 Kubernetes、Prometheus、OpenTracing、gRPC 和 Fluentd,这些技术与 Envoy 还有整个云原生开发社区是互补的。</p>    <p><strong>期待</strong></p>    <p>在撰写本文时,Envoy 有来自至少 10 个不同组织的 78 位贡献者,主要维护者在 Lyft 和 Google 工作。总体来说,这个项目一直表现非常好。Lyft 将 Envoy 捐献给 CNCF,既是回馈开源社区的一种方式,也是对事实的认可:基金会的资源将有助于解锁下一阶段的项目增长。作为一种技术,Envoy 有机会成为现代服务架构的主要构件块。所有在 Lyft 工作的人,以及所有在诸多不同组织中为 Envoy 工作的人,对与 CNCF 的合作将带来的美好未来都十分期待。</p>    <p>来自: <a href="/misc/goto?guid=4959010989410379334" id="link_source2">InfoQ</a></p>