云原生技术范式颠覆

——从Spring Cloud到

Service Mesh框架重构之路

尊龙时凯

徐超

郭总在《数字化的力量》一书提到过：

数字化时代的新技术范式最典型的特征是以云原生为核心，，，，以大数据、
、、物联网
、、
、云计算、、可穿戴设备、、、区块链、、、人工智能等多种数字技术为通用技术。。与一百多年前的电力技术、、、两百多年前的蒸汽机技术一样
，
，，，这种新技术范式所包含的一系列通用技术正日益渗透到经济、、、、社会和生活的各个角落，，
，广泛应用于传统产业的各个领域。。

郭为.数字化的力量[M]. 北京：机械工业出版社，，，，2022.

作为新一代微服务架构体系，
，
，，Service Mesh技术有效地解决了Spring Cloud微服务架构和服务治理过程中的痛点问题，，，，一经推出便引起了很大的反响。。。。近几年来，，，
，伴随着云原生的热火朝天，，Service Mesh被推向了巅峰，，，从陌生走向大家的视界
。。。。对于初创企业或全新产品，，，选择 Service Mesh变得相对轻松很多，，，，毕竟不存在迁移的问题。。。。但对于大部分企业或成熟的产品体系，，这样大的架构转型就变得很难以实施，
，，需要多加权衡利弊，，，面对Service Mesh带来的好处，，不得不迫使向它靠拢。。

目前很多企业或产品还是采用基于SDK的传统微服务框架（例如
，，，，Dubbo、
、
、、Spring Cloud等）进行服务治理，
，，，而随着Service Mesh的普及
，
，，
，越来越多的企业开始布局自己的Service Mesh框架体系，
，但多数企业刚开始不会激进地将所有业务迁移至Serivice Mesh，，，毕竟这样风险太大、、、、收益太慢
。
。
。。像Java技术栈应用依然保留原框架
，
，，，而非Java技术栈应用采用Service Mesh框架，，不同开发语言可以用不同的技术框架，
，，但业务不能被框架割裂，
，，，那么在这两种架构体系下应用服务如何互联互通？？？？微服务如何统一治理？？？？传统微服务又如何平滑迁移至Service Mesh呢？？
？？

如何解决上述问题呢？？？今天我们就针对构建基于Spring Cloud向Service Mesh框架迁移过程中的诸多问题展开讨论，，，尽可能提供一套完善的解决方案和迁移思路，，
，，供大家参考。。。

01.背景

微服务是一个很大的概念，，不同人对它的理解都各不相同
，，
，，甚至在早期微服务架构中出现了一批四不像的微服务架构产品，，，，有人把单纯引入Spring Boot、、Spring Cloud框架也叫做微服务架构，，，实际上却只是将它作为服务的Web运行环境而已
。。。。

微服务纷纷落地，，并投入生产，，，但随着微服务规模的不断壮大，，，每增加一个微服务，，，，就可能会增加一些依赖的基础设施和第三方的配置，，，
，比如Kafka实例配置等，，，相应CI/CD的配置也会增加或调整。。
。同时随着微服务数量增多、、、
、业务复杂性的提升及需求的多样性等（如，，，对接第三方异构系统等），，服务间通信的错综复杂，，，
，一步步地将微服务变得更加臃肿，，，，服务治理也是难上加难
，
，而这些问题在单体架构中却是很容易解决。。
。。为此，
，，有人开始怀疑当初微服务化是否是明智之选
，，甚至考虑回归到传统单体应用。。

正如下图所示，
，PPT中的微服务总是美好的，，但现实中的微服务却是一团糟糕，，想甩甩不掉
，，越看越糟心
。
。
。
。难道就没有办法了么？？？？

1.1

传统微服务架构面临的挑战

面对上述暴露出的问题，
，，，并在传统微服务架构下，，经过实践的不断冲击，，面临了更多新的挑战，
，，，综上所述
，，，，产生这些问题的原因有以下这几点：

● 过于绑定特定技术栈。。当面对异构系统时
，，需要花费大量精力来进行代码的改造，，
，不同异构系统可能面临不同的改造。。

● 代码侵入度过高
。
。。。开发者往往需要花费大量的精力来考虑如何与框架或 SDK结合，
，并在业务中更好的深度融合，，，，对于大部分开发者而言都是一个高曲线的学习过程。。。。

● 多语言支持受限。。。微服务提倡不同组件可以使用最适合它的语言开发，，
，但是在Spring Cloud框架下就是Java的天下，，，多语言的支持难度很大
。。。
。这也就导致在面对异构系统对接时的无奈
，，，，或退而求其次的方案。。。

● 老旧系统维护难
。。
。面对老旧系统，
，，，很难做到统一维护、、治理、、监控等，，在过度时期往往需要多个团队分而管之，
，，维护难度加大。。

上述这些问题都是在所难免，，众所周知技术演进来源于实践中不断的摸索
，，
，将功能抽象、、
、解耦
、、、、封装、、、服务化。。。随着传统微服务架构暴露出的这些问题，，将迎来新的挑战、、
、新的机遇，，让大家纷纷寻找其他解决方案。。。。

1.2

迎来新一代微服务架构

为了解决传统微服务面临的问题，
，，
，以应对全新的挑战，，，微服务架构也进一步演化，，，最终催生了Service Mesh的出现，
，迎来了新一代微服务架构。。。为了更好地理解Service Mesh的概念和存在的意义，，，我们来回顾一下这一演进过程。。

1.2.1 耦合阶段

在微服务架构中
，，服务发现、
、熔断、、、治理等能力是微服务架构重要的组成部分
。。。微服务化之后，，，，服务更加的分散，，，复杂度变得更高，，起初开发者将诸如熔断、
、、超时等功能和业务代码封装在一起，，使服务具备了网络控制能力，，，如下图所示：

这种方案虽然易于实现，
，，但从设计角度来讲却存在一定的缺陷。。。

● 基础设施功能（如，，，，服务发现
，，，，负载均衡、、、、熔断等）和业务逻辑高度耦合。。
。

● 每个微服务都重复实现了相同功能的代码。。

● 管理困难。
。。。如果某个服务的负载均衡发生变化，
，，，则调用它的相关服务都需要更新变化。。。

● 开发者不能集中精力只关注于业务逻辑开发。。。
。

1.2.2 公共库SDK

基于上面存在的问题，，，便想到将基础设施功能设计为一个公共库SDK，，，，让服务的业务逻辑与这些功能分离，，，
，降低耦合度，
，提高重复利用率
，，使得开发者只需要关注公共库SDK的依赖及使用，
，，不必关注实现这些公共功能，，从而更加专注于业务逻辑的开发，，，
，比如Spring Cloud框架是类似的方式。。如下图所示：

实际上即便如此
，，它仍然有一些不足之处。。。
。

● 这些公共库SDK存在较为陡峭的学习成本
，
，需要耗费开发人员一定的时间和人力与现有系统集成，，，，甚至需要考虑修改现有代码进行整合。。。

● 这些公共库SDK一般都是通过特定语言实现，，缺乏多语言的支持
，，在对现有系统整合时有一定的局限性。。。。

● 公共库SDK的管理和维护依然需要耗费开发者的大量精力，
，，并需专门人员来进行管理维护
。。。

1.2.3 Sidecar模式

基于公共库SDK的启发，，加上跨语言问题
、、更新后的发布和维护等问题，，，
，人们发现更好的解决方案是把它作为一个代理，，，，服务通过这个透明的代理完成所有流量的控制。。。。

这就是典型的Sidecar代理模式，，，也被翻译为边车代理，，，它作为与其他服务通信的桥梁，，为服务提供额外的网络特性，，
，并与服务独立部署
，
，对服务零侵入，，，，更不会受限于服务的开发语言和技术栈，，如下图所示：

● 以Sidecar模式进行通信代理，，，实现了基础实施层与业务逻辑的完全隔离，，，在部署、、、、升级时带来了便利，
，，，做到了真正的基础设施层与业务逻辑层的彻底解耦。。。。另一方面
，，，Sidecar可以更加快速地为应用服务提供更灵活的扩展
，，而不需要应用服务的大量改造。。。

于是
，，，应用服务终于可以做到跨语言开发、、、并更专注于业务逻辑的开发。
。
。

1.2.4 Service Mesh

把Sidecar模式充分应用于一个庞大的微服务架构系统，
，，为每个应用服务配套部署一个Sidecar代理
，
，完成服务间复杂的通信
，
，最终得到一个如下所示的网络拓扑结构，，，这就是Service Mesh，，
，又称之为“服务网格”。
。。。

至此，，迎来了全新一代微服务架构——Service Mesh，
，，
，它将彻底解决了传统微服务架构所面临的问题
。。
。
。

1.3

什么是Service Mesh

在开始进入主题之前，
，，我认为有必要再对Service Mesh进行统一的阐述
，，，，这样将有助于理解它，，
，，更加便于阅读接下来的内容。
。。

1.3.1 Service Mesh介绍

Service Mesh翻译为“服务网格”，，，作为服务间通信的基础设施层。。轻量级高性能网络代理
，
，，提供安全的、、
、、快速的、、
、可靠地服务间通讯，，与实际应用部署一起，，，，但对应用透明
。。应用作为服务的发起方，
，，，只需要用最简单的方式将请求发送给本地的服务网格代理，，，
，然后网格代理会进行后续的操作，，，，如服务发现，，
，负载均衡，，最后将请求转发给目标服务。。。。

Service Mesh目的是解决系统架构微服务化后的服务间通信和治理问题。。服务网格由Sidecar节点组成，
，，这个模式的精髓在于实现了数据面（业务逻辑）和控制面的解耦。
。具体到微服务架构中，，，，即给每一个微服务实例同步部署一个Sidecar。。

在Service Mesh部署网络结构图中，，，绿色方块为应用服务，，蓝色方块为 Sidecar，，，，应用服务之间通过Sidecar进行通信，
，，，整个服务通信形成图中的蓝色网络连线，，，，图中所有蓝色部分就形成了Service Mesh。。其具备如下主要特点：

● 应用程序间通讯的中间层。。。。

● 轻量级网络代理
。。。。

● 应用程序无感知。。。

● 解耦应用程序的重试/超时、
、、监控、、、、追踪和服务发现。。。。

Service Mesh的出现解决了传统微服务框架中的痛点，
，，，使得开发人员专注于业务本身，，
，，同时，
，
，将服务通信及相关管控功能从业务中分离到基础设施层。
。。。

1.3.2 Service Mesh的功能

Service Mesh作为微服务架构中负责网络通信的基础设施层
，，，具备网络处理的大部分功能
。。。
。下面列举了一些主要功能：

● 动态路由。。。可通过路由规则来动态路由到所请求的服务，
，，便于不同环境、、、不同版本等的动态路由调整。。。

● 故障注入。。。通过引入故障来模拟网络传输中的问题（如延迟）来验证系统的健壮性，，方便完成系统的各类故障测试。。。

● 熔断。。通过服务降级来终止潜在的关联性错误。。
。

● 安全。。在Service Mesh上实现了安全机制（如TLS），
，，并且很容易在基础设施层完成安全机制更新。。

● 多语言支持
。
。。作为独立运行且对业务透明的Sidecar代理，，Service Mesh很轻松地支持多语言的异构系统。。

● 多协议支持。。同多语言一样
，，也支持多协议。。

● 指标和分布式链路追踪。。

概括起来，，，
，Service Mesh主要体现在以下4个方面
：

● 可见性：运行时指标遥测、、分布式跟踪
。
。。
。

● 可管理性：服务发现、、负载均衡、、、、运行时动态路由等。。。

● 健壮性：超时、、重试、
、
、、熔断等弹性能力。
。

● 安全性：服务间访问控制、、、、TLS加密通信
。。

1.3.3 Service Mesh解决什么问题

Service Mesh主要解决用户如下3个维度的痛点需求：

● 完善的微服务基础设施

通过将微服务通信下沉到基础设施层，，
，，屏蔽了微服务处理各种通信问题的复杂度
，，，形成微服务之间的抽象协议层。。。开发者无需关心通信层的具体实现
，
，，也无需关注RPC通信（包含服务发现、、、、负载均衡
、、、、流量调度
、、、流量降级、、、监控统计等）的一切细节，，真正像本地调用一样使用微服务
，，通信相关的一起工作直接交给Service Mesh。。
。。

● 语言无关的通信和链路治理

功能上，
，，，Service Mesh并没有提供任何新的特性和能力
，
，，Service Mesh提供的所有通信和服务治理能力在Service Mesh之前的技术中均能找到，，比如Spring Cloud就实现了完善的微服务RPC通信和服务治理支持。。

Service Mesh改变的是通信和服务治理能力提供的方式，
，，通过将这些能力实现从各语言业务实现中解耦，，下沉到基础设施层面，，以一种更加通用和标准化的方式提供，，，，屏蔽不同语言、、、不同平台的差异性，
，
，，有利于通信和服务治理能力的迭代和创新
，，使得业务实现更加方便。
。。

Service Mesh避免了多语言服务治理上的重复建设，，通过Service Mesh语言无关的通信和服务治理能力，，，，助力于多语言技术栈的效率提升。。

● 通信和服务治理的标准化

■ 微服务治理层面，
，，Service Mesh是标准化、
、
、
、体系化
、
、无侵入的分布式治理平台。。。

■ 标准化方面，，，
，Sidecar成为所有微服务流量通信的约束标准，，
，，同时Service Mesh的数据平台和控制平面也通过标准协议进行交互
。。。
。

■ 体系化方面，，，从全局考虑，，
，提供多维度立体的微服务可观测能力（Metric、、
、、Trace
、、、Logging），
，并提供体系化的服务治理能力，，，如限流、、
、熔断、、安全、、灰度等。
。。

通过标准化，，，带来一致的服务治理体验
，
，减少多业务之间由于服务治理标准不一致带来的沟通和转换成本，，，提升全局服务治理的效率。。

1.4

框架迁移迫在眉睫

为了更好的占领市场，，，满足更多业务场景的需求，，
，传统微服务架构（如，，基于Spring Cloud框架的微服务架构）面临了众多新的挑战，，而Service Mesh的出现正好解决了这些问题。
。
。面对新的框架体系，
，对于传统微服务架构该如何应对？？？？

对于Spring Cloud框架的微服务向Service Mesh框架迁移必将迫在眉睫，，，是推翻重来，，还是循序迁移？？？
？如果迁移，
，又该如何？？？？

（上篇完）