对应选择服务网格

详情描述：

哪种服务网格较适合你的企业?用以支撑微服务开发的服务网格框架，每种方案都给出了其适用场景。

服务网格一直有很高的热度。正如Linkerd的作者William Morgan所提到的：“服务网格本质上无非就是和应用捆绑在一起的用户空间代理。

Envoy是许多服务网格框架的核心组件，是一个通用的开源代理，常被用于Pod内的sidecar以拦截流量。

Istio是基于Envoy构建的一个可扩展的开源服务网格。开发团队可以通过它连接、加密、管控和观察应用服务。Istio 的关键特性包括负载均衡、流量路由、策略创建、可度量性及服务间认证。

Istio 有两个部分组成：数据平面和控制平面。数据平台负责流量管理，通过 Envoy 的 sidecar 代理来实现流量路由和服务间调用。控制平面是主要由开发者用来配置路由规则和观测指标。

Istio 观测指标是细粒度的属性，其中包含和服务行为相关的特定数据值。

Linkerd
按照官网的说法，Linkerd 是一个轻量级、安全优先的 Kubernetes 服务网格。它的创建流程快到让人难以置信(据称在 Kubernetes 安装只需要 60 秒)，这是大多数开发者喜闻乐见的事情。Linkerd 并没有采用基于 Envoy 的构建方案。而是使用了一个基于 Rust 的高性能代理 linkerd2-proxy，这个代理是专门为 Linkerd 服务网格编写的。

Consul Connect 是来自 HashiCorp 的服务网格，专注于路由和分段，通过应用级的 sidecar 代理来提供服务间的网络特性。 Consult Connect 侧重于应用安全，提供应用间的双向安全 TLS 连接以实现授权和加密。

Consult Connect 独特的一点是提供了两种代理模式。一种是它内建的代理，同时它还支持 Envoy 方案。Connect 强调可观测性，集成了例如 Prometheus 用这样的工具来监控来自 sidecar 代理的数据。Consul Connect 可以灵活地满足开发者的使用需求。

Kuma 来源于 Kong，自称是一个非常好用的服务网格替代方案。Kuma 是一个基于 Envoy 的平台无关的控制平面。 Kuma 提供了安全、观测、路由等网络特性，同时增强了服务间的连通性。Kuma 同时支持 Kubernetes 和虚拟机。

Kuma 让人感兴趣的一点是，它的企业版可以通过一个统一控制面板来运维管理多个互相隔离独立的服务网格。这项能力可以满足安全要求高的使用场景。既符合隔离的要求，又实现集中控制。

Maesh 是来自 Containous 的容器原生的服务网格，标榜自己是比市场其它服务网格更轻量级更易用的方案。和很多基于 Envoy 构建的服务网格不同，Maesh 采用了 Traefik， 一个开源的反向代理和负载均衡器。

Network Service Mesh(NSM)是一款专门为 telcos 和 ISPs 设计的服务网格。它提供了一层级用以增强服务在 Kubernetes 的低层级网络能力。NSM 目前是 CNCF 的沙箱项目。

如何选择
正如文中所提到的，可供选择的服务网格方案有很多，选择一款合适的服务网格，主要考虑的因素包括，你能接受它带来多大的侵入性，它的安全性如何，以及平台成熟度等

1: 依赖Envoy。Envoy 又是一个活跃的社区生态。开源，同时是许多服务网格的底座。Envoy 具备的丰富特性使得其成为一个很难绕过的因素。

2：具体使用场景。如果不是所有应用都部署在 Kubernetes，则应该优先考虑平台无关的方案。

3：现有容器管理平台。 AWS 的 EKS，红帽的 OpenShift，Consul。沿袭原有的生态，可以继承并拓展原有的特性。而这些可能是开源方案所不能提供的。

4：所在行业。许多服务网格不是为特定行业专门设计的。Kuma 统一管理多个隔离服务网格的能力可能更适用于受到高度管制的金融行业。

5：对可视化的要求。可观测性是服务网格的核心能力之一。考虑进一步定制和更深度能力的团队应该优先考虑 Istio 或 Consul。

6：是否遵循开发标准。遵循开发标准使得你的平台更具备前瞻性和可扩展性。这使得企业会倾向于采用支持 SMI 的方案，Maesh 或其他基金会孵化的项目如 Linkerd。

7：是否重视用户体验。考虑运维人员的易用性是评判新工具的关键指标。这方 Linkerd 似乎在开发者中间口碑不错。

8：团队准备。评估你的团队所具备的资源和技术储备，在技术选型时决定你们适合用基于 Envoy 的 Istio，或是供应商抽象封装的方案，例如 OpenShift。