J9集团

云原生技术范式颠覆

——从Spring Cloud到

Service Mesh框架沉构之路

J9集团信息

徐超

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

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

郭为.数字化的力量[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框架迁徙必将火烧眉毛，是颠覆沉来，还是循序迁徙？若是迁徙，又该若何？

（上篇完）