网格简化
一个旗号在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网关位于一组微服务和“外部”世界之间，可根据需要路由服务请求，因此请求者无需知道它正在处理基于微服务的应用程序。 另一方面，服务网格在微服务应用程序内部“调解”请求，各个组件都充分了解其环境。
另一种方式去思考它， 贾斯汀·沃伦在福布斯写道 ，是一个服务网是东西向的交通集群内和API网关是南北交通要进出集群。 但是，服务网格的整体思想仍处于早期阶段，并且还在不断变化中。 现在，许多服务网格（包括Linkerd和Istio）也都提供了南北功能。
服务网格架构
服务网格的概念仅在最近几年才出现，并且有许多解决“服务网格”问题的方法，即管理微服务的通信。 Aspen Mesh的Andrew Jenkins 确定了关于服务网格创建的通信层可能位于何处的三个可能的选择 ：
- 在每个微服务导入的库中
- 在为特定节点上的所有容器提供服务的节点代理中
- 在与应用程序容器一起运行的sidecar容器中
基于边车的模式是目前最流行的服务网格模式之一，以至于在某种程度上它已成为服务网格的同义词。 虽然严格说来并非如此，但“边车”方法已经吸引了很多人，因此我们将更详细地讨论这种架构。
服务网格中的边车
说sidecar容器与您的应用程序容器“并排”是什么意思？ 红帽有一个很好的解释 。 这种类型的服务网格中的每个微服务容器都有一个与其对应的另一个代理容器。 服务到服务通信所需的所有逻辑都从微服务中提取出来，并放入了sidecar中。
这似乎很复杂-毕竟，您实际上是在将应用程序中的容器数量加倍！ 但是，您还将使用一种设计模式，这对简化分布式应用程序至关重要。 通过将所有网络和通信代码放入一个单独的容器中，您已将其作为基础结构的一部分，并使开发人员不必将其作为应用程序的一部分来实现。
本质上，您剩下的就是可以将微服务集中在其业务逻辑上的微服务。 微服务不需要知道如何在运行它们的疯狂环境中与所有其他服务通信。 它只需要知道如何与边车通信，剩下的就由他来完成。
服务网格：Linkerd，Envio，Istio，领事
那么可以使用哪些服务网格？ 嗯，那里没有现成的商业产品。 大多数服务网格都是开源项目，需要进行一些改进才能实现。 著名的是：
- Linkerd （发音为“ linker-dee”）—在2016年发布，因此是这些产品中最古老的产品，Linkerd从Twitter开发的图书馆中剥离出来。 这个领域的另一个沉重打击者Conduit被纳入Linkerd项目，并构成Linkerd 2.0的基础 。
- 特使 -Created在Lyft，特使占据一个服务网Kong的“数据平面”部分。 为了提供完整的服务网格，需要将其与“控制平面”配对，例如…
- Istio-由Lyft，IBM和Google合作开发的Istio是一项控制计划，旨在为Envoy等代理提供服务。 虽然Istio和Envoy是默认对，但是每个都可以与其他平台配对。
- HashiCorp Consul — Consul 1.2 引入的一项功能，称为Connect，为HashiCorp的分布式系统添加了服务加密和基于身份的授权，以进行服务发现和配置，从而将其转变为完整的服务网格。
哪种服务网格最适合您？ 进行比较超出了本文的范围，但是值得注意的是，以上所有产品均已在大型且苛刻的环境中得到证明。 Linkerd和Istio具有最广泛的功能集，但是它们都在快速发展。 您可能需要检查一下乔治·米兰达（George Miranda）对Linkerd，Envoy和Istio的功能的细分情况，但请记住，他的文章是在Conduit和Linkerd联合之前编写的。
还要记住，这个空间是新的，新的竞争对手可能随时出现。 例如，亚马逊于2018年11月开始提供AWS服务网格的公开预览。 考虑到有多少家商店使用亚马逊的公共云， AWS App Mesh应该会产生重大影响。
翻译自: https://www.infoworld.com/article/3402260/what-is-a-service-mesh-easier-container-networking.html
网格简化
