CN112783570A - 基于服务网格的应用迁移方法、系统和介质 - Google Patents

Abstract

本公开涉及一种基于服务网格的应用迁移方法、系统和介质。其中所述服务网格基于SpringCloud框架集成，所述方法包括：步骤S1、在Kubernetes集群中部署所述服务网格和微服务平台组件；步骤S2、通过配置DockerFile构建经打包的java程序的镜像，将所述镜像发送至镜像仓库；以及步骤S3、在容器云平台中的服务网格中注入代理以实现所述应用的迁移。该方法将使用SpringCloud开发的微服务系统迁移到服务网格平台时，无需手动去除已引入的原生SpringCloud框架中组件依赖，同时减少系统稳定性风险。

Description

基于服务网格的应用迁移方法、系统和介质

技术领域

本公开涉及数据迁移领域，更具体地，涉及一种基于服务网格的应用迁移方法、系统和介质。

背景技术

微服务架构将单体系统按照业务划分为一组小服务，每个服务独立开发、部署、运维，并运行在不同的进程中，通过轻量级的通讯方式相互调用，各服务互相配合，为用户提供最终价值。近些年，无数的架构师和开发者针对不同场景的各种问题提供了多种解决方案和开源框架，其中SpringCloud是一个解决微服务架构实施问题的综合性框架，它整合了很多第三方组件并创建了一些非常优秀的边缘组件，稳定性高，它为微服务架构中设计的配置管理、服务治理、断路器、智能路由等提供了简单的开发方式。

在云计算的快速发展下，云原生的概念也应运而生。云原生是将应用程序运行在云上的一套技术体系，即采用开源技术栈将应用程序进行容器化部署，基于微服务架构提高应用的灵活性和可维护性，并借助敏捷开发、DevOps持续迭代和自动化运维等方法，充分利用云平台的弹性伸缩和分布式等优势，从而实现动态调度资源、服务解耦、横向扩容、持续交付。在云原生技术体系中，容器编排技术Kubernetes是基石，它是一个基于容器技术的分布式系统支撑平台，其中的Service机制具有服务注册、服务发现和负载均衡功能，Kubernetes具有强大的集群管理能力和故障发现以及自我修复能力，可进行服务的滚动升级和在线扩容，自动调动可扩展资源，极大的简化了用户的运维，提升了资源的弹性，真正的做到了按需使用，降低了用户的成本。

从微服务的工具集来看，Kubernetes本身支持微服务架构，将微服务部署到Pod中，可实现微服务之间的相互访问，但是服务间访问的管理如熔断、限流、动态路由、链路追踪等都不在Kubernetes的能力范围内，服务网格技术Istio可以很好地解决这一问题。

服务网格是一种处理服务间通讯的基础设施层，负责服务之间的网络调用、限流、熔断和监控，服务网格尤其适用于在云原生场景下，帮助应用程序在复杂的服务拓扑间可靠地传递请求。在传统SpringCloud框架中，将服务治理的公共逻辑抽象出成一个公共库，通过SDK的形式在各微服务中引用，业务代码与治理逻辑在同一个进程中，由于这些服务治理大部分都是基于Java开发，则业务代码必须与SDK使用同一种语言。而Istio使用一种Sidecar模式，将治理逻辑彻底从用户的业务代码中剥离出来，用户的业务代码与治理逻辑处于独立的进程中，二者的代码和运行无耦合，且适配各种开发语言。

目前，将使用SpringCloud开发的微服务系统迁移到服务网格平台,并使用Kubernetes自身提供的服务注册发现及负载均衡能力和服务网格的流量治理能力时，目前的解决方案就是手动去除已引入的原生SpringCloud框架中Eureka、Ribbon组件依赖，并重写业务代码，调用Kubernetes提供的接口。这大大增加企业成本，降低开发效率，增加系统稳定性风险；企业需要维护新老两套系统，增加系统维护成本。

发明内容

提供了本公开以解决现有技术中存在的上述问题。

公开了一种基于服务网格的应用迁移方案，其仅需简单引入依赖，即可将基于SpringCloud开发的微服务系统快速迁移到服务网格平台中，无缝对接，侵入性小，无需重构代码，效率高。企业只需维护一套系统，当需要将系统从服务网格平台中回退至微服务系统，只需删除依赖即可，维护成本大大降低。

根据本公开的第一方面，提供了一种基于服务网格的应用迁移方法。所述方法包括：步骤S1、在Kubernetes集群中部署所述服务网格和微服务平台组件；步骤S2、通过配置DockerFile构建经打包的java程序的镜像，将所述镜像发送至镜像仓库；以及步骤S3、在容器云平台中的服务网格中注入代理以实现所述应用的迁移。

具体地，在所述步骤S1中，部署的所述微服务平台组件包括注册中心和配置中心。

具体地，在所述步骤S2中，利用依赖管理工具来打包所述java程序。

具体地，在步骤S3中，通过以下方式之一来注入所述代理：设置所述Kubernetes的命名空间标签；使用kubectl label namespace default istio-injection＝enabled命令；以及通过yaml文件，使用istioctl kube-inject-f xxx.yaml命令。

具体地，通过以下方式之一来关闭注入所述代理：设置所述Kubernetes的命名空间标签；以及使用kubectl label namespace default istio-injection＝disabled命令。

根据本公开的第二方面，提供了一种基于服务网格的应用迁移系统。所述系统包括：部署单元，被配置为，在Kubernetes集群中部署所述服务网格和微服务平台组件；构建单元，被配置为，通过配置DockerFile构建经打包的java程序的镜像，将所述镜像发送至镜像仓库；以及注入单元，被配置为，在容器云平台中的服务网格中注入代理以实现所述应用的迁移。

具体地，部署的所述微服务平台组件包括注册中心和配置中心；以及所述构建单元进一步被配置为，利用依赖管理工具来打包所述java程序。

具体地，所述注入单元进一步被配置为，通过以下方式之一来注入所述代理：设置所述Kubernetes的命名空间标签；使用kubectl label namespace default istio-injection＝enabled命令；以及通过yaml文件，使用istioctl kube-inject-f xxx.yaml命令。

具体地，所述注入单元进一步被配置为，通过以下方式之一来关闭注入所述代理：设置所述Kubernetes的命名空间标签；以及使用kubectl label namespace defaultistio-injection＝disabled命令。

根据本公开的第三方面，一种存储有指令的非暂时性计算机可读介质，当所述指令由处理器执行时，执行根据本公开第一方面中任一项所述的基于服务网格的应用迁移方法中的步骤。

综上，本公开的技术方案仅需简单引入依赖，即可将基于SpringCloud开发的微服务系统快速迁移到服务网格平台中，无缝对接，侵入性小，无需重构代码，效率高。企业只需维护一套系统，当需要将系统从服务网格平台中回退至微服务系统，只需删除依赖即可，维护成本大大降低。

附图说明

在不一定按比例绘制的附图中，相同的附图标记可以在不同的视图中描述相似的部件。具有字母后缀或不同字母后缀的相同附图标记可以表示相似部件的不同实例。附图大体上通过举例而不是限制的方式示出各种实施例，并且与说明书以及权利要求书一起用于对所公开的实施例进行说明。在适当的时候，在所有附图中使用相同的附图标记指代同一或相似的部分。这样的实施例是例证性的，而并非旨在作为本装置或方法的穷尽或排他实施例。

图1示出了根据本公开实施例的服务网格适配器框架初始化流程图；

图2示出了根据本公开实施例的服务网格适配器框架微服务间网络通讯流程图；

图3示出了根据本公开实施例的基于服务网格的应用迁移方法的流程图；以及

图4示出了根据本公开实施例的基于服务网格的应用迁移系统的结构图。

具体实施方式

为使本领域技术人员更好的理解本公开的技术方案，下面结合附图和具体实施方式对本公开作详细说明。下面结合附图和具体实施例对本公开的实施例作进一步详细描述，但不作为对本公开的限定。本文中所描述的各个步骤，如果彼此之间没有前后关系的必要性，则本文中作为示例对其进行描述的次序不应视为限制，本领域技术人员应知道可以对其进行顺序调整，只要不破坏其彼此之间的逻辑性导致整个流程无法实现即可。

下面将结合附图详细说明根据本公开实施例的基于服务网格Istio的应用迁移方案。

图1示出了根据本公开实施例的服务网格适配器框架初始化流程图，如图1所示，在原有SpringCloud应用基础上引入服务网格适配器框架。当应用启动时，服务网格适配器框架会根据标识判断当前运行环境为容器环境或者是虚拟机/物理机环境。当运行环境为虚拟机/物理机环境时，框架会采用原生SpringCloud框架初始化的方式进行。当运行环境为容器环境时，框架会跳过SpringCloud所有服务治理组件的初始化，但会读取SpringCloud核心服务治理组件的配置，例如Ribbon组件的负载均衡策略、请求超时时间，重试次数等，Hystrix组件的熔断限流策略等。并对SpringCloud核心服务治理组件的配置进行汇总、清洗、计算，生成服务治理适配器。通过拼装成Kubernetes中CustomResourceDefinition资源的形式向Istio下发。此时原有SpringCloud应用中所有在服务网格适配器框架中可兼容的服务治理策略都将无感迁移至Istio中。

图2示出了根据本公开实施例的服务网格适配器框架微服务间网络通讯流程图，如图2所示，在源微服务应用需访问目标微服务应用时，首先会根据图2中初始化的结果生成SpringCloud原生Feign组件或框架自定义的Feign组件。当采用SpringCloud原生Feign组件时，会采用SpringCloud服务治理组件进行服务治理，例如使用Ribbon组件的负载均衡、请求超时控制，请求重试等，Hystrix组件的熔断限流等。当采用框架自定义Feign组件时，请求不会通过SpringCloud的服务治理组件，而是请求数据组件Envoy，而初始化时下发到Istio的服务治理能力，最终会在数据组件Envoy中生效。请求经过数据组件Envoy时，服务治理能力会自动生效，通过Istio拉取的服务列表进行寻址、超时、熔断限流等。

图3示出了根据本公开实施例的基于服务网格的应用迁移方法的流程图，如图3所示，在步骤S1，在Kubernetes集群中部署所述服务网格Istio和微服务平台组件。具体地，部署的所述微服务平台组件包括注册中心和配置中心。保证基础设施Kubernetes集群正常，并在Kubernetes集群中部署服务网格Istio，以及微服务注册中心、配置中心等微服务平台组件。

在步骤S2，通过配置DockerFile构建经打包的java程序的镜像，将所述镜像发送至镜像仓库。具体地，利用依赖管理工具来打包所述java程序。在原有微服务java程序中，通过maven、gradle等依赖管理工具，或者lib中加入jar包，执行maven package或gradlebuild打包java程序。编写DockerFile，将打包好的jar包或war包构建镜像，并推送至公司内部镜像仓库或者DockerHub。

在步骤S3，在容器云平台中的服务网格Istio中注入代理以实现所述应用的迁移。具体地，在公有容器云平台，或者私有容器云平台中部署服务通过以下方式之一来注入所述代理：设置所述Kubernetes的命名空间标签；使用kubectl label namespace defaultistio-injection＝enabled命令；以及通过yaml文件，使用istioctl kube-inject-fxxx.yaml命令。

在一些实施例中，发生前提是当云端的服务网格数据面、控制面或者其他基础设施出现可用性事故时，在公有容器云平台，或者私有容器云平台中修改服务。具体地，通过以下方式之一来关闭注入所述代理：设置所述Kubernetes的命名空间标签；以及使用kubectl label namespace default istio-injection＝disabled命令。修改环境标识和框架可以识别的标识或采用框架自动检测环境的方式使框架感知到环境的变化来激活逃生模式，采用Kubernetes原地重启或者滚动重启等策略对运行的容器进行重启。重启成功后，微服务体系注册中心已经存在该微服务，则成功逃生。

综上，本公开第一方面的技术方案仅需简单引入依赖，即可将基于SpringCloud开发的微服务系统快速迁移到服务网格平台中，无缝对接，侵入性小，无需重构代码，效率高。企业只需维护一套系统，当需要将系统从服务网格平台中回退至微服务系统，只需删除依赖即可，维护成本大大降低。

根据本公开的第二方面，提供了一种基于服务网格Istio的应用迁移系统。图4示出了根据本公开实施例的基于服务网格Istio的应用迁移系统的结构图，如图4所示，所述系统包括：部署单元401，被配置为，在Kubernetes集群中部署所述服务网格和微服务平台组件；构建单元402，被配置为，通过配置DockerFile构建经打包的java程序的镜像，将所述镜像发送至镜像仓库；以及注入单元403，被配置为，在容器云平台中的服务网格中注入代理以实现所述应用的迁移。

具体地，部署的所述微服务平台组件包括注册中心和配置中心；以及所述构建单元402进一步被配置为，利用依赖管理工具来打包所述java程序。

具体地，所述注入单元403进一步被配置为，通过以下方式之一来注入所述代理：设置所述Kubernetes的命名空间标签；使用kubectl label namespace default istio-injection＝enabled命令；以及通过yaml文件，使用istioctl kube-inject-f xxx.yaml命令。

具体地，所述注入单元403进一步被配置为，通过以下方式之一来关闭注入所述代理：设置所述Kubernetes的命名空间标签；以及使用kubectl label namespace defaultistio-injection＝disabled命令。

根据本公开的第三方面，一种存储有指令的非暂时性计算机可读介质，当所述指令由处理器执行时，执行根据本公开第一方面中任一项所述的基于服务网格的应用迁移方法中的步骤。

综上，本公开的各个方面使用服务网格适配器框架快速将原生SpringCloud微服务系统迁移至服务网格平台，能够在无任何业务代码侵入的前提下适配服务网格的调用模式，有效使用了服务网格提供的服务注册、服务发现、均衡负载、流量指令等功能；以及对原生SpringCloud与服务网格耦合的功能进行解耦，增强通讯时代码的调用效率，提高响应时间，增强应用性能。使用本公开提供的技术方案可以非常快捷方便完成从虚拟机或物理机向服务网格进行迁移；若迁移过程发生任何异常，系统回退也非常方便，为应用系统的稳定、安全、高效运行提供了保障。

注意，根据本公开的各个实施例中的各个单元，可以实现为存储在存储器上的计算机可执行指令，由处理器执行时可以实现相应的步骤；也可以实现为具有相应逻辑计算能力的硬件；也可以实现为软件和硬件的组合(固件)。在一些实施例中，处理器可以实现为FPGA、ASIC、DSP芯片、SOC(片上系统)、MPU(例如但不限于Cortex)、等中的任何一种。处理器可以通信地耦合到存储器并且被配置为执行存储在其中的计算机可执行指令。存储器可以包括只读存储器(ROM)、闪存、随机存取存储器(RAM)、诸如同步DRAM(SDRAM)或Rambus DRAM的动态随机存取存储器(DRAM)、静态存储器(例如，闪存、静态随机存取存储器)等，其上以任何格式存储计算机可执行指令。计算机可执行指令可以被处理器访问，从ROM或者任何其他合适的存储位置读取，并加载到RAM中供处理器执行，以实现根据本公开各个实施例的无线通信方法。

此外，尽管已经在本文中描述了示例性实施例，其范围包括任何和所有基于本公开的具有等同元件、修改、省略、组合(例如，各种实施例交叉的方案)、改编或改变的实施例。权利要求书中的元件将被基于权利要求中采用的语言宽泛地解释，并不限于在本说明书中或本申请的实施期间所描述的示例，其示例将被解释为非排他性的。因此，本说明书和示例旨在仅被认为是示例，真正的范围和精神由以下权利要求以及其等同物的全部范围所指示。

以上描述旨在是说明性的而不是限制性的。例如，上述示例(或其一个或更多方案)可以彼此组合使用。例如本领域普通技术人员在阅读上述描述时可以使用其它实施例。另外，在上述具体实施方式中，各种特征可以被分组在一起以简单化本公开。这不应解释为一种不要求保护的公开的特征对于任一权利要求是必要的意图。相反，本发明的主题可以少于特定的公开的实施例的全部特征。从而，以下权利要求书作为示例或实施例在此并入具体实施方式中，其中每个权利要求独立地作为单独的实施例，并且考虑这些实施例可以以各种组合或排列彼此组合。本发明的范围应参照所附权利要求以及这些权利要求赋权的等同形式的全部范围来确定。

Claims (10)

1.一种基于服务网格的应用迁移方法，其特征在于，所述服务网格基于SpringCloud框架集成，所述方法包括：

步骤S1、在Kubernetes集群中部署所述服务网格和微服务平台组件；

步骤S2、通过配置DockerFile构建经打包的java程序的镜像，将所述镜像发送至镜像仓库；以及

步骤S3、在容器云平台中的服务网格中注入代理以实现所述应用的迁移。

2.根据权利要求1所述的基于服务网格的应用迁移方法，其特征在于，在所述步骤S1中，部署的所述微服务平台组件包括注册中心和配置中心。

3.根据权利要求2所述的基于服务网格的应用迁移方法，其特征在于，在所述步骤S2中，利用依赖管理工具来打包所述java程序。

4.根据权利要求3所述的基于服务网格的应用迁移方法，其特征在于，在步骤S3中，通过以下方式之一来注入所述代理：

设置所述Kubernetes的命名空间标签；

使用kubectl label namespace default istio-injection＝enabled命令；以及

通过yaml文件，使用istioctl kube-inject-f xxx.yaml命令。

5.根据权利要求4所述的基于服务网格的应用迁移方法，其特征在于，通过以下方式之一来关闭注入所述代理：

设置所述Kubernetes的命名空间标签；以及

使用kubectl label namespace default istio-injection＝disabled命令。

6.一种基于服务网格的应用迁移系统，其特征在于，所述服务网格基于SpringCloud框架集成，所述系统包括：

部署单元，被配置为，在Kubernetes集群中部署所述服务网格和微服务平台组件；

构建单元，被配置为，通过配置DockerFile构建经打包的java程序的镜像，将所述镜像发送至镜像仓库；以及

注入单元，被配置为，在容器云平台中的服务网格中注入代理以实现所述应用的迁移。

7.根据权利要求6所述的基于服务网格的应用迁移系统，其特征在于，其中：

部署的所述微服务平台组件包括注册中心和配置中心；以及

所述构建单元进一步被配置为，利用依赖管理工具来打包所述java程序。

8.根据权利要求7所述的基于服务网格的应用迁移系统，其特征在于，所述注入单元进一步被配置为，通过以下方式之一来注入所述代理：

设置所述Kubernetes的命名空间标签；

使用kubectl label namespace default istio-injection＝enabled命令；以及

通过yaml文件，使用istioctl kube-inject-f xxx.yaml命令。

9.根据权利要求8所述的基于服务网格的应用迁移系统，其特征在于，所述注入单元进一步被配置为，通过以下方式之一来关闭注入所述代理：

设置所述Kubernetes的命名空间标签；以及

使用kubectl label namespace default istio-injection＝disabled命令。

10.一种存储有指令的非暂时性计算机可读介质，当所述指令由处理器执行时，执行根据权利要求1-5中任一项所述的基于服务网格的应用迁移方法中的步骤。

Images