数字中国·星火文集 | 云原生技术范式颠覆——从Spring Cloud到Service Mesh框架重构之路（下篇） - pg电子官方网站新闻

中|EN

合作咨询

首页 > pg电子官方网站新闻 > 数字中国·星火文集 | 云原生技术范式颠覆——从Spring Cloud到Service Mesh框架重构之路（下篇）

数字中国·星火文集 | 云原生技术范式颠覆——从Spring Cloud到Service Mesh框架重构之路（下篇）

发布时间：2022-06-16
来源：
大中小
打印

云原生技术范式颠覆

——从Spring Cloud到

Service Mesh框架重构之路

pg电子官方网站

徐超

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 资源配置，以实现服务间互通，统一治理，整个实现逻辑架构如下图所示。