微服务作为现代组织事实上的软件架构风格的兴起以及云原生应用程序模型的快速采用为应用程序基础架构和应用程序管理带来了各种变化。

虽然我们在DevOpsCloud-NativeToolLandscape中简要谈到了这个主题，但本文将深入探讨细节。要了解服务器网格背后的原因，我们首先需要了解云原生模型。云原生应用程序通常包含数百个微服务，并且根据服务的大小，每个服务可能会进一步泄露到数千个实例中。

当您将启用编排的调度添加到组合中时，生成的微服务结构非常复杂，这使得服务间通信成为一个非常困难的过程。这就是服务网格的用武之地。

简而言之，服务网格是一个专用的基础设施层，添加它是为了确保构成应用程序的微服务之间的通信流程简化。作为低延迟运行的可配置基础设施层，服务网格旨在处理应用程序基础设施服务之间发生的越来越多的进程间通信。

随着云原生应用模型的兴起，开发者面临着越来越多的微服务的前景。这导致越来越需要使服务间通信尽可能快速和安全。在实际世界中，服务网格的实现是通过部署大量与应用程序代码一起工作的网络代理（标记为“边车”）来完成的。每个服务器实例都部署了一个sidecar。

应用程序是否知道此类代理的部署？原则上，应用程序不需要。根据部署情况，开发人员可能决定让应用程序了解此类网络代理。最近，组织越来越多地将服务网格作为云原生应用程序模型的重要组成部分。采用服务网格的知名组织包括PayPal、Ticketmaster和CreditKarma。甚至云原生计算基金会也接受了Linkerd——流行的开源服务网格——作为一个官方项目。这证明了服务网格在现代应用程序环境中越来越受欢迎。

关于服务网格是否是一种网络模型，人们提出了各种问题。虽然服务网格绝对是一种网络模型，但它在TCP/IP之上的抽象层中运行。此网络模型与预定义的假设一起工作，即底层L3/L4网络可运行并在各种服务间点之间传送字节。这种服务网格网络模型的另一个假设是当前网络仍然不可靠，这意味着网格应该具备网络故障能力。

与TCP/IP的相似之处

如上所述，服务网格位于TCP/IP层之上的抽象层，但它与通信协议共享各种特性。以下是一些相似之处：

这两种网络模型之间存在显着差异，允许服务模型在TCP/IP协议之上运行一层。虽然后一种模型旨在完成分配的任务，但服务网格在更广泛的范围内运行。

除了完成分配的目标外，服务网格还负责让开发人员增强对应用程序运行时的可见性和控制。虽然服务通信更像是一项独立运行的后端任务，但服务网格的集成可以更有效地对其进行监控和管理。

服务网格实际上是如何工作的？

对高级通信协议的需求源于现代应用程序的复杂性。服务网格的集成不仅简化了整个流程，还使整个团队的工作效率更高。与每个服务器实例相连的网络代理（边车）负责各种功能，否则这些功能将由每个微服务自行完成。这些功能包括服务间通信和监控任何与安全相关的活动。

这允许明确区分应用程序的管理方式，因为开发人员现在可以只关注应用程序代码管理，这涉及开发、支持和维护。另一方面，运维团队可以有效管理服务网格和应用运行服务。现代服务网格，例如开源Linkerd，通过利用各种先进技术来处理这些问题。

服务网格的任务是利用这些特性，并确保它们与它们运行的复杂环境协同工作。

有关服务网格如何工作的分步指南

为了详细说明服务网格的运行方式，我们将使用一个示例场景。对于此实例，我们将介绍服务网格(Linkerd)收到请求后发生的事件：

收到请求后，服务网格的任务是确定服务应指向何处。有各种各样的问题需要回答：

这种分层决策能力允许服务网格定位到正确的目的地。此外，所有这些路由协议都是可配置的，并且可以应用于两种类型的流量——全局流量和任意流量。

一旦找到所需微服务的确切目的地，服务网格必须检索与来自发现端点的请求中概述的详细信息相对应的服务器实例。如果检索到的数据与服务网格在实践中通常监控的数据相反，它将立即决定信任哪个信息源。

最终实例是根据他们的反应速度来选择的。服务网格如何衡量这一点？它监控观察到的最近请求的延迟，然后选择花费最少时间的实例。然后，服务网格将请求发送到实例，如果成功执行，则记录结果结果的延迟和响应类型。

有时，服务器实例可能会出现故障，从而阻碍请求的成功执行。这可能是由于某个实例发生故障、变得无响应或因维护而停机。在这种情况下，服务网格会在另一个实例上重试请求。这种做法的唯一问题是，如果请求是幂等的，服务网格只会用另一个实例重试。幂等请求导致相同的结果，无论它们在哪个服务实例中执行。

一旦请求成功执行，现代服务网格允许记录和观察关键指标。他们分析这种行为的每一个细节，并以度量和分布式跟踪的形式记录下来——然后传输到一个集中的度量系统。

那不是全部

还记得我告诉过你服务网格具有高级故障排除能力吗？如果一个服务器实例不断返回错误，那么服务网格不会简单地忽略该实例。服务网格将这样的服务器实例从整个负载均衡池中移除。这允许转换资源并提高效率。

这是另一个展示现代服务网格功效的示例。当一个请求由于截止日期而过去时，服务网格会识别此类请求并自动使请求失败。服务网格不会继续重试失败的请求并增加网络负载，而是确保资源的有效分配。除了其他功能外，服务网格还可以执行协议升级、动态切换流量以及在其他服务中启动和终止TLS。

使用服务网格作为抽象层有多种好处。这里是其中的一些：

提高标准化

随着现代应用程序继续分布在一个庞大的基础上，它们的功能行为也变得极其不稳定——这取决于底层支持网络。由于跨不同网络的这种不同行为，确保应用程序的全天候可用性可能成为一项严峻的挑战。使用服务网格，网格可以处理应用程序的旋转、折叠和分割。它使数据中心更加标准化和组织化。

增强可见性

高级服务网格分析请求行为以确定请求最多的组件，以便可以定位它们以便于访问。再加上它的问题排查能力，它对整个系统有一个全面的概览。如前所述，服务网格可以存储此数据以供进一步使用。开发人员可以使用这些数据来识别趋势和威胁，从而改进整个开发和构建过程。

高级安全

与单体软件架构相反，微服务软件由不同种类的服务组成。有些可能有很长的寿命，而另一些的生命周期很短。这使得唯一身份的分配和工作政策的执行变得越来越复杂。

相反，开发人员可以使用服务网格在所有实时实例和所有可操作的微服务上实施相关策略。由于它能够识别正在运行的微服务及其运行位置，因此它可以根据微服务的类型和行为应用策略。这不仅消除了为每个服务或实例分配唯一ID的需要，而且还允许开发人员无误地执行策略。

有多种服务网格工具可供开发人员使用。与云原生应用程序的其他方面不同，该领域可用的工具大多是开源项目。在服务网格方面，没有现成的商业工具。

发音为“linker-dee”，这是所有服务网格中最古老的，于2016年发布。它基本上是从Twitter开发的库设计的衍生项目开始的。还有另一个服务网格，Conduit，它获得了广泛的普及。它在2017年被整合到Linkerd程序中，并在Linked2.0的创建中发挥了重要作用。

Envoy是另一个服务网格，它的起源可以追溯到一个著名的组织。在这种情况下，它是Lyft。特使针对服务网格的“数据计划”部分。为了提供完整的功能，它需要与“控制平面”服务网格结合使用。

为了让像Envoy这样的“数据平面”服务网格平台正常工作，组织需要一个“控制平面”服务网格。这就是Istio应运而生的原因。作为IBM、谷歌和Lyft之间的协作成果——Istio和Envoy成对运行，在两个服务网格组件之间提供完整的平台内可行性。

HashiCorp顾问

HashiCorp本质上作为一个用于服务发现和配置的分布式系统运行。随着Consul1.2的发布，他们引入了一个名为Connect的功能，该功能允许服务加密和基于身份的授权。这将它变成了一个完整的服务网格产品。

随着开发人员继续应对管理微服务带来的复杂性，服务网格将继续在云原生应用程序生态系统中得到更多采用。随着利用服务网格的用户和开发人员社区蓬勃发展，全球各地的组织已经开始将服务网格集成到他们的软件架构设计中。随着计算的不断发展，服务网格在应用程序环境中的范围也将发生变化。