本文获得BUOYANT授权翻译发表，转载需要注明来自公众号EAWorld。

作者：William Morgan 

译者：月满西楼 

原题：What’s a service mesh? And why do I need one?

Service mesh是一个专用的基础设施层，功能在于提供安全、快速、可靠的服务间通讯（service-to-service）。一个云原生应用（cloud native application）的构建离不开Service mesh。

在过去的一年里，Service mesh已悄然兴起，并成为云堆栈的一个重要组件。 像Paypal、Lyft、Ticketmaster和Credit Karma 这样的高流量公司都在他们的产品应用中添加了Service mesh。 今年1月，Linkerd，作为一个面向云原生应用的开源Service mesh，成为了云原生计算基金会（CFCF）的官方项目。但到底什么是Service mesh? 为什么突然受到如此大的关注？

在本文中，我将详细介绍Service mesh的定义，并通过过去10年里它在应用程序架构中的变化和大家追溯一下Service mesh的发展历程。

首先，我将把Service mesh与API网关、边界代理edge proxies和企业服务总线的相关但又截然不同的概念区分开来。 然后，我将介绍Service mesh的发展方向，以及在云原生时代， 新一代的微服务开发技术Service mesh将带给我们什么样的期待与变化。 

1、什么是Service mesh？

Service mesh是用于处理服务间通讯的专用基础设施层。它负责通过复杂的拓扑结构服务来提供可靠的请求传递，这些服务构成了新一代云原生应用程序。事实上，Service mesh通常是作为一组轻量级高性能网络代理实现的，这些代理与应用程序代码部署在一起，但应用程序本身不需要关心这些。(不过，外界对此尚存在异议) 

Service mesh作为单独层的概念与云原生应用程序的大规模普及有关。 在云原生模型中，单个应用程序可能包含数百个服务; 每个服务可能又包含数千个实例;并且这些实例中的每一个都可能处于不断变化的状态，因为它们是由像Kubernetes这样的服务协调程序动态调度的。世界上的服务通讯不仅极其复杂，而且是运行时行为（runtime behavior）的一个普遍和基本的组成部分。管理好它对于确保端到端性能和可靠性是至关重要的。

2、Service mesh

是一个网络模型吗?

Service mesh是一个网络模型，它是位于TCP/IP之上的抽象层。它假定底层的L3/L4网络是真实存在的，并且能够点对点地传递字节。(它还假定了这个网络像运行环境的其他方面一样，是不可靠的； 因此，Service mesh必须能够处理网络故障。) 

Service mesh在某些方面其实是类似于TCP/IP。就像TCP栈抽象出了网络端点之间可靠传递字节的机制一样，Service mesh在服务之间可靠地传递请求的机制也是抽象的。与TCP相同的是，Service mesh并不关心实际的有效负载，也不关心它的编码问题。应用程序有一个高级目标(“从A到B发送一些数据”)， Service mesh的职责，和TCP一样，是在这个数据的发送过程中解决故障并圆满完成数据发送。

但与TCP不同的是，Service mesh具有更高的性能，它的使命超越了“仅仅让它可以工作”， 并且有一个更重要的目标: 它提供了统一的、应用广泛的观点，应用程序在运行操作时具有可视性和可控性。Service mesh的明确目标是将服务通讯从不可见的、隐含的基础设施中抽离出来，在云原生系统中扮演重要的一级成员的角色,从而可对系统进行监控，管理和控制。

3、Service mesh/

服务网格具体能做什么？

在云原生应用中可靠地传递请求可能非常复杂。 像Linkerd这样的Service mesh，通过一系列强大技术来管理这种复杂性: 链路熔断、延迟感知、负载均衡，eventually consistent (“advisory”) 服务发现，服务续约及下线与剔除。这些功能必须协同工作，而这些功能与它们所操作的复杂环境之间的交互作用是非常微妙的。

例如，当通过Linkerd工具处理某个服务的请求时，简化的事件时间表如下：

1. Linkerd应用动态路由规则来确定请求者所需要的服务。应该将请求发送到生产或Staging的服务中吗？还是到本地数据中心或云平台服中? 

还是到正在进行测试的最新版本的或已通过审核的旧有版本的服务中? 所有这些路由规则都是动态可配置的， 并且可以应用到整个系统和任意的流量段中。 

2. 找到了正确的目标之后，Linkerd从相关的服务发现节点中检索相应的实例池(这其中可能有好几个)。 如果这些信息与Linkerd在实践中所观察到的有所背离，Linkerd就会决定选择相对正确的信息来源。 

3. Linkerd根据各种因素选择最有可能返回快速响应的实例，包括所观察到的最近请求的延迟。 

4. Linkerd尝试将请求发送到实例，记录结果的延迟和响应类型。 

5. 如果实例关闭，无响应或无法处理请求，Linkerd会在另一个实例上重新尝试该请求(但只有它知道请求是幂等的情形下-即不管操作多少次结果都不变的性质)。 

6. 如果一个实例连续地返回错误，Linkerd会将其从负载均衡池中择出去，然后再进行周期性的重新尝试(例如，一个实例可能正在经历一个暂时性的失败)。 

7. 如果请求的截止时间已过，Linkerd将主动取消请求，不会通过进一步的重新尝试进行加载。 

8. Linkerd以metrics和分布式跟踪的形式捕捉了上述行为的各个方面，这些都被发送到一个集中的metrics系统。

当然， 这只是Linkerd的简化版本，Linkerd还可以发起和终止TLS，执行协议升级，动态转移流量，并在数据中心之间进行失效转移！

Linkerd Service mesh管理服务到服务间的通讯，并将其与应用程序代码进行剥离。

需要注意的是，这些功能旨在兼顾应用实例（Point）的快速恢复能力和应用（application）的快速恢复能力。对于大型分布式系统来说，无论其架构如何，都有一个典型的特征：很容易出现局部的小故障，这些小故障最终可能会演变为整个系统的灾难性故障。 Service mesh必须被设计成能够通过减少负载和在底层系统接近其极限时让其快速失效来防止这些恶化演变。

4、为什么说使用Service mesh

是非常有必要的？

Service mesh最终并不是引入一项新功能，而是功能定位的转变。Web应用程序总是必须管理服务间通信的复杂性。要想了解Service mesh模型的起源， 我们可以追溯过去15年以来的这些应用程序的发展历程。 

你可以思考下2000年的中型web应用程序的典型架构: 三层应用程序。 在这个模型中，应用程序逻辑、web服务逻辑和存储逻辑都是单独的一层。 层之间的通信虽然复杂，但这种复杂性是限定在一定范围内，因为毕竟只有两个跳转。这里没有“网格”，但是在每个层的代码中处理的跳转之间有通信逻辑。

当这种架构方式在面对应用程序内部逻辑越来越复杂化的情形时，它就开始崩溃了。 像Google、Netflix和Twitter这样的公司无时无刻都面临着巨大的流量需求，它们实现了云原生方案的前身: 应用层被分解成许多服务(有时称为“微服务”)，层级间则形成了一个拓扑结构。 在这些系统中，广义的通讯层突然变得相关起来， 但通常以“胖客户端”的库集（library）形式出现， 比如twitter的Finagle，Netflix的Hystrix，以及Google的Stubby就是这样的例子。

从很多方面上来讲，像Finagle, Stubby和Hystrix这些库集其实是Service mesh的雏形。虽然它们受其周围环境的细节影响，并且需要使用特定的语言和框架，但是它们是用于管理服务到服务间通信的专用基础设施，并且(在开源Finagle和 Hystrix库集的情形下)可以在其公司之外使用。

到了云原生应用时期， 云原生模型本身结合了许多小型服务的微服务方法和两个额外的因素:容器(例如Docker)，它提供了资源隔离和依赖关系管理，以及一个编排层(例如Kubernetes)，它将底层硬件抽象出了一个同质池。 

这三个组件支持应用程序在负载下可弹性伸缩的自然机制， 并能够处理云平台环境中存在的部分故障。 

但面对数百个服务或数千个实例，和随时在重新安排实例的编排层，单个请求经由服务拓扑的路径可能非常复杂， 而由于容器使每个服务用不同的语言写入处理变得更容易了，库集方法也就不再可行了。

这种复杂性和关键性的结合，激发了对服务到服务间通信的专用基础层的需求，这个专用层与应用程序代码分离出来，并能够捕捉底层环境的高度动态特性。就是这一专用层我们称之为Service mesh。

5、Service mesh的未来发展

在云原生系统中，Service mesh的运用正在迅速增长，而未来，还有一条广阔的，令人兴奋的发展路线图等着我们去探索。无服务器计算（例如亚马逊的Lambda）的要求直接适用于Service mesh的命名和链接模型，并且是它在云原生系统中角色的自然扩展。

服务身份和访问策略的作用在云原生环境中仍然很新鲜，Service mesh在此很好的扮演着重要的角色。最后，Service mesh，就像在它之前的TCP/IP一样，将继续被推进运用到底层基础设施层中。 正如Linkerd从Finagle这样的系统演化而来，Service mesh的当前化身是一个独立的用户空间代理，必须明确地添加到云堆栈中，并且将继续发展。

6、小结

Service mesh是云堆栈的一个关键组件。 Linkerd发布至今虽然才一年多点，但已成为云原生计算基金会（CFCF）的主要成员，并拥有一个活跃的用户群体。其中的用户包括像Monzo这样的初创公司，他们正在颠覆英国的银行业；和Paypal、Ticketmaster和Credit Karma这样的大型知名互联网公司；以及像Houghton Mifflin Harcourt这样的拥有数百年业务的公司。

Linkerd开源社区的用户每天都在证明并分享Service mesh模型的价值。同时我们也在致力于打造令人惊叹的出色产品， 并在持续壮大和活跃我们的社区，一个强者云集、不可思议的开源社区！你还犹豫什么呢，加入我们吧!

原文链接：https://buoyant.io/2017/04/25/whats-a-service-mesh-and-why-do-i-need-one/

关于EAWorld

微服务，DevOps，元数据，企业架构原创技术分享，EAii（Enterprise Architecture Innovation Institute）企业架构创新研究院旗下官方微信公众号。

微信号：eaworld，长按二维码关注