Service Mesh 是新瓶装旧酒吗？

作者 | 李云（花名：至简）阿里云高级技术专家

导读：在即将过去的 2019 年，Service Mesh 开源产品的成熟度虽在全球范围内没有发生质的变化，但在国内仍出现了一些值得特别关注的事件。比如：阿里巴巴在双11 的部分电商核心应用上落地了完整的 Service Mesh 解决方案，借助双11 的严苛业务场景完成了规模化落地前的初步技术验证。本文作者将结合自己在阿里巴巴落地实践 Service Mesh 过程中的观察与思考，来和大家进行分享。

新技术出现时所主张的价值一定会引发相应的探讨，Service Mesh 也不例外。

以往，怀疑 Service Mesh 价值的观点主要有两大类。

第一类是应用的数量并没有达到一定的规模，在 Service Mesh 增加运维和部署复杂度的情形下，认为所带来的成本和复杂度高于所获得的收益。

从根本上来看，这一类并非真正怀疑 Service Mesh 的价值，而是主张在 Service Mesh 还没有完全成熟和普及的情形下，在未来合适的时机再考虑采纳。当然，我在与外部客户交流时也碰到一些特例，他们即便在应用数很少的情形下，仍希望通过 Service Mesh 去解决非 Java 编程语言（比方说 Go）的分布式链路追踪等服务治理问题，虽说这些能力在 Java 领域有相对成熟的解决方案，但在非 Java 领域确实偏少，所以很自然地想到了采用 Service Mesh。

第二类怀疑 Service Mesh 价值的，是应用的数量具有相当的规模且对分布式应用的规模问题也有很好的认知，但由于在发展的过程中已经积累了与 Service Mesh 能力相当的那些（非体系化的）技术，造成初识 Service Mesh 时有“老酒换新瓶”的感觉而不认可其价值。阿里巴巴过去也曾属于这一阵营。

阿里巴巴在分布式应用的开发和治理方面的整体解决方案的探索有超过十年的历程，且探索过程持续地通过双11 这样的严苛场景做检验和孵化，采用单一的 Java 语言打造了一整套的技术。即便如此，应对分布式应用的规模问题依然不轻松，体现于因为缺乏顶层设计而面临体系性不足，加之对技术产品自身的用户体验缺乏重视，最终导致运维成本和技术门槛都偏高。在面临这些阵痛之际，云原生的概念逐渐清晰地浮出了水面。

云原生主张技术产品在最为严苛的场景下仍能提供一定质量的服务而体现良好弹性，同时也强调技术产品本身应当具有良好的易用性，以及将来为企业需要多云和混合云的 IT 基础设施提供支撑（即：帮助实现分布式应用的可移植性）。

云原生的概念不仅很好地契合了阿里巴巴集团在技术发展上亟待解决的阵痛，也迎合了阿里巴巴将云计算作为集团战略、让云计算普惠社会的初衷。在这一背景下，阿里巴巴做出了全面云原生化的决定，Service Mesh 作为云原生概念中的关键技术之一，当然也包含在其中。

Service Mesh 给阿里巴巴带来的价值

Service Mesh 所带来的第一个变化体现于：服务治理手段从过去的框架思维向平台思维转变。

这种转变并非后者否定前者，而是前后者相结合去更好地发挥各自的优势。两种思维的最大区别在于，平台思维不仅能实现应用与技术基础设施更好的解耦，也能通过平台的聚集效应让体系化的顶层设计有生发之地。

框架思维向平台思维转变在执行上集中体现于“轻量化”和“下沉”两个动作。

轻量化是指将那些易变的功能从框架的 SDK 中移出，结果是使用了 SDK 的应用变得更轻，免除了因易变功能持续升级所带来的低效；也彻底让应用的开发者无需关心这些功能，让他们能更好地聚焦于业务逻辑本身；
从框架中移出的功能放到了 Service Mesh 的 Sidecar 中实现了功能下沉。

Service Mesh 作为平台性技术，将由云厂商去运维和提供相应的产品，通过开源所构建的全球事实标准一旦被所有云厂商采纳并实现产品化输出，那时应用的可移植性问题就能水到渠成地解决。

功能下沉在阿里巴巴落地 Service Mesh 的过程中也看到了相应的价值。阿里巴巴的电商核心应用基本上都是用 Java 构建的，在 Mesh 化之前，RPC 的服务发现与路由是在 SDK 中完成的，为了保证双11 这样的流量洪峰场景下的消费者用户体验，会通过预案对服务地址的变更推送做降级，避免因为频繁推送而造成应用进程出现 Full GC。Mesh 化之后，SDK 的那些功能被放到了 Sidecar（开发语言是 C++）这一独立进程中，这使得 Java 应用进程完全不会出现类似场景下的 Full GC 问题。

软件设计的质量主要体现在“概念”和“关系”两个词上。

同样功能的一个系统，不同的概念塑造与切分将产生完全不同的设计成果，甚至影响到最终软件产品的工程质量与效率。当概念确定后，关系也随之确立，而关系的质量水平体现在解耦的程度上。Service Mesh 使得应用与技术基础设施之间的关系变得更松且稳定，通过流量无损的热升级方案，使得应用与技术基础设施的演进变得独立，从而加速各自的演进效率。软件不成熟、不完善并不可怕，可怕的是演进起来太慢、包袱太重。

阿里巴巴在落地 Service Mesh 的过程中，体会到了松耦合所带来的巨大工程价值。当应用被 Mesh 化后，接下来的技术基础设施的升级对之就透明了，之前因为升级工作所需的人力配合问题可以通过技术产品化的手段完全释放。另外，以往应用进程中包含了业务逻辑和基础技术的功能，不容易讲清楚各自对计算资源的消耗，Service Mesh 通过独立进程的方式让这一问题得以更好地隔离而实现量化，有了量化结果才能更好地对技术做优化。

Service Mesh 所带来的第二个变化在于：技术平台的建设从面向单一编程语言向面向多编程语言转变。

对于初创或小规模企业来说，业务应用的开发采用单一的编程语言具有明显优势，体现于因为个体掌握的技术栈相同而能带来良好的协作效率，但当企业的发展进入了多元化、跨领域、规模更大的更高阶段时，多编程语言的诉求就随之产生，对于阿里巴巴这样的云厂商来说更是如此（所提供的云产品不可能过度约束客户所使用的编程语言）。多编程语言诉求的背后是每种编程语言都有自己的优势和适用范围，需要发挥各自的优势去加速探索与创新。

从技术层面，这一转变意味着：

第一，技术平台的能力需要尽可能地服务化，避免因为服务化不彻底而需要引入 SDK，进而带来多编程语言问题（即因为没有相应编程语言的 SDK 而无法使用该编程语言）；
第二，在无法规避 SDK 的情形下，让 SDK 变得足够的轻且功能稳定，降低平台化和多编程语言化的工程成本，支持多编程语言 SDK 最好的手段是采用 IDL。

从组织层面，这一转变意味着平台技术团队的人员技能需要多编程语言化。一个只有单一编程语言的团队是很难做好面向多编程语言的技术平台的，不只是因为视角单一，还因为无法“吃自己的狗食”而对多编程语言问题有切肤之痛。

Service Mesh 带来的发展机遇

在这两个变化之下，我们来聊一聊 Service Mesh 所带来的发展机遇。

首先，Service Mesh 创造了一次以开发者为中心去打造面向未来的分布式应用开发平台的机会。

在 Service Mesh 出现之前，各种分布式服务治理技术产品的发展，缺乏强有力的抓手去横向拉通做体系化设计和完成能力复用，因而难免出现概念抽象不一致和重新造轮子的局面，最终每个技术产品有自己的一套概念和独立的运维控制台。当多个运维控制台交到开发者手上时，他们需要做大量的学习，去理解每个运维控制台的概念以及它们之间的关系，背后所带来的困难和低效是很容易被人忽视的。

本质上，Service Mesh 的出现是解决微服务软件架构之下那些藏在应用与应用之间的复杂度的。它的出现使得所有的分布式应用的治理问题被放到了一起去考虑。换句话说，因为 Service Mesh 的出现，我们有机会就分布式应用的治理做一次全局的设计，也有机会将各种技术产品整合到一起而避免重复建设的问题。

未来的分布式应用开发平台一定是基于 Service Mesh 这一基础技术的。为此，需要借这个契机从易用性的角度重新梳理应给开发者塑造的心智。易用性心智的确立，将使得开发者能在一个运维控制台上做最少的操作，通过为他们屏蔽背后的技术实现细节，而减轻他们在使用时的脑力负担，以及降低操作失误带来安全生产事故的可能性。

理论上，没有 Service Mesh 之前这些工作也能做，但因为没有具体的横向技术做抓手而无法落地。

其次，Service Mesh 给其他技术产品创造了重新思考云原生时代的发展机会。

有了 Service Mesh 后，以前很多独立的技术产品（比如，服务注册中心、消息系统、配置中心）将变成 BaaS（Backend as a Service）服务，由 Service Mesh 的 Sidecar 负责与它们对接，应用对这些服务的访问通过 Sidecar 去完成，甚至有些 BaaS 服务被 Sidecar 终结而完全对应用无感。

这些变化并非弱化了那些 BaaS 服务的重要性。相反，因为其重要性而需要与 Service Mesh 做更好的整合去为应用提供服务，与此同时探索做一定的能力增强。比方说，Service Mesh 所支持的应用版本发布的灰度功能（包括蓝绿发布、金丝雀发布、A/B 测试），并非每一个 BaaS 服务在 Mesh 化后就能很好地支持这一功能，而是需要做相应的技术改造才行。请注意，这里主要讲的是应用的灰度能力，而非 BaaS 服务自身的灰度能力。当然，并不妨碍探索通过 Service Mesh 让 BaaS 服务自身的灰度工作变得简单且低风险。

未来很多技术产品的竞争优势将体现于它能否与 Service Mesh 形成无缝整合。

无缝整合的核心驱动力，源于用户对技术产品的易用性和应用可移植性的需要。基于这一认识，阿里巴巴正在将 RocketMQ/MetaQ 消息系统的客户端中的重逻辑剥离到 Envoy 这一 Sidecar 中（思路依然是“下沉”），同时基于 Service Mesh 所提供的能力做一定的技术改造，以便 RocketMQ/MetaQ 能很好地支撑应用的灰度发布。类似这样的思考与行动，相信未来会在更多的技术产品上出现。

再次，Service Mesh 给技术基础设施如何与业务基础技术更好地协同提供了一次探索机会。

每一种业务（比如电商）都会构建基于所在领域的基础技术，这类技术我们称之为业务基础技术。当阿里巴巴希望将某一业务的基础技术搬到外部去服务客户时，面临业务基础技术如何通过服务化去满足客户已选择的、与业务基础技术不同的编程语言的问题，否则会出现基于 Java 构建的业务基础技术很难与 Go 所编写的应用协同。

在 Service Mesh 致力于解决服务化问题的过程中，能否通过一定的技术手段，让业务基础技术的能力通过插件的形式“长”在 Service Mesh 之上是一个很值得探索的点。当业务基础技术以插件的形式存在时，业务基础技术无需以独立的进程存在而取得更好的性能，且这一机制也能被不同的业务复用。阿里巴巴的 Service Mesh 技术方案所采用的 Sidecar 开源软件 Envoy 正在积极地探索通过 Wasm 技术去实现流量处理的插件机制，将该机制进一步演变成为业务基础技术插件机制是值得探索的内容。

下图示例说明了业务基础技术的插件机制。

图中两个彩色分别代表了不同的业务（比如一个代表电商，另一个代表物流），两个业务的基础技术并非开发了两个独立的应用（进程）然后做发布和运维管理，而是基于 Wasm 所支持的编程语言实现了业务技术插件，这一点可以理解为用多编程语言的方式解决业务服务化问题，而非强制要求采用与 Sidecar 一样的编程语言。插件通过 Service Mesh 的运维平台进行管理，包含安装、灰度、升级、监控等能力。