J9集团

云原生技术范式颠覆

——从Spring Cloud到

Service Mesh框架沉构之路

J9集团信息

徐超

02.Service Mesh迁徙规划

对于还未涉足Service Mesh 的企业或产品，其传统微服务架构如若已选取 Spring Cloud 框架构建，此时向Service Mesh 框架迁徙又该若何做？必要综合思考哪些成分？是否有依可据？

接下来，就构建基于Spring Cloud向 Service Mesh 框架迁徙提供一些建议规划和思路，供各人参考。

2.1

迁徙场景

传统微服务框架，以最为典型的Spring Cloud 框架为例进行迁徙注明。首先，先看一下这样的一个迁徙场景，目前的微服务架构如下图左边部门：

● 利用是部署在虚构机或物理机上。（服务还未容器化）。

● 框架是基于 Spring Cloud 框架开发。（服务中蕴含的业务逻辑和 Spring Cloud 组件相依赖，业务和框架高度耦合）

● 开发说话以Java为主。（存在跨说话的问题）

● 注册中心选取的是 Consul 或 Eureka。（服务需引入注册中心依赖包，存在肯定的耦合）

目前开源 Istio 已经成为 Service Mesh 事实上的尺度，更是新一代微服务架构发展的趋向，因而公司但愿尝试迁徙到 Istio 框架，但愿最终形成类似上图的右边部门。

2.2

迁徙蹊径

面对上述迁徙场景，确定要引入 Service Mesh 前，必要彻底搞明显 Service Mesh 迁徙的具体蹊径。

首先，要对自己项目做以下评估：

● 是否真的有必要引入迁徙到 Service Mesh 上？

● 当前微服务架构下，是否面对传统微服务架构面对的挑战？

● 当前微服务架构，是否已经故障或影响未来业务的发展？

● 公司或技术团队，是否有能力、人力、精力来投入到 Service Mesh 的迁徙？

其次，实现 Service Mesh 微服务平台的搭建。当前所处阶段是否已经支持容器化和 Kubernetes。若是当前业务已经运行在 Kubernetes 之上，则 Service Mesh 的迁徙将会比力顺畅；若是当前业务没有运行在Kubernetes上，因 Service Mesh 当前典型的 Istio 框架对 Kubernetes 有着过度依赖，所以可能就无法直接从 Spring Cloud 迁徙到 Istio 框架，即便定造批改 Istio 以接触对 Kubernetes 的依赖，将会支出很大的价值。这时通常有两条迁徙蹊径可供选择。

● 蹊径一：非 Kubernetes 环境下，先接入 Sidecar

若是当前业务没法急剧容器化，同时又有引入 Service Mesh 的火急需要，可采取先接入 Sidecar，来满足当前业务的痛点需要。在引入 Sidecar 时，要把稳其未来的演进方向，思考后续可能持续向 Service Mesh 迁徙，一旦机遇成熟并引入 Kubernetes 容器化后，则可能顺利由 Sidecar 的方式直接演进到 Service Mesh。

Service Mesh 当前典型的 Istio 框架在非 Kubernetes 下没有很好的支持（听说未来会齐全脱离对Kubernetes 的依赖），对 Istio 进行定造化批改以支持非 Kubernetes 环境将会支出很大的价值，非出格强烈的需要和壮大的技术储蓄，通常不建议这么做，出格是对于一些中幼公司而言。

若是肯定要在非 Kubernetes 环境下引入 Service Mesh，数据平面可使用 Envoy，节造平面可凭据 XDS 和谈进行自研。

● 蹊径二：先进行 Kubernetes 容器化刷新，再接入 Service Mesh

倘若公司有云平台或容器化团队，可选取公司资源共享的方式，先借助其他团队来实现 Kubernetes 容器化刷新，再接入 Service Mesh。

最后，基于构建的 Service Mesh 框架，将业务利用逐步迁徙到 Service Mesh 。

2.3

迁徙准则

在执行迁徙时，必必要时刻遵守以下迁徙准则。

● 渐进式迁徙： 为预防 Service Mesh 迁徙过程中的风险，必须选取渐进式迁徙准则，每次只迁徙少量服务，待迁徙后观察足够长的功夫，没有问题后再持续迁徙。

● 业务通明： 为削减 Service Mesh 迁徙对业务的影响，削减业务的迁徙阻力，迁徙初期必须确保业务齐全通明且不必要过多的调换和批改。

● 兼容性： 在迁徙阶段，必然会存在两种模式（ Spring Cloud 和 Service Mesh 框架）并存，在迁徙过程中必要充分思考两者的兼容性，使得迁徙前后网络买通，至少可能满足未迁徙和已迁徙部门可能通讯。

2.4

迁徙规划

从 Spring Cloud 向 Service Mesh 框架迁徙，大体上分为四个步骤：Spring Cloud 架构分析、容器化刷新、Service Mesh 微服务平台搭建和利用迁徙。

2.4.1 Spring Cloud架构分析

Spring Cloud 架构分析的主张在于沉新相识当前微服务架构下的所有职能，便于在向 Service Mesh 迁徙时做筹备，思考哪些职能必要迁徙，哪些不必要迁徙，哪些必要刷新等。如下图所示是基于 Spring Cloud 齐全构建的微服务架构解决规划。

从上图经过度析，能够汇总得知它重要由以下几部门组成：

● 代理&网关：提供统一对表或对内的接见入口，蕴含路由、鉴权、限流、熔断、降级等统一处置。

● 注册中心：提供服务的注册与发现职能。

● 利用服务：覆盖整个业务服务，蕴含业务逻辑实现、框架SDK及表部组件依赖交互等。

● 中央件&数据存储：为利用服务提供额表的支持能力。

● CI&CD：持续集成、持续部署。

上述这几部门中哪些内容是我们能够去掉或者是基于 Service Mesh （以 Istio 为例）可能去做的？经过度析得知，能够代替的组件蕴含网关（Gateway 或者 Zuul，由 Ingress gateway 或者 egress 代替），熔断器（hystrix，由 Sidecar 代替），注册中心（Eureka 及 Eureka client，由 Polit，Sidecar 代替），负载平衡（ Ribbon，由 Sidecar 代替）等。

此阶段，我们可能大体知路 Spring Cloud 中的哪些内容能够由 Istio 处置，哪些内容能够持续沿用。

2.4.2 容器化刷新

容器化刷新，重要针对目前还未引入 Kubernetes 容器化的场景。在容器化刷新之前，有必要知路刷新的优势及要求。

容器化刷新优势：

● 更。杭蟮淖试蠢眯， 最大限度榨取和共享物理资源，多项目更能体现出容器化的优势，节约部署 IT 成本。

● 更快：秒级启动，实现业务系统更快的开发迭代和交付部署。

● 弹性：凭据业务负载进行弹性容器伸缩，弹性扩大。

● 方便：容器化业务部署支持蓝绿/灰度/金丝雀等颁布，回滚，越发矫捷方便。

● 矫捷：监控底层 node 节点健康状态，矫捷调度至最优节点部署。

● 强一致性：容器将环境和代码打包在镜像内，保障了测试与出产环境的强一致性。

容器化刷新要求：

● 把握 Docker 技术：开发人员需熟悉 Docker 容器化技术，纯熟编写 Dockerfile 文件。

● 把握 Kubernetes 编排系统：熟悉 Kubernetes 容器化编排系统，熟悉各组件资源清单编写、高可用、 RBAC 安全战术等。

容器化刷新，重要分为以下两个阶段：

● 容器化构建：将基于 Spring Cloud 搭建的所有服求实现容器化构建，实现 Docker 镜像打包。

● 容器化治理：基于 Kubernetes 或容器云平台进行服务容器的治理。

2.4.3 Service Mesh 微服务平台搭建

Service Mesh 框架拔取业界典型的 Istio 框架。

2.4.3.1 Istio基础框架搭建

基于 Istio 框架搭建 Istio 基础框架，在节造平面和数据平台别离提供以下能力：

● 节造平面：提供服务?格节造指令下发、服务配置、权限节造等职能。

● 数据平台：提供服务治理、服务监控及运维、流量管控等职能。

上述Spring Cloud的职能在 Istio 框架上都能找到对应的职能，并通过适当的资源清单配置即可实现。

Istio 架构图如下：

至此，一个 Istio 基础框架搭建实现，可能提供 Service Mesh 的所有能力。

2.4.3.2 Istio扩大和定造

在迁徙蹊径中已经提及过，对于非Kubernetes 环境，建议先引入 Sidecar，并采取 Istio 对虚构机的支持规划，在虚构机环境下运行。但若是有多平台支持的场景，好比寂仔 Kubernetes 环境，又有虚构机环境，需对 Istio 进行定造化刷新，去掉对 Kubernetes 的强依赖和耦合，增长对其他平台的支持。（对于多平台的支持，目前Istio 还未支持，但从 Istio 官方有关文档能够看出，多平台的支持最终注定支持，我们只需拭目以待。）

Istio对 Kubernetes 的耦合重要有以下几个方面，因而必要针对性的适配批改。

（1）API资源治理层对 Kubernetes API Server 的依赖

资源治理层是Istio 对 Kubernetes 依赖最大的处所。Istio 对主题资源的治理，是以 Kubernetes CRD 为基础，并使用 kubectl 作为号令行操作入口，kubectl 挪用 API Server，将资源存放在 etcd 中，并通过 Kubernetes CRD 机造触发资源调换事务通知，通知关切 Istio 资源调换事务的？榻杏泄卮χ。

如需解除Istio对 Kubernetes 的绑定，则必要自行实现这一套API治理方式，并且做到平台无关。

（2）通讯接见层面对kube DNS 的依赖

通讯层面，在客户端发送要求前，先通过DNS 获取服务的虚构IP地址，Istio 的 DNS 实现沿用Kubernetes DNS 规划，基于 DNS 通过服务名实现直接接见。因而必要在 DNS 规划层面接触和Kubernetes 的耦合，并使用平台无关的 DNS 解决规划。

2.4.3.3 两种框架并存

对于体量较大的业务，不成能一次性迁徙实现，需遵守“渐进式迁徙”准则，则现实迁徙过程中可能面对这样的诉求：

● 一些存量老业务运行在虚构机或者物理机上，临时没有容器化刷新打算，但但愿通过 Service Mesh 来做服务治理。

● 新上的业务或者存量的非关键业务能够做为试点，介绍器化、Service Mesh 化，其它业务依然选取原有的运行方式和微服务框架。

● 对于未迁徙的存量利用和迁徙实现的 Service Mesh 利用依然能维持业务上的互通。

面对上述这些真实而又合理的诉求，在进行 Service Mesh 微服务平台搭建时，必然会存在两种框架并存的场景，如下图所示，左边是未迁徙的存量服务，右边是容器化并 Service Mesh 化的试点服务，但这种模式服务间却是互不一样，且无法统一治理。

然而两种框架并存时，若何服务间互通，统一治理？

在业内盛行这样一句话：推算机科学领域的任何问题都能够通过增长一个间接的中央层来解决。

同样，我们能够针对 Service Mesh 的节造平面做些文章，通过自界说节造插件（WASM）将 Spring Cloud 框架中原有注册中心的职能纳入进来，由节造平面提供原有服务注册与发现的能力，并结合 Istio 中入口网关 Ingress 和 ServiceEntry 资源配置，以实现服务间互通，统一治理，整个实现逻辑架构如下图所示。

至此，实现了基于Spring Cloud和 Istio 两种框架的并存。

2.4.4 利用迁徙

到这里，已经实现了 Service Mesh 微服务平台的搭建，在这样的平台上我们若何将Spring Cloud 利用逐步向 Service Mesh 迁徙？

2.4.4.1 去除沉叠职能

先来看一下 Spring Cloud 框架与 Istio 框架的职能沉叠情况：

从上表职能对比分析，存在大量的沉叠职能，需将Spring Cloud 与 Istio 中沉叠职能去除，缺失职能保留，理论上可轻松去沉。对于 Spring Cloud 而言，这些沉叠职能大部门只需去除 pom.xml 中依赖包、有关配置及代码中注解即可轻松实现，渣滓一个相对干净的利用。

2.4.4.2 利用注入

利用注入是指在将利用服务部署到网格时，将 Sidecar 注入到利用服务中，以实现网格的代理。

Sidecar 注入，分为手动注入和自动注入：

● 手动注入：通过手动执行 istioctl kube-inject 来沉新机关利用的 CRD yaml。

● 自动注入：通过 Kubernetes 的 mutable webhook 回调 istio-sidecar-injector 服务来沉新机关利用的 CRD yaml。

如下图所示：

无论是手动注入还是自动注入，Sidecar 注入的性质是将运行 Sidecar 所必要的镜像地址、启动参数、所衔接的 Istio 集群及配相信息填充到注入模版，并增长到利用的 CRD yaml 中，最终通过 Kubernetes 悠久化资源并拉起利用和 Sidecar 的 POD。

此时，利用已成功迁徙部署到 Service Mesh 。

03.总结

正如《数字化的力量》一书中所说：

这种升级刷新和技术范式的转换并不是在一夜之间实现的,数字技术必要通过在社会经济的各个方面进行逐步利用,通过量的堆集进而最终引起质的飞跃,使我们从新的技术范式的形成阶段进入到不变发展阶段。

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

这篇文章从传统微服务架构起头一步步介绍到Service Mesh，并提出了传统微服务架构面对的挑战，针对近况，为了更好的满足市场需要，而不被市场裁减，介绍了传统微服务若何滑润迁徙到 Service Mesh 的过程，并给出了一些解决规划、步骤及思路，供各人参考。

参考资料

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

https://istio.io/latest/docs/concepts/what-is-istio/

刘俊海.Service Mesh微服务架构设计[M].北京：机械工业出版社，2019.

https://mp.weixin.qq.com/s/y9PZLgHhVcdsMuTzAyIMsQ

https://www.servicemesher.com/blog/service-mesh-rebuild-microservice-market/

https://mp.weixin.qq.com/s/-MszFJORuDJKf3V5ndyimw

https://www.servicemesher.com/blog/netease-yeation-service-mesh/

（下篇完）