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

   <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>