Service Mesh 是一个专门使服务与服务之间的通信变得安全、快速和可靠的的基础设施。如果你正在在构建一个云原生（ Cloud Native ）应用，那么你一定需要 Service Mesh 。

在过去的一年中， Service Mesh 成为了云原生技术栈的关键组件。像 PayPal , Ticketmaster 和 Credit Karma 这样的大厂，已经将 Service Mesh 加入到他们的应用中。并且在 2017 年 1 月，开源的 Service Mesh 软件 Linkerd 加入云原生基金会（ CNCF ），成为云原生基金会（CNCF）的官方项目。但是什么是真正的 Service Mesh？它又为何突然变的如此重要？

在这篇文章，我会讲解 Service Mesh 的定义，并通过应用服务架构过去十年的发展追溯其起源。并将 Service Mesh 与其他相似的概念，包括 API 网关，边缘代理以及 ESB （enterprise service bus）进行区分。最终，将会描述 Service Mesh 的发展方向，以及随着云原生概念的普及，Service Mesh 发生的变化。

什么是 Service Mesh

Service Mesh 这个服务网络专注于处理服务和服务间的通讯。其主要负责构造一个稳定可靠的服务通讯的基础设施，并让整个架构更为先进和 Cloud Native。在实践中，Service Mesh 基本来说是一组轻量级的服务代理和应用逻辑的服务在一起，并且对于应用服务是透明的。

Service Mesh 作为独立层的概念与云原生应用的兴起有关。在云原生模式，单个应用可能有数百个服务组成，每个服务又可能有上千个实例，而每个实例都有可能被像 Kubernetes 这样的服务调度器不断调度从而不断变化状态。而这些复杂的通信又普遍是服务运行时行为的一部分，这时确保端到端的通信的性能和可靠性就变的至关重要。

Service Mesh 就是一个网络模型吗？

Service Mesh 是一个位于 TCP/IP 上的抽象层的网络模型。它假定底层 L3/L4 网络存在并且能够从一点向另一点传输数据。（它还假定这个网络和环境的其他方面一样不可靠，所以 Service Mesh 也必须能够处理网络故障。）

在某些方面，Service Mesh 就像是网络七层模型中的第四层 TCP 协议。其把底层的那些非常难控制的网络通讯方面的控制面的东西都管了（比如：丢包重传、拥塞控制、流量控制），而更为上面的应用层的协议，只需要关心自己业务应用层上的事了。

与 TCP 不同的是， Service Mesh 想要达成的目的不仅仅是正常的网络通讯。它为应用提供了统一的，可视化的以及可控制的控制平面。Service Mesh 是要将服务间的通信从无法发现和控制的基础设施中分离出来，并对其进行监控、管理和控制。

Service Mesh 实际上做了什么？

在云原生应用中传递可靠的请求是十分复杂的。而 Linkerd 提供了服务熔断、重试、负载均衡、熔断降级等功能，通过其强大的功能来管理那些必须运行在复杂环境中的服务。

这里列举一个通过 Linkerd 向服务发出请求的简单流程：

通过 Linkerd 的动态路由规则来确定打算连接哪个服务。这个请求是要路由到生产环境还是演示环境？是请求本地数据中心的服务还是云上的服务？是请求正在测试的最新版的服务还是已经在生产中经过验证的老版本？所有的这些路由规则都是动态配置的，可以全局应用也可以部分应用。
找到正确的目的服务后，Linkerd 从一个或几个相关的服务发现端点检索实例池。如果这些信息与 Linkerd 的服务发现信息不同， Linkerd 会决定信任哪些信息来源。
Linkerd 会根据观察到的最近的响应延迟来选择速度最快的实例。
Linkerd 发送请求给这个实例，记录延迟和响应类型。
如果这个实例挂了、无响应或者无法处理请求， Linkerd 会再另一个实例上重试这个请求（但只有在请求是幂等的时候）。
如果一个实例一直请求失败， Linkerd 会将其移出定时重试的负载均衡池。
如果请求超时， Linkerd 会主动将请求失效，而不是进一步重试从而增加负载。
Linkerd 会记录指标和分布式的追踪上述行为的各个方面，将他们保存在集中的指标系统中。

以上只是简化版的介绍， Linkerd 还可以启动和重试 TLS ，执行协议升级，动态切换流量，甚至在故障之后数据中心的切换。

值得注意的是，这些功能旨在为每个实例和应用程序提供弹性伸缩。而大规模的分布式系统（无论是如何构建的）都有一个共同特点：都会因为许多小的故障，而升级为全系统灾难性的故障。Service Mesh 则被设计为通过快速的失效和减少负载来保护整个系统免受这样灾难性的故障。

为什么 Service Mesh 是必要的？

Service Mesh 本质上并不是什么新技术，而是功能所在位置的转变。Web 应用需要管理复杂的服务通信，Service Mesh 模式的起源和演变过程可以追溯到15年前。

参考2000年左右中型 Web 应用的典型三层架构，在这个架构中，应用被分为三层：应用逻辑、Web 服务逻辑、存储逻辑。层之间的通信虽然复杂，但是毕竟范围有限，最多只有 2 跳。这里并不是 “Mesh” 的，但在每层中处理跳转的代码是存在通信逻辑的。

当这种架构向更大规模发展的时候，这种通信方式就无以为继了。像 Google、Netflix 和 Twitte ，在面临巨大的请求流量的时候，他们实现了云原生应用的前身：应用被分割成了许多服务（现在称作“微服务”），这些服务组成了一种网格结构。在这些系统中，通用通信层突然兴起，表现为“胖客户端”的形式——Twitter 的 Finagle，Netflix 的 Hystrix 和 Google 的 Stubby 都是很典型的例子。

现在看来，像 Finagle 、Stubby 和 Hystrix 这样的库就是最早的 Service Mesh。虽然它们是为特定环境、语言和框架定制了，但都是作为基础设施专门用于管理服务间的通信，并（在 Finagle 和 Hystrix 开源的情况下）在其他公司的应用中被使用。

这三个组件都有应用自适应机制，以便在负载中进行拓展，并处理在云环境中的部分故障。但是对于数百个服务或数千个实例，以及不时需要重新调度的业务层实例，单个请求通过的调用链可能变的非常复杂，而且服务可能由不同的语言编写，这时基于库的解决方案可能就不再适用了。

服务通信的复杂性和重要性导致我们急需一个专门的基础设施层来处理服务间的通信，该层需要与业务代码解耦，并且具有捕获底层环境的动态机制。这就是 Service Mesh。

Service Mesh 的未来

Service Mesh 在云生态下迅速的成长，并且有着令人激动的未来等待探索。对无服务器计算（Serverless，例如 Amazon 的 Lambda）适用的 Service Mesh 网络模型，在云生态系统中角色的自然拓展。Service Mesh 可能成为服务身份和访问策略这些在云原生领域还是比较新的技术的基础。最后，Service Mesh，如之前的TCP / IP，将推进加入到底层的基础架构中。就像 Linkerd 是由像 Finagle 这样的系统发展而来，Service Mesh 将作为单独的用户空间代理添加到云原生技术栈中继续发展。

结语

Service Mesh 是云原生技术栈的关键技术。Linkerd 成立仅 1 年就成为了云原生基金会（CNCF）的一部分，拥有蓬勃发展的社区和贡献者。使用者从像 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/

Service Mesh 是什么，我们为什么需要它？相关推荐

聊聊Service Mesh：linkerd
[编者的话]随着企业逐渐将传统的单体应用向微服务或云原生应用的转变,虽然微服务或者云原生应用能给企业带来更多的好处,但也会带来一些具有挑战的问题,如怎么管理从单体应用转向微服务所带来的服务间通讯的复杂 ...
下一代 Service Mesh -- istio 架构分析
前面的分享中,我们讲到,出于性能和稳定的考虑,我们没有采用以 istio 为代表的第二代 service mesh技术,而是直接使用了 Envoy 搭配自己的 xDS 服务. 然而我们还是有必要去了解 ...
百度大规模Service Mesh落地实践
导读:百度过去基于rpc框架的服务治理存在各种框架能力层次不齐.业务自身服务治理效率低.全局可观测性不足等诸多问题.本文介绍了百度内部落地service mesh的实践过程,以基础稳定性能力治理和流量 ...
基于Service Mesh构建更现代的服务架构
点击上方蓝色字体,选择"设为星标" 优质文章,及时送达前言传统业务模型中,客户端和服务端之间放置一个负载均衡器,比如nginx.我们的客户端可以是移动程序或者web系统. 当服 ...
实施Service Mesh前，你需要考虑这几个问题
随着我们需要治理的微服务数量越来越多,我们必须开始着手解决服务间通信的复杂性问题,而Service Mesh(服务网格)的出现恰逢其时,作为基础设施层,它能够以透明代理的形式提供安全.快速.可靠的服务 ...
Service Mesh是大方向，那Database Mesh呢？
在微服务和云原生大潮的卷席之下,服务化一直以来是人们关注的重点.但服务化之后,真正绕不开的数据访问却鲜有论道.尽管目前的关系型数据库远达不到云原生的要求,并且对分布式的不友好在长期以来也饱受诟病,但不 ...
十问 | 关于Service Mesh 和Kubernets的最前沿思考
小蚂蚁说: 在7月6日ArchSummit全球架构师峰会2018深圳站上,蚂蚁金服平台数据技术部的杨冰.Service Mesh布道师敖小剑.蚂蚁金服技术专家毛小云和来自阿里大文娱UC基础部的曾彬,四 ...
Service Mesh：调度千军万马微服务，2.0妥妥的
冠望发自凹非寺量子位报道 | 公众号 QbitAI 过去一年,继Kubernetes风靡,Service Mesh已成功上位变成当之无愧的技术网红. TA不但可以极大简化用户使用体验,还将大中 ...
Service Mesh — Overview
目录文章目录目录微服务的两个层面微服务架构服务治理的难点 Service Mesh(服务网格) Service Mesh 的设计思想 Istio 的实现原理 Service Mesh 的问题 ...
Service Mesh — APIGW vs ServiceMesh
目录文章目录目录 APIGW vs ServiceMesh 原本清晰的界限:定位和职责 APIGW 访问内部服务,算东西向还是南北向? Sidecar:真正的重合点如何融合东西向和南北向的通讯方 ...

Service Mesh 是什么，我们为什么需要它？