在讨论微服务架构和容器化时, 近年来，一组经过生产验证的工具吸引了大多数人的注意:服务网格.

实际上，微服务架构和 Kubernetes (通常是程式化的“k8”)已经迅速成为可扩展应用程序的标准, 使管理服务间通信的问题成为热门话题——服务网格是一个有吸引力的解决方案. 我自己也在生产环境中使用过服务网格，特别是Linkerd、Istio和早期形式的 Ambassador. 但是服务网格到底是做什么的呢? 哪一个是最好的使用? 你怎么知道你是否应该使用一个呢?

要回答这些问题，理解为什么要开发服务网格是有帮助的. 从历史上看，传统的IT基础设施将应用程序作为整体运行. One service ran on one server; if it needed more capacity, 解决方案是通过配置更大的机器来垂直扩展它.

达到这种方法的极限, 大型科技公司迅速采用了三层架构, 将负载均衡器与应用程序服务器和数据库层分离. 虽然这个体系结构仍然具有一定的可伸缩性, 他们决定将应用层分解为微服务. 为了使应用程序可扩展，这些服务之间的通信对于监视和保护变得至关重要.

允许服务间通信, 这些公司开发了内部图书馆:Twitter的骗局, Netflix的Hystrix, 还有谷歌的斯塔比 2016年成为gRPC). 这些库旨在解决微服务架构带来的问题:服务之间的安全性, latency, monitoring, 以及负载平衡. 但是将一个大型库作为一个依赖项来管理——在多种语言中——既复杂又耗时.

最后，这种类型的库被更易于使用的轻量级代理所取代. 这些代理在外部独立于应用程序层——对应用程序来说可能是透明的——并且更容易更新, maintain, and deploy. 因此，服务网格诞生了.

什么是服务网格?

A service mesh is a software infrastructure layer for controlling communication between services; it’s generally made of two components:

1. The data plane，它处理应用程序附近的通信. 通常，这是作为一组网络代理与应用程序一起部署的，如前所述.
2. The control plane, 谁是服务网格的“大脑”. 控制平面与代理交互，推送配置, 确保服务发现, 集中可观测性.

服务网格围绕服务间通信有三个主要目标:

1. Connectivity
2. Security
3. Observability

Connectivity

服务网格体系结构的这一方面允许服务发现和动态路由. It also covers 沟通弹性，例如重试、超时、断路和速率限制.

服务网的一个主要特点是 load balancing. 所有服务都通过代理网格化，从而允许在服务之间实现负载平衡策略, 比如轮循, random, 最少的请求. 这些策略是服务网格用来决定哪个副本将接收原始请求的策略, 就像在每个服务前面都有一个小的负载平衡器一样.

最后，服务网格提供 routing control 以流量转换和镜像的形式.

Security

在传统的微服务架构中, 服务之间使用未加密的流量进行通信. 就安全性而言，未加密的内部通信现在被认为是一种糟糕的做法, 特别是对于公共云基础设施和零信任网络.

在对硬件没有直接控制的情况下，除了保护客户数据的隐私之外， 加密内部流量 在系统被破坏的情况下增加了一层额外的复杂性. 因此，所有的服务网格都使用 互TLS (mTLS) 服务间通信的加密.e.，所有代理间通信.

服务网格甚至可以强制执行 复杂的授权策略矩阵，根据针对特定环境和服务的策略允许或拒绝流量.

Observability

服务网格的目标是为服务间通信带来可见性. 通过控制网络，服务网格加强可观察性，提供 layer-seven指标，这反过来又允许 自动警报 当流量达到某些可定制的阈值时.

通常由第三方工具或插件(如Jaeger或Zipkin)支持, 这种控制还允许通过 注入HTTP跟踪头.

服务网格的好处

创建服务网格是为了抵消微服务架构带来的一些操作负担. 那些有微服务架构经验的人知道，它们每天都需要大量的工作来操作. 要充分利用微服务的潜力，通常需要外部工具来处理集中式日志, 配置管理, 可扩展性机制, among others. 使用服务网格 标准化这些功能，以及它们的设置和集成.

服务网格可观察性, in particular, 提供非常通用的调试和优化方法. 由于服务之间交换的粒度和完全可见性, 工程师——尤其是航天工程师——可以做得更多 快速解决 可能的错误和系统错误配置. 使用服务网格跟踪, 它们可以跟踪请求从进入系统(通过负载平衡器或外部代理)一直到堆栈内的私有服务. 他们可以使用日志来映射请求并记录它在每个服务中遇到的延迟. The end result: 详细了解系统性能.

流量管理在全面发布新版本服务之前提供了强大的可能性:

1. Reroute 请求的百分比很小.
2. Even better, mirror 生产请求到新版本，以实时流量测试其行为.
3. A/B test 任何服务或服务的组合.

服务网格简化了上述所有场景, 更容易避免和/或减轻生产中的意外情况.

Kubernetes服务网格比较

In many ways, service meshes are the ultimate set of tools for microservices architecture; many of them run on one of the top container orchestration tools, Kubernetes. Kubernetes最好的服务网格是什么? 我们选择了今天在Kubernetes上运行的三个主要服务网格:, Istio, 和Consul Connect. Istio似乎是目前最流行的服务网格. 我们还将讨论其他一些服务网格:Kuma、Traefik Mesh和AWS App Mesh. 虽然目前在使用和社区方面不太突出, 他们很有希望在这里复习并密切关注.

关于Sidecar代理的快速说明

并非每个Kubernetes或k8的服务网格都采用相同的架构方法, 但一个常见的是杠杆作用 sidecar pattern. 这涉及到在主应用程序上附加一个代理(sidecar)，以拦截和调节应用程序的入站和出站网络流量. In practice, 这是在Kubernetes中通过每个应用程序pod中的辅助容器完成的，该容器将遵循应用程序容器的生命周期.

服务网格的边车方法有两个主要优点:

• Sidecar代理独立于运行时甚至应用程序的编程语言.
  • 这意味着无论在哪里使用服务网格，都可以很容易地启用它的所有特性, 整个堆栈.
• 侧车具有与应用程序相同级别的权限和对资源的访问权限.
  • sidecar可以帮助监视主应用程序使用的资源, 无需将监视集成到主应用程序代码库中.

但是sidecars是好坏参半的，因为它们直接影响了应用程序:

• 侧车初始化可能导致应用程序的启动机制死锁.
• Sidecar代理在应用程序上增加了潜在的延迟.
• Sidecar代理还增加了资源占用，在规模上可能会花费大量资金.

考虑到这些优点和缺点, sidecar方法在服务网格社区中经常是争论的主题. That said, 在我们的服务网格比较中，六个服务网格中有四个使用Envoy sidecar代理, and Linkerd uses its own sidecar implementation; Traefik Mesh does not use sidecars in its design.

Linkerd Review

linkard于2017年推出，是市场上最古老的服务网络. 由Buoyant(一家由两名前twitter工程师创办的公司)创建的linkkerd v1基于 芬格尔和妮蒂.

linkkerd v1被描述为超前的时代，因为它是一个完整的, 生产就绪的服务网格. 与此同时，它在资源使用方面有点沉重. 此外，文档中的重大漏洞使得它难以在生产环境中进行设置和运行.

With that, 浮力有机会使用一个完整的生产模型, 从中获得经验, 并运用这些智慧. 结果就是Conduit, 该公司于2018年发布了完整的linkkerd重写，并于当年晚些时候更名为linkkerd v2. Linkerd v2 brought with it several compelling improvements; since Buoyant’s active development of Linkerd v1 ceased long ago, 本文其余部分提到的“链接”指的是v2.

完全开源, Linkerd的数据平面依赖于用Rust编写的自制代理，控制平面依赖于用Go编写的源代码.

Connectivity

链接代理具有重试和超时功能，但在撰写本文时没有断路或延迟注入. Ingress support is extensive; Linkerd boasts integration with the following ingress controllers:

• Traefik
• Nginx
• GCE
• Ambassador
• Gloo
• Contour
• Kong

linkard中的服务配置文件提供了增强的路由功能, 提供用户指标, retry tuning, 超时设置, 都是基于每条路线. 至于负载均衡, Linkerd提供自动代理注入, 它自己的仪表盘, 以及对Grafana的本地支持.

Security

Linkerd中的mTLS支持很方便，因为它的初始设置是自动的, 它的自动每日按键旋转也是如此.

Observability

开箱即用，link的统计和路由可以通过CLI观察到. 在GUI方面，选项包括预制的Grafana仪表板和原生的linkard仪表板.

Linkerd可以插入到Prometheus的实例中.

跟踪可以通过使用OpenTelemetry(以前的OpenCensus)作为收集器的附加组件来启用, 而耶格自己在追踪.

Installation

链接安装是通过注入sidecar代理完成的, 这是通过在Kubernetes中为你的资源添加注释来完成的吗. 有两种方法:

1. Using a Helm chart. (对于许多人来说，Helm是Kubernetes资源的配置和模板管理器.)
2. 安装Linkerd CLI，然后使用它将Linkerd安装到集群中.

第二种方法从下载并运行安装脚本开始:

curl -sL http://run.linkerd.io/install | sh

从那里，链接的CLI工具 linkerd 提供了一个有用的工具包，帮助安装linkard的其余部分，并与应用程序集群和控制平面进行交互.

链接检查——pre 将运行您的链接安装所需的所有初步检查, 提供清晰和精确的日志，说明为什么潜在的Linkerd安装可能还不能正常工作. Without --pre，该命令可用于安装后调试.

下一步是在集群中安装Linkerd，运行:

链接安装| kubectl apply -f -

Linkerd will then install many different components with a very tiny resource footprint; hence, 他们自己有一个微服务方法:

• linkerd-controller，它提供了CLI和指示板交互使用的公共API
• linkerd-identity，它提供了实现mTLS的证书颁发机构
• linkerd-proxy-injector，它通过改变pod的配置来处理代理的注入
• linkerd-web, 哪个提供了一个仪表板，允许监控部署和pod, 以及内部链接组件

linklink的大部分配置都基于 CustomResourceDefinitions (CRDs). 这被认为是开发Kubernetes附加软件时的最佳实践——就像在Kubernetes集群中持久地安装插件一样.

添加分布式跟踪——这可能是也可能不是linkd用户真正需要的，因为 一些常见的误解-需要对链接收集器和链接收集器进行另一个步骤. 为此，我们首先创建一个配置文件:

cat >> config.yaml << EOF
tracing:
  enabled: true
EOF

要启用跟踪，我们将运行:

链接升级——config config.kubectl应用-f -

与任何基于sidecar代理的服务网格一样，您需要 修改应用程序代码 要启用跟踪. The bulk of this is simply adding a client library to propagate tracing headers; it then needs to be included in each service.

linkid的流量拆分特性，通过它暴露出来 服务网格接口 (SMI)兼容的API，已经允许 canary releases. 但要实现它们和流量管理的自动化，你还需要 外部工具 like Flagger.

Flagger是一个渐进式交付工具，它将评估Linkerd所说的内容 “黄金”指标: “请求量、成功率和延迟分布.” (Originally, 谷歌SREs使用了这个术语 golden signals 并包含了第四个指标——饱和度——但linkard并没有涵盖它，因为这需要一些不能直接访问的指标, 例如CPU和内存使用情况.) Flagger tracks these while splitting traffic using a feedback loop; hence, 你可以实现自动的和参数敏感的金丝雀版本.

在深入研究安装过程之后, 很明显，要使linkard服务网格可操作并利用通常需要的功能, 最终很容易运行至少12个服务. 也就是说，linkd在安装时提供的服务网格比其他服务网格多.

链接服务网格摘要

Advantages:

linkard受益于其创建者的经验, 两名前推特工程师曾参与内部工具的开发, Finagle, 后来从领客v1了解到. 作为第一个服务网格之一, linkedin拥有一个繁荣的社区(它的Slack拥有超过5个社区),000 users, 此外，它还有一个活跃的邮件列表和Discord服务器)，以及一套广泛的文档和教程. linkard的第2版已经成熟了.9，其通过证明 大公司 比如诺德斯特龙、eBay、Strava、Expedia和Subspace. linkard可以获得由Buoyant提供的付费企业级支持.

Drawbacks:

要充分发挥linkard服务网格的潜力，有一个非常强大的学习曲线. 仅在Kubernetes容器中支持linkd.e.(没有基于虚拟机的“通用”模式). linklink sidecar代理不是Envoy. 虽然这确实允许浮力调整它，因为他们认为合适的, 它消除了Envoy提供的固有可扩展性. 这也意味着linkard缺少对断路、延迟注入和速率限制的支持. 没有特定的API可以轻易地控制linkard控制平面. (不过，您可以找到gRPC API绑定.)

自v1以来，linkard在可用性和易于安装方面取得了很大的进步. 缺少正式公开的API是一个值得注意的遗漏. 但是多亏了精心设计的文档, linkard的开箱即用功能很容易测试.

Consul Connect审查

我们的下一个服务网格竞争者Consul Connect是一个独特的混合体. 来自HashiCorp的Consul以其用于分布式架构的键值存储而闻名, 已经存在很多年了吗. 在Consul发展成为一套完整的服务工具之后, HashiCorp决定在此基础上构建一个服务网格:Consul Connect.

准确地说，它的混合性质:

Consul Connect数据平面基于Envoy，它是用c++编写的. Consul Connect的控制平面是用Go编写的. 这是由Consul KV(一个键值存储)支持的部分.

像大多数其他服务网格一样, Consul Connect通过在应用程序pod中注入sidecar代理来工作. 就架构而言，Consul Connect是基于 agents and servers. Consul Connect的开箱即用意味着具有高可用性(HA) three or five servers as a StatefulSet 指定pod反亲和力. Pod反亲和是一种确保分布式软件系统的Pod不会在同一节点(服务器)上结束的实践。, 从而保证在任何单个节点故障的情况下可用性.

Connectivity

There’s not much that makes Consul Connect stand out in this area; it provides what any service mesh does (which is 相当多)，加上基于路径的路由、流量转移和负载平衡的第七层功能.

Security

与其他服务网格一样，Consul Connect提供基本的mTLS功能. 它还具有Consul和Vault之间的本地集成(也是由HashiCorp提供的)。, 哪个可以用作CA提供程序来管理和签署集群中的证书.

Observability

Consul Connect采用最常见的可观察性方法，将Envoy合并为侧车代理，以提供第七层功能. 配置Consul Connect的UI以获取指标需要更改内置配置文件，还需要启用像Prometheus这样的指标提供程序. 也可以配置一些Grafana仪表板来显示相关的服务特定指标.

Installation

Consul Connect使用Helm图安装到Kubernetes集群中:

添加hashicorp http://helm.releases.hashicorp.com

您需要修改默认值 values.yaml 如果你想启用UI或让Consul Connect模块注入它的sidecar代理:

Helm install -f consul-values.mysql hashicorp hashicorp/consul

咨询成员和检查各个节点，Consul建议 exec然后使用CLI工具将其导入其中一个容器 consul.

要提供Consul提供的开箱即用的web UI，请运行 Kubectl端口转发服务/hashicorp-consul-ui 18500:80.

Consul Connect服务网格摘要

Advantages:

• Consul is backed by HashiCorp; as a freemium product, 还有一个企业版本，它添加了一些功能，提供企业级支持. 就开发团队的经验而言，Consul是市场上最古老的工具之一.
• Consul有一个坚实的企业社区，并且可以在50的基础设施上运行,000 nodes. 此外，它自2014年以来一直存在，相对于市场而言，它是一个成熟的产品.
• 由于本机支持，Consul Connect在VM中运行良好.
• 使用Consul Connect, 在顶级科技公司，实现应用程序集成的深度可以达到pre-service-mesh的实现. 这要归功于公开了完整文档化的库级API.

Drawbacks:

• Consul Connect的学习曲线比其他服务网格更陡峭，需要更多的调优才能运行可视化仪表板和指标.
• HashiCorp的文档并不简单, 让用户挖掘和实验来正确配置它.
• 交通管理文档很难找到，主要由Envoy文档的链接组成, 它没有提供有关Consul Connect流量管理的详细信息.
• Consul Connect的SMI接口仍处于试验阶段.

对于那些寻求企业级产品的人来说，Consul Connect是一个非常好的选择. HashiCorp以其产品质量而闻名，Consul Connect也不例外. 与其他服务网格相比，我可以看到两个强大的优势:来自公司的企业版本的强大支持，以及为各种架构(不仅仅是Kubernetes)准备的工具。.

Istio Review

2017年5月，谷歌、IBM和Lyft宣布了Istio. 当Istio进入服务网格工具的竞争时，它在技术领域获得了很好的曝光率. 它的作者在第一版中一直根据用户反馈添加功能.9.

Istio承诺提供比竞争对手更重要的新功能:自动负载平衡, fault injection, and many more. 这为它赢得了社区的广泛关注, 但是我们将在下面详细说明, 使用Istio绝非易事:Istio已被公认为特别复杂，难以投入生产.

从历史上看，Istio项目在源代码更改方面经常出现波动. 一旦在控制平面上采用了微服务架构，Istio现在(从版本1开始)就已经实现了.5)搬回整体架构. Istio回归集中化的理由是，微服务很难被运营商监控, 代码库太冗余了, 这个项目有 达到组织成熟度-不再需要许多小团队在孤岛中工作.

However, 在此过程中，Istio因拥有最大数量的开放GitHub问题而臭名昭著. 在撰写本文时，大约有800个问题是开放的，大约有12000个问题是关闭的. 虽然问题数量可能具有欺骗性, in this case, 它们确实代表了对以前损坏的特性和失控的资源使用的有意义的改进.

Connectivity

与Consul Connect和Linkerd相比，Istio在流量管理方面非常强大. 这要归功于广泛提供的子特性:请求路由, fault injection, 交通转移, 请求超时, 电路打破, 控制服务网格的入口和出口流量. 虚拟服务和目标规则的概念使其在流量管理方面非常完善.

However, 所有这些可能性都伴随着学习曲线, 以及Kubernetes集群上那些新资源的管理.

Security

Istio 拥有一套全面的安全相关工具, 主要有两个轴:身份验证和授权. Istio可以在不同的范围内执行不同级别的策略:特定于工作负载, namespacewide, or meshwide. 所有这些安全资源都通过Istio crd进行管理，例如 AuthorizationPolicy or PeerAuthentication.

超出了标准的mTLS支持, Istio还可以配置为接受或拒绝未加密的流量.

Observability

Here, Istio是非常先进的开箱即用, 有几种类型的遥测技术提供了对服务网格的可靠见解. 指标基于四个黄金信号(延迟), traffic, errors, and, to some extent, saturation).

值得注意的是，Istio为控制平面本身提供了度量. 它还提供分布式跟踪和访问日志, 吹嘘与积家的明确兼容性, Lightstep, 和Zipkin来实现跟踪.

没有原生的仪表板，但是有对Kiali管理控制台的官方支持.

Installation

安装过程如下所示 官方步骤. Istio也作为beta特性集成到GKE中，但是GKE使用的是Istio 1.4.X，旧的微服务版本，而不是最新的单体版本.

原生安装从下载最新版本开始:

curl -L http://istio.. io/downloadIstio | sh -

After cd进入新创造的世界 istio-* 文件夹中，您可以将其添加到您的路径中，以便使用 istioctl utility tool:

导出路径= $ PWD / bin: $路径

从这里，您可以通过以下方式将Istio安装到Kubernetes集群 istioctl:

istioctl安装

这将安装Istio default profile. istioctl 配置文件允许您创建不同的安装配置，并在必要时在它们之间切换. 但即使在单一侧面的情况下，你也可以 深度定制 通过修改一些cd来安装Istio.

Istio资源将更难管理，因为您将需要管理几种crdVirtualService, DestinationRule, and Gateway 至少是为了确保交通管理到位.

• A VirtualService 资源是声明服务和应用于请求的不同路由规则的配置.
• A DestinationRule 资源用于对特定目标的流量策略进行分组和实施.
• A Gateway 创建资源来管理入站和出站服务网格流量(即.e.，额外的特使代理，但在边缘运行，而不是作为侧车.)

The semantic details 是否超出了本综述的范围, 但是让我们看一个快速的例子，展示它们一起工作. 假设我们有一个电子商务网站，其服务名为 products. Our VirtualService 可能是这样的:

apiVersion:网络.istio.io/v1alpha3
: VirtualService
metadata:
  名称:products-route
  名称:电子商务
spec:
  hosts:
  -产品#解释为产品.ecommerce.svc.cluster.local
  http:
  - match:
    - uri:
        前缀:“/ listv1”
    - uri:
        前缀:目录“/”
    rewrite:
      uri:“/ listproducts”
    route:
    - destination:
        主持人:产品#诠释为产品.ecommerce.svc.cluster.local
        subset: v2
  - route:
    - destination:
        主持人:产品#解释为产品.ecommerce.svc.cluster.local
        subset: v1

相应的 DestinationRule could then be:

apiVersion:网络.istio.io/v1alpha3
: DestinationRule
metadata:
  name: products
spec:
  host: products
  trafficPolicy:
    loadBalancer:
      simple: random#或LEAST_CONN或ROUND_ROBIN
  subsets:
  - name: v1
    labels:
      version: v1
  - name: v2
    labels:
      version: v2
  - name: v3
    labels:
      version: v3

Lastly, our Gateway:

apiVersion:网络.istio.io/v1alpha3
kind: Gateway
metadata:
  名称:cert-manager-gateway
  名称空间:istio-system
spec:
  selector:
    istio: ingressgateway
  servers:
  - port:
      number: 80
      name: http
      protocol: HTTP
    hosts:
    - "*"

有了这三个文件，Istio安装就可以处理基本流量了.

Istio服务网格摘要

Advantages:

• 在不同的服务网格中, Istio是在撰写本文时拥有最大在线社区的一个. 其结果是其主要竞争对手的10倍以上, it’s the most talked-about service mesh on the web; its GitHub contributors are likewise an order of magnitude beyond those of Linkerd.
• Istio supports both Kubernetes and VM modes; the latter is in beta as of version 1.9.

Drawbacks:

• Istio不是自由的，从两个方面来说:
  • 就阅读文档所需的时间而言，它的要求很高, set it up, 让它正常工作, and maintain it. 取决于基础设施的大小和服务的数量, Istio将需要几周到几个月的全职工作才能完全发挥功能并集成到生产中.
  • 它还增加了大量的资源开销:每1个Envoy容器将占用350个cpu (mCPU),每秒000个请求(RPS). 甚至控制平面本身也会消耗资源. (以前，资源使用很难预测，但经过一些努力， istiod 已经稳定下来 1 vCPU and 1.5 GB of memory.)
• 它没有本地管理仪表板，不像linkard.
• Istio需要使用自己的入口网关.
• Istio控制平面仅在Kubernetes容器(例如.e.，没有VM模式，不像Istio的数据平面).

Istio是科技巨头联合起来创建一个开源项目来解决他们共同面临的挑战的一个很好的例子. Istio项目作为一个整体花了一些时间来构建自身(回想起从微服务到单体架构的转变)，并解决了许多最初的问题. Today, Istio完全做到了人们期望从服务网格中得到的一切，并且可以得到极大的扩展. 但所有这些可能性都对知识有很高的要求, work hours, 以及支持其在生产环境中使用的计算资源.

Kuma快速回顾

由Kong创造，然后开源，Kuma达到了1.0 in late 2020. To some extent, 它是为了应对第一个服务网格相当重且难以操作而创建的.

Its feature list suggests it to be very modular; the idea behind Kuma is to orient it toward integration with applications already running on Kubernetes or other infrastructure.

• In the area of 交通管理， Kuma提供常见的服务网格功能，如故障注入和断路器.
• 超越服务间mTLS加密, 数据平面和控制平面之间的交换在熊城通过a保护 数据平面代理令牌.
• Observability 在Kuma通过不同的流量策略来定义度量、跟踪和记录.
• 服务发现 由于Kuma自己的DNS解析器运行在控制平面的5653端口上，因此可以通过Kuma访问.
• 隈研吾非常强调 multimesh功能:您可以轻松地将多个Kubernetes集群或VM环境组合成具有多区域部署类型的常见Kuma集群.
• Kuma easily 与香港门户集成 香港现有用户.

Kuma的通用(非kubernetes)版本需要PostgreSQL作为依赖项，而Kong的 CTO 强烈反对支持重度精神分裂症. 但是Kuma从一开始就是基于多云和多集群部署的理念开发的, 它的仪表盘反映了这一点.

虽然Kuma在服务网格领域还很年轻, 到目前为止，很少有生产使用的情况, 这是一个有趣而有前途的竞争者.

Traefik网格快速审查

原名Maesh, Traefik Mesh(由Traefik Labs开发)是服务网格工具竞赛中的另一个新成员. The project mission is to democratize the service mesh by making it easy to use and configure; the developers’ experience with the well-thought-out Traefik Proxy put them in a prime position to accomplish that.

• 交通管理 Traefik Mesh的功能包括断路和限速.
• In terms of observability, Traefik Mesh具有原生OpenTracing支持和开箱即用的度量(标准安装自动包含Prometheus和Grafana)。, 节省了设置时间.
• For security除了mtl之外，这些规范是smi兼容的，并且Traefik Mesh允许通过访问控制对流量权限进行微调.

Traefik Mesh需要在集群上安装CoreDNS. (虽然Azure从1月1日起默认使用CoreDNS.12, 在撰写本文时，GKE默认为kube-dns, 这意味着在这个案子中有一个重要的额外步骤.)它还缺乏多集群功能.

That said, Traefik Mesh在我们的服务网格比较中是独一无二的，因为它不使用侧车注入. Instead, 它作为守护进程部署在所有节点上，充当服务之间的代理, 使其非侵入性. 总体而言，Traefik Mesh易于安装和使用.

AWS应用程序网格快速审查

In the world of cloud providers, AWS是第一个实现可插入Kubernetes(特别是EKS)和其他服务的本地服务网格的公司. AWS App Mesh于2018年11月发布，自那以后AWS一直在对其进行迭代. The main advantage of AWS App Mesh is the preexisting AWS ecosystem and market position; the big community behind AWS overall will continue to drive its usage and usability.

• 交通管理 在AWS应用程序中，Mesh在常见功能之上包括断路功能.
• 由于AWS App Mesh是由AWS托管的，所以它是一个 全托管服务，这意味着不必担心资源使用或控制平面可用性.
• Observability 可以通过Prometheus或AWS X-Ray完成.

该项目不是开源的, 不支持SMI, 网上也没有太多关于控制平面的HA标准的信息. AWS应用程序网格更多 复杂的设置 比其他kubernetes原生服务网格要多，并且在线社区很少(Stack Overflow上有24个答案), 在GitHub上有400颗星)，但这是因为用户应该从AWS的支持中受益.

AWS App Mesh与AWS有原生集成, 从EKS开始，扩展到其他AWS服务，如ECS (Fargate)和EC2. 与Traefik Mesh不同，它支持多集群. 此外，像大多数服务网格一样，它基于注入Envoy，这是一个经过实战考验的侧车代理.

Kubernetes服务网格比较表

这里给出的六个Kubernetes服务网格选项有一些共同点:

• 协议支持它们都适用于HTTP、HTTP/2、gRPC、TCP和WebSockets.
• They all have basic security 默认情况下以代理之间的mTLS的形式.
• 通过设计，服务网格提供某种形式的 load balancing.
• 这六个，至少，还包括一个 请求重试 选项中的流量管理功能.
• Lastly, 服务发现 是任何服务网格的核心特性吗.

但是，当涉及到服务网格基础设施时，确实存在值得强调的差异, 交通管理, observability, deployment, 以及其他方面.

Infrastructure

交通管理

Observability

* OpenCensus和OpenTracing于2019年合并为OpenTelemetry, 但你可能会发现链接上的文章提到了OpenCensus, 以及Istio和Traefik关于OpenTracing的文章.

Deployment

其他服务网格考虑事项

我们应该使用Kubernetes服务网格吗?

现在我们已经了解了什么是服务网格, how they work, 以及它们之间的众多差异, 我们可以问:我们需要一个服务网格吗?

这是过去几年sre和云工程师面临的一个大问题. Indeed, 微服务给网络通信带来了运营上的挑战，而服务网格可以解决这些挑战. 但服务网，在很大程度上，带来了他们的 own 在安装和操作方面的挑战.

我们可以在许多项目中看到出现的一个问题是服务网格, 在概念验证阶段和生产阶段之间存在差距. That is, it’s unfortunately rare for companies to achieve staging environments that are identical to production in every aspect; with service meshes involving crucial infrastructure, 规模和边缘相关的效果可以带来部署惊喜.

服务网格仍在大量开发和改进中. 这实际上对具有高部署速度的团队很有吸引力，这些团队已经掌握了“保持最先进的艺术”，并且可以密切关注云原生工具的开发周期.

然而，对其他人来说，服务网格的发展速度可能更像是一个陷阱. 建立一个服务网格是很容易的，但却忘记了维护它的需要. 安全补丁可能无法应用，或者, 即使记得, 可能以已弃用的特性或一组已修改的依赖项的形式携带计划外的问题.

在生产环境中建立服务网格的人力成本也很高. 对于任何团队来说，评估这一点并了解服务网格的好处是否会超过初始设置时间都是一个明智的目标. 不管“简单”的演示安装显示了什么，服务网格都是困难的.

In short, 服务网格可以解决大规模部署项目的一些典型问题，但也可能引入其他问题, 所以要准备好投入时间和精力. 在一个包含25个微服务和每秒5个查询负载的假设基础设施中, 我建议至少有一个人(最好是两个)花至少一个月的时间来准备概念验证和验证关键方面，然后再考虑在生产环境中运行它. 一旦设置好了, 预测频繁升级的需求——它们将影响基础设施的核心组件, 即网络通信.

Kubernetes服务网格:可扩展应用架构的(复杂)演变

我们已经看到了什么是服务网格:一套工具来应对新挑战 microservices architecture. 透过交通管理, observability, 服务发现, 增强了安全性, 服务网格可以揭示对应用程序基础架构的深刻见解.

市场上有多个参与者，有时由GAFAM等人推动.在某些情况下，它们已经开源或推广了自己的内部工具. 尽管有两种不同的实现类型, 服务网格将始终具有一个控制平面(系统的大脑)和一个数据平面, 由将拦截应用程序请求的代理组成.

回顾三个最大的服务网格(链接), Consul Connect, 和Istio)，我们已经看到了他们选择实施的不同战略以及它们带来的优势. Linkerd, 是市场上最老的服务网, 受益于其创造者在Twitter的经验. HashiCorp, for its part, 提供企业级的Consul Connect, 拥有高水平的专业知识和支持. Istio, 它最初在网上引起了广泛关注, 已经发展成为一个成熟的项目了吗, 最终交付一个功能齐全的平台.

但这些演员远不是唯一的, 一些较少被提及的服务网络也出现了:Kuma, Traefik Mesh, 和AWS应用程序网格, among others. Kuma, from Kong, 是为了使服务网格“简单”并可插入到任何系统中而创建的, not just Kubernetes. Traefik Mesh受益于已有的Traefik Proxy的经验，并做出了罕见的决定，避免了sidecar Proxy. 最后但同样重要的。, AWS决定开发自己版本的服务网格, 而是依赖可靠的特使挎斗代理.

在实践中，服务网格仍然很难实现. 尽管服务网格的好处是引人注目的, their impact, critically, 双向切割:服务网格的失败可能导致你的微服务无法相互通信, 可能会毁掉你的全部筹码. 一个臭名昭著的例子是:Linkerd版本和Kubernetes版本之间的不兼容 完全的生产中断 Monzo是一家网上银行.

尽管如此，整个行业都在围绕Kubernetes和像 Microsoft-spearheaded SMI, Kubernetes上服务网格的标准接口. 在众多其他项目中，云原生计算基金会(CNCF)拥有基于envoy的项目 开放服务网格 (OSM)倡议，这也是 最初引入 by Microsoft. 服务网格生态系统仍在热议, 我预测未来几年将会出现一个冠军, 就像Kubernetes成为事实上的容器编排工具一样. 目前，本文应该可以帮助您根据自己的需求选择最佳的服务网格.