一文了解“Service Mesh（服务网格）”的历史与现在

对于大多数人来说，“Service Mesh（服务网格）”仍然是一个新概念，因此，谈论它的“历史”可能看起来有点滑稽。但事实上，早在 2010 年初，在一些大网络规模的公司中，服务网格的概念就隐约开始逐步形成了。因此，服务网格确实有一段历史值得去探索、去理解。

在深入历史脉络之前，让我们先聊聊“现在”。什么是服务网格？为什么它突然成为了云原生领域的热门话题？

服务网格是用于控制和监视微服务应用程序中的内部服务到服务流量的软件基础结构层。它通常采用与应用程序代码一起部署的网络代理的“数据平面”的形式，以及用于与这些代理交互的“控制平面”。在这个模型中，开发人员（“服务所有者”）可以非常幸福地完全意识不到服务网格的存在，而运营商（“平台工程师”）则被授予一套新的工具来确保可靠性、安全性和可见性。

服务网格为什么会突然流行？简而言之，是因为对于许多公司来说，像 Docker 和 Kubernetes 这样的工具已经“解决了部署的问题”——至少是差不多解决了。但 Docker 和 Kubernetes 没能解决运行时的问题。而这就是服务网格的用武之地。

“解决部署问题”是什么意思？使用 Docker 和 Kubernetes 之类的技术可以为企业大大减少部署大量应用或服务时的操作负担。使用 Docker 和 Kubernetes，部署 100 个应用程序或服务的工作量，不再是部署单个应用程序的 100 倍。这是历史性的向前迈出的一大步，对于许多公司来说，它可以极大降低采用微服务的成本。这可能不仅仅是因为 Docker 和 Kubernetes 在所有正确的级别提供了强大的抽象，更是因为它们标准化了整个组织的打包和部署模式。

但是，一旦应用程序运行之后呢？毕竟，部署不是生产的最后一步; 部署完之后，应用程序还必须运行。如此一来问题就变成了：像使用 Docker 和 Kubernete 进行标准化部署时一样，我们还能以同样的方式来将应用程序的运行时操作也标准化吗？

为了解决这个问题，服务网格应运而生。从本质上讲，服务网络提供统一的全局方式来控制和测量应用程序或服务之间的所有请求流量（在数据中心的说法中，即“东西向”流量）。对于采用微服务的公司而言，此请求流量在运行时行为中起着至关重要的作用。由于服务通过响应传入请求和发出传出请求来工作，因此请求流成为应用程序在运行时的行为方式的关键决定因素。因此，将流量管理标准化，则成为将应用程序运行时标准化的工具。

通过提供 API 来分析和操作此流量，服务网络为整个组织的运行时操作提供了标准化机制——包括确保可靠性、安全性和可见性的方法。和任何优秀的基础设施层一样，服务网格（在理想情况下）的工作方式与服务的构建方式无关。

服务网格是如何形成的？

那么服务网格从何而来？做了一些软件考古之后，我们发现服务网格提供的核心功能——请求级负载均衡、断路、重试、仪器等——基本上并不是新功能。其实，服务网格最终是功能的重新包装，真正发生转变的是“地方”，而不是“什么”。

服务网格的起源始于大约 2010 年三层应用程序架构模型的兴起——这是一种简单的架构，一度为网络上的绝大多数应用程序提供动力。在这个模型中，请求流量发挥着重要作用（有两个跃点！）。应用程序流量首先由“Web 层”处理，“web 层”又与“app 层”对话，后者又与“数据库层”对话。Web 层中的 Web 服务器旨在处理大量传入请求，需要非常迅速地将它们小心地交给相对较慢的应用服务器。（Apache、NGINX 和其他流行的 Web 服务器都有非常复杂的逻辑来处理这种情况。）同样，应用层使用数据库库与后备存储进行通信。这些库通常负责以针对此用例优化的方式处理缓存、负载均衡、路由、流控制。

但是，这种三层应用程序架构模型，在过载的情况下会开始崩溃——特别是在 app 层，随着时间的推移它的负载会变得非常大。像谷歌、Facebook、Netflix、Twitter 这样的大公司学会了将单体架构拆分成许多独立运行的块，从而催生了微服务的兴起。在引入微服务的那一刻，还引入了东西向流量。在这个世界上，通信不再是专一的，而是在每一项服务之间。通信若出错，整个网站都会出现故障。

因此，这些公司都以类似的方式做出了回应：他们编写了“胖客户端”库来处理请求流量。这些库——例如谷歌的 Stubby、Netflix 的 Hysterix、Twitter 的 Finagle——为所有服务提供了统一的运行时操作方式。开发人员或服务所有者使用这些库向其他服务发出请求，而在这个框架下，这些库将负责负载均衡、路由、断路、遥测。通过在应用程序中的每个服务之间提供统一的行为、可见性和控制点，这些库形成了表面上最初的服务网格——没有花哨的名称。

Proxy 的兴起

快进到现代的云原生世界。当然，这些库仍然存在。但是，鉴于进程外代理提供的操作便利性，库的吸引力显著降低了——尤其是当容器和编排框架的出现使得部署复杂性大幅下降时。

代理避免了库的许多缺点。例如，当一个库发生变化时，必须在每个服务中部署这些变化，这个过程往往需要复杂的组织层面的协调工作。相比之下，代理可以在不重新编译和重新部署每个应用程序的情况下进行升级。同样，代理支持多语言系统，在多语言系统中由服务组成的应用程序是用不同语言编写的——而这种方法对于库而言过于昂贵。

也许最重要的是，对于大型组织而言，在代理而不是库中实现服务网络，会将提供必要功能的责任，从服务所有者手上，转移到最终使用该服务的终端用户（即平台工程团队）手上。服务提供者和使用者的这种一致性，将会让这些团队把握自己的命运，消除开发和运维之间复杂的依赖关系。

这些因素都有助于服务网格的兴起。通过部署代理的分布式“网格”（它可以作为底层基础架构的一部分而不是应用程序本身来进行维护），并通过提供集中式 API 来分析和操作此流量，服务网格为跨越整个组织的运行时操作提供了标准化机制，包括确保可靠性、安全性和可见性的方法。

企业级服务网格应用

Service Mesh 极大地简化了用户体验，并将大中型企业的 Kubernetes 落地引领进下一个全新阶段，被业界普遍认为是新一代的微服务架构的最佳技术设计。日前，国内外企业及技术领域对 Service Mesh 技术的应用和探索开展的如火如荼，对大多数使用容器的企业而言，Service Mesh 仿佛是容器部署中亟待补齐的最后一块拼图。