Service Mesh框架对比：Linkerd vs. Istio( 二 ) _框架

数据层

在一个典型的服务网格环境中，服务的部署过程将纳入一个专有的外挂代理。如前文所述，服务并不直接向网络传递消息，而是由本身的代理来进行通信。这样的机制封装了服务间通信的复杂性。服务网格内的代理之间相互连接，构成了数据层。
默认情况下，Istio使用Envoy作为数据层，Envoy原本是设计用来与其他类型的代理（比如Nginx）来进行工作的。Linkerd使用自有的代理。

平台支持

尽管声称支持大量的环境和框架，但在实践中，Istio仅能与kubernetes相处融洽，这严重限制了他的应用范畴。
Linkerd 2.x目前也需要与Kubernetes协同工作。然而Linkerd 1.x 部署广泛，并处于活跃的研发状态，可以在多种环境和框架下工作，包括与AWS ECS、DC/OS和Docker协同工作。能够支持如此广泛的环境，得益于Linkerd 1.x 可以基于主机的部署模式，这使得其可以与用户的环境进行整合而无需以外挂的形式部署。

文章插图

Linkerd 1.x 主机部署模式：linkerd服务网格可以基于主机部署。基于这样的模式，同一主机的多个微服务共享一个Linkerd（1.x）实例。

主机部署模式的主要缺点在于单点代理的失败将影响多个微服务。从另一方面讲，主机部署模式相对于外挂模式对资源的消耗更低。

协议支持

基于外挂代理，Istio和Linkerd 2.x 都支持HTTP 1.1, HTTP2, gRPC和TCP协议的服务间通信。但Linkerd 1.x 不支持TCP连接。

实现语言

Istio的控制层和Linkerd 2.x 都是用Go语言编写的，Istio数据层的Envoy代理是由C++编写的，Linkerd 2.x 的数据层是用Rust编写的。Linkerd 1.x 是用Scala编写的。

安全、加密和授权

Istio的控制层组件提供了如下的安全功能： Citadel：密钥和证书管理。Pilot：认证策略和安全命名信息的分发。Mixer：授权和审计的管理。外挂：实现代理间基于TLS加密的安全通信。
本文成文时，Linkerd的自动化的TLS加密还处于实验阶段，主机间认证也还未获支持。

外挂注入

将外挂加入到部署包并且在服务网格的控制层进行注册的过程即为“外挂注入” 。Istio和Linkerd都支持手动和自动的外挂注入。

高可用性

Istio支持高可性，当且仅当配置了Kubernetes的多副本模式，并且打开podAntiAffinity开关的情况下。
linkerd的高可用性目前仍处于实验阶段。

监控和跟踪

Istio原生支持Prometheus并且集成了Jaeger来进行分布式跟踪。Linkerd支持Prometheus和Grafana从外部进行监控，但目前并不支持分布式跟踪。

性能

【Service Mesh框架对比：Linkerd vs. Istio】Linkerd 2.x 在性能上的常规开销总体上比Istio要低一些。一项关于两者的性能测试表明，基于一组由HTTP请求组成的测试负载，每秒的千次查询数（kqps）基准值是30-35kqps，经由代理转发后，性能会有所下降，Linkderd降到了10-12kqps，而Istio则降到了3.2-3.9kqps 。
五、什么时候应该谨慎使用服务网格？有五个主要的原因，可能阻止你考虑使用服务网格来管理微服务架构所带来的潜在的网络复杂性挑战。
1、服务网格具有排他性
服务网格是一个平台解决方案，因此是排他性的。这意味着你将被迫在“服从他们的方式”和“基于我自己的业务和技术考量选择适合的方式”之间做出选择。根据你所处的形势，对服务网格的前期投资可能十分昂贵。
而且，如果说控制应用和服务间通信对你的组织来说具有战略性的重要意义的话，那么使用一个现成的服务网格就没有意义了。这样或许可以受益于框架成长带来的收益，但无法对你的目标实现控制。
2、服务网格具有复杂性
服务网格的部署将向你的架构引入相当可观的复杂性。部署过程需要引入外挂代理，服务网格需要与现有的环境进行整合并在未来的时间里反复的配置，所有的加密可能需要重新设计。基于Kubernetes这样的平台建立服务网格的实例，会要求你不仅是服务网格的专家，并且是熟悉Kubernetes的专家。
3、服务网格可能运行缓慢
随着网格的扩张和路由表的膨胀，通过一系列代理进行的路由通信将慢的痛苦异常。
4、服务网格倾向于建立自治的架构蓝图
使用服务网格来追踪服务间的通信请求并不总是像最初那样看起来有价值。比如，假设你的微服务环境与其他团队的应用和服务相整合，在跨越不同的技术团队和业务单元的边界时，翻译不同的追踪记录将十分挑战，如果是企业级环境或者是云端供应商的情况下，这种挑战将更加严峻。