Linkerd or Istio？哪一个Service Mesh框架更适合你？

翻译 | 宋松
原文 | https://medium.com/solo-io/li...

本周我开始写一篇比较Istio和Linked的帖子，而且告诉我本身：我将用一个表格来比较二者的特性，这将会很棒，人们会爱上它，这个世界将会幸福几秒钟。我向本身承诺这将是一个公平的比较，没有任何偏见。虽然比较的表格仍然存在，但我转移了文章的终点：目标再也不是哪一个更好，而是哪一个更适合你、你的应用程序和你的组织。

在职业生涯的一段时间中，我曾担任某公司的售前架构师，记得有不少次咱们被要求填写产品比较表。我常常须要运用创造力来确保产品看起来很好，几乎不惜一切代价避免表格中使人不愉快的“不支持”的框。考虑到诚信工做，可是有时候不得不这样作。

站在评价者的角度来看，我理解他们（但愿）的目的是进行公平的比较，在这种程度上，对比的表格彷佛是一种可靠的方式。咱们知道一个项目的成功能够预测职业的发展，咱们都喜欢这一点。但问题是：若是评估的最终目标是产品对比表格，而不是能让企业更有竞争力的高质量软件，那么这个评估的最后将只是一些“表格”的工做。

产品比较并非最终目的，经过比较知道哪些对你的用例最好才是最终目的。所以让咱们经过七个方面来深刻研究Service Mesh，主要是如下几个方面：

• 流量管理
• 安全
• 安装/配置
• 支持的环境
• 监测
• 策略管理
• 性能

对于上述七个方面中的每个，我都将发表我的观点，但愿个人观点可以帮你作出更接近于简洁的决策。

流量管理

须要强调的是，Istio和Linkerd的区别在于数据平面使用了两种不一样的代理技术。

Istio使用Envoy做为其代理。Envoy是C++编写的，最初是由Lyft构建，以便以非Kubernetes方式促进微服务的流量管理。许多公司已经将Envoy扩展为Kubernetes的ingress技术。

Linkerd（v2）使用的是一种名为Linkerd-proxy的专用服务网格代理。这个代理是使用Rust编写的，与该代理一块儿，许多低级代理（网络客户机与服务器）功能在另外一个也是由rust编写名为Tower的项目中实现。Tower依赖于Tokio，Tokio是一个由Rust编写的事件驱动非阻塞I/O库。若是你和我同样欣赏统计学，那么Rust已经连续四年（201六、201七、201八、2019）一直是Stack-overflow最受欢迎的语言。

Istio是构建与Envoy之上的所以在流量管理方面它是占据优点的，Envoy已经包含了重要的IMHO功能，好比子集路由。用户仍然可使用Linkerd实现金丝雀/蓝绿/a-b发布，但必须依靠单独的Kubernetes服务和可以分发流量的集群ingress技术，好比Gloo（gloo.solo.io）。

Linkerd团队在最近一次社区会议上公开表示，计划在将来的版本中实现更加高级的L7流量管理功能。

安全

关于安全，我正在考虑保护通讯通道的能力。Istio和Linkerd二者都提供了合理的安全保护功能。

Istio和Linkerd都依赖于外部根证书，所以二者都能保证进行安全通讯。这听起来像是一个很好的周末项目，你以为呢？

安装和配置

鉴于Istio能够安装在许多不一样的平台上，安装说明可能会存在很大的不一样。在写这篇文章的时候，关于Linkerd的安装，我对一些预先须要安装功能的检查印象很深入。有不少次我在共享的Kubernetes集群中安装一些Linkerd功能时，我不清楚我是否拥有必要的权限。对于Linkerd，pre-check（或check-pre）检查你是否拥有在安装过程当中建立Kubernetes所需资源的权限。

环境支持和部署模型

对因而选择kubernetes或者是非Kubernetes安装，这是一个很直接的问题，Linkerd2是用基于kubernetes方式构建的，至少目前是这样的，而Istio收到了一下其余的公司的贡献，但愿istio能在非kubernetes环境中运行。

考虑多集群部署，客观来讲对于它的解释可能很棘手。从技术上来说，共享根CA证书的多个不一样集群（具备不一样的控制平面）上的服务之间能够有效的通讯。

Istio扩展了上述概念，由于它支持不一样情形下的多个集群：

• 单个控制平面便可知足不一样集群之间网络链接和pod之间IP寻址。
• 经过使用具备单个控制平面的集群边界网关（egress和ingress）便可访问多个集群上的kubernetes API服务器。

在上述两种状况下，包含控制平面的集群将成为mesh管理的SPOF（single point of failure）。在咱们这个能够在同一区域下的多个可用区域上部署单个集群的世界中，这将再也不是一个问题，但仍然不能彻底忽略它。

监测

能够说Istio的管理控制台是一个缺失的部分。 Kiali Observability Console确实解决了一些管理员对service mesh所需的一些需求。

Kiali（κιάλι）是一个希腊词，意思是望远镜，从Kiali的网站上能够清楚的看到它打算成为一个可监测性的控制台，而不只仅是一个Service Mesh管理控制台。

Linkerd控制台还不完整，可是社区决定也要构建一个管理仪表盘的目标是一个优点。

Linkerd未能提供请求追踪。想要以非侵入方式查看请求追踪跨度必须等待Linkerd实现该功能。Istio利用了Envoy支持添加追踪headers的事实。

应该提醒用户，应用程序须要准备好转发跟踪headers，若是没有准备，代理能够生成新的跟踪IDS，这可能会无心中将单个请求分割为多个请求跨度使请求之间失去必要的关联性。大多数开发框架都有转发headers的选项，而无需用户编写大量的代码。

策略管理

Istio的爱好者，请欢欣鼓舞！Istio的策略管理能力使人印象深入。

该项目构建了一个可扩展的策略管理机制，容许其余技术可从多个方面与Istio集成，请参阅下面的“template”列表以及一些集成的提供者。你能够认为“template”是一种集成。

为了突出其余策略类型，Istio也可适用于rating和limiting以及提供对主体身份验证的开箱即用支持。Linkerd用户依赖集群ingress控制器提供rating和limiting。

对于主体身份验证，我一直认为它应该委托给应用程序。请记住#4分布式计算的谬论：网络是安全的。对此持零信任策略。

Istio使人印象深入的策略管理能力是须要代价的。考虑到他的普遍性，管理众多的选项增长了本已昂贵的运营成本。

Istio（Mixer）的策略管理组件也增长了显著的性能，咱们将在下面详细讨论。

性能

对比表在哪里？幸运的是，就在最近，发布了两个很棒的博客，对Istio和Linkerd的性能进行了比较，我在下面引用了其中一些结论：

对于这种综合工做负载，Istio的Envoy代理使用比Linkerd多50%的CPU。Linkerd的控制平面使用了一小部分Istio，特别是在考虑“core”组件时。

——Michael Kipper — Benchmarking Istio & Linkerd CPU（https://medium.com/@ihcsim/li...）

And…

在本实验中，与基线设置相比，Linkerd2-meshed设置和Istio-meshed设置都经历了更高的延迟和更低的吞吐量。在Istio-meshed设置中产生的延迟高于在Linkerd2-meshed设置中观察到的延迟。Linkerd2-Meshed设置可以处理比Istio-Meshed设置更高的HTTP和GRPC ping吞吐量。

——Ivan Sim — Linkerd 2.0 and Istio Performance Benchmark（https://medium.com/@ihcsim/li...）

意识到Mixer所增长的处理时间，Istio团队目前正致力于重写Mixer组件：“Mixer将用c++从新并直接嵌入到Envoy中。将再也不有任何独立的Mixer服务。这将提升性能并下降运营复杂性。”

—Source Mixer V2 Design Document（https://docs.google.com/docum...）

总结

是的，Istio比Linkerd2.3有多的特性。这是很好的，更多的特性意味着处理更复杂和边缘用例的能力加强。这没什么神奇的，更多的特性一般意味着更多的配置，潜在的资源利用率和运营成本的增长，全部这里有三条建议：

• 若是你不知道80%最多见的工做负载是什么样子的，那么你将很难选择服务网格。若是你不知道这些数字，你的企业可能尚未准备好进行服务网格的使用。若是你只是在探索，那就另当别论了。
• 若是你想计划解决全部可能的当前和将来的cases（一般叫作comparison spreadsheet），那么你将会有一段糟糕的时间。你极可能会过分获取，这对你购买的任何软件都是如此。
• 盲目的选择一种技术或另外一种会让你过的很糟糕。炒做可能很厉害，但请记住，你并非在炒做业务（除非真的在炒做）。

试试Istio和Linkerd！ Solo SuperGloo是最简单的方式。

我使用SuperGloo是由于它很是简单，能够快速启动两个服务网格，而我几乎不须要作任何努力。咱们并无在生产中使用它，可是它很是适合这样的任务。每一个网格其实是两个命令。

——Michael Kipper — Benchmarking Istio & Linkerd CPU — Shopify（https://medium.com/@michael_8...）。

在Solo.io（https://www.solo.io/），咱们但愿为你的服务网格采用之旅提供便利。 Solo SuperGloo咱们的服务Mesh orchestrator能够经过直观简单的命令安装和管理流行的服务网格技术。 正如Michael上面所指出的那样，安装Istio或Linkerd会成为一个单行活动。 SuperGloo并不止于此，它在不一样的服务网格技术之上提供了一个抽象，容许对多个网格进行一致且可重复的操做。 SuperGloo是彻底开源的，you can try it right now（https://supergloo.solo.io/）。

本文由博云研究院原创翻译发表，转载请注明出处。