Envoy 加入 CNCF

在本月 Lyft 宣布将 Envoy 交给 CNCF 托管后，Envoy 的开发者 Matt Klein 发表博客，简述了 Envoy 的发展历史以及开源 Envoy 背后的原因。本文最初发布于 Lyft 官方博客，原文 Envoy joins the CNCF ，经原作者授权由 InfoQ 中文站翻译并分享。

我很高兴与大家分享一个消息， Envoy 正式加入 Cloud Native Computing Foundation（ CNCF ）—— Kubernetes 的家园——成为它的第十一个托管项目。Lyft 于 2016 年 9 月 14 日宣布了Envoy 项目，也就是差不多一年前。这是令人难以置信的一年！ 在这篇文章中，我将简要叙述该项目的历史，以及我们是如何到达这个重大日子的。

早期历史

我在2015 年5 月加入了Lyft。当时，Lyft 已经开始了从单体（monolith）到基于微服务架构的迁移过程，并部署了30 多个服务。虽然Lyft 已经体验到并行和解耦开发的许多优势，但新架构也带来了挑战。首先，Lyft 开发人员面临着这样的现实：网络本质上是不可靠的，当问题发生时，几乎无法确定问题的根源。物理网络？虚拟网络？硬件？应用程序？谁知道？在这一时期，Lyft 的开发人员不愿意将关键功能移出单体，因为他们认为我们基于微服务发展起来的基础设施不太稳定。要让Lyft 意识到分布式架构的绝对优势，我们必须直接解决微服务网络和可观察性问题。

在Lyft 之前，我有幸在亚马逊的EC2 以及Twitter 的大规模分布式网络工作多年。我发现，不同的组织在解决分布式网络问题上存在很大差异。在Twitter，他们使用Finagle 作为服务间通信的框架，我也看到了它的优势和不足。与此同时，我领导了一个基于C++ 的新边缘代理开发项目，这个代理至今仍然在为Twitter 的流量提供服务。

我们不可小觑Finagle 和 Netflix OSS 套件这样的类库。它们提供了一组丰富的分布式系统网络功能，如服务发现、负载均衡、重试、超时、熔断器、协议转换、统计、日志、跟踪等。所有这些都旨在让网络对程序开发人员透明。然而，基于类库的部署方法在 Twitter 上是有问题的，尽管将近 100％的服务都运行在 JVM 上。由于服务提供者升级和部署缓慢，Finagle 的一次更新可能需要数月才能完成。

我们想复制并扩展 Finagle 的功能，将功能转移到自包含的进程中，这样更容易迭代和部署。Lyft 和许多其他公司一样，也有许多使用不同语言开发的服务，因此进程外代理方式变得尤为重要，这样可以避免在众多不同的类库中重复每个功能。另外，从我在 edge 服务系统方面的工作经验来看，性能——尤其是在最小化尾部延迟方差（tail latency variance）方面——对于分布式网络组件来说是至关重要的。

因此，在调研过现有的开源方案无法满足需求之后，才有了 Envoy。出于性能的考虑，我们选择 C++ 作为实现语言，并于 2015 年 5 月开始开发。初版于 2015 年 9 月初开发完成并部署。最初，Envoy 被用作 Lyft 的边缘代理。经过不断迭代，我们的团队加入了更多功能，并开始将 Envoy 作为我们的边车（sidecar）服务间代理。到 2016 年初夏，Envoy 在 Lyft 全面部署，并被用于所有边缘网络和服务间网络，形成了一个超过一百个服务和每秒传送数百万个请求的网格（mesh）。更为关键的是，Lyft 工程已经进入了一个新阶段：开发人员开始信任 Envoy 提供的网络抽象。关键的功能正在被逐步移出单体，而且他们没有对整个网络的稳定性和可观察性提出任何质疑。

开源

Lyft 的业务几乎完全基于开源技术。没有它，那些我们所知道的和喜爱的打车服务就不可能延续到今天。鉴于在 Envoy 上的大量开发投入，而且我们也了解到，许多其他组织在从单体到微服务架构迁移过程中，也面临着同样的挑战。我们希望能够回馈社区，因为社区促进了我们公司的发展。因此，我们决定开源 Envoy，并围绕它建立社区。

我将不会完整回顾在开源之后的几个月中发生的事情，因为我已经写过了。我也不会花很多时间来详细讨论为什么我认为Envoy 在过去一年中已经有了如此巨大的增长（以前的链接帖子有讨论这个，如我最近发表的关于通用数据面板API 的帖子）。

我想说的是，在过去一年里，我们对业界的反应感到十分惊讶。Envoy 的大客户数量在持续增长，基于Envoy 构建的产品数量也在增长。在一年前，我们完全不敢想象Envoy 会成为现代互联网的基础网络技术。然而，一年之后，这个项目正在向这个目标迈进。

捐赠给CNCF

在Envoy 社区难以置信地增长的同时，也面临着很多挑战。维护一个成功的OSS 项目所带来的考验和困难需要我们投入越来越多的精力去克服，因为这是一个艰难且费力不讨好的工作。在过去9 个月里，虽然Google 是一个非凡的合作伙伴（我们现在有好几个Google 维护者！），但我有时仍然会觉得这个项目受限于我，因时间有限，我无法专注于一些事情上，如市场推广、社区组织、文档、开发人员推广等。因此，我们开始考虑将Envoy 捐献给基金会，基金会可以帮忙分担维护工作。此外，合适的基金会也将有助于推动Envoy 与现有托管项目紧密协作。

在经过研究讨论及正式的申请程序和投票之后，我们在CNCF 找到了我们的家。Lyft 非常兴奋地提供了一项技术，在我们的大规模增长过程中，这个技术对基础设施的稳定性是至关重要的。我们希望Envoy 能够帮助到其他组织。CNCF 组建了一个专家团队负责处理各种开源事务，在项目最佳实践方面提供帮助，此外还提供了现有的稳定技术，如Kubernetes、Prometheus、OpenTracing、gRPC 和Fluentd，这些技术与Envoy 还有整个云原生开发社区是互补的。

期待

在撰写本文时，Envoy 有来自至少10 个不同组织的78 位贡献者，主要维护者在Lyft 和Google 工作。总体来说，这个项目一直表现非常好。Lyft 将Envoy 捐献给CNCF，既是回馈开源社区的一种方式，也是对事实的认可：基金会的资源将有助于解锁下一阶段的项目增长。作为一种技术，Envoy 有机会成为现代服务架构的主要构件块。所有在Lyft 工作的人，以及所有在诸多不同组织中为Envoy 工作的人，对与CNCF 的合作将带来的美好未来都十分期待。

感谢薛命灯对本文的审校。

给InfoQ 中文站投稿或者参与内容翻译工作，请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博（ @InfoQ ， @丁晓昀），微信（微信号： InfoQChina ）关注我们。