CN107872334B

CN107872334B - 一种微服务架构系统中灰度升级的方法及装置

Info

Publication number: CN107872334B
Application number: CN201610848373.3A
Authority: CN
Inventors: 王健雄; 邓光明
Original assignee: ZTE Corp
Current assignee: ZTE Corp
Priority date: 2016-09-23
Filing date: 2016-09-23
Publication date: 2022-05-20
Anticipated expiration: 2036-09-23
Also published as: CN107872334A

Abstract

一种微服务架构系统中灰度升级的方法及装置，所述方法包括：确定两个微服务版本集合，所述两个微服务版本集合分别对应升级前和升级后的微服务组件的类型和版本；创建升级任务，指定待升级的微服务组件的类型和版本；对所述待升级的微服务组件的部分实例进行删除旧版本实例、创建新版本实例的操作，形成新旧逻辑系统；开启用户迁移；评估所述新旧逻辑系统的运行结果，确定升级方向；根据升级方向，完成升级或回退。本发明在微服务架构系统内部构建出与系统级灰度对应的新旧版本逻辑系统，在微服务级灰度的资源占用下模拟了系统级灰度的运行形态，实现了系统级灰度和微服务级灰度的统一，提供了微服务系统架构实现灰度升级的通用解决方案。

Description

一种微服务架构系统中灰度升级的方法及装置

技术领域

本发明涉及微服务架构升级技术领域，特别是涉及一种微服务架构系统中灰度升级的方法及装置。

背景技术

微服务架构是一种基于SOA架构在新技术条件下演进的一种新架构模型，以其灵活性、可实施性、可扩展性、可独立测试、可独立部署、可独立运行等一系列优点使得在IT和CT领域达到广泛的推广和使用，因此围绕微服务架构迅速衍生出一系列的技术和方案，但主要都是描述微服务切分和部署相关的内容，对于微服务架构下的升级介绍有限，而且大部分都是考虑简单的滚动升级模式，参见附图9滚动升级示意图，其中微服务组件B是待升级组件，存在三个实例，需要升级到B’，滚动升级的原理为依次将待升级组件B撤销重建为新版本B’，这个过程是假定组件间完全无耦合，B组件杀死旧版本重建成新版本，对上下文A组件和C组件透明，而且所有的升级台阶都必须满足这一要求。

滚动升级的要求通常比较难以满足，而且系统越复杂越难满足，而复杂系统却是微服务架构主要使用领域，因此微服务架构的复杂系统通常不能使用滚动升级来完成升级。复杂系统通常对升级都有着较高的要求，升级过程业务不中断是其重要特性指标，而灰度升级以业务无中断、高可靠、低风险的升级特性，成为复杂系统常用的升级选择。

灰度升级是在升级领域中的一种可以平滑切换升级模式。其基本原理为当有些服务器的需要升级时，可以先升级其中的部分服务器，进行测试，如评估测试结果正常，再升级其他的服务器，这种由点带面的解决方式，相比其他升级存在下面优点：

1.升级影响范围可灵活控制，可以将升级影响的范围控制在能接受范围内，有效降低了升级失败的风险；

2.升级问题可以提前发现，在正式环境中运行业务测试，可以对新版本进行真实测试，提高升级测试的有效性，提高了整体升级的成功率；

3.升级回退简单，升级范围小回退速度快；

4.新旧版本并存同时提供服务，通过动态迁移用户来避免业务中断或者减少业务中断时长。

灰度升级通常可划分三个阶段：升级准备阶段，构建新版本的运行环境；灰度期间，迁移测试用户到新版本，构建新旧版本并行并收集新版本的指标数据，完成本次升级效果评估；升级结束阶段，根据评估结果，切换所有用户到新版本，结束旧版本，或者结束新版本，回退到旧版本。

灰度升级模式通常都是系统级粒度的灰度方式，即需要提供新旧两个版本的完整系统，两个系统通常是隔离的两个实体，各自独立完成服务，可以分别从系统角度进行评估，也可以支持系统内多个组件/微服务的联动修改升级，但是因为是物理隔离就需要在升级期间运行两套完整系统，意味着需要占用双倍的资源，很容易出现资源浪费，而且在有些场景下可能就无法提供额外资源用于升级。在微服务架构系统的认知中，系统内各个微服务都是相对独立、自制的，这样也应该需要支持对系统中一个或者数个微服务进行升级。现有部分所谓的微服务灰度升级直接将微服务与系统对应，仅仅考虑了单个微服务的版本更替，虽然不存在资源浪费，但忽视了微服务属于系统的事实，灰度升级的评估也是针对微服务自身，并没有从系统服务角度评估，评估结果没有体现最终升级形态的运行结果，相比系统级的灰度升级，仅仅针对升级微服务的评估是不完整，不真实的，无法发现系统级的问题，增加了升级失败风险，而且这种升级在微服务存在联动修改，需要联动升级就无法灰度，因为无法控制上下文新旧微服务的交叉处理。因此两种灰度方式都存在各自的优缺点，其中，系统级灰度的优点为能够整体服务测试，测试效果好，测试完整，新旧微服务间采用物理，无影响，支持多个微服务升级，支持微服务关联升级，但缺点为资源占用高；微服务级灰度的优点为资源占用少，缺点为新旧微服务间存在影响，只支持单个微服务测试，测试片面，不完整，不支持微服务关联升级。

发明内容

本发明旨在至少解决现有技术中存在的技术问题之一。为此，本发明的一个目的在于基于灰度升级的原理和微服务系统架构的特性，提供一种微服务架构系统中灰度升级的方法。

根据本发明实施例的微服务架构系统中灰度升级的方法，包括：

确定两个微服务版本集合，所述两个微服务版本集合分别对应升级前和升级后的微服务组件的类型和版本；

创建升级任务，指定待升级的微服务组件的类型和版本；

对所述待升级的微服务组件的部分实例进行删除旧版本实例、创建新版本实例的操作，形成新旧逻辑系统；

开启用户迁移；

评估所述新旧逻辑系统的运行结果，确定升级方向；

根据升级方向，完成升级或回退。

本发明所述方法以微服务架构系统中各微服务组件的版本和类型构建新旧版本集合，对应系统级灰度中升级前后的各微服务形态，以新旧版本集合为基础，在微服务组件中约定支持版本集合识别策略，在增加消息源标示和增加同微服务类型实例间转发通道的辅助下，在微服务架构系统内部构建出与系统级灰度对应的两套新旧版本逻辑系统，在微服务级灰度的资源占用下模拟了系统级灰度的运行形态，实现了系统级灰度和微服务级灰度的统一，提供了微服务系统架构实现灰度升级的通用解决方案。

与现有微服务架构下的升级相比，可以在不增加系统额外资源或者在很小额外资源的条件下实现微服务架构下的灰度升级，测试效果好，并且是以微服务组件为单位，低风险、高可靠、业务无中断和可快速回退的升级一个或者多个微服务组件，与普通的滚动升级相比更容易满足复杂系统的升级要求，这种方式下的灰度升级，升级的范围可以是一个或者多个微服务，降低了微服务在升级间绝对无耦合的要求，对于存在微服务间耦合的升级，可以采用一次同时升级相关微服务的方式，因为不存在相关微服务的新旧版本交叉的情况，不会对接口增加额外要求，同样可以保持灰度升级，实现相关微服务整体切换，降低了微服务升级的无耦合要求。

另外，根据本发明上述实施例的微服务架构系统中灰度升级的方法，还可以具有如下附加的技术特征：

进一步地，在本发明的一个实施例中，所述创建升级任务，指定待升级的微服务组件的类型和版本的步骤包括：

配置普通消息流和测试消息流的路由区分策略。

进一步地，在本发明的一个实施例中，所述测试消息流与升级后业务流对应，所述普通消息流与升级前业务流对应，所述配置普通消息流和测试消息流的路由区分策略的步骤包括：

配置所述测试消息流与所述升级后的微服务组件的类型和版本对应的微服务版本集合相匹配，配置所述普通消息流与所述升级前的微服务组件的类型和版本对应的微服务版本集合匹配。

进一步地，在本发明的一个实施例中，所述创建升级任务，指定待升级的微服务组件的类型和版本的步骤之后，所述方法还包括：

将所述升级任务的信息同步给所述微服务架构系统内的所有微服务组件，开启升级，每个所述微服务组件确定自身归属的微服务版本集合；

所述待升级的微服务组件的所有实例启动相关的消息路由。

进一步地，在本发明的一个实施例中，所述开启用户迁移的步骤包括：

接受外部消息的微服务组件对外部消息进行消息路由控制，并对该外部消息进行接收，所述微服务架构系统内的消息根据路由设置分别在所述新旧逻辑系统间完成处理和返回。

进一步地，在本发明的一个实施例中，所述微服务架构系统内的消息根据路由设置分别在所述新旧逻辑系统间完成处理和返回的步骤包括：

所述新旧逻辑系统内的微服务组件依据消息源、消息发送类型和接受者微服务组件所属版本集合并按照预定路由策略进行处理，所述预定路由策略包括：当消息类型为单播消息时，若消息源信息与自身不在同一个版本集合内，则在所述待升级的微服务组件的所有实例开启的转发通道中转发，否则正常处理；当消息类型为广播消息时，若消息源信息与自身不在同一个版本集合内，则丢弃；否则正常处理。

进一步地，在本发明的一个实施例中，所述评估所述新旧逻辑系统的运行结果，确定升级方向的步骤包括：

判断新逻辑系统是否正常运行；

若是，则更改用户迁移方式，所有外部消息都在新逻辑系统中处理；若否，则更改用户迁移方式，所有外部消息都在旧逻辑系统中处理。

本发明的另一个目的在于提出一种微服务架构系统中灰度升级的装置。

根据本发明实施例的微服务架构系统中灰度升级的装置，包括：

确定单元，用于两个微服务版本集合，所述两个微服务版本集合分别对应升级前和升级后的微服务组件的类型和版本；

升级任务创建单元，用于创建升级任务，指定待升级的微服务组件的类型和版本；

重建单元，用于对所述待升级的微服务组件的部分实例进行删除旧版本实例、创建新版本实例的操作，形成新旧逻辑系统；

用户迁移开启单元，用于开启用户迁移；

评估单元，用于评估所述新旧逻辑系统的运行结果，确定升级方向；

删除单元，用于根据升级方向，完成升级或回退。

另外，根据本发明上述实施例的微服务架构系统中灰度升级的装置，还可以具有如下附加的技术特征：

进一步地，在本发明的一个实施例中，所述升级任务创建单元包括配置子单元，所述配置子单元用于配置普通消息流和测试消息流的路由区分策略。

进一步地，在本发明的一个实施例中，所述测试消息流与升级后业务流对应，所述普通消息流与升级前业务流对应，所述配置子单元用于配置所述测试消息流与所述升级后的微服务组件的类型和版本对应的微服务版本集合相匹配，所述配置子单元还用于配置所述普通消息流与所述升级前的微服务组件的类型和版本对应的微服务版本集合匹配。

进一步地，在本发明的一个实施例中，所述装置还包括：

同步单元，用于将所述升级任务的信息同步给所述微服务架构系统内的所有微服务组件，并开启升级，每个所述微服务组件确定自身归属的微服务版本集合；

转发通道开启单元，用于使所述待升级的微服务组件的所有实例启动相关的消息路由。

进一步地，在本发明的一个实施例中，所述用户迁移开启单元包括外部消息处理子单元和内部消息处理子单元；

所述外部消息处理子单元用于使接受外部消息的微服务组件对外部消息进行消息路由控制，并对该外部消息进行接收；

所述内部消息处理子单元用于使所述微服务架构系统内的消息根据路由设置分别在所述新旧逻辑系统间完成处理和返回。

进一步地，在本发明的一个实施例中，所述内部消息处理子单元用于使所述新旧逻辑系统内的微服务组件依据消息源、消息发送类型和接受者微服务组件所属版本集合并按照预定路由策略进行处理，所述预定路由策略包括：当消息类型为单播消息时，若消息源信息与自身不在同一个版本集合内，则在所述待升级的微服务组件的所有实例开启的转发通道中转发，否则正常处理；当消息类型为广播消息时，若消息源信息与自身不在同一个版本集合内，则丢弃；否则正常处理。

进一步地，在本发明的一个实施例中，所述评估单元包括判断子单元和处理子单元；

所述判断子单元用于判断新逻辑系统是否正常运行；

所述处理子单元用于在所述新逻辑系统正常运行时，更改用户迁移方式，使所有外部消息都在新逻辑系统中处理；所述处理子单元还用于在所述新逻辑系统未正常运行时，更改用户迁移方式，使所有外部消息都在旧逻辑系统中处理。

本发明的附加方面和优点将在下面的描述中部分给出，部分将从下面的描述中变得明显，或通过本发明的实践了解到。

附图说明

本发明的上述和/或附加的方面和优点从结合下面附图对实施例的描述中将变得明显和容易理解，其中：

图1是根据本发明一实施例中新旧逻辑系统的消息流的逻辑示意图；

图2是根据本发明一实施例中升级前后的微服务版本集合的示意图；

图3是根据本发明一实施例中实际消息流向和表现效果消息流向的逻辑示意图；

图4是根据本发明一实施例中外部消息错误发送正确返回的逻辑示意图；

图5是根据本发明一实施例中外部消息错误发送错误返回的逻辑示意图；

图6是根据本发明一实施例中外部消息正确发送错误返回的逻辑示意图；

图7是根据本发明一实施例中外部消息正确发送正确返回的逻辑示意图；

图8是根据本发明一实施例的微服务架构系统中灰度升级的装置的结构框图；

图9是现有技术中滚动升级微服务组件的逻辑示意图。

具体实施方式

下面详细描述本发明的实施例，所述实施例的示例在附图中示出，其中自始至终相同或类似的标号表示相同或类似的元件或具有相同或类似功能的元件。下面通过参考附图描述的实施例是示例性的，仅用于解释本发明，而不能理解为对本发明的限制。

在本发明的描述中，术语“纵向”、“横向”、“上”、“下”、“前”、“后”、“左”、“右”、“竖直”、“水平”、“顶”、“底”等指示的方位或位置关系为基于附图所示的方位或位置关系，仅是为了便于描述本发明而不是要求本发明必须以特定的方位构造和操作，因此不能理解为对本发明的限制。

本发明一实施例的微服务架构系统中灰度升级的方法，包括：

S101，确定两个微服务版本集合，所述两个微服务版本集合分别对应升级前和升级后的微服务组件的类型和版本；

S102，创建升级任务，指定待升级的微服务组件的类型和版本；

S103，对所述待升级的微服务组件的部分实例进行删除旧版本实例、创建新版本实例的操作，形成新旧逻辑系统；

S104，开启用户迁移；

S105，评估所述新旧逻辑系统的运行结果，确定升级方向；

S106，根据升级方向，完成升级或回退。

本实施例所述方法以微服务架构系统中各微服务组件的版本和类型构建新旧版本集合，对应系统级灰度中升级前后的各微服务形态，以新旧版本集合为基础，在微服务组件中约定支持版本集合识别策略，在增加消息源标示和增加同微服务类型实例间转发通道的辅助下，在微服务架构系统内部构建出与系统级灰度对应的两套新旧版本逻辑系统，在微服务级灰度的资源占用下模拟了系统级灰度的运行形态，实现了系统级灰度和微服务级灰度的统一，提供了微服务系统架构实现灰度升级的通用解决方案。

根据本发明的一个示例，所述两个微服务版本集合均处于所述微服务架构系统中，所述步骤S102中，所述创建升级任务，指定待升级的微服务组件的类型和版本的步骤包括：

配置普通消息流和测试消息流的路由区分策略。

根据本发明的一个示例，所述测试消息流与升级后业务流对应，所述普通消息流与升级前业务流对应，所述配置普通消息流和测试消息流的路由区分策略的步骤包括：

根据本发明的一个示例，所述创建升级任务，指定待升级的微服务组件的类型和版本的步骤之后，所述方法还包括：

所述待升级的微服务组件的所有实例启动相关的消息路由。

根据本发明的一个示例，所述开启用户迁移的步骤包括：

根据本发明的一个示例，所述微服务架构系统内的消息根据路由设置分别在所述新旧逻辑系统间完成处理和返回的步骤包括：

根据本发明的一个示例，所述评估所述新旧逻辑系统的运行结果，确定升级方向的步骤包括：

判断新逻辑系统是否正常运行；

根据本发明的一个示例，根据升级方向，完成升级或回退的具体步骤为：

删除待升级微服务组件的旧版本实例或者新版本实例，完成升级或回退；

关闭升级标示，取消所述两个微服务版本集合的判断，取消外部消息标示设置，完成灰度升级。

根据本发明的一个示例，步骤S102中，所述创建升级任务，指定待升级的微服务组件的类型和版本，未指定的为不升级的微服务组件，所述创建升级任务的步骤之后，所述方法还包括：

所述待升级的微服务组件根据升级任务信息感知升级差异，由旧版本微服务组件升级至新版本微服务组件，所述新版本微服务组件处理升级后的业务流消息，所述旧版本微服务组件处理升级前的业务流消息，所述升级后的业务流消息在所述不升级微服务组件和所述新版本微服务组件之间交互，所述升级前的业务流消息在所述不升级微服务组件和所述旧版本微服务组件之间交互。

参照下面的描述和附图，将清楚本发明的实施例的这些和其他方面。在这些描述和附图中，具体公开了本发明的实施例中的一些特定实施方式，来表示实施本发明的实施例的原理的一些方式，但是应当理解，本发明的实施例的范围不受此限制。相反，本发明的实施例包括落入所附加权利要求书的精神和内涵范围内的所有变化、修改和等同物。

在微服务架构系统中要求每个微服务组件都可以独立运行，独立部署，也同样有着自身的版本号，这些微服务组件类型和版本信息，构成一个版本集合，对于升级前和升级后提供服务的一系列微服务，即对应着新旧版本集合。升级的微服务组件将在升级前后会发生版本变化，如附图2所示，图中MS3是在本次升级需要升级的微服务组件，对于不升级微服务组件则版本保持不变，如图2中的MS1，MS2，MS4。按照系统级灰度的隔离要求，升级前后的微服务组件间交互都是在各自的版本集中实例间完成，不存在相互交叉访问，否则相关的业务测试就不代表真实的处理过程，因为这些交叉交互在最终升级成功后的系统中是不存在的，这种要求在微服务级灰度下的业务处理流程就表现为图中表现的限制。

在微服务级灰度下，对于不升级的微服务组件不需要感知升级差异，消息处理维持不变，而对于升级的微服务组件处理的消息是不同的，新版本微服务处理升级后的业务流消息，旧版本微服务则处理升级前的业务流消息，对应真实升级前后的处理方式，因此在微服务级灰度的系统实例，就存在两种处理流程：一种消息流向，对应升级前业务流，仅在不升级微服务组件和待升级旧版微服务组件间交互，对应系统级灰度下不升级系统的处理过程；另一种消息流向，则对于升级后业务流，仅在不升级微服务组件和待升级新版本微服务组件间交互，对应系统级灰度下升级系统的处理过程。因为这两个处理过程仅仅是逻辑流程，实际上是在一个系统内，也就是在一个物理系统内存在两种处理过程，合并这两个逻辑处理过程在一个系统内就如附图1所示，其中，MS1(V1)、MS2(V1)和MS4(V3)为本次不升级微服务组件，MS3(V4)为本次升级旧版本微服务组件，MS3(V5)为本次升级新版本微服务组件。为了达到这种隔离和处理消息，还需要以下特征：

1)在升级过程中需要确定两个微服务版本集合，对应升级前和升级后运行形态的所有微服务类型和版本，这些信息需要在系统内所有微服务组件都是可知的。

2)所有发给其他微服务组件或者相同微服务组件类型但不同实例的消息中需要标示出消息源，即所触发消息的微服务组件类型和版本。消息源是指最初的请求源，中间处理和最终处理的微服务组件不能修改请求源信息，只能转发传递，MS1向MS2请求一个服务处理，MS2在响应MS1请求时，需要向MS3请求获取一个辅助操作，对于MS2向MS3请求的辅助操作是因为MS1请求所触发的，MS2自身不是源，因此辅助操作请求消息的请求源信息需要填写MS1，而不是MS2，相反如果是MS2在处理MS1请求过程中同时向MS3发送的消息是自身的触发的行为，其消息源必须填写MS2。

3)所有外部发往本系统的消息，在系统边界微服务组件中，即能接受外部消息的微服务组件，对消息源类型进行标注，这个设置需要结合测试消息流(与系统内升级后业务流对应)和普通消息流(与系统内升级前业务流对应)的区分策略来设置，与灰度升级的第二步的用户迁移相关，保证迁移用户消息源的微服务版本集合属性匹配，即测试消息流设置成新版本集合匹配，普通消息流与旧版本集合匹配，这种匹配的实现方式，可以是在新旧版本集合中增加两各虚拟的微服务版本和集合，设置接受到的消息是这两个虚拟的微服务。

4)本发明中升级微服务支持类型不同版本间消息转发通道，可以仅在升级期间开启，只有升级的微服务开启版本间转发，其中，这种转发是按类型转发，不做实例定点。

5)对于边界微服务升级场景，有时接受消息对外是有状态物理连接，要求流入和流出必须在一个微服务实例，这时则需要边界微服务间定点实例做特殊转发，这个转发是针对实例的，优先级要高于版本间转发，其实这个转发对于有状态的边界微服务在正常处理也是需要的，但需要与升级结合起来考虑。

6)微服务类型支持按照消息源、消息发送类型和接受者微服务所属版本集合按照预定策略处理，所述预定策略包括：当消息类型为单播消息时，若消息源信息与自身不在同一个版本集合内，则在所述待升级的微服务组件的所有实例开启的转发通道中转发，否则正常处理；当消息类型为广播消息时，若消息源信息与自身不在同一个版本集合内，则丢弃；否则正常处理。对于消息类型可以作为消息的基本参数供各微服务查询，处理策略也是通用处理，可以由公共模块统一拦截处理，应用不感知，由公共模块做通用支持。

基于上述各项特征，本发明另一实施例的微服务架构系统中灰度升级的方法包括：

由升级服务创建升级任务，指定需要升级的微服务类型和版本，包括普通消息和测试消息的路由区分策略；

升级任务信息同步给系统内所有微服务，开启升级，版本集合类型判断生效，微服务确定自身归属的版本集合类型；

待升级微服务类型所有实例开启转发通道，边界微服务类型对特殊转发通道开启升级支持；

对待升级微服务类型的部分实例进行删除重新创建新版本实例，新版本实例启动后自动开启相关消息路由；

至此新旧逻辑系统已经构建；

打开用户迁移开关，外部消息在边界微服务根据路由策略设置消息标示；

消息在系统内根据消息标示分别在新旧逻辑系统完成处理返回；

评估新旧逻辑系统的运行结果，确定升级方向；

评估新逻辑系统运行正常，更改用户迁移方式，所有外部消息都在新逻辑系统处理；评估新逻辑系统运行异常，更改用户迁移方式，所有外部消息都在旧逻辑系统处理；

根据升级方向，删除待升级微服务类型的新版本或者旧版本实例，完成升级或者回退；

关闭升级标示，取消版本集合类型判断，取消外部消息标示设置；

完成灰度升级。

此外，消息的发送和转发对上下游微服务没有要求，转发也是在相同微服务组件内部，不改变微服务组件自身对外的发布特性，对外屏蔽内部升级要求，由微服务组件内部协调完成，符合微服务架构对微服务自制、微服务间低耦合的要求。从实现来看也可以由消息消费者选择具体消息接受者，但增加了服务间的耦合，破坏了要求微服务自制原则。

下面详细描述本发明内部消息的实际发生和外部消息的实际发送情况。

在其中的一个示例中，系统内部消息的发送，会分为两种场景，正确发送和错误发送两种场景，以升级后消息错误发送和升级前消息正确发送为例，流程参见附图3，其中，MS2(V1)为本次不升级微服务组件，MS1(V1)和MS3(V2)为本次升级旧版本微服务组件，MS1(V2)和MS3(V3)为本次升级新版本微服务组件。

正确发送分为下列步骤：

步骤S01：微服务组件MS1(V1)实例向微服务组件MS2(V1)发送消息，携带消息标示，指示为旧版本集合；

步骤S02：微服务组件MS2(V1)收到消息，判断自身不升级，处理后发送给微服务组件MS3；

步骤S03：微服务组件MS3(V2)实例收到消息，检查消息标示与自身都属于旧版本集合，完成处理；

步骤S04：对外表现为微服务组件MS1(V1)旧版本集合发送的消息都在旧版本集合内处理。

错误发送分为下列步骤：

步骤S11：微服务组件MS1(V2)实例向微服务组件MS2(V1)发送消息，携带消息标示，指示为新版本集合；

步骤S12：微服务组件MS2(V1)收到消息，判断自身不升级，处理后发送给微服务组件MS3；

步骤S13：微服务组件MS3(V2)实例收到消息，检查消息标示，消息源为新版本集合而自身属于旧版本集合，转发给微服务组件MS3(V3)实例；

步骤S14：微服务组件MS3(V3)实例收到消息，完成处理；

步骤S15：对外表现为微服务组件MS1(V2)新版本集合发送的消息都在新版本集合内处理。

在其中的一个示例中，系统外部进来消息的需要在边界微服务插入消息标示，在边界微服务升级时，实际收到消息的边界微服务版本可能与消息本身按照分发策略区分后的结果不一致，但返回时如果返回是有连接的则需要原地返回，这里会分为四种场景，正确发送错误返回、正确发送正确返回、错误发送正确返回和错误发送错误返回，这里假定边界微服务与外部是有连接，对于无连接的场景，如采用UDP交互，则不存在返回错误的场景。

错误发送正确返回分为下列步骤，流程参见附图4，其中，MS2(V1)为本次不升级微服务组件，MS1(V1)为本次升级旧版本微服务组件，MS1(V2)为本次升级新版本微服务组件：

步骤S21：外部服务将属于升级前业务流消息发往边界微服务组件MS1(V2)；

步骤S22：边界微服务组件MS1(V2)根据区分策略，识别为升级前业务流消息，增加消息标示，标示为旧版本版本集合，同时消息出口标示为自身；

步骤S23：边界微服务组件MS1(V2)通过版本间转发流转发消息给微服务组件MS1(V1)；

步骤S24：微服务组件MS1(V1)收到消息，检查消息标示与自身所属版本集合匹配，完成处理，下发给微服务组件MS2(V1)继续处理；

步骤S25：微服务组件MS2(V1)实例收到消息，自身不升级，直接处理返回结果到微服务组件MS1(V1)；

步骤S26：微服务组件MS1(V1)实例收到处理结果，检查为边界微服务，并且为有连接消息，根据消息出口标示，使用边界特殊转发流发送给定向微服务组件MS1(V2)；

步骤S27：微服务组件MS1(V2)收到边界特殊转发流过来的结果，使用原有连接返回结果给外部服务。

注：在实际实现中边界特殊转发流和版本间转发流可以合一，通过标示区分。

错误发送错误返回分为下列步骤，流程参见附图5，其中，MS2(V1)为本次不升级微服务组件，MS1(V1)为本次升级旧版本微服务组件，MS1(V2)为本次升级新版本微服务组件：

步骤S31：外部服务将属于升级前业务流消息发往边界微服务组件MS1(V2)；

步骤S32：边界微服务组件MS1(V2)根据区分策略，识别为升级前业务流消息，增加消息标示，标示为旧版本版本集合，同时消息出口标示为自身；

步骤S33：边界微服务组件MS1(V2)通过版本间转发流转发消息给微服务组件MS1(V1)；

步骤S34：微服务组件MS1(V1)收到消息，检查消息标示与自身所属版本集合匹配，完成处理，下发给微服务组件MS2(V1)继续处理；

步骤S35：微服务组件MS2(V1)实例收到消息，自身不升级，直接处理返回结果到微服务组件MS1(V2)；

步骤S36：微服务组件MS1(V2)实例收到处理结果，检查为外部消息处理结果，并且为有连接消息，消息出口标示为自身，则直接返回给外部服务，不做转发。

正确发送错误返回分为下列步骤，流程参见附图6，其中，MS2(V1)为本次不升级微服务组件，MS1(V1)为本次升级旧版本微服务组件，MS1(V2)为本次升级新版本微服务组件：

步骤S41：外部服务将属于升级前业务流消息发往边界微服务组件MS1(V1)；

步骤S42：边界微服务组件MS1(V1)根据区分策略，识别为升级前业务流消息，增加消息标示，标示为旧版本版本集合，同时消息出口标示为自身；

步骤S43：微服务组件MS1(V1)检查消息标示与自身所属版本集合匹配，完成处理，下发给微服务组件MS2(V1)继续处理；

步骤S44：微服务组件MS2(V1)实例收到消息，自身不升级，直接处理返回结果到微服务组件MS1(V2)；

步骤S45：微服务组件MS1(V2)实例收到处理结果，检查为边界微服务，并且为有连接消息，根据消息出口标示不是自身，使用边界特殊转发流根据出口标示发送给定向微服务组件MS1(V1)；

步骤S46：微服务组件MS1(V1)收到边界特殊转发流过来的结果，使用原有连接返回结果给外部服务。

正确发送正确返回分为下列步骤，流程参见附图7，其中，MS2(V1)为本次不升级微服务组件，MS1(V1)为本次升级旧版本微服务组件，MS1(V2)为本次升级新版本微服务组件：

步骤S51：外部服务将属于升级前业务流消息发往边界微服务组件MS1(V1)；

步骤S52：边界微服务组件MS1(V1)根据区分策略，识别为升级前业务流消息，增加消息标示，标示为旧版本版本集合，同时消息出口标示为自身；

步骤S53：微服务组件MS1(V1)检查消息标示与自身所属版本集合匹配，完成处理，下发给微服务组件MS2(V1)继续处理；

步骤S54：微服务组件MS2(V1)实例收到消息，自身不升级，直接处理返回结果到微服务组件MS1(V1)；

步骤S55：微服务组件MS1(V2)实例收到处理结果，检查为边界微服务，并且为有连接消息，根据消息出口标示是自身返回给外部服务，否则使用边界特殊转发流根据出口标示发送给定向微服务组件MS1(V1)；

步骤S56：微服务组件MS1(V1)收到边界特殊转发流过来的结果，使用原有连接返回结果给外部服务。

基于同一发明构思，本发明实施例还提供了一种微服务架构系统中灰度升级的装置，请参见附图8，该装置包括：

用户迁移开启单元，用于开启用户迁移；

删除单元，用于根据升级方向，完成升级或回退。

与现有技术相比，采用本发明所述系统，可以在不增加系统额外资源或者在很小额外资源的条件下实现微服务架构下的灰度升级，测试效果好，并且是以微服务组件为单位，低风险、高可靠、业务无中断和可快速回退的升级一个或者多个微服务组件，与普通的滚动升级相比更容易满足复杂系统的升级要求，这种方式下的灰度升级，升级的范围可以是一个或者多个微服务，降低了微服务在升级间绝对无耦合的要求，对于存在微服务间耦合的升级，可以采用一次同时升级相关微服务的方式，因为不存在相关微服务的新旧版本交叉的情况，不会对接口增加额外要求，同样可以保持灰度升级，实现相关微服务整体切换，降低了微服务升级的无耦合要求。

根据本发明的一个示例，所述升级任务创建单元包括配置子单元，所述配置子单元用于配置普通消息流和测试消息流的路由区分策略。

根据本发明的一个示例，所述测试消息流与升级后业务流对应，所述普通消息流与升级前业务流对应，所述配置子单元用于配置所述测试消息流与所述升级后的微服务组件的类型和版本对应的微服务版本集合相匹配，所述配置子单元还用于配置所述普通消息流与所述升级前的微服务组件的类型和版本对应的微服务版本集合匹配。

根据本发明的一个示例，所述装置还包括：

根据本发明的一个示例，所述用户迁移开启单元包括外部消息处理子单元和内部消息处理子单元；

根据本发明的一个示例，所述内部消息处理子单元用于使所述新旧逻辑系统内的微服务组件依据消息源、消息发送类型和接受者微服务组件所属版本集合并按照预定路由策略进行处理，所述预定路由策略包括：当消息类型为单播消息时，若消息源信息与自身不在同一个版本集合内，则在所述待升级的微服务组件的所有实例开启的转发通道中转发，否则正常处理；当消息类型为广播消息时，若消息源信息与自身不在同一个版本集合内，则丢弃；否则正常处理。

根据本发明的一个示例，所述评估单元包括判断子单元和处理子单元；

所述判断子单元用于判断新逻辑系统是否正常运行；

根据本发明的一个示例，所述删除单元根据升级方向、完成升级或回退的具体步骤为删除待升级微服务组件的旧版本实例或者新版本实例，完成升级或回退。

在流程图中表示或在此以其他方式描述的逻辑和/或步骤，例如，可以被认为是用于实现逻辑功能的可执行指令的定序列表，可以具体实现在任何计算机可读介质中，以供指令执行系统、装置或设备(如基于计算机的系统、包括处理器的系统或其他可以从指令执行系统、装置或设备取指令并执行指令的系统)使用，或结合这些指令执行系统、装置或设备而使用。就本说明书而言，“计算机可读介质”可以是任何可以包含、存储、通信、传播或传输程序以供指令执行系统、装置或设备或结合这些指令执行系统、装置或设备而使用的装置。

计算机可读介质的更具体的示例(非穷尽性列表)包括以下：具有一个或多个布线的电连接部(电子装置)，便携式计算机盘盒(磁装置)，随机存取存储器(RAM)，只读存储器(ROM)，可擦除可编辑只读存储器(EPROM或闪速存储器)，光纤装置，以及便携式光盘只读存储器(CDROM)。另外，计算机可读介质甚至可以是可在其上打印所述程序的纸或其他合适的介质，因为可以例如通过对纸或其他介质进行光学扫描，接着进行编辑、解译或必要时以其他合适方式进行处理来以电子方式获得所述程序，然后将其存储在计算机存储器中。

应当理解，本发明的各部分可以用硬件、软件、固件或它们的组合来实现。在上述实施方式中，多个步骤或方法可以用存储在存储器中且由合适的指令执行系统执行的软件或固件来实现。例如，如果用硬件来实现，和在另一实施方式中一样，可用本领域公知的下列技术中的任一项或他们的组合来实现：具有用于对数据信号实现逻辑功能的逻辑门电路的离散逻辑电路，具有合适的组合逻辑门电路的专用集成电路，可编程门阵列(PGA)，现场可编程门阵列(FPGA)等。

在本说明书的描述中，参考术语“一个实施例”、“一些实施例”、“示例”、“具体示例”、或“一些示例”等的描述意指结合该实施例或示例描述的具体特征、结构、材料或者特点包含于本发明的至少一个实施例或示例中。在本说明书中，对上述术语的示意性表述不一定指的是相同的实施例或示例。而且，描述的具体特征、结构、材料或者特点可以在任何的一个或多个实施例或示例中以合适的方式结合。

尽管已经示出和描述了本发明的实施例，本领域的普通技术人员可以理解：在不脱离本发明的原理和宗旨的情况下可以对这些实施例进行多种变化、修改、替换和变型，本发明的范围由权利要求及其等同物限定。

Claims

1.一种微服务架构系统中灰度升级的方法，其特征在于，包括：

创建升级任务，指定待升级的微服务组件的类型和版本；

开启用户迁移；

评估所述新旧逻辑系统的运行结果，确定升级方向；

根据升级方向，完成升级或回退；

所述评估所述新旧逻辑系统的运行结果，确定升级方向的步骤包括：

判断新逻辑系统是否正常运行；

2.根据权利要求1所述的微服务架构系统中灰度升级的方法，其特征在于，所述创建升级任务，指定待升级的微服务组件的类型和版本的步骤包括：

配置普通消息流和测试消息流的路由区分策略。

3.根据权利要求2所述的微服务架构系统中灰度升级的方法，其特征在于，所述测试消息流与升级后业务流对应，所述普通消息流与升级前业务流对应，所述配置普通消息流和测试消息流的路由区分策略的步骤包括：

4.根据权利要求1所述的微服务架构系统中灰度升级的方法，其特征在于，所述创建升级任务，指定待升级的微服务组件的类型和版本的步骤之后，所述方法还包括：

所述待升级的微服务组件的所有实例启动相关的消息路由。

5.根据权利要求1所述的微服务架构系统中灰度升级的方法，其特征在于，所述开启用户迁移的步骤包括：

6.根据权利要求5所述的微服务架构系统中灰度升级的方法，其特征在于，所述微服务架构系统内的消息根据路由设置分别在所述新旧逻辑系统间完成处理和返回的步骤包括：

7.一种微服务架构系统中灰度升级的装置，其特征在于，包括：

用户迁移开启单元，用于开启用户迁移；

删除单元，用于根据升级方向，完成升级或回退；

所述评估单元包括判断子单元和处理子单元；

所述判断子单元用于判断新逻辑系统是否正常运行；

8.根据权利要求7所述的微服务架构系统中灰度升级的装置，其特征在于，所述升级任务创建单元包括配置子单元，所述配置子单元用于配置普通消息流和测试消息流的路由区分策略。

9.根据权利要求8所述的微服务架构系统中灰度升级的装置，其特征在于，所述测试消息流与升级后业务流对应，所述普通消息流与升级前业务流对应，所述配置子单元用于配置所述测试消息流与所述升级后的微服务组件的类型和版本对应的微服务版本集合相匹配，所述配置子单元还用于配置所述普通消息流与所述升级前的微服务组件的类型和版本对应的微服务版本集合匹配。

10.根据权利要求7所述的微服务架构系统中灰度升级的装置，其特征在于，所述装置还包括：

11.根据权利要求7所述的微服务架构系统中灰度升级的装置，其特征在于，所述用户迁移开启单元包括外部消息处理子单元和内部消息处理子单元；

12.根据权利要求11所述的微服务架构系统中灰度升级的装置，其特征在于，所述内部消息处理子单元用于使所述新旧逻辑系统内的微服务组件依据消息源、消息发送类型和接受者微服务组件所属版本集合并按照预定路由策略进行处理，所述预定路由策略包括：当消息类型为单播消息时，若消息源信息与自身不在同一个版本集合内，则在所述待升级的微服务组件的所有实例开启的转发通道中转发，否则正常处理；当消息类型为广播消息时，若消息源信息与自身不在同一个版本集合内，则丢弃；否则正常处理。