所有垂直行业的组织都在继续加速采用微服务。这导致容器和客户/服务通信的使用量相应爆炸式增长。事实证明，安全，大规模和可观察地管理这些通信非常具有挑战性。这在企业内部造成了越来越多的复杂性和波动性。因此，运营商和开发人员都强烈希望封装网络的复杂性并将其推入新的网络基础设施层。目前，处理这些复杂问题的最流行的方法是服务网格。
因此，对于这篇博文，我们将比较和对比两个流行服务网格Linkerd和Istio的功能集。我们还将探讨使用服务网格的参数，以及根据您的用例或体系结构，其他类型的解决方案可能更有意义的场景。
什么是服务网格？
服务网格是一个专用的基础设施层，可在微服务架构内进行服务到服务调用，可靠，快速和安全。它是可以插入服务的代理网格，完全从业务服务中抽象出网络。简而言之，服务网格旨在解决开发人员在与远程端点通信时面临的诸多挑战。
什么是Istio？
Istio是一个开源服务网格，最初由谷歌，IBM和Lyft开发。该项目于2017年5月公布，其1.0版本于2018年7月发布.Istio建立在作为其数据平面的Envoy代理之上。尽管它显然是目前最流行的服务网格，但它仅用于所有实用目的，仅适用于Kubernetes。
什么是Linkerd？
Linkerd最初是用Scala编写的，旨在基于每个主机进行部署。对其相对较大的内存占用的批评随后促成了Conduit的开发，这是一种专门针对Kubernetes的轻量级服务网，用Rust和Go编写。此后，Conduit项目已被折叠成Linkerd，后者重新推出了Linkerd 2.0。虽然Linkerd 2.x目前特定于Kubernetes，但Linkerd 1.x可以基于每个节点进行部署，因此在需要支持各种环境的情况下使其成为更灵活的选择。除非另有说明，否则下面的比较是指Linkerd 2.x.
比较特征和功能
1. 架构
Istio和Linkerd都支持通过流行的边车模式进行部署，该模式为每个微服务分配一个单独的代理。微服务不是直接调用其他服务，而是连接到本地代理。然后，此代理将调用路由到相应的服务实例的代理，该代理又将调用传递给其本地微服务。这个服务代理网格形成数据平面。在服务网格中，数据平面由控制平面配置和监视，控制平面通常单独部署。
2.控制平面
控制平面是一组API和工具，用于控制网格中的代理行为。控制平面是用户指定身份验证策略，收集度量标准和配置数据平面的整体。
Istio的控制平面由三个部分组成。首先，Pilot负责配置数据平面。接下来，Mixer收集流量指标并响应来自数据平面的各种查询，例如授权，访问控制和配额检查。根据启用的适配器，它还可以与日志记录和监视系统连接。最后，Citadel允许开发人员基于服务标识而不是网络控制来构建零信任环境。它负责为每个服务分配证书，并且还可以在需要时接受外部证书颁发机构密钥。
Linkerd的控制平面由一个控制器组件，一个提供管理仪表板的Web组件和一个度量组件组成，该组件由Prometheus和Grafana的修改版本组成。
3. 数据平面
在典型的服务网格中，服务部署被修改为包括专用的边车代理。服务不是直接通过网络呼叫服务，而是调用其本地边车代理，这反过来又封装了服务到服务交换的复杂性。服务网格中的互连代理集代表其数据平面。
默认情况下，Istio使用Envoy作为其数据平面，即使它被设计为与其他代理（如Nginx）一起使用。Linkerd提供自己的代理。
4. 平台支持
虽然Istio 声称支持各种环境和框架，但在实践中，它仅在Kubernetes上得到很好的支持，使其成为较窄的服务网格选项之一。
同样，Linkerd 2.x目前也需要Kubernetes。但是，Linkerd 1.x仍然广泛部署并正在积极开发中，旨在运行在许多环境和框架中，包括AWS ECS，DC / OS和Docker。这种更广泛的环境支持的主要原因是每个[url=https://linkerd.io/1/advanced/deployment/per-host]主机[/url]可以部署 Linkerd 1.x ，这使它可以与不适合边车部署的环境集成。
每主机部署模型的缺点是单个代理故障将影响多个服务。另一方面，与边车模型相比，每主机部署导致更低的资源消耗，考虑到Linkerd 1.x的相对较高的资源需求，这是一个重要的考虑因素。
5.支持的协议
Istio和Linkerd 2.x都通过其sidecar代理支持服务之间的HTTP 1.1，HTTP2，gRPC和TCP通信。Linkerd 1.x不支持TCP连接。
6.实施语言
Istio（控制平面）和Linkerd 2.x都用Go编写。用于Istio数据平面的代理Envoy是用C ++编写的，而实现Linkerd 2.x数据平面的代理是用Rust编写的。Linkerd 1.x是用Scala编写的。
7.安全性，加密和授权
Istio的控制平面组件提供以下安全功能：
- Citadel：密钥和证书管理。
- Pilot：分发身份验证策略和安全命名信息。
- 混音器：授权和审计的管理。
- Sidecars：在代理之间实现安全通信，支持TLS加密。
在撰写本文时，Linkerd中的自动TLS加密被标记为“实验性”，并且不支持主机到主机的身份验证。
8.边车注入
将边车添加到部署工件并将其与服务网格控制平面一起注册的过程称为“边车注入”.Entio和Linkerd都支持手动和自动边车注入。
9. 高可用性
如果配置了多个副本并使用了podAntiAffinity标志，则Istio支持Kubernetes的高可用性。
Linkerd的高可用性功能目前标记为“实验性”。
10.监控和跟踪支持
Istio本身支持Prometheus并与Jaeger集成以进行分布式跟踪。Linkerd支持Prometheus和Grafana开箱即用，但目前不支持分布式跟踪。
11.性能
Linkerd 2.x的性能开销通常低于Istio的性能开销。在两个服务网格之间的性能基准测试中，显示对于由HTTP回声组成的测试负载，每秒的查询从基线每秒30-35000次查询（kqps）下降到10-12 kqps，用于Linkerd和3.2 Istio为-3.9 kqps。
什么时候服务网格可能是一个坏主意？
您可能不希望考虑使用服务网格来管理微服务架构所带来的潜在复杂网络挑战，这有五个主要原因。
1.服务网格是有意见的
服务网格是一种平台解决方案，因此往往非常自以为是。这意味着您可能会发现自己必须“按照自己的方式工作”而不是对您的业务或技术堆栈最有意义的方式。根据您的具体情况，这项前期投资可能过于昂贵。
同样，如果控制应用程序和服务如何相互通信对您的组织来说具有战略重要性，那么使用现有的服务网格毫无意义。采用服务网格可以让您从技术涨潮中受益，但不允许您控制自己的命运。
2.服务网格很复杂
部署服务网格会增加相当大的复杂性。部署需要接收边车，服务网格需要集成到环境中然后不断重新配置，并且可能必须重新设计加密。因此，在像Kubernetes这样的平台上运行服务网格将要求您不仅成为您选择的服务网格的专家，而且还要成为平台的专家。
3.服务网格可能很慢
随着网格的增长和路由表的大小增加，通过一系列代理路由流量会变得非常缓慢。
4.服务网格更喜欢自包含的蓝图
采用服务网格来跟踪服务中的请求并不总是像它第一次出现那样有价值。例如，如果您的微服务环境结合了来自不同团队的应用程序和服务，那么当跨越不同工程团队和业务部门的边界时，解释跟踪可能非常具有挑战性，更不用说企业或云提供商了。
5.服务网格适用于开发人员
服务网格专注于战术开发人员对服务到服务调用的关注。它们无助于控制复杂的新兴行为，这些行为是以规模和非预期的方式相互交互的应用程序和服务有机地发展而来的。