为什么说 Service Mesh 是微服务发展到今天的必然产物？

过去三年里，架构领域最火的方向非微服务莫属。

微服务的好处显而易见，它本身所具备的可扩展性、可升级性、易维护性、故障和资源的隔离性等诸多特性使得产品的生产研发效率大大提高。同时，基于微服务架构设计风格，研发人员可以构建出原生对于“云”具备超高友好度的系统，让产品的持续集成与发布变得更为便捷。

但是，世界上没有完美无缺的事物，微服务也是一样。著名软件大师，被认为是十大软件架构师之一的 Chris Richardson 曾一针见血地指出：“微服务应用是分布式系统，由此会带来固有的复杂性。开发者需要在 RPC 或者消息传递之间选择并完成进程间通讯机制。此外，他们必须写代码来处理消息传递中速度过慢或者不可用等局部失效问题。”

在云原生模型里，一个应用可以由数百个服务组成，每个服务可能有数千个实例，而每个实例可能会持续地发生变化。这种情况下，服务间通信不仅异常复杂，而且也是运行时行为的基础。管理好服务间通信对于保证端到端的性能和可靠性来说是无疑是非常重要的。

以上种种复杂局面便催生了服务间通信层的出现，这个层既不会与应用程序的代码耦合，又能捕捉到底层环境高度动态的特点，让业务开发者只关注自己的业务代码，并将应用云化后带来的诸多问题以不侵入业务代码的方式提供给开发者。

这个服务间通信层就是 Service Mesh，它可以提供安全、快速、可靠的服务间通讯（service-to-service）。

在过去的一年中，Service Mesh 已经成为云原生技术栈里的一个关键组件。很多拥有高负载业务流量的公司都在他们的生产应用里加入了 Service Mesh，如 PayPal、Lyft、Ticketmaster 和 Credit Karma 等。

那么，对于 Service Mesh 这种新兴事物，它有哪些显而易见的优点？现在是否是企业落地 Service Mesh 的好时机？市面上有哪些好用的开源解决方案？InfoQ 记者就这些问题采访了普元云计算架构师、微服务专家宋潇男。

InfoQ：Service Mesh 现在国内基本都翻译为“服务网格”了，它的出现也没多长时间。根据我们的了解，它今年年中开始迅速在社区中流行并获得关注。能否谈谈你对 Service Mesh 的理解？它的出现最终是为了解决什么问题？

宋潇男：Service Mesh 这个词本身出现的时间确实不长，但是它所描绘的事情存在的时间可不短，其本质就是分布式系统的动态链接过程，眼下最大众化的分布式系统就是微服务，所以可以简单地说，Service Mesh 就是微服务的动态链接器（Dynamic Linker）。

让我们回忆一下单机程序的运作方式，源代码被编译器编译为一系列目标文件，然后交由链接器将这些目标文件组装成一个可执行文件，链接过程就是将各个目标文件之间对符号（方法、变量、函数、接口等）的引用转化为对内存地址的引用，由于这个过程在生成可执行文件时就完成了，所以被称为静态链接。

后来为了程序的模块化和功能上的解耦与共用，开始把一些常见的公共程序剥离出来，制作成库文件供其他程序使用，在引用这些库文件的程序运行时，操作系统上的动态链接器会在库文件中查询到被引用的符号，然后将这些符号的内存地址映射到该程序的虚拟内存空间之中，由于这个过程是在程序运行时完成的，所以被称为动态链接。

再后来出现了分布式系统，程序被散布在网络中的不同主机上，那么如何链接这些程序呢？业界走过了和链接单机程序类似，但是却艰难得多的一段历程。因为这个访谈是在微服务的大背景下进行的，为了叙述方便，我们从现在开始把这些程序称为服务。业界最开始是把这些服务的网络地址写在配置文件中，这个方案显然问题太多、很不靠谱。所以接下来自然而然地出现了服务注册中心来统一记录这些服务的网络地址并维护这些地址的变化，服务通过注册中心提供的客户端 SDK 与注册中心通信并获得它们所依赖的服务的网络地址。由于网络通信远没有内存通信稳定，为了保证可靠的服务调用，又出现了用于流量控制的 SDK，提供流量监控、限流、熔断等能力。

在大型系统中，被依赖的服务往往以多实例的方式运行在多个主机上，有多个网络地址，所以又出现了用于负载均衡的 SDK。现在问题貌似是解决了，但是我们手里多了一堆 SDK，我们手上已有的应用，必须用这些 SDK 重新开发，这显然可行度不高，而对于新开发的应用，我们又发现这些 SDK 体积过大，以 Netflix OSS 提供的 SDK 为例，依赖包动辄上百兆，在做微服务开发时，经常发现 SDK 的体积比程序本身还大很多倍，如果你使用容器技术，你会发现你的程序和基础容器的体积加起来还没 SDK 大，所以经常有人吐槽说现在的这些所谓的微服务框架实际上不是为微服务设计的。另外，SDK 还会带来性能伸缩性的问题，在性能要求较高的系统中，SDK 往往成为了性能瓶颈。再回头看一下单机上动态链接过程的顺畅，这种基于 SDK 的微服务动态链接方案简直是难用的不得了。

这时业界才开始关注已经存在了一段时间的 Service Mesh 方案，Service Mesh 的基础是一个网络代理，这个网络代理会接管微服务的网络流量，通过一个中央控制面板进行管理，将这些流量转发到该去的地方，并在这个代理的基础之上，扩展出一系列的流量监控、限流、熔断甚至是灰度发布、分布式跟踪等能力，而不需要应用本身做出任何修改，让开发者摆脱了 SDK 之苦，也避免了由于 SDK 使用不当造成的一系列问题，同时这个代理工作在网络层，一般情况下也不会成为性能瓶颈。怎么样，是不是有一些单机上动态链接过程的感觉了？

InfoQ：那在 Service Mesh 没有出现之前，微服务架构之间的通信是用什么方式解决的？都有哪些解决方案？

宋潇男：之前的方案也不少，比如刚刚提到的 Netflix OSS 的 SDK 方案，一些大型互联网公司在解决自身内部遇到的问题后，也开源出了一些方案，还有一些规模不太大、不太复杂的系统通过 Nginx 反向代理做了一些服务发现方案，值得注意的是，现在 Nginx 官方也推出了基于 Nginx 的 Service Mesh 方案。

InfoQ：采用 Service Mesh 是否需要对正在使用的一些微服务框架作出改动？企业落地 Service Mesh 有哪些难点？现在是开始转向 Service Mesh 的好时机吗？

宋潇男：目前成熟的微服务框架大多是 SDK 方案，如果你的应用已经用了这些 SDK 进行开发，那么引入 Service Mesh 肯定要做出很多改动的，简单地说，就是改回去。

目前企业要落地 Service Mesh，我觉得并不是一个好时机，先不说落地的难点，首先要面对的问题是 Service Mesh 框架的选型难题，目前最多生产部署的 Service Mesh 方案是 Linkerd，但是由 Google 和 IBM 牵头、众多新老 IT 厂商支持的 Istio 方案似乎又更有前景，可惜 Istio 现在刚刚 0.3 版本，还不能生产使用。所以与其在两种方案间摇摆不定，不如再等等看。而近期 Linkerd 又发布了一个新的 Service Mesh 方案 Conduit，使得局势进一步扑朔迷离。所以我的建议是，再等等看。

InfoQ：目前社区都有哪些 Service Mesh 的开源解决方案呢？（可否介绍下？Linkerd、Envoy、Istio）

宋潇男：主要就是由 Buoyant 公司推出的 Linkerd 和 Google、IBM 等厂商牵头的 Istio。Linkerd 更加成熟稳定些，Istio 功能更加丰富、设计上更为强大，社区相对也更加强大一些。所以普遍认为 Istio 的前景会更好，但是毕竟还处于项目的早期，问题还很多。

InfoQ：Istio 是目前最为流行的开源解决方案，也有大厂加持，可否解释下 Istio 的架构设计？以及它的社区发展情况？

宋潇男：Istio 的架构并不复杂，其核心组件只有四个。首先是名为 Envoy 的网络代理，用来协调服务网格中所有服务的出入站流量，并提供服务发现、负载均衡、限流熔断等能力，还可以收集大量与流量相关的性能指标；其次是名为 Mixer 收集器，用来从 Envoy 代理收集流量特征和性能指标；然后是名为 Pilot 的控制器，用来将流量协调的策略和规则发送到 Envoy 代理；最后是名为 Istio-Auth 的身份认证组件，用来做服务间访问的安全控制。

详见下图：

至于社区的发展，其实并不是特别火热，毕竟项目正式启动才半年多，而且与大多数开发者的距离比较远，所以关注者并不是很多。我想让大多数开发者不去关心它，也正是 Service Mesh 的意义所在吧。想想单机时代，有多少人会去关注动态链接器呢？我们总是说应该让开发人员更多的关心业务，可是看看现在的微服务、DevOps 方案，把多少程序运行期的事情推给开发人员解决，这其实是不对的，而 Service Mesh 正是要逆转这个不好的趋势。

InfoQ：现在 Service Mesh 开始逐步成为一个大家“炒作”的新技术，那在你看来， Service Mesh 的引入又会带来哪些新的问题呢？

宋潇男：我以前总是开玩笑说，新技术总是解决一个问题，再带来一堆问题，就好像汽车解决了出行问题，然后带来了修车、修路、建加油站、卖车险等一堆问题，世界就是在这个过程中进步的。可是到了 Service Mesh 这儿，确实想不出它会引入些什么问题，当然这是假设在 Service Mesh 成熟稳定之后。

在我看来，在三到五年之后，Kubernetes 会成为服务器端的标准环境，就像现在的 Linux，而 Service Mesh 就是运行在 Kubernetes 上的分布式应用的动态链接器，届时开发一个分布式应用将会像开发单机程序一样简单，业界在分布式操作系统上长达三十多年的努力将以这种方式告一段落。

嘉宾简介

宋潇男，普元信息云计算架构师。目前在普元负责容器相关的技术架构工作，曾在华为云计算部门负责分布式存储和超融合基础设施的产品与解决方案规划管理工作。曾负责国家电网第一代云资源管理平台和中国银联 OpenStack 金融云的技术方案、架构设计和技术原型工作。在云计算的萌芽期曾参与 Globus、HPC 等分布式系统的研究工作，拥有十余年的 UNIX 和分布式系统技术经验。

期待与作者一同交流、探讨 Service Mesh 相关话题，欢迎扫描群助手『小波波』二维码，加入由本文作者宋潇男主持的技术讨论微信群，加群暗号：1219