Service Mesh 服务网格的概念最近非常火。无论基于Kubernetes 的Istio，还是Service Mesh的先行者Linkerd，都有不小的热度。本文将介绍服务网格的基本理念和它的发展历史。

本文由宋雾代首发于https://www.jianshu.com/p/ea10bec95977 转载请注明出处

什么是服务网格？

服务网格是用于控制和监控微服务应用程序中的内部服务到服务流量的软件基础结构层。它通常采取与应用程序代码一起部署，作为网络代理的 "数据平面" 和与这些代理交互的 "控制平面" 的形式。在此模型中，服务网格对于开发人员 (服务所有者) 是透明的， 而运维人员 (平台工程师) 则被授予一套新的工具，以确保可靠性、安全性和可见性。

为什么服务网格突然这么受欢迎？对许多公司来说，Docker 和 Kubernetes 这样的工具已经 "解决了部署问题"，或者说几乎解决了。但他们还没有解决运行时的问题。这就是服务网格的由来。

什么是解决了部署问题？使用 Docker 和 Kubernetes 等功能可显著减轻部署的增量操作负担。使用这些工具，部署100个应用或服务不再是部署单个应用的100倍。这是向前迈出的一大步，对许多公司来说，这导致采用微服务的成本大幅降低。这不仅是因为 Docker 和 Kubernetes 所提供了强大的抽象，而且还因为它们使整个组织的打包和部署模式过程标准化了。

当我们的应用程序运行起来以后，然后呢？毕竟，部署并不是生产的最后一步，应用程序仍需运行。因此, 问题就变成了：我们能否像 Docker 和 Kubernetes 标准化部署操作一样, 对应用程序的运行时操作进行标准化？

为了回答这个问题，我们转向服务网格。服务网格的核心是提供统一的全局方法来控制和测量应用或服务之间的所有请求流量 (用数据中心的话说, 叫做东西流量EAST-WEST traffic)。对于采用微服务的公司，此请求流量在系统运行中发挥着至关重要的作用。由于服务通过响应传入的请求和发出请求来工作，因此请求流成为决定应用程序在运行时行为的关键因素。因此，标准化此流量的管理将成为标准化应用程序运行时操作的切入口。

东西流量与南北流量^[2]
南北流量（NORTH-SOUTH traffic）和东西流量（EAST-WEST traffic）是数据中心环境中的网络流量模式。
假设我们尝试通过浏览器访问某些Web应用。Web应用部署在位于某个数据中心的应用服务器中。在多层体系结构中，典型的数据中心不仅包含应用服务器，还包含其他服务器，如负载均衡器、数据库等，以及路由器和交换机等网络组件。假设应用服务器是负载均衡器的前端。
客户端和服务器之间的流量被称为南北流量。简而言之，南北流量是server-client流量。
不同服务器之间的流量与数据中心或不同数据中心之间的网络流被称为东西流量。简而言之，东西流量是server-server流量。
该命名来自于绘制典型network diagrams的习惯。在图表中，通常核心网络组件绘制在顶部（NORTH），客户端绘制在底部（SOUTH），而数据中心内的不同服务器水平（EAST-WEST）绘制。

通过提供用于分析和操作此流量的 api，服务网格为整个组织的运行时操作提供了标准化机制，包括确保可靠性、安全性和可见性的方法。与任何好的基础结构层一样，服务网格 (理想情况下) 的工作方式与服务的构建方式无关。

服务网格的形成

那么服务网格是从哪里来的呢？我们回顾一下架构的发展历程，我们发现服务网格提供的核心功能：如请求级负载平衡、断路、重试、检测，这些并不是全新的功能。相反，服务网格做的是功能的重新打包。所以服务网格并不是一个全新的事物，而是对传统功能的重新整合。

服务网格的起源始于大约2010年应用程序体系结构的三层模型的兴起：这是一个简单的体系结构，一度为绝大多数应用程序提供了动力。在此模型中，应用程序流量首先由web 层处理，而 web 层又与应用层对话, 而应用层又与数据库层对话。web 层中的 web 服务器旨在非常快速地处理大量传入请求，并将其小心地传递给相对缓慢的应用服务器。(apache、nginx 和其他流行的 web 服务器都有处理这种情况的非常复杂的逻辑）。同样，应用层使用数据库的类库与后备存储进行通信。这些库通常针对此模型下的缓存、负载平衡、路由、流控制等进行了优化。
但这种模型在随着负载的提高开始分解。尤其是在应用层，随着时间的推移，它可能会变得相当庞大。互联网巨头公司如Google、Facebook、Netflix、Twitter等学会了将这些应用分解成大量独立运行的子服务从而催生了微服务的兴起。在引入微服务的那一刻，也引入了东西流量。基于微服务的架构的数据交互变成了每一个服务之间的交互。而一旦某个服务出了问题，则可能导致整个网站的不可用。

这些公司都以类似的方式给出了解决方案：他们编写了 "胖客户端" 库来处理请求流量。这些库（Google的 Stubby、Netflix 的 Hysterix、Twitter 的 Finagle）为所有服务提供了统一的运行时操作方式。开发人员或服务所有者使用这些库向其他服务发出请求。这些库封装了负载平衡、路由、断路、监测。通过在应用程序中的每个服务中提供统一的行为、可见性和控制点，这些库形成了服务网格的雏形。

代理服务的崛起

如今越来越多的应用搬到了云上。尽管这些类库仍然存在，但是相比起进程外代理提供的操作便利性，库的吸引力要低得多，特别是当容器和服务调配器（Orchestrators）的出现使部署复杂性大幅下降时。
代理避开了库的许多缺点。例如，当库发生更改时，必须在每个服务中部署这些更改。而这一过程通常非常复杂。相比之下，升级代理的过程，无需重新编译和重新部署每个应用程序。代理同时支持多语言系统（应用程序由服务组成，使用不同的编程语言编写），而这对于库来说成本高得令人望而却步。
也许最重要的是对于较大的组织来说，在代理中而不是在库中实现服务网格，可以将提供运行时操作所需功能这一责任从服务所有者手中移走，而交由这一功能的最终消费者：平台工程团队来负责。这种提供者和使用者的一致性使这些团队能够有充分的自主性，并分离开发和运维之间的复杂依赖关系。
服务网格让运行时操作变得更加健全和方便，这些因素都促成了它的兴起。这些代理作为基础架构一部分而不是应用程序本身进行维护，通过部署这些分布式的“网格”，以及通过提供用于分析和操作此流量的集中式 api, 服务网格提供了对于整个组织来说标准化的运行时操作机制，从而确保系统的可靠性、安全性和可见性。

参考资料：

1. The History of the Service Mesh Willam Morgan
2. 南北流量和东西流量——它们是什么意思? 好雨云帮