Service Mesh框架选型对比分析：Linkerd、Envoy、Istio、Conduit

旧城等待， 2022-11-12 02:00 912阅读 0赞

当前，业界主要有以下主要几种`Service Mesh`框架，下面进行详细的说明及对比。

# 1、Linkerd #

`Linkerd`是Buoyant公司2016年率先开源的高性能网络代理，是业界的第一款`Service Mesh`框架。其主要用于解决分布式环境中服务之间通信面临的一些问题，如网络不可靠、不安全、延迟丢包等问题。

`Linkerd`使用**Scala语言编写**，运行于`JVM`，底层基于Twitter的`Finagle`库，并对其做了相应的扩展。最主要的是`Linkerd`具有快速、轻量级、高性能等特点，每秒以最小的延迟及负载处理万级请求，易于水平扩展。除此之外，还有以下功能：

*  支持多平台：可运行于多种平台，比如`Kubernetes`、`DC/OS`、`Docker`，甚至虚拟机或物理机。
 *  无缝集成多种服务发现工具。
 *  支持多协议，如`gRPC`、`HTTP/1.x`、`HTTP/2`，甚至可通过`linkerd-tcp`支持TCP协议。
 *  支持与第三方分布式追踪系统`Zipkin`集成。
 *  灵活性、扩展性高，可通过其提供的接口开发自定义插件。

目前，`Linkerd`和`Linkerd2`并行开发，其情况如下：

*  `Linkerd`：`Linkerd`使用\*\*`Scala`语言编写\*\*，运行于`JVM`，底层基于Twitter的`Finagle`库，并对其做了相应的扩展。
 *  `Linkerd2`：使用`Go`语言和`Rust`语言完全重写了`Linkerd`，专门用于`Kubernetes`。

`Linkerd`本身是数据平面，负责将数据路由到目标服务，同时保证数据在分布式环境中传输是安全、可靠、快速的。另外，`Linkerd`还包括控制平面组件`Namerd`，通过控制平面`Namerd`实现中心化管理和存储路由规则、中心化管理服务发现配置、支持运行时动态路由以及暴露`Namerd API`管理接口。

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3hjYmV5b25k_size_16_color_FFFFFF_t_70]

*  **控制平面**
    
    是在`Kubernetes`特定命名空间中运行的一组服务。这些服务可以完成各种事情：聚集遥测数据，提供面向用户的API，向数据平面代理提供控制数据等。
    
    由以下部分组成：
    
     *  `Controller`：由`public-api`容器组成，该容器为`CLI`和`dashboard`提供接口API。
     *  `Destination`：数据平面中的每个代理都使用此组件来查找将请求发送到哪里。还用于获取服务配置信息，如：路由指标，重试和超时等。
     *  `Identity`：该组件提供了证书的颁发，接受来自代理的[CSRs][]并返回正确身份签名的证书。这些证书由代理在启动时获取，并且必须在代理准备就绪之前发出。随后，它们可用于`Linkerd`代理之间的任何连接以实现`mTLS`。
     *  `Proxy Injector`：是一个注入程序，每次创建一个`pod`时，它都会接收一个`webhook`请求。该注入程序检查资源以查找特定于`Linkerd`的注释（`linkerd.io/inject: enabled`）。当存在该注释时，注入器将更改容器的规范，并添加 `initContainer`包含代理本身的以及附属工具。
     *  `Service Profile Validator`：用于在保存新服务配置文件之前先对其进行验证。
     *  `Tap`：从`CLI`和`dashboard`接收请求，以实时监视请求和响应。
 *  **数据平面**
    
    由轻量级代理组成，这些代理作为`sidecar`容器与服务代码的每个实例一起部署。为了将服务“添加”到`Linkerd`服务网格，必须重新部署该服务的`Pod`，以在每个Pod中包含数据平面代理。

# 2、Envoy #

同`Linkerd`一样，`Envoy`也是一款高性能的网络代理，于2016年10月份有Lyft公司开源，为云原生应用而设计，可作为边界入口，处理外部流量，此外，也作为内部服务间通信代理，实现服务间可靠通信。`Envoy`的实现借鉴现有生产级代理及负载均衡器，如`Nginx`、`HAProxy`、硬件负载均衡器及云负载均衡器的实践经验，同时基于`C++`编写及Lyft公司生产实践证明，`Envoy`性能非常优秀、稳定。

`Envoy`既可用作独立代理层运行，也可作为`Service Mesh`架构中数据平面层，因此通常`Envoy`跟服务运行在一起，将应用的网络功能抽象化，`Envoy`提供通用网络功能，实现平台及语言无法性。除此之外，还有以下功能：

*  优先支持`HTTP/2`和`gRPC`，同时支持`Websocket`和TCP代理。
 *  API驱动的配置管理方式，支持动态管理、更新配置以及无连接和请求丢失的热重启功能。
 *  `L3/L4`层过滤器形成`Envoy`核心的连接管理功能。
 *  通过与多种指标收集工具及分布式追踪系统集成，实现运行时指标收集、分布式追踪，提供整个系统及服务的运行时可见性。
 *  内存资源使用率低，`sidecar`是`Envoy`最常用的部署模式。

# 3、Istio #

`Istio`是由`Google`、`IBM`和`Lyft`发起的开源的`Service Mesh`框架。该项目在2017年推出，并在2018年7月发布了1.0版本。

`Istio`是`Service Mesh`目前的实现的典型代表，如果`Sidecar`是整个`Service Mesh`的数据面，那么`Istio`主要在控制面上做了更多的改进，`Istio`使用`Envoy`作为`Sidecar`，控制面相关全部使用`Golang`编写，性能上有了很大的提升。

**`Istio` 首先是一个服务网格，但是`Istio`又不仅仅是服务网格：在 `Linkerd`，`Envoy` 这样的典型服务网格之上，`Istio`提供了一个完整的解决方案，为整个服务网格提供行为洞察和操作控制，以满足微服务应用程序的多样化需求。**

`Istio`在服务网络中统一提供了许多关键功能：

*  流量管理：控制服务之间的流量和API调用的流向，使得调用更可靠，并使网络在恶劣情况下更加健壮。
 *  可观察性：了解服务之间的依赖关系，以及它们之间流量的本质和流向，从而提供快速识别问题的能力。
 *  策略执行：将组织策略应用于服务之间的互动，确保访问策略得以执行，资源在消费者之间良好分配。策略的更改是通过配置网格而不是修改应用程序代码。
 *  服务身份和安全：为网格中的服务提供可验证身份，并提供保护服务流量的能力，使其可以在不同可信度的网络上流转。
 *  除此之外，`Istio`针对可扩展性进行了设计，以满足不同的部署需要。
 *  平台支持：`Istio`旨在在各种环境中运行，包括跨云， 预置，`Kubernetes`，`Mesos`等。最初专注于`Kubernetes`，但很快将支持其他环境。
 *  集成和定制：策略执行组件可以扩展和定制，以便与现有的`ACL`，日志，监控，配额，审核等解决方案集成。

这些功能极大的减少了应用程序代码，底层平台和策略之间的耦合，使微服务更容易实现。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3hjYmV5b25k_size_16_color_FFFFFF_t_70 1]

`Istio`架构图中各个子模块功能如下：

*  `Envoy`：负责各个应用服务之间通信。
 *  `Pilot`：管理和配置`Envoy`，提供服务发现、负载均衡和智能路由，保证弹性服务（服务超时次数、重试、熔断策略）。
 *  `Mixer`：信息监控检查。
 *  `Istio-Auth`：提供服务和服务、用户和服务之间的认证服务，实现访问控制，解决是谁访问的是哪个 API 的问题。

其中，图中的通信代理组件为`Envoy`，这是`Istio`原生引入的，但`Linkerd`也能够集成对接`Istio`。

# 4、Conduit #

`Conduit`于2017年12月发布，作为由Buoyant继`Linkerd`后赞助的另外一个开源项目，作为`Linkerd`面向`Kubernetes`的独立版本。`Conduit`旨在彻底简化用户在`Kubernetes`使用服务网格的复杂度，提高用户体验，而不是像`Linkerd`一样针对各种平台进行优化。

`Conduit`的主要目标是轻量级、高性能、安全并且非常容易理解和使用。同`Linkerd`和`Istio`，`Conduit`也包含数据平面和控制平面，其中数据平面由`Rust`语言开发，使得`Conduit`使用极少的内存资源，而控制平面由`Go`语言开发。`Conduit`依然支持`Service Mesh`要求的功能，而且还包括以下功能：

*  超级轻量级和极快的性能。
 *  专注于支持`Kubernetes`平台，提高运行在`Kubernetes`平台上服务的可靠性、可见性及安全性。
 *  支持`gRPC`、`HTTP/2`和`HTTP/1.x`请求及所有TCP流量。

`Conduit`以极简主义架构，以零配置理念为中心，旨在减少用户与`Conduit`的交互，实现开箱即用。

# 5、对比总结 #

下面对上述各种Service Mesh框架进行简单的比较汇总，见下表所示：

<table> 
 <thead> 
  <tr> 
   <th>功能</th> 
   <th>Linkerd</th> 
   <th>Envoy</th> 
   <th>Istio</th> 
   <th>Conduit</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>代理</td> 
   <td><code>Finagle</code> + <code>Jetty</code></td> 
   <td><code>Envoy</code></td> 
   <td><code>Envoy</code></td> 
   <td><code>Conduit</code></td> 
  </tr> 
  <tr> 
   <td>熔断</td> 
   <td>支持。基于连接的熔断器<code>Fast Fail</code>和基于请求的熔断器<code>Failure Accrual</code>。</td> 
   <td>支持。通过特定准则，如最大连接数、 最大请求数、最大挂起请求数或者最大重试数的设定。</td> 
   <td>支持。通过特定准则，如最大连接数和最大请求数等的设定。</td> 
   <td>暂不支持。</td> 
  </tr> 
  <tr> 
   <td>动态路由</td> 
   <td>支持。通过设置<code>Linkerd</code>的<code>dtab</code>规则实现不同版本服务请求的动态路由。</td> 
   <td>支持。通过服务的版本或环境信息实现。</td> 
   <td>支持。通过服务的版本或环境信息实现。</td> 
   <td>暂不支持。</td> 
  </tr> 
  <tr> 
   <td>流量分流</td> 
   <td>支持。以增量和受控的方式实现分流。</td> 
   <td>支持。以增量和受控的方式实现分流。</td> 
   <td>支持。以增量和受控的方式实现分流。</td> 
   <td>暂不支持。</td> 
  </tr> 
  <tr> 
   <td>服务发现</td> 
   <td>支持。支持多种服务发现机制，如基于文件的服务发现、<code>Consul</code>、<code>Zookeeper</code>、<code>Kubernetes</code>等。</td> 
   <td>支持。通过提供平台无关的服务发现接口实现与不同服务发现工具集成。</td> 
   <td>支持。通过提供平台无关的服务发现接口实现与不同服务发现工具集成。</td> 
   <td>只支持<code>Kubernetes</code>。</td> 
  </tr> 
  <tr> 
   <td>负载均衡</td> 
   <td>支持。提供多种负载均衡算法。</td> 
   <td>支持。提供多种负载均衡算法，如<code>Round Robin</code>、加权最小请求、哈希环、<code>Maglev</code>等。</td> 
   <td>支持。提供多种负载均衡算法，如<code>Round Robin</code>、加权最小请求、哈希环、<code>Maglev</code>等。</td> 
   <td>支持。当前只有HTTP请求支持基于<code>P2C</code> + <code>least-loaded</code>的负载均衡算法。</td> 
  </tr> 
  <tr> 
   <td>安全通信</td> 
   <td>支持<code>TLS</code>。</td> 
   <td>支持<code>TLS</code>。</td> 
   <td>支持<code>TLS</code>。</td> 
   <td>支持<code>TLS</code>。</td> 
  </tr> 
  <tr> 
   <td>访问控制</td> 
   <td>不支持。</td> 
   <td>不支持。</td> 
   <td>支持。基于<code>RBAC</code>的访问控制。</td> 
   <td>暂不支持。</td> 
  </tr> 
  <tr> 
   <td>可见性</td> 
   <td>分布式追踪(<code>Zipkin</code>)、运行时指标(<code>InfluxDB</code>、<code>Prometheus</code>、<code>statsd</code>)</td> 
   <td>分布式追踪(<code>Zipkin</code>)、运行时指标(<code>statsd</code>)</td> 
   <td>分布式追踪(<code>Zipkin</code>)、运行时指标(<code>Prometheus</code>、<code>statsd</code>)、监控(<code>NewRepic</code>、<code>Stackdriver</code>)</td> 
   <td>运行时指标(<code>Prometheus</code>)</td> 
  </tr> 
  <tr> 
   <td>部署模式</td> 
   <td><code>sidecar</code>或者<code>per-host</code>模式</td> 
   <td><code>sidecar</code>模式</td> 
   <td><code>sidecar</code>模式</td> 
   <td><code>sidecar</code>模式</td> 
  </tr> 
  <tr> 
   <td>控制平面</td> 
   <td><code>Namerd</code></td> 
   <td>没有，但可通过API实现。</td> 
   <td><code>Pilot</code>、<code>Mixer</code>、<code>Citadel</code></td> 
   <td><code>Conduit</code></td> 
  </tr> 
  <tr> 
   <td>协议支持</td> 
   <td><code>HTTP/1.x</code>、<code>HTTP/2</code>、<code>gRPC</code></td> 
   <td><code>HTTP/1.x</code>、<code>HTTP/2</code>、<code>gRPC</code>、<code>TCP</code></td> 
   <td><code>HTTP/1.x</code>、<code>HTTP/2</code>、<code>gRPC</code>、<code>TCP</code></td> 
   <td><code>HTTP/1.x</code>、<code>HTTP/2</code>、<code>gRPC</code>、<code>TCP</code></td> 
  </tr> 
  <tr> 
   <td>运行平台</td> 
   <td>平台无关</td> 
   <td>平台无关</td> 
   <td>目前支持<code>Kubernetes</code>，平台无关是最终实现目标。</td> 
   <td>只支持<code>Kubernetes</code>。</td> 
  </tr> 
 </tbody> 
</table>

综上对比，推荐选择生态比较完善的`Istio`。

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3hjYmV5b25k_size_16_color_FFFFFF_t_70]: /images/20221022/9761d0b9427b449781cb2168fddeeae9.png
[CSRs]: https://en.wikipedia.org/wiki/Certificate_signing_request
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3hjYmV5b25k_size_16_color_FFFFFF_t_70 1]: /images/20221022/e3ef6c35f515465fae0c75d2f0b69181.png