服务|Service Mesh框架对比：Linkerd vs. Istio 本文由公众号EAWorld翻译发表

文章插图
本文由公众号EAWorld翻译发表，转载需注明出处。
作者：Marcus Schiesser
译者：白小白
原题：Comparing Service Meshes: Linkerd vs. Istio
原文：
引言：各个细分行业和领域的组织机构正在持续的加速采用微服务架构。随之而来的是容器的使用以及端点和服务通信的爆炸式增长。企业内部的复杂性和不确定性正在不断增加。如何在这样的情况下实现对规模化通信安全性和可见性的管理颇具挑战。因此，无论是运营者或者开发者都强烈渴望将网络层的复杂性封装为一个新的网络基础架构层。当此之时，处理此事的最流行的方式是服务网格（Service Mesh）。
因此，在本文中，我们将对比两种主流的服务网络的特性，以找出两者的异同之处，即Linkerd和Istio 。文中也会提及有关服务网格使用的争论，探寻在某种特定的场景下，基于特定的用例和架构，何者比何者更具优势。
一、服务网格是什么？服务网格是一个专有的基础设施层，这一层级的存在可以使得微服务架构内部的服务间通信更加可靠、快捷和安全。其基本的理念是在服务间插入一个代理组成的网络来实现对网络层的抽象。一言以蔽之，服务网格的设计初衷就是帮助开发者解决微服务间的交互挑战。
二、Istio是什么？Istio是由Google、IBM和Lyft发起的开源的服务网格项目。该项目在2017年推出，并在2018年7月发布了1.0版本。 Istio基于Envoy代理并以之为数据层（data plane）。可以说Istio是如今最炙手可热的服务网格，但由于仅应用于Kubernetes ，其应用价值受到某种限制。
三、Linkerd是什么?Linkerd（音似chickadee），最初是由Buoyant团队于2016年打造的一个服务网格项目。 Linkerd是CNCF的官方项目，基于Twitter的Finagle项目并和后者一样，最初是由Scala语言编写，设计理念是支持基于主机（物理主机或者虚拟节点）的部署模式。由于最初版本的内存占用广受诟病，导致了Conduit项目的开发， Conduit是一个轻量级的服务网格，为Kubernetes定制，用Rust和Go语言编写。 Conduit项目目前已经合并到Linkerd项目，并在2018年7月发布为Linkerd 2.0 版本。鉴于Linkerd 2.x 基于Kubernetes ，而Linkerd 1.x 可以基于节点的模式部署，当面临复杂环境的场景时，人们可以有更灵活的选择。除非特指，本文的比较都是基于Linkerd 2.x 。
四、特性和功能对比

架构

Istio和Linkerd都支持以主流的外挂（Sidecar）模式部署。在这种模式下，每个微服务都被分配一个单独的代理。微服务间的通信并不直接进行，而是通过自身的代理转发。代理会将请求路由到目标微服务的代理，该代理再将请求转发到目标微服务。所有这些服务代理构成了数据层。在服务网格的架构下，数据层由控制层（control plane）来进行配置和监控，控制层一般另行独立部署。

文章插图
架构图示意：以Istio为例。 Envoy代理以外挂形式部署。在这样的部署模型中，代理将注入每个容器单元，因此可以独立的配置。 Istio控制层由很多的组件组成，用来对服务间通信进行配置、度量、控制和安全管控。

控制层

控制层的使命是通过一系列API和工具对服务网格内的代理实现控制。在控制层中，可以将整个数据层作为一个整体来指定认证策略，收集度量指标，进行配置。
Istio的控制层由三个组件构成。首先是Pilot ，负责配置数据层。其次是Mixer ，负责收集通信流量的度量指标，并响应数据层各种不同的查询请求，包括授权、访问控制和配额查询等。基于所启用的适配器的不同， Mixer也可与日志和监控系统进行对接。最后是Citadel ，这个组件允许开发者基于服务身份认证而非网络控制建立一个零信任（零信任， zero-trust ，简单讲，即假定所有通信方不可信赖并必须进行验证）机制的网络环境。 Citadel负责为每个服务指定证书，如果有需要，也可以接受外部的证书授权密钥。
白小白：

文章插图
Linkerd的控制层由一个Web组件、一个控制组件和一个度量组件组成。 Web组件提供了基于Web的管理控制面板。控制组件由多个容器部署组成。完成了控制层的多数功能（包括聚合遥测数据，提供用户界面API ，为数据层提供控制数据等）。度量组件由定制化的Prometheus和Grafana组成。 Prometheus负责抓取Linkerd暴露的度量指标并储存下来。 Linkerd本身会生成很多外部面板， Grafana负责渲染和展现这些面板。