你填了吗？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微信公众号。