架构新纪元（六）：跨语言服务治理方案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》等图书译者。