ServiceMesh为服务通信带来了安全性、弹性和可见性，因此开发人员不必这样做。数字化转型趋势下的IT变革之一，就是将大型单体应用分解为微服务。这些小的、离散的功能单元运行在容器中，它们的软件包包含了服务的所有代码，并且可以很容易地从一台服务器隔离到另一台服务器。像这样的容器化架构很容易在云端扩展和运行，并且可以快速部署和迭代单个微服务。然而，随着应用规模越来越大，同一个服务的多个实例并发运行，这些微服务之间的通信变得越来越复杂。服务网格是一种新兴的架构形式，旨在以减少管理和编程开销的方式动态连接这些微服务。什么是服务网格？从广义上讲，正如RedHat所描述的“服务网格”，“服务网格是一种控制应用程序的不同部分如何共享数据的方法”。但是这个描述可能包含很多不同的东西。事实上，它听起来很像大多数开发人员熟悉的客户端-服务器应用程序中间件。服务网格的独特之处在于它是为分布式微服务环境的独特性质而构建的。在由微服务构建的大型应用程序中，可能存在给定服务的多个实例，它们运行在不同的本地或云计算服务器上。显然，所有这些活动部件使得单个微服务很难找到它们需要与之通信的其他服务。服务网格自动处理服务的即时发现和连接，因此开发人员和微服务都不必这样做。将服务网格视为开放系统互连(OSI)网络模型的第7级软件定义网络(SDN)。正如软件定义网络(SDN)创建了一个抽象层，因此网络管理员不必处理物理网络连接，服务网格将应用程序的底层基础设施与企业交互的抽象架构分开。随着开发人员开始努力解决真正庞大的分布式架构的问题，服务网格的概念应运而生。Linkerd是该领域的第一个项目，作为Twitter内部项目的一个分支而诞生。Istio是另一个受到主要企业支持的流行服务网络，起源于Lyft。服务网格负载平衡服务网格提供的一个关键特性是负载平衡。人们通常将负载平衡视为一种网络功能，企业希望防止任何一台服务器或网络链路被流量淹没，以便他们的数据包可以相应地进行路由。正如TwainTaylor所描述的那样，了解服务网格在应用程序级别执行类似的操作，可以很好地理解服务网格在应用程序层如何类似于软件定义的网络。本质上，服务网格的一项工作是跟踪分布在基础设施中的各种微服务的哪些实例是“最健康的”。它可能会轮询以查看它们的运行情况，或跟踪哪些实例正在响应缓慢的服务请求，并将后续请求发送到其他实例。服务网格可以为网络路由做类似的工作，注意到消息需要很长时间才能到达目的地，并采用其他路由进行补偿。这些速度慢的原因可能是底层硬件的问题，或者仅仅是服务因请求而过载。重要的是，服务网格可以找到同一服务的另一个实例并将其路由到该实例，从而最有效地利用整个应用程序的容量。ServiceMesh与Kubernetes如果对基于容器的架构有一定的了解，可能会怀疑Kubernetes（流行的开源容器编排平台）是否符合要求。毕竟，Kubernetes的重点不就是管理容器之间的通信方式吗？正如Kublr公司在其公司博客上指出的那样，Kubernetes的服务资源可以被认为是一种非常基本的服务网格，因为它提供了服务发现和循环请求的平衡。但是功能齐全的服务网格提供了更多，例如管理安全策略和加密，“断线”以暂停对响应缓慢的实例的请求。人们需要了解的是，大多数服务网格确实需要像Kubernetes这样的编排系统。服务网格提供扩展功能，而不是替代品。服务网格与API网关每个微服务都将提供一个应用程序编程接口(API)作为其他服务与其通信的一种方式。这就提出了服务网格与其他更传统形式的API管理（例如API网关）之间的差异的问题。正如IBM所解释的那样，API网关位于一组微服务和外部世界之间，根据需要路由服务请求，这样请求者就不需要知道它正在处理基于微服务的应用程序。另一方面，服务网格在微服务应用程序内部调解请求，并要求用户充分了解他们的环境。另一种思考方式，正如JustinWarren指出的那样，服务网格用于集群内的东西向流量，API网关用于进出集群的南北向流量。但是服务网格的想法仍处于早期阶段并且在不断变化。许多服务网格（包括Linkerd和Istio）现在也提供南北流量能力。服务网格架构服务网格的概念是最近几年才出现的，解决“服务网格化”问题的方法有很多种，即管理微服务的通信。AspenMesh的AndrewJenkins确定了服务网格创建的通信层可能存在的三个可能选项：在每个微服务导入的库中。在为特定节点上的所有容器提供服务的节点代理中。在与应用程序容器一起运行的边车容器中。Sidecar是将应用程序组件部署到单独的进程或容器中以提供隔离和封装。基于sidecar的模式是最流行的服务网格模式之一，以至于在某些方面它通常是服务网格的同义词。虽然并不严格，但sidecar容器的方式已经引起了很多关注，这是一种需要人们仔细研究的架构。服务网格中的Sidecars什么是“与其应用程序容器一起运行的Sidecars容器”？RedHat对此有很好的解释。这种服务网格中的每个微服务容器都有一个对应的代理容器。服务到服务通信所需的所有逻辑都从微服务中抽象出来并放入边车中。这可能看起来很复杂，毕竟企业已经有效地将其应用程序中的容器数量增加了一倍。而且还使用了一种设计模式，这是简化分布式应用程序的关键。通过将所有网络和通信代码放在一个单独的容器中，它已经使它成为基础设施的一部分，并使开发人员无需将其作为应用程序的一部分来实现。本质上，剩下的就是可以专注于其业务逻辑的微服务。微服务不需要知道如何在复杂环境中与其他所有服务进行通信。它只需要知道如何与sidecars通信，剩下的由sidecars处理。服务网格：Linkerd、Envio、Istio、Consul那么有哪些服务网格可用呢？没有现成的商业产品。大多数服务网格都是需要一些最终实现的开源项目。一些比较知名的产品是：Linkerd-2016年发布，所以最早的产品Linkerd是从Twitter开发的一个库中分叉出来的。该领域的另一个主要产品Conduit已进入Linkerd项目，并构成了Linkerd2.0的基础。Envio-创建于Lyft，Envoy占据服务网格的“数据平台”部分。要提供完整的服务网格，它需要与“控制平面”配对。Istio-由Lyft、IBM和Google开发，Istio是针对服务代理（例如Envoy）的服务计划。虽然Istio和Envoy是默认配对，但每个都可以与其他平台配对。HashiCorpConsul-在Consul1.2中引入，这个名为Connect的特性为HashiCorp的分布式系统添加了服务加密和基于身份的授权，用于服务发现和配置，将其变成一个完整的服务网格。那么哪个服务网格更好呢？很难比较，但这些产品都已在大型和苛刻的环境中得到验证。Linkerd和Istio具有广泛的功能集，但两者都在迅速发展。还要记住，新的竞争者随时可能出现在市场上。例如，2018年11月，亚马逊开始提供AWSServiceMesh的公开预览。鉴于亚马逊公共云的广泛采用，AWSAppMesh的推出应该会产生重大影响。
