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