为何Linkerd不使用Envoy

你填了吗？2020年CNCF中国云原生问卷

问卷连接（https://www.wjx.cn/jq/9714648...）

---

做者：William Morgan

(Photo by Paul Felberbauer on Unsplash)

在这篇文章中，我将描述为何Linkerd不是创建在Envoy之上。

这是一篇写起来有点奇怪的文章。毕竟，Linkerd没有使用过上百万个项目，并且这些决策都不值得在博客上发表。可是Linkerd没有特别使用Envoy这一事实已经成为一个足够常见的讨论话题，所以它可能值得一个很好的解释。

我还要声明，这不是一篇“糟糕的Envoy”的博客文章。Envoy是一个伟大的项目，显然是许多人的选择，咱们对从事这项工做的优秀人士只有尊敬。咱们天天都向Linkerd用户推荐使用了Envoy的入口控制器，像Ambassador，而在世界各地的生产系统中，你能够发现Envoy和Linkerd并肩工做。

可是咱们没有选择在Envoy之上创建Linkerd。相反，咱们构建了一个专用的“微代理”，简称为Linkerd2-proxy，它是针对服务网格边车用例进行优化的。在日益拥挤的同类服务网格项目领域，Linkerd在这方面独树一帜。但咱们为何要走这条路呢？

对这个问题的完整回答本质上是细致入微的和技术性的--确切地说，就是那些在流行的、博客驱动的云原生应用世界中容易被淹没的内容。因此在这篇文章中，我将尽我最大的努力以一种坦率和专一于工程的方式来阐述缘由。毕竟，Linkerd是由工程师建立的，也是为工程师服务的，若是说有一件事让我感到骄傲的话，那就是咱们是在工程权衡的基础上作出决定的，而不是市场压力。

简而言之：Linkerd不使用Envoy，由于使用Envoy不容许咱们创建世界上最轻、最简单、最安全的Kubernetes服务网格。

做为最轻、最简单、最安全的Kubernetes服务网格是Linkerd对用户的承诺，这也使得Linkerd在服务网格中独一无二：它很是简单，更轻，更安全。而咱们可以作到这一点的缘由是--你猜对了--由于咱们创建在Linkerd2-proxy而不是Envoy的基础上。不是由于Envoy很差，而是由于Linkerd2-proxy更好--至少对于做为Kubernetes边车代理的很是具体和有限的用例来讲。

让咱们来看看缘由。

Linkerd2-proxy是什么？

在深刻讨论细节以前，有必要进一步了解一下Linkerd2-proxy。

Linkerd2-proxy是专门为服务网格边车用例设计的“微代理”。Linkerd2-proxy构建在大约2020年的世界上最现代的网络编程环境之上，并驱动了许多需求：Rust异步网络生态系统，包括像Tokio、Tower和Hyper这样的库。就纯粹的技术进步而言，Linkerd2-proxy是整个CNCF景观中最早进的技术之一。

像Envoy同样，Linkerd2-proxy是一个100%开源的Apache v2 CNCF项目，其特色是按期的第三方审计，一个活跃的社区，以及在世界各地的关键任务系统中的大规模生产使用。与Envoy不一样的是，Linkerd2-proxy仅设计用于一种用例：在从Linkerd控制平面接收配置的同时，将请求从一个Kubernetes pod代理到另外一个Kubernetes pod。与Envoy不一样的是，Linkerd2-proxy被设计成一个实现细节：它不是面向用户的，它不能做为一个通用的构建块使用，它有一个无聊的名字。这意味着Linkerd2-proxy每每会被忽视，尽管咱们最近在一些文章中对其进行了深刻研究，并在路线图中给出了一些解释。

那么，为何叫“微代理（micro-proxy）”呢？尽管咱们要在词典中引入另外一个术语，但“代理”这个词并不能彻底表明Linkerd2-proxy。代理相似于Envoy、NGINX、Apache或httproxy。这些项目能够作各类各样的事情（“将带有匹配此通配符的路径的HTTP请求发送到此后端，同时重写这些头文件、压缩任何Javascript文件和旋转访问日志”），而且它们有一个配置和调优表面来匹配。在生产环境中使用代理须要大量的操做投资：若是你正在运行Apache，那么你将在某个地方找到Apache专家。

可是Linkerd2-proxy是不一样的。它被设计成一个实现细节，不须要专门的知识或专门的操做投资（尽管Linkerd做为一个总体，固然，确实须要投资）。没有面向用户的YAML；相反，经过注入时设置的少许环境变量和运行时由Linkerd控制平面自动配置Linkerd2-proxy。咱们将Linkerd2-proxy的调优范围保持在最低限度，以便最终用户不多须要直接接触它。简而言之：Linkerd2-proxy被设计成隐藏在幕后，做为一个实现细节，而且仅仅工做。

简而言之：Linkerd2-proxy与Envoy、NGINX和Apache等代理有很大的不一样，“proxy”这个词并不能很好地表明它。

复杂性

那么为何咱们要创建Linkerd2-proxy而不是Envoy呢？一个主要缘由是复杂性。

Envoy是一种灵活的、通用的代理，这也是它受欢迎的主要缘由。你可使用Envoy做为一个入口，做为一个出口，做为一个服务网格边车，以及在许多其余方式。可是这种灵活性带来了复杂性。

做为一个比较，截至2020年11月，Envoy仓库的C++代码为172 KLOC，“复杂性得分”（以分支和循环衡量）为19k。相比之下，Linkerd2-proxy只有30 KLOC，复杂度得分为1.5k。换句话说：Linkerd2-proxy代码基比Envoy小5倍，经过这种方法，它的复杂性比Envoy小10倍

固然，这不是一个苹果对苹果的计算。它不捕获仓库以外的库或依赖项；复杂性分数不能在语言之间严格地移植；等等。但它可让你大体了解这些项目的相对规模：就内部而言，Linkerd2-proxy比Envoy要小几个数量级，也要简单几个数量级。

这种复杂性是Envoy的失败吗？不。Envoy有不少复杂的代码由于它能够作不少复杂的事情。可是，这种复杂性是构建专一于简单性（尤为是操做简单性）的项目的很是困难的基础。

简而言之：Envoy是瑞士军刀。Linkerd2-proxy是一根针。

资源消耗

对于任何基于边车的服务网格，有一点是清楚的：你将会有不少代理。

这意味着数据平面消耗的CPU和内存是运行服务网格成本的关键组成部分，尤为是在应用程序扩展时。

使用Linkerd2-proxy容许咱们严格控制Linkerd的资源消耗。例如，在咱们使用Kinvolk的开源基准测试工具对Linkerd和Istio进行的内部基准测试中，以每秒4000个请求的接入流量，咱们看到Linkerd2-proxy实例的内存始终在14mb到15mb之间，而Istio的Envoy的内存在135mb到175mb之间，是这个大小的10倍。相似地，Linkerd2-proxy在测试运行中的CPU使用始终为每一个实例15ms （CPU毫秒），而Istio的Envoy在22ms到156ms之间--多50%到多10倍。

一样，这不是一个彻底公平的比较。这些是针对特定应用程序和特定配置的内部基准测试，毫无疑问，Istio的一些设计决策在这里扮演了重要角色。但Istio是由世界一流的工程师建造的，关键是：若是Linkerd是在Envoy上建造的，咱们将不得不本身作出许多一样的设计决定。

简而言之：在实践中，在服务网格上下文中，Linkerd2-proxy使用的系统资源只是Envoy所使用的系统资源的一部分。

安全

最后一点也许是最富哲理的一点：安全。数据平面的安全性对于任何服务网络都是一个巨大的问题。例如，Linkerd在世界各地的生产中被用于处理异常敏感的数据，从健康信息到我的可识别的细节再到金融交易。

咱们没有理由认为Envoy是不安全的。可是从某种程度上说，它是安全的（特别是在C++代码的170+ KLOC的状况下），它是安全的，它是经过让许多很是聪明的工程师使用它、检查它、归档CVEs、修复bug和重复的手工和昂贵的过程来实现的。这是软件安全的“传统过程”，并且至少在适当的时候是有效的。它也很昂贵、困难并且容易失败。C++代码的安全性是出了名的难，即便对最有经验的程序员也是如此。

更重要的是，这不是咱们但愿Linkerd所依赖的安全模型，也不是咱们所相信的系统编程安全的将来。咱们选择Rust做为Linkerd2-proxy是有意为之的：Rust的内存安全性使咱们能够放心地在Linkerd2-proxy中编写安全代码，从而将咱们对人类发现问题的依赖最小化。固然，这并非说Linkerd2-proxy不存在安全漏洞！相反，它将拥有更少的；咱们须要少依赖本身卑微的才能来避免它们；咱们将再也不常常要求咱们的用户对他们的系统进行关键升级，以保持安全。

简而言之：Linkerd2-proxy的Rust基础让咱们对Linkerd的数据平面的安全性有了信心。

Linkerd可使用Envoy吗？

简单性、资源消耗和安全性是咱们决定不采用Envoy的驱动因素。然而，咱们相信代理的选择最终是一个实现细节。虽然咱们在Linkerd2-proxy上投入了大量的资金，但咱们也会按期从新评估Envoy。我能够明确地说，若是对咱们的用户来讲，这个折衷方案对Envoy有利，咱们将毫无疑问地采用它。

不过，咱们对将来的服务网络采纳者的建议很简单：忽略这些噪音。你的工做不是“使用服务网络”或“采用Envoy”，甚至“只使用CNCF技术”。你的工做是清楚地了解你要解决的问题，而后选择最能解决它的解决方案。不管你选择什么，你都将不得不接受它--因此确保你的决策是基于具体的需求和充分理解的工程权衡，而不是基于时尚或趋势。

常见问题解答

那么为何这么多的服务网格使用Envoy？

由于编写本身的现代、可伸缩、高性能网络（微）代理很是困难。真的很难。在过去的几年里，构建Linkerd2-proxy和Rust网络库使之成为多是许多人付出的巨大努力。除非你的项目既具有技术实力，又有解决这一挑战的愿望，不然使用Envoy要容易得多。

可是Envoy不是服务网格的“标准”吗？

不是。一个标准是互操做性所必需的东西。对服务网格相当重要的标准是TCP或HTTP，或者像SMI这样容许在服务网格之上构建工具的标准。（例如，这是Argo经过SMI为canary发布驱动Linkerd的绝佳例子。）

Envoy做为服务网格数据平面代理的广泛选择并非一个标准，而是一个简单的共性。Envoy成为一个“服务网格标准”意味着什么？咱们能够把数据平面保留在原来的位置，而后换掉控制平面？咱们能够用不一样的控制平面操做同一个数据平面？这些都是牵强附会的用例。

但若是咱们要求使用Envoy呢？

我认为这不是一个真正的要求。你的工做不是采用某一特定的技术。你的工做是解决问题。

若是你的问题是“咱们须要创建一个可靠的、安全的、可观察的Kubernetes平台，而不须要付出疯狂的复杂性成本”，那么我强烈建议你考虑看看Linkerd。

如今谁在生产中使用Linkerd2-proxy？

每一个使用Linkerd的人都使用Linkerd2-proxy。这意味着你能够找到Linkerd2-proxy为Nordstrom、微软、H-E-B、Chase、Clover Health、HP等公司的关键生产架构提供支持。

其余的服务网格项目可使用Linkerd2-proxy吗？

不太可以。可是任何对构建高性能超轻网络代理感兴趣的人均可以使用支持Linkerd的底层Rust网络库。

听起来使人惊叹！我如何开始使用Linkerd？

我没想到你会问。你能够在大约5分钟内安装Linkerd，包括相互TLS，不须要配置。从咱们的入门指南开始。

Linkerd适用于全部人

Linkerd是一个社区项目，由CNCF托管。若是你有功能需求、问题或评论，咱们欢迎你加入咱们快速增加的社区！Linkerd托管在GitHub上，咱们在Slack、Twitter和邮件列表上都有一个蓬勃发展的社区。来一块儿玩吧！

点击阅读网站原文。

---

CNCF (Cloud Native Computing Foundation)成立于2015年12月，隶属于Linux  Foundation，是非营利性组织。
CNCF（云原生计算基金会）致力于培育和维护一个厂商中立的开源生态系统，来推广云原生技术。咱们经过将最前沿的模式民主化，让这些创新为大众所用。扫描二维码关注CNCF微信公众号。