共计 5188 个字符，预计需要花费 13 分钟才能阅读完成。
你填了吗？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 微信公众号。
