手机版
你好,游客 登录 注册 搜索
背景:
阅读新闻

Envoy加入CNCF

[日期:2017-09-20] 来源:infoq.com  作者:mattklein123 ,译者 敖小剑 [字体: ]

在本月Lyft宣布将Envoy交给CNCF托管后,Envoy的开发者Matt Klein发表博客,简述了Envoy的发展历史以及开源Envoy背后的原因。

我很高兴与大家分享一个消息,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的合作将带来的美好未来都十分期待。

本文最初发布于Lyft官方博客,原文Envoy joins the CNCF,经原作者授权由InfoQ中文站翻译并分享。

本文永久更新链接地址http://www.linuxidc.com/Linux/2017-09/146995.htm

linux
相关资讯       CNCF  Envoy加入CNCF  Envoy 
本文评论   查看全部评论 (0)
表情: 表情 姓名: 字数

       

评论声明
  • 尊重网上道德,遵守中华人民共和国的各项有关法律法规
  • 承担一切因您的行为而直接或间接导致的民事或刑事法律责任
  • 本站管理人员有权保留或删除其管辖留言中的任意内容
  • 本站有权在网站内转载或引用您的评论
  • 参与本评论即表明您已经阅读并接受上述条款