Service Mesh 是新瓶装旧酒吗？

点击下载《不同的 双11 技术：阿里巴巴经济体云原生实践》

本文节选自《不同的 双11 技术：阿里巴巴经济体云原生实践》一书，点击上方图片便可下载！

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

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

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 所带来的第二个变化在于：技术平台的建设从面向单一编程语言向面向多编程语言转变。

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

• 第一，技术平台的能力须要尽量地服务化，避免由于服务化不完全而须要引入 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 的运维平台进行管理，包含安装、灰度、升级、监控等能力。

因为插件是“长”在 Service Mesh 之上的，插件化的过程就是业务技术服务化的过程。

另外，Service Mesh 须要提供一种选择能力，让业务的应用开发者或运维者选择本身的机器上须要哪些插件（能够理解为插件市场）。另外一个值得关注的点是：插件的运维和管理能力以及必定的质量保证手段由 Service Mesh 平台提供，但运维、管理和质量保证的责任由各插件的提供者承担。这种划分将有效地杜绝全部插件的质量由 Service Mesh 平台去承担而带来的低效，分而治之还是改善不少工程效率的良方。

• 最后，Service Mesh 给探索面向将来的异地多活、应用永远在线的总体技术解决方案打开了一扇大门。

服务之间的互联互通，服务流量的控制、观测和安全加固是微服务软件架构下所要解决的关键问题，这些问题与规模化下的服务可用性和安全性紧密相关。将来，经过 Service Mesh 的流量控制能力能作不少改善应用发布和运维效率的文章，那时才能真正看到一个灵动、称手的云平台。

<a name="rPDIm"></a>

Service Mesh 的“三位一体”发展思路

阿里巴巴做为云计算技术的供应商，在探索 Service Mesh 技术的道路上，不仅是考虑如何让云原生技术红利在阿里巴巴内部兑现，同时还思考着如何将技术红利带给更多的阿里云客户。基于此，阿里巴巴就 Service Mesh 的总体发展思路遵循“三位一体”，即阿里巴巴内部、阿里云上的相应商业产品和开源软件将采用同一套代码。

就咱们与阿里云客户交流的经验来看，他们乐于尽最大可能采用非云厂商所特有的技术方案，以避免被技术锁定而在将来的发展上出现掣肘。另外，他们只有采纳开源的事实标准软件才有可能达成企业的多云和混合云战略。基于客户的这一诉求，咱们在 Service Mesh 的技术发展上特别重视参与开源事实标准的共建。在 Istio 和 Envoy 两个开源项目上，咱们都会致力于将内部所作的那些优化反哺给开源社区。

将来，咱们将在 Service Mesh 领域坚决而扎实地探索，也必定会将探索成果和思考持续地分享给你们。

本书亮点

• 双11 超大规模 K8s 集群实践中，遇到的问题及解决方法详述
• 云原生化最佳组合：Kubernetes+容器+神龙，实现核心系统 100% 上云的技术细节
• 双 11 Service Mesh 超大规模落地解决方案

“阿里巴巴云原生微信公众号（ID：Alicloudnative）关注微服务、Serverless、容器、Service Mesh等技术领域、聚焦云原生流行技术趋势、云原生大规模的落地实践，作最懂云原生开发者的技术公众号。”