服务网格平台探索性指南

向微服务的转变面临着一系列挑战。若是认为微服务的架构，设计和开发很复杂，那么部署和管理它们也一样复杂。

开发人员须要确保跨服务的通讯是安全的。他们还须要实施分布式跟踪，以告知每次调用须要多长时间。重试，断路器等分布式服务的一些最佳实践为服务带来了弹性。微服务一般是多语言的，并使用不一样的库和SDK。编写通用的可重用软件来管理跨HTTP，gRPC和GraphQL等不一样协议的服务内通讯很是复杂，昂贵且耗时。

部署基于微服务的应用程序后，上线以后的运维将由DevOps团队执行。他们须要监视服务运行情况，延迟，日志，事件和跟踪。 DevOps团队还有望实施基于策略的路由，以配置蓝/绿部署，金丝雀版本和滚动升级。最后，须要将源自多个微服务的指标，事件，日志和警报进行汇总，并与现有的可观察性和监视技术栈集成。

服务网格是云原生和微服务世界中的一种新现象，它试图为开发人员和运营商解决这些问题。在容器编排以后，若是有一项技术引发了开发人员和操做员的注意，那么绝对是服务网格。云原生倡导者建议在生产环境中运行微服务时使用服务网格。

服务网格使开发人员无需构建特定于语言的SDK和工具来管理服务内通讯。对于运营商而言，服务网格可提供即用型流量策略，可观察性以及来自堆栈的洞察力。

服务网格的最好之处在于它是一种“零侵入”软件，不会强制更改代码或配置。经过利用sidecar的模式，服务网格将代理注入到每一个服务中，充当主机服务的代理。因为代理会拦截每一个入站和出站调用，所以它能够在调用堆栈中得到无与伦比的可见性。与服务相关联的每一个代理将从调用堆栈收集的遥测发送到集中式组件，该组件还充当控制平面。运营商配置流量策略时，会将其提交到控制平面，控制平面将该策略推送到代理中以影响流量。软件可靠性工程师（SRE）利用服务网格的可观察性来深刻了解应用程序。

服务网格与现有的API网关或Kubernetes入口控制器集成在一块儿。 API网关和入口处理南北流量时，服务网格负责东西向流量。

总而言之，服务网格是实现安全的服务到服务通讯的基础结构层。它依赖于与每一个微服务一块儿部署的轻量级网络代理。集中式控制平面协调代理以管理流量策略，安全性和可观察性。

即便服务网格主要与打包为容器的微服务一块儿使用，它也能够与VM甚至物理服务器集成。经过有效利用服务网格的流量策略，能够无缝集成跨多个环境运行的应用程序。这个因素使服务网格成为混合云和多云的关键推进因素之一。

有多种服务网格可供企业选择。本文试图帮助比较和对比云原生生态系统中可用的一些主流服务网格平台。

AWS App Mesh

AWS App Mesh在AWS re：Invent 2018上推出，旨在将服务网格的优点带到Amazon Web Services的计算和容器服务中。可使用Amazon EC2，Amazon ECS，AWS Fargate，Amazon EKS甚至AWS Outposts轻松配置它。

因为App Mesh能够充当VM和容器的服务网格，所以Amazon基于虚拟服务，虚拟节点，虚拟路由器和虚拟路由建立了一个抽象层。

虚拟服务表明部署在VM或容器中的实际服务。虚拟服务的每一个版本都映射到一个虚拟节点。虚拟服务和虚拟节点之间存在一对多关系。部署新版本的微服务后，只需将其配置为虚拟节点便可。相似于网络路由器，虚拟路由器充当虚拟节点的端点。虚拟路由器具备一条或多条遵循流量策略和重试策略的虚拟路由。网格对象充当全部相关实体和服务的逻辑边界。

代理与参与网格的每一个服务相关联，该代理处理网格内流动的全部流量。

假设咱们在AWS中运行两项服务：servicea.apps.local和serviceb.apps.local。

咱们能够轻松地启用这些服务的网格，而无需修改代码。

咱们注意到，serviceb.apps.local具备虚拟服务，一个虚拟节点，一个具备两个虚拟路由的虚拟路由器，这些虚拟路由决定了发送到微服务的v1和v2的流量的百分比。

与大多数服务网格平台同样，AWS App Mesh也依赖于开源Envoy代理数据平面。 App Mesh控制平面在构建时考虑了AWS计算服务。亚马逊还定制了Envoy代理以支持此控制平面。

将AWS App Mesh与Amazon EKS结合使用时，您将得到自动sidecar注入的好处以及在YAML中定义App Mesh实体的能力。亚马逊为EKS构建了CRD，以简化带有标准Kubernetes对象的App Mesh的配置。

AWS App Mesh生成的遥测能够与Amazon CloudWatch集成。指标能够导出到第三方服务（例如Splunk，Prometheus和Grafana）以及开放式跟踪解决方案（例如Zipkin和LightStep）。

对于使用AWS计算服务的客户，AWS App Mesh是免费的。 AWS App Mesh不收取任何额外费用。

Consul Connect

HashiCorp的Consul做为具备内置键/值数据库的服务发现平台而启动。它充当在同一主机或分布式环境中运行的服务的高效，轻量级负载均衡器。Consul公开用于发现注册服务的DNS查询接口。它还对全部注册的服务执行健康检查。

在容器和Kubernetes成为主流以前就已经建立了Consul。可是微服务和服务网格的兴起促使HashiCorp将Consul扩展为功能完善的服务网格平台。服务网格扩展Consul Connect使用相互传输层安全性（TLS）提供服务到服务的链接受权和加密。

有关实施Consul的详细说明和分步指南，请参阅个人Consul Service Discovery和Consult Connect教程。

因为sidecar模式是服务网格的首选方法，所以Consul Connect带有本身的代理来处理入站和出站服务链接。基于插件体系结构，Envoy能够用做Consul Connect的替代代理。

Consul Connect向Consul添加了两个基本功能-安全性和可观察性。

默认状况下，Consul将TLS证书添加到服务端点以实现相互TLS（mTLS）。这样能够确保始终对服务之间的通讯进行加密。安全策略是经过intentions实现的，这些intentions定义了服务的访问控制并用于控制哪些服务能够创建链接。intentions能够拒绝或容许来自特定服务的流量。例如，数据库服务能够拒绝直接来自Web服务的入站流量，但容许经过业务逻辑服务发出的请求。

当Envoy用做Consul Connect的代理时，它将利用L7的可观察性功能。能够将与Consul Connect集成的Envoy配置为将遥测发送到各类来源，包括statsd，dogstatsd和Prometheus。

根据上下文，Consul能够充当客户端（代理）或服务器，当与Nomad和Kubernetes等编排器集成时，它支持Sidecar注入。有一张Helm chart能够在Kubernetes中部署Consul Connect。 Consul Connect配置和元数据做为注释添加到提交给Kubernetes的pod规范中。它能够与Ambassador集成，后者是Datawire的入口控制器，用于处理南北向流量。

Consul缺少用于实施蓝/绿部署或Canary版本的高级流量路由和拆分功能。与其余服务网格选择相比，它的安全流量策略不是很灵活。经过Envoy的集成，能够配置一些高级路由策略。可是，Consul Connect没有为此提供接口。

整体而言，Consul和Consul Connect是健壮的服务发现和网格平台，易于管理。

Istio

Istio是由Google，IBM和Red Hat支持的最受欢迎的开源服务网格平台之一。

Istio仍是最先使用Envoy做为代理的服务网格技术之一。它遵循与微服务关联的集中式控制平面和分布式数据平面的标准方法。

尽管Istio能够与虚拟机一块儿使用，可是它主要与Kubernetes集成。能够将部署在特定名称空间中的Pod配置为具备自动sidecar注入功能，其中Istio会将数据平面组件附加到Pod。

Istio为微服务开发人员和运营商提供了四种主要功能：

• 流量管理：Istio简化了诸如断路器，超时和重试之类的服务级别属性的配置，并使其易于实现基于百分比的流量拆分的配置，如A/B测试，canary部署和分段式部署。它还提供了开箱即用的故障恢复功能，有助于使您的应用程序更强大，以防止相关服务或网络的故障。 Istio带有本身的Ingress，可处理南北向流量。
• 扩展性：WebAssembly 是一种沙盒技术，能够用于扩展 Istio 代理（Envoy）的能力。Proxy-Wasm 沙盒 API 取代了 Mixer 做为 Istio 主要的扩展机制。在 Istio 1.6 中将会为 Proxy-Wasm 插件提供一种统一的配置 API。
• 安全：Istio为服务内通讯提供了开箱即用的安全功能。它提供了基础安全通讯通道，并大规模管理服务通讯的身份验证，受权和加密。借助Istio，默认状况下就能够保护服务通讯，从而使开发人员和操做员能够在各类协议和运行时之间一致地执行策略，而无需更改代码或配置。
• 可观察性：因为Istio的数据平面拦截了入站和出站流量，所以能够了解当前的部署状态。 Istio提供了强大的跟踪，监视和日志记录功能，可深刻了解服务网格部署。 Istio带有集成的和预先配置的Prometheus和Grafana仪表板，以提升可观察性。

Google和IBM将托管的Istio做为其托管Kubernetes平台的一部分提供。 Google将Knative构建为基于Istio的无服务器计算环境。对于Anthos和Cloud Run等Google服务，Istio已成为其核心基础。与其余产品相比，Istio被认为是一个复杂而繁重的服务网格平台。可是可扩展性和丰富的功能使其成为企业的首选平台。

Kuma

Kuma于2019年9月启动，是服务网格生态系统的最新参与者之一。它是由API网关公司Kong，Inc开发和维护的，该公司以相同的名称Kong来构建开源和商业产品。

Kuma是对Kong API网关的逻辑扩展。前者处理南北流量，然后者处理东西向流量。

像大多数服务网格平台同样，Kuma带有单独的数据平面和控制平面组件。控制平面是服务网格的核心支持者，它支持全部服务配置的基本原理，而且能够无限扩展以管理整个组织中的成千上万的服务。 Kuma将快速数据平面与高级控制平面相结合，容许用户经过Kubernetes或REST API中的自定义资源定义（CRD）轻松设置权限，公开指标并设置路由策略。

Kuma的数据平面与Envoy代理紧密集成，使数据平面能够在Kubernetes中部署的虚拟机或容器中运行。 Kuma有两种部署模式：

1）通用
2）Kubernetes。

在Kubernetes中运行时，Kuma利用API服务器和etcd数据库存储配置。在通用模式下，它须要外部PostgreSQL做为数据存储。

控制平面组件Kuma-cp管理一个或多个数据平面组件kuma-dp。在网格上注册的每一个微服务都运行kuma-dp的惟一副本。在Kubernetes中，kuma-cp在kuma系统名称空间内做为CRD运行。为kuma注释的名称空间能够将数据平面注入每一个pod中。

Kuma附带了一个GUI，可提供部署概述，包括向控制平面注册的每一个数据平面的状态。可使用相同的界面查看来自附加到微服务的代理的运行情况检查，流量策略，路由和跟踪。

Kuma服务网格具备内置的CA，用于基于mTLS加密流量。能够基于与微服务关联的标签来配置流量许可。跟踪能够与Zipkin集成，而指标能够重定向到Prometheus。

Kuma缺乏一些先进的弹性功能，例如断路，重试，故障注入和延迟注入。

Kuma是精心设计的干净的服务网格实现。它与Kong Gateway的集成可能会推进其在现有用户和客户中的采用。

Linkerd 2.x

Linkerd 2.x是Buoyant专为Kubernetes构建的开源服务网格。它得到了Apache V2的许可，而且是一个Cloud Native Computing Foundation孵化项目。

Linkerd是一个超轻便，易于安装的服务网格平台。它具备三个组件– 1）CLI和UI，2）控制平面和3）数据平面。

一旦将CLI安装在能够与Kubernetes群集通讯的计算机上，就可使用单个命令安装控制平面。控制平面的全部组件都做为Kubernetes部署安装在linkerd名称空间中。 Web和CLI工具使用控制器的API服务器。目标组件将路由信息告知运行数据平面的代理。注入器是Kubernetes准入控制器，每次建立Pod时都会接收Webhook请求。该服务用于将代理做为sidecar注入到命名空间中启动的每一个pod。身份组件负责管理对实现代理之间的mTLS链接相当重要的证书。点击组件从CLI和Web UI接收请求，以实时监视请求和响应。

Linkerd随附了预配置的Prometheus和Grafana组件，提供了现成的仪表板。

数据平面具备轻量级代理，可将其做为辅助工具附加到服务。有一个Kubernetes初始化容器来配置iptables来定义流量，并将代理链接到控制平面。

Linkerd符合服务网格的全部属性-流量路由/拆分，安全性和可观察性。

有趣的是，Linkerd并未使用Envoy做为代理。相反，它依赖于用Rust编程语言编写的专用轻量级代理。 Linkerd的堆栈中没有内置入口，但能够与入口控制器配合使用。

在Istio以后，Linkerd是流行的服务网格平台之一。考虑到轻量级且易于使用的服务网格，它吸引了开发人员和运营商的注意力。

Maesh

Maesh来自于Containous，该公司创建了流行的 ingress Traefik。与Kong，Inc相似，Containous创建了Maesh以补充Traefik。当Maesh处理微服务中的东西向流量时，Traefik则驱动着南北向流量。与Kuma同样，Maesh也能够与其余入口控制器一块儿使用。

与其余服务网格平台相比，Maesh采用了不一样的方法。它不使用边车模式来操纵流量。相反，它为每一个Kubernetes节点部署了一个Pod，以提供定义良好的服务端点。即便部署了Maesh，微服务也能够继续工做。可是，当他们使用Maesh公开的替代终结点时，他们能够利用服务网格功能。

Maesh的目标是提供一种非侵入性和非侵入性的基础架构，为开发人员提供选择功能。但这也意味着该平台缺乏某些关键功能，例如透明TLS加密。

Maesh支持服务网格的基本功能，包括路由和可观察性（安全性除外）。它支持Service Mesh Interface（SMI）项目定义的最新规范。

在我在Kubernetes中部署的全部服务网格技术中，我发现Maesh是最简单，最快的平台。