Service Mesh发展历程

一、服务网格从何而来？

服务网格模型的起源可以追溯到过去几十年服务器端应用程序的演变。

考虑 2000 年代中型 Web 应用程序的典型“三层”架构。在此模型中，应用程序逻辑、Web 服务逻辑和存储逻辑都是独立的层。层之间的通信虽然复杂，但范围有限——毕竟只有两跳。

当这种架构方法被推到非常高的规模时，它开始崩溃。谷歌、Netflix 和 Twitter 等公司面临着巨大的流量需求，实施了实际上是云原生方法的前身：应用层被拆分为微服务，层成为拓扑。这些系统通过采用通用通信层解决了这种复杂性。

二、什么是 Service Mesh？

Service Mesh 是微服务时代的 TCP/IP 协议。

根据维基百科的定义：

微服务 (Microservices) 是一种软件架构风格，它是以专注于单一责任与功能的小型功能区块 (Small Building Blocks) 为基础，利用模块化的方式组合出复杂的大型应用程序，各功能区块使用与*语言无关* (Language-Independent/Language agnostic) 的 API 集相互通信。

三、微服务和Service Mesh技术的发展历程

Pattern: Service Mesh，详细的介绍了从开发者视角来看，服务开发模式和Service Mesh技术的演化过程，个人认为是非常经典的学习Service Mesh的资料。

自从几十年前首次引入分布式系统以来，我们了解到分布式系统支持我们之前甚至无法想到的用例，但它们也引入了各种新问题。

当这些系统很少见且简单时，工程师通过最大限度地减少远程交互的数量来处理增加的复杂性。处理分发的最安全方法是尽可能避免分发，即使这意味着在不同系统之间重复逻辑和数据。

但我们作为一个行业的需求将我们推得更远，从几台大型中央计算机到成百上千的小型服务。在这个新世界中，我们必须开始摆脱困境并应对新的挑战和未解决的问题，首先以个案方式完成临时解决方案，然后采用更复杂的方法。随着我们更多地了解问题领域并设计出更好的解决方案，我们开始将一些最常见的需求具体化为模式、库以及最终的平台。

服务架构发展历程

第一时代：

首先考虑让两台或多台计算机相互通信，设想如下：

一项服务与另一项服务对话以实现最终用户的某个目标。这是一个明显过于简化的视图，因为在代码操作的字节和通过电线发送和接收的电信号之间转换的许多层都丢失了。不过，抽象对于我们的讨论来说已经足够了。让我们通过将网络堆栈显示为一个不同的组件来添加更多细节：

第二时代：原始通信时代

上述模型的变体自 1950 年代以来一直在使用。起初，计算机稀有且昂贵，因此两个节点之间的每条链路都经过精心设计和维护。随着计算机变得越来越便宜和流行，连接的数量和通过它们的数据量急剧增加。随着人们越来越依赖网络系统，工程师需要确保他们构建的软件达到用户所需的服务质量。

为了达到预期的质量水平，需要回答许多问题。人们需要找到让机器找到彼此的方法，在同一条线上处理多个同时连接，允许机器在不直接连接时相互通信，跨网络路由数据包，加密流量等。

其中，有一种叫做流控制的东西，我们将使用它作为示例。流量控制是一种机制，可防止一个服务器发送的数据包超出下游服务器的处理能力。这是必要的，因为在网络系统中，您至少有两台不同的、独立的计算机，它们彼此之间不太了解。计算机 A以给定的速率向计算机 B发送字节，但不能保证B将以一致且足够快的速度处理接收到的字节。例如，B可能正忙于并行运行其他任务，或者数据包可能乱序到达，而B被阻塞等待应该首先到达的数据包。这意味着不仅A不会获得B的预期性能，而且还可能使事情变得更糟，因为它可能会使B过载，现在必须将所有这些传入数据包排队等待处理。

有一段时间，人们期望构建网络服务和应用程序的人能够应对上面在他们编写的代码中提出的挑战。在我们的流控制示例中，这意味着应用程序本身必须包含逻辑，以确保我们不会因数据包而使服务过载。这种网络密集型逻辑与您的业务逻辑并列。在我们的抽象图中，它会是这样的：

第三时代：TCP时代

幸运的是，技术迅速发展，很快像 TCP/IP 这样的标准将流量控制和许多其他问题的解决方案纳入网络堆栈本身。这意味着那段代码仍然存在，但它已从您的应用程序中提取到您的操作系统提供的底层网络层：

这种模式取得了巨大的成功。即使在需要高性能和可靠性的情况下，很少有组织不能仅使用商用操作系统附带的 TCP/IP 堆栈来推动其业务发展。

第四时代：第一代微服务

尽管几十年前开发的 TCP/IP 堆栈和通用网络模型仍然是使计算机相互通信的强大工具，但更复杂的体系结构引入了另一层要求，这时，分布式系统特有的通信语义出现了，如熔断策略、负载均衡、服务发现、认证和授权、quota限制、trace和监控等等，于是服务根据业务需求来实现一部分所需的通信语义。

第五时代：第二代微服务

为了避免每个服务都重写一套相同的分布式系统通信的语义功能，随着技术的发展，一些面向微服务架构的开发框架出现了，如以至于Twitter 的 Finagle和Facebook 的 Proxygen以及Spring Cloud等大型复杂库变得非常流行，这些框架实现了分布式系统通信需要的各种通用语义功能：如负载均衡和服务发现等，因此一定程度上屏蔽了这些通信细节，使得开发人员使用较少的框架代码就能开发出健壮的分布式系统。

大多数开创微服务架构的组织都遵循上述模型，例如 Netflix、Twitter 和 SoundCloud。随着系统中服务数量的增长，开发人员也发现了一些本质问题。

其一，开发团队要花更多精力去掌握和管理复杂的框架本身（需要将 1/10 的员工专门用于构建工具）；
其二，开发框架限制了特定的工具、运行时和语言，没支持的平台外，要额外花时间去将代码移植到新平台，，无法专注业务本身逻辑。
其三，框架以lib库的形式和服务联编，框架库的升级也无法对服务透明，服务会因为和业务无关的lib库升级而被迫升级；

下一个合乎逻辑的步骤

与我们在网络堆栈中看到的类似，非常希望将大规模分布式服务所需的特性提取到底层平台中。

将这个想法结合到我们的图表中，我们最终可以得到如下所示的内容：

第六时代：第一代Service Mesh

不幸的是，更改网络堆栈以添加这一层并不是一项可行的任务。许多从业者找到的解决方案是将其实现为一组代理。这里的想法是，服务不会直接连接到其下游依赖项，而是所有流量都将通过一小块透明地添加所需功能的软件。

因此以Linkerd，Envoy，NGINX Service Mesh为代表的代理模式（边车模式）应运而生，这就是第一代Service Mesh，它将分布式服务的通信抽象为单独一层，在这一层中实现负载均衡、服务发现、认证授权、监控追踪、流量控制等分布式系统所需要的功能，作为一个和服务对等的代理服务，和服务部署在一起，接管服务的流量，通过代理之间的通信间接完成服务之间的通信请求，这样上边所说的三个问题也迎刃而解。

Linkerd使用了一系列强大的技术，例如双向 TLS (mTLS)、延迟感知负载平衡、重试、成功率检测、透明流量转移等。

Envoy 是一个为云原生应用设计的开源边缘与服务代理。它是为单一服务和应用程序设计的高性能 C++ 分布式代理，以及为大型微服务 Service Mesh 体系结构设计的通信总线和通用数据平面。

NGINX Service Mesh (NSM) 是一个高度集成的轻量级的服务网格的开发版本，它利用 NGINX Plus 支持的数据平面来管理 Kubernetes 环境中的容器流量。

服务网格

在这种模型中，您的每个服务都将有一个伴随代理 sidecar。鉴于服务之间仅通过 sidecar 代理进行通信，会得到类似于下图的部署：

从上图可以看到代理之间的互连形成了一个网状网络，可以称为Service Mesh。

服务网格是用于处理服务到服务通信的专用基础设施层。它负责通过构成现代云原生应用程序的服务的复杂拓扑来可靠地交付请求。在实践中，服务网格通常被实现为一组轻量级网络代理，这些代理与应用程序代码一起部署，而无需应用程序了解。

他的定义最有力的方面可能是它不再将代理视为孤立的组件，而是承认它们形成的网络本身就是有价值的东西。

第七时代：第二代Service Mesh

第一代Service Mesh由一系列独立运行的单机代理服务构成，为了提供统一的上层运维入口，演化出了集中式的控制面板，所有的单机代理组件通过和控制面板交互进行网络拓扑策略的更新和单机数据的汇报。这就是以Istio为代表的第二代Service Mesh。

我们看到实际的服务流量仍然直接从代理流向代理，但控制平面知道每个代理实例。控制平面使代理能够实现访问控制和指标收集等需要合作的东西：

至此，见证了7个时代的变迁，大家一定清楚了Service Mesh技术到底是什么，以及是如何一步步演化到今天这样一个形态。

现在，我们再回过头来看Buoyant的CEO William Morgan，也就是Service Mesh这个词的发明人，对Service Mesh的定义：

服务网格是一个基础设施层，用于处理服务间通信。云原生应用有着复杂的服务拓扑，服务网格保证请求在这些拓扑中可靠地穿梭。在实际应用当中，服务网格通常是由一系列轻量级的网络代理组成的，它们与应用程序部署在一起，但对应用程序透明。

这个定义中，有四个关键词：

基础设施层+请求在这些拓扑中可靠穿梭：这两个词加起来描述了Service Mesh的定位和功能，是不是似曾相识？没错，你一定想到了TCP；
网络代理：这描述了Service Mesh的实现形态；
对应用透明：这描述了Service Mesh的关键特点，正是由于这个特点，Service Mesh能够解决以Spring Cloud为代表的第二代微服务框架所面临的三个本质问题。

四、服务网格的未来是什么？

服务网格采用的疯狂步伐几乎没有放缓的迹象。与大多数成功的技术一样，服务网格的最终未来可能非常无聊：退居幕后，存在但被视为理所当然，实际上并没有得到太多关注。

因此，Service Mesh 令人兴奋的未来与其说是技术本身如何进步，不如说在于它解锁了什么。

五、结尾

服务网格通常实现为与应用程序代码一起部署的一组可扩展的网络代理（有时称为sidecar的模式）。这些代理处理微服务之间的通信，并充当可以引入服务网格功能的点。代理包括服务网格的数据平面，并由其控制平面作为一个整体进行控制。

服务网格的兴起与“云原生”应用的兴起息息相关。在云原生世界中，一个应用程序可能包含数百个服务；每个服务可能有数千个实例；并且这些实例中的每一个都可能处于不断变化的状态，因为它们是由像 Kubernetes 这样的编排器动态调度的。在这个世界中，服务到服务的通信不仅非常复杂，而且是应用程序运行时行为的基本部分。管理它对于确保端到端的性能、可靠性和安全性至关重要。

Service Mesh具有如下优点：

屏蔽分布式系统通信的复杂性(负载均衡、服务发现、认证授权、监控追踪、流量控制等等)，服务只用关注业务逻辑；
真正的语言无关，服务可以用任何语言编写，只需和Service Mesh通信即可；
对应用透明，Service Mesh组件可以单独升级；

当然，Service Mesh目前也面临一些挑战：

Service Mesh组件以代理模式计算并转发请求，一定程度上会降低通信系统性能，并增加系统资源开销；
Service Mesh组件接管了网络流量，因此服务的整体稳定性依赖于Service Mesh，同时额外引入的大量Service Mesh服务实例的运维和管理也是一个挑战；

历史总是惊人的相似。为了解决端到端的字节码通信问题，TCP协议诞生，让多机通信变得简单可靠；微服务时代，Service Mesh应运而生，屏蔽了分布式系统的诸多复杂性，让开发者可以回归业务，聚焦真正的价值。