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已经连续四年（2016、2017、2018、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/）。
本文由博云研究院原创翻译发表，转载请注明出处。