翻译 | 宋松
原文 | 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/）。
本文由博云研究院原创翻译发表，转载请注明出处。