架构新纪元（六）：跨语言服务治理方案 Service Mesh

Service Mesh 是新兴的微服务架构，被誉为下一代微服务，同时也是云原生技术栈的代表技术之一。

1.Service Mesh 的由来

2016 年 1 月，离开 Twitter 公司的基础设施工程师 William Morgan 和 Oliver Gould 在 GitHub 上发布了 Linkerd 0.0.7 版本，他们同时组建了一个小型创业公司 Buoyant，业界第一个 Service Mesh 项目就此诞生。

2016 年年初，Service Mesh 还只是 Buoyant 公司的内部项目，而在那之后，随着 Linkerd 的开发和推广，Service Mesh 开始逐步走向社区并被广泛接受、喜爱、推崇。

2016 年 9 月 29 日，在 SF Microservices 大会上，“Service Mesh”这个词第一次在公开场合被使用，这标志着 Service Mesh 这个术语正式从 Buoyant 公司走向社区。

2016 年 10 月，Alex Leong 开始在 Buoyant 公司的官方博客中连载 A Service Mesh for Kubernetes 系列博文。随着“The services must mesh”口号被喊出，Buoyant 开始了 Service Mesh 的布道。

2017 年 1 月 23 日，Linkerd 加入 CNCF，项目类型被定义为“Service Mesh”。这是 Service Mesh 发展历程中的重要事件，代表着 CNCF 社区对 Service Mesh 理念的认同。

2018 年 7 月，CNCF 社区正式发布了云原生定义 1.0 版本，非常明确地指出，云原生代表技术包括容器、服务网格（Service Mesh）、微服务、不可变基础设施和声明式 API，至此 Service Mesh 技术被放到了一个前所未有的高度上。

从 2016 年到 2018 年，两年左右的时间里，Service Mesh 经历了从无到有，再到被社区广泛接受，乃至被人追捧的过程。

2.Service Mesh 的定义

Service Mesh 的定义最早是由出品 Linkerd 的 Buoyant 公司的 CEO William 在他的经典博客文章 What’s a service mesh? And why do I need one? 中给出的。Linkerd 是业界第一个 Service Mesh 项目，而 Buoyant 则创造了 Service Mesh 这个词汇。作为 Service Mesh 全球第一位布道师，William 给出的这个定义是非常官方和权威的，具体如下。

A service mesh is a dedicated infrastructure layer for handling service-to-service communication. It’s responsible for the reliable delivery of requests through the complex topology of services that comprise a modern, cloud native application. In practice, the service mesh is typically implemented as an array of lightweight network proxies that are deployed alongside application code, without the application needing to be aware.

服务网格是一个基础设施层，用于处理服务间通信。现代云原生应用有着复杂的服务拓扑结构，服务网格负责在这些拓扑结构中实现请求的可靠传递。在实践中，服务网格通常被实现为一组轻量级网络代理，它们与应用程序部署在一起，对应用程序是透明的。

3.Service Mesh 详解

下面我们将深入了解 Service Mesh 的具体部署模型和工作方式，以便更好地理解 Service Mesh 的含义。

单个服务调用

图 8-2 是单个服务调用下的 Service Mesh 部署模型，当发起一个请求时，作为请求发起者的客户端应用实例会首先通过简单方式将请求发送到本地的 Service Mesh 代理实例。注意此时应用实例和代理实例是两个独立的进程，它们之间的通信方式是远程调用，而不是代码层面的方法调用。

图 8-2 单个服务调用下的 Service Mesh 部署模型

然后，Service Mesh 的代理实例会完成完整的服务间通信的调用流程，如服务发现、负载均衡等基本功能，熔断、限流、重试等容错功能，以及各种高级路由功能，安全方面的认证、授权、鉴权、加密等，最后将请求发送给目标服务。最终表现为 Sidecar 模式，实现和传统类库类似甚至比传统类库更完备的功能。

Sidecar 这个词译为“边车”或者“车斗”。Sidecar 模式早在 Service Mesh 出现前就在软件开发领域中被使用了，它的灵感来源于实物，通过在原有的两轮摩托的一侧增加一个边车来实现对原有功能的扩展，见图 8-3。

图 8-3 Sidecar 的灵感

Service Mesh 通过在请求调用的路径中增加 Sidecar，将原本由客户端完成的复杂功能下沉到 Sidecar 中，实现对客户端的简化和服务间通信控制权的转移。

多个服务调用

如图 8-4 所示，当多个服务依次调用时，Service Mesh 表现为一个单独的通信层。在服务实例之下，Service Mesh 接管整个网络，负责所有服务间的请求转发，从而让服务只需简单地发送请求和处理请求，不必再负责传递请求的具体逻辑。中间服务间通信的环节被剥离出来，变为一个抽象层，称为服务间通信专用基础设施层。

图 8-4 多个服务依次调用

大量服务调用

当系统中存在大量服务时，服务间的调用关系就会表现为网状。如图 8-5 所示，在每个“格子”中左边的是应用程序，右边的是 Service Mesh 的 Sidecar，Sidecar 之间的线条表示服务之间的调用。可以看到，Sidecar 之间的服务调用关系形成了一个网络，这也就是 Service Mesh（服务网格）名字的由来。

图 8-5 大量服务调用

此时 Service Mesh 依然表现为一个通信层，只是这个通信层的内部更加复杂，服务之间的关系不再是简单的顺序调用，而是彼此相互调用，最终形成网状。

Service Mesh 定义回顾

再来回顾一下 Service Mesh 的定义，详细理解什么是 Service Mesh。

• 抽象：Service Mesh 是一个抽象层，负责完成服务间通信。但是和传统类库方式不同的是，Service Mesh 将这些功能从应用中剥离出来，形成了一个单独的通信层，并将其下沉到基础设施层。

• 功能：Service Mesh 负责实现请求的可靠传递，从功能上来说和传统的类库方式并无不同，原有的功能都可以继续提供，甚至可以做得更好。

• 部署：Service Mesh 在部署上体现为轻量级网络代理，以 Sidecar 模式和应用程序一对一部署，两者之间的通信是远程调用的，但是要通过 Localhost。

• 透明：Service Mesh 对应用程序是透明的，其功能实现完全独立于应用程序。应用程序无须关注 Service Mesh 的具体实现细节，甚至对 Service Mesh 的存在也可以无感知。这样带来的一个巨大优势是，Service Mesh 可以独立部署升级、扩展功能、修复缺陷，而不必改动应用程序。

图 8-6 对 Service Mesh 的定义给出了概括和总结，需要注意的是，如果把应用程序去掉，只呈现出 Sidecar 和 Sidecar 之间的调用关系，这个时候 Service Mesh 的概念就会特别清晰：Sidecar 和调用关系形成完整的网络，代表服务间复杂的调用关系，承载着系统内的所有应用。

图 8-6 Service Mesh 定义的概括与总结

图 8-6 体现了 Service Mesh 定义中非常重要的一点，和传统的 Sidecar 模式不同的是，Service Mesh 不再将代理视为单独的组件，而是强调由这些代理连接而形成的网络。Service Mesh 非常强调服务间通信网络的整体，而不是简单地以个体的方式单独看待每个代理。

至此，我们描述了 Service Mesh 的定义并进行了详细的解释，希望可以帮助各位读者理解什么是 Service Mesh。

相关文章：

架构新纪元（一）：从分布式架构到云原生架构

架构新纪元（二）：什么是云原生？

架构新纪元（三）：云原生的生态圈

架构新纪元（四）：观察分布式服务

架构新纪元（五）：云原生生态的基石 Kubernetes

本文节选自图书《未来架构：从服务化到云原生》。本书对快速演进中的云原生数据架构、典型分布式数据库中间件进行了剖析，重点介绍 Service Mesh 等新兴概念，创新性地提出了 Database Mesh 的理念，深度揭秘 Apache 项目——ShardingSphere。

购买链接： https://u.jd.com/sbmG4Y

作者简介：

张亮

京东数科数据研发负责人，Apache ShardingSphere 发起人兼 PPMC 成员。热爱分享，拥抱开源，主张代码优雅化，擅长以 Java 为主的分布式架构以及以 Kubernetes 和 Mesos 为主的云平台的构建。ShardingSphere 已进入 Apache 软件基金会，是京东集团首个进入 Apache 的开源项目，也是 Apache 首个分布式数据库中间件。

吴晟

Apache SkyWalking 创始人及 PPMC 成员，Apache ShardingSphere 原型作者及 PPMC 成员，Apache Zipkin 贡献者，Apache 孵化器导师，CNCF 基金会 OpenTracing 标准化委员会成员，W3C Trace Context 规范贡献者。擅长分布式架构、性能监控与诊断、分布式追踪、云原生监控等领域。

敖小剑

具有十七年软件开发经验，资深码农，微服务专家，Cloud Native 拥护者，敏捷实践者，Service Mesh 布道师，ServiceMesher 中文社区联合创始人。专注于基础架构建设，对微服务、云计算等相关技术有着深入研究和独到见解。

宋净超

蚂蚁金服云原生布道师，ServiceMesher 中文社区联合创始人，Kubernetes 社区成员，Istio 社区成员，《Cloud Native Go》《Python 云原生》《云原生 Java》等图书译者。