Service Mesh简史

最新推荐文章于 2024-09-08 02:51:22 发布

ZYQDuron

最新推荐文章于 2024-09-08 02:51:22 发布

阅读量375

点赞数

分类专栏：云帮开源技术分享文章标签：微服务架构 servicemesh

云帮同时被 3 个专栏收录

82 篇文章 1 订阅

订阅专栏

技术分享

81 篇文章 0 订阅

订阅专栏

开源

31 篇文章 0 订阅

订阅专栏

William Morgan

Service Mesh是一个相当新的概念，讲它的“历史”似乎有些勉强。就目前而言，Service Mesh已经在部分企业生产环境中运行了超过18个月，它的源头可以追溯到2010年前后互联网公司面对大规模业务的开发。

那么Service Mesh为什么会突然变成一个热门话题的？

Service Mesh是一个软件基础设施层，用于控制和监视微服务应用的内部、服务到服务的通信，通常的形式是部署在应用旁网络代理的“数据平面（data plane）”，或者是与浙西诶代理交互的“控制平面（control plane）”。在Service Mesh模式下，开发者对服务网格无感知，而运维人员获得了一套新工具，协助确保服务的可靠性、安全性和可见性。

它通常采用部署在应用程序代码旁边的网络代理的“数据平面”和用于与这些代理交互的“控制平面”的形式。在这个模型中，开发人员(“服务所有者”)不知道服务网格的存在，而操作员(“平台工程师”)获得了一套新的工具，以确保可靠性、安全性和可见性。

对于很多公司来说，Docker和Kubernetes已经“解决了部署”（至少一开始是这样的），但还没有解决运行时的问题，这正是Service Mesh的用武之地。

“解决了部署”是什么意思？使用Docker和Kubernetes等工具可以显著降低部署时的操作负担。有了这些工具，部署100个应用程序或服务的工作量不再是部署一个应用程序的100倍。这是向前迈出的一大步，对许多公司来说，这将显著降低采用微服务的成本。这不仅因为Docker和Kubernetes在所有合适的级别上提供了强大的抽象，而且因为它们标准化了整个组织的打包和部署模式。

但是一旦应用程序开始运行，又是怎样的情形？毕竟，部署不是生产的最后一步——这个应用程序仍然需要运行、需要交付、需要产生价值。因此，问题就变成了：我们是否可以用Docker和Kubernetes标准化部署时间操作（deploy-time ops）的相同方式来标准化应用程序的运行时操作？

要回答这个问题，不妨求教Service Mesh。Service Mesh的核心是提供统一的、全局的方法来控制和测量应用程序或服务之间的所有请求流量(用数据中心的话说，就是“east-west”流量)。对于采用了微服务的公司来说，这种请求流量在运行时行为中扮演着关键角色。因为服务通过响应传入请求和发出传出请求来工作，所以请求流成为应用程序在运行时行为的关键决定因素。因此，标准化流量管理成为标准化应用程序运行时的工具。

通过提供api来分析和操作此流量，Service Mesh为跨组织的运行时操作提供了标准化的机制——包括确保可靠性、安全性和可见性的方法。与任何好的基础架构层一样，Service Mesh采用的是独立于服务的构建方式。

Service Mesh如何形成

那么，Service Mesh是从哪里来的呢？通过做一些“软件考古学”，我们发现服务网格提供的核心功能——诸如request-level的负载均衡、断路器、重试、检测——并不是基本的新特性。相反，Service Mesh是功能的重新打包——a shift in where，not what。

Service Mesh起源于2010年左右应用架构的三层模型——一种简单的体系结构，一度为web上的绝大多数应用提供“动力”。在这个模型中，应用流量首先由“web层”来处理，后者又会与“应用层”进行对话，之后又会与“数据库层”对话。web层中的web服务器被设计成能够非常快速地处理大量传入的请求，并将它们小心地交给相对较慢的应用服务器(Apache、NGINX和其他流行的web服务器都有非常复杂的逻辑来处理这种情况)。同样，应用层使用数据库库与back stores进行通信。这些库通常以一种针对这个用例进行优化的方式处理缓存、负载均衡、路由、流控制等。

So far so good，但是这个模型面对大规模业务时开始显露出疲态——尤其是在应用层，随着时间的推移它会变得非常大。早期的网络规模公司——谷歌、Facebook、Netflix、Twitter——学会了把这块巨石分解成许多独立运行的碎片，催生了微服务的兴起。在引入微服务的那一刻，east-west traffic随之引入。在这个世界上，通信不再是专门的，而是在每个服务之间。当它出错时，网站就会崩溃。

这些公司都以类似的方式进行应对——他们编写了“fat client”库来处理请求流量。这些库——谷歌的Stubby、Netflix的HYstrix、Twitter的Finagle——提供了跨所有服务的统一的运行时操作方式。开发者或服务所有者将使用这些库向其他服务发出请求，库将在后台执行负载均衡、路由、断路等等。通过为应用中的每个服务提供统一的行为、可见性和控制点，这些库表面上形成了第一个Service Mesh。

代理崛起

当我们回到当下以云为本的世界，这些库仍然存在。但是，由于进程外代理提供的操作便利，库的吸引力正在降低——尤其是在与容器和编排的出现所带来的部署复杂性显著降低的情况下。

代理绕过了库的许多缺点。例如，当一个库发生更改时，这些更改必须在每个服务中部署，这个过程通常需要复杂的组织协作。而代理，无需重新编译和重新部署，就可以升级应用。同样，代理允许使用多种语言系统，应用可以由不同的语言编写，当然这种方法对于库来说代价是非常大的。

也许对于大型组织来说，最重要的是，在代理服务器而不是库中实现——服务网格负责将运行时操作所需的功能提供给服务所有者，并被这些功能的最终用户掌握 - 平台团队。提供者和消费者的这种对齐，允许这些团队掌握自己的命运，并将dev和ops之间的复杂依赖关系分离。

以上这些因素共同促成了Service Mesh的兴起，也使运行时操作变得更为健全。通过部署一个分布式代理的“网”，可以作为底层基础设施的一部分维护，而不是维护应用本身，并通过提供集中的api来分析和操作流量，Service Mesh为整个组织运行时操作提供了一个标准的机制，同时确保可靠性、安全性和可见性。