CN111736872A - 灰度发布升级方法、装置、计算机系统及可读存储介质 - Google Patents

Abstract

本发明涉及人工智能领域，公开了灰度发布升级方法、装置、计算机系统及可读存储介质，包括：识别需要升级的应用设为升级应用，将其他应用设为辅助应用；将升级应用的请求消息切换到升级应用的非灰度实例上，在升级应用中上线新版本的灰度实例；将辅助应用中的请求消息切换到其自身的非灰度实例上，使所述升级应用和辅助应用的非灰度实例串联成为旧版本链路；将所述升级应用和所述辅助应用中的灰度实例串联成为新版本链路；在升级应用中上线新版本的非灰度实例，将新版本链路中升级应用的请求消息切换至新版本的非灰度实例。本发明还涉及区块链技术，信息可存储于区块链节点中。本发明无需大量硬件资源支持，保证了实例升级的平顺性和稳定性。

Description

灰度发布升级方法、装置、计算机系统及可读存储介质

技术领域

本发明涉及人工智能的云服务技术领域，尤其涉及一种灰度发布升级方法、装置、计算机系统及可读存储介质。

背景技术

很多公司在系统迭代上线的过程中，经常会遇到停机发版上线的情况；在传统的应用中，这些公司可能会首先备份老版本包，接着停掉当前应用服务并上传新包，最后重启应用服务。这种传统的发版方式不仅繁琐，而且中间停机宕调的那段时间无法正常给用户提供服务，严重影响用户体验。

为解决以上问题，一些企业采用通过在应用的上层准备一台Nginx(负载均衡器)，当需要更新应用时，先在冗余机器或者当前机器使用不同端口启动新版本的应用，然后使用Nginx把流量切过来。

这样虽然可以免去应用的重启过程，但是这种方式的应用升级不仅需要大量硬件资源的支持，还会因Nginx的重启耗时对服务器的平顺性和稳定性造成影响。

发明内容

本发明的目的是提供一种灰度发布升级方法、装置、计算机系统及可读存储介质，用于解决现有技术存在的应用升级不仅需要大量硬件资源的支持，还会因Nginx的重启耗时对服务器的平顺性和稳定性造成影响的问题；本申请可应用于智慧政务场景中，从而推动智慧城市的建设。

为实现上述目的，本发明提供一种灰度发布升级方法，用于同时具有灰度实例和非灰度实例的应用进行优雅上下线，包括：

接收升级请求，识别服务器中需要升级的应用并将其设为升级应用，将所述服务器中其他应用设为辅助应用；其中，所述升级请求包括有需要升级实例的应用的编号；

将所述升级应用所接收到的请求消息切换到所述升级应用的非灰度实例上，下线所述升级应用的旧版本灰度实例，在所述升级应用中上线新版本的灰度实例；

将所述辅助应用所接收到的请求消息切换到其自身的非灰度实例上，使所述升级应用和所述辅助应用的非灰度实例串联成为旧版本链路；

更新辅助应用中灰度实例的元数据版本号，将所述升级应用和所述辅助应用中的灰度实例串联成为新版本链路；

下线所述升级应用中的非灰度实例，并在所述升级应用中上线新版本的非灰度实例，将所述新版本链路中升级应用的请求消息逐步切换至所述新版本的非灰度实例。

上述方案中，将所述升级应用和所述辅助应用中的灰度实例串联成为新版本链路之后，包括：

对所述新版本链路进行验证，判断所述新版本链路是否通过验证；若通过，则将所述新版本链路上应用的元数据版本号设为所述新版本链路的链路版本号；若未通过，则发出升级失败信号。

上述方案中，对所述新版本链路进行验证，判断所述新版本链路是否通过验证的步骤，包括：

提取网关接收到的请求消息；

在所述请求消息的请求头中增加测试版本号，其中，所述测试版本号与新版本链路的链路版本号一致；

根据所述测试版本号将所述请求消息发送至所述新版本链路；

监测所述新版本链路在处理所述请求消息获得处理结果的过程中，是否生成实例化异常信息；若是，则判定所述新版本链路未通过验证，并将所述实例化异常信息上传至区块链；若否，则判定所述新版本链路通过验证。

上述方案中，将所述升级应用和所述辅助应用中的灰度实例串联成为新版本链路之后，包括：

将旧版本链路上的请求消息逐步切换至新版本链路，直至所有请求消息均切换至所述新版本链路。

上述方案中，所述请求消息至少由一个请求报文构成；

将旧版本链路上的请求消息逐步切换至新版本链路的步骤，包括：

接收请求报文，判断所述请求报文中是否具有指定版本号；若是，则将所述请求报文发送至链路版本号与所述指定版本号一致的链路；若否，则将所述请求报文发送至预设的版本计算器，所述版本计算器按照预设的权重规则分配所述请求报文，使旧版本链路上的请求消息逐步切换至新版本链路。

上述方案中，所述权重规则包括至少一个时间段及与所述时间段对应的权重比例；所述版本计算器按照预设的权重规则分配所述请求报文的步骤，包括：

所述版本计算器自接收到第一个请求消息开始计时，并识别接收到的请求消息所处的时间段，按照该时间段对应的权重比例分配所述请求消息的发送版本号；

将所述请求消息发送至与其发送版本号对应的链路。

上述方案中，将所述新版本链路中升级应用的请求消息逐步切换至所述新版本的非灰度实例之后，包括：

更新所述辅助应用中的非灰度实例的元数据版本号，及更新网关中的配置版本号使其与所述辅助应用中更新后的元数据版本号对应。

为实现上述目的，本发明还提供一种灰度发布升级装置，用于同时具有灰度实例和非灰度实例的应用进行优雅上下线，包括：

升级识别模块，用于接收升级请求，识别服务器中需要升级的应用并将其设为升级应用，将所述服务器中其他应用设为辅助应用；其中，所述升级请求包括有需要升级实例的应用的编号；

切换升级模块，用于将所述升级应用所接收到的请求消息切换到所述升级应用的非灰度实例上，下线所述升级应用的旧版本灰度实例，在所述升级应用中上线新版本的灰度实例；

切换串联模块，用于将所述辅助应用所接收到的请求消息切换到其自身的非灰度实例上，使所述升级应用和所述辅助应用的非灰度实例串联成为旧版本链路；

更新串联模块，用于更新辅助应用中灰度实例的元数据版本号，将所述升级应用和所述辅助应用中的灰度实例串联成为新版本链路；

下线切换模块，用于下线所述升级应用中的非灰度实例，并在所述升级应用中上线新版本的非灰度实例，将所述新版本链路中升级应用的请求消息逐步切换至所述新版本的非灰度实例。

为实现上述目的，本发明还提供一种计算机系统，其包括多个计算机设备，各计算机设备包括存储器、处理器以及存储在存储器上并可在处理器上运行的计算机程序，所述多个计算机设备的处理器执行所述计算机程序时共同实现上述灰度发布升级方法的步骤。

为实现上述目的，本发明还提供一种计算机可读存储介质，其包括多个存储介质，各存储介质上存储有计算机程序，所述多个存储介质存储的所述计算机程序被处理器执行时共同实现上述灰度发布升级方法的步骤。

本发明提供的灰度发布升级方法、装置、计算机系统及可读存储介质，通过识别服务器中需要升级的应用并将其设为升级应用，将所述服务器中其他应用设为辅助应用；将所述升级应用的请求消息切换到所述升级应用的非灰度实例上，下线所述升级应用的旧版本灰度实例，在所述升级应用中上线新版本的灰度实例；因此，下线的灰度实例将不会对请求消息调用的实例产生影响，保证了实例下线的平顺性，以及处理请求消息的稳定性；

将所述辅助应用中的请求消息切换到其自身的非灰度实例上，使所述升级应用和辅助应用的非灰度实例串联成为旧版本链路；更新辅助应用中灰度实例的元数据版本号，将所述升级应用和所述辅助应用中的灰度实例串联成为新版本链路；下线所述升级应用中的非灰度实例，并在所述升级应用中上线新版本的非灰度实例，将所述新版本链路中升级应用的请求消息逐步切换至所述新版本的非灰度实例；因此，仅需对应用中的流量进行调节，无需大量硬件资源的支持并且无需构建Nginx(负载均衡器)，因此避免了因Nginx的重启耗时对服务器的平顺性和稳定性造成影响的情况发生。

附图说明

图1为本发明灰度发布升级方法实施例一的流程图；

图2为本发明灰度发布升级方法实施例一中同时具有灰度实例和非灰度实例的服务器的结构框图；

图3为本发明灰度发布升级方法实施例一中将应用B中的请求消息切换到应用B的非灰度实例上的结构框图；

图4为本发明灰度发布升级方法实施例一中在应用B中上线新版本的灰度实例的结构框图；

图5为本发明灰度发布升级方法实施例一中将应用A的请求消息切换到其自身的非灰度实例上，将应用C的请求消息切换到其自身的非灰度实例上的结构框图；

图6为本发明灰度发布升级方法实施例一中更新应用A和应用C中灰度实例的元数据版本号的结构框图；

图7为本发明灰度发布升级方法实施例一中在应用B中上线新版本的非灰度实例的结构框图；

图8为本发明灰度发布升级方法实施例二中一种灰度发布升级方法的具体方法流程图；

图9为本发明灰度发布升级方法实施例二中对所述新版本链路进行验证，判断所述新版本链路是否通过验证的具体方法流程图；

图10为本发明灰度发布升级方法实施例二中将旧版本链路上的请求消息逐步切换至新版本链路的具体方法流程图；

图11为本发明灰度发布升级装置实施例三的程序模块示意图；

图12为本发明计算机系统实施例四中计算机设备的硬件结构示意图。

具体实施方式

为了使本发明的目的、技术方案及优点更加清楚明白，以下结合附图及实施例，对本发明进行进一步详细说明。应当理解，此处所描述的具体实施例仅用以解释本发明，并不用于限定本发明。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

本发明提供的灰度发布升级方法、装置、计算机系统及可读存储介质，适用于云计算技术领域，为提供一种基于升级识别模块、切换升级模块、切换串联模块、更新串联模块和下线切换模块的灰度发布升级方法。本发明通过识别服务器中需要升级的应用并将其设为升级应用，将所述服务器中其他应用设为辅助应用；将所述升级应用的请求消息切换到所述升级应用的非灰度实例上，下线所述升级应用的旧版本灰度实例，在所述升级应用中上线新版本的灰度实例；将所述辅助应用中的请求消息切换到其自身的非灰度实例上，使所述升级应用和辅助应用的非灰度实例串联成为旧版本链路；更新辅助应用中灰度实例的元数据版本号，将所述升级应用和所述辅助应用中的灰度实例串联成为新版本链路；下线所述升级应用中的非灰度实例，并在所述升级应用中上线新版本的非灰度实例，将所述新版本链路中升级应用的请求消息逐步切换至所述新版本的非灰度实例。

实施例一：

请参阅图1，本实施例的一种基于云技术的灰度发布升级方法，用于同时具有灰度实例和非灰度实例的应用进行优雅上下线，包括：

S101：接收升级请求，识别服务器中需要升级的应用并将其设为升级应用，将所述服务器中其他应用设为辅助应用；其中，所述升级请求包括有需要升级实例的应用的编号；

S102：将所述升级应用所接收到的请求消息切换到所述升级应用的非灰度实例上，下线所述升级应用的旧版本灰度实例，在所述升级应用中上线新版本的灰度实例；

S103：将所述辅助应用所接收到的请求消息切换到其自身的非灰度实例上，使所述升级应用和辅助应用所述升级应用和辅助应用的非灰度实例串联成为旧版本链路；

S104：更新辅助应用中灰度实例的元数据版本号，将所述升级应用和辅助应用所述升级应用和辅助应用中的灰度实例串联成为新版本链路；

S107：下线所述升级应用中的非灰度实例，并在所述升级应用中上线新版本的非灰度实例，将所述新版本链路中升级应用的请求消息逐步切换至所述新版本的非灰度实例。

在示例性的实施例中，请参阅图2，以运行有灰度发布升级方法的服务器2，对所述服务器2中同时具有灰度实例和非灰度实例的应用进行优雅上下线为例，服务器2中包括应用A、应用B、应用C，升级请求中的编号为B，那么将服务器2中应用B设为升级应用，将应用A和应用C设为辅助应用。

请参阅图3，将应用B中的请求消息切换到应用B的非灰度实例上，使应用B的灰度实例上的请求消息为0，下线应用B的灰度实例；此时，请求消息对应用B的调用将完全路由到应用B的非灰度实例，因此，下线应用B的灰度实例将不会对请求消息调用应用B的实例产生影响，保证了实例下线的平顺性，以及服务器2处理请求消息的稳定性。

请参阅图4，在应用B中上线新版本的灰度实例，并更新所述应用B灰度实例的元数据版本号和系统版本号；其中，所述元数据版本号是指服务发现框架元数据版本号(Eurekametadata Version)，所述系统版本号是指分布式版本控制系统版本号(git Version)，因此，将应用B的灰度实例Eureka metadata Version从0.0.1变为0.0.2；可选的，还可将应用B的灰度实例上运行的git版本号变为新版本灰度实例的版本号，如：从原版本的git版本号082472d，变为新版本灰度实例的版本号023181c，由于git是一个开源的分布式版本控制系统，可以有效、高速地处理从很小到非常大的项目版本管理，因此，通过修改git版本号也便于控制应用中实例是升级。

请参阅图5，将应用A的请求消息切换到其自身的非灰度实例上，将应用C的请求消息切换到其自身的非灰度实例上，将应用A、应用B和应用C的非灰度实例串联成为旧版本链路。

请参阅图6，将应用A和应用C中灰度实例的元数据版本号，修改为应用B的灰度实例的元数据版本号，例如：将应用A和应用C的灰度实例的版本号从Eureka metadataVersion：0.0.1，更新为：Eureka metadata Version：0.0.2，使所述应用A、应用B和应用C的灰度实例因具有相同的元数据版本号(0.0.2)而串联形成新版本链路，即使所述应用A、应用B和应用C的非灰度实例因具有相同的元数据版本号(0.0.2)串联形成新版本链路。

请参阅图7，在应用B中上线新版本的非灰度实例，并更新所述应用B非灰度实例的元数据版本号和系统版本号；其中，所述元数据版本号是指服务发现框架元数据版本号(Eureka metadata Version)，所述系统版本号是指分布式版本控制系统版本号(gitVersion)，因此，将应用B的非灰度实例Eureka metadata Version从0.0.1变为0.0.2；可选的，还可将应用B的非灰度实例上运行的git版本号变为新版本灰度实例的版本号，如：从原版本的git版本号082472d，变为新版本灰度实例的版本号023181c，由于git是一个开源的分布式版本控制系统，可以有效、高速地处理从很小到非常大的项目版本管理，因此，通过修改git版本号也便于控制应用中实例是升级。

本实施例通过切换所述升级应用和辅助应用中的灰度实例和非灰度实例实现请求消息的负载调配，以实现服务器中应用实例的优雅上线和优雅下线，因此仅需对应用中的流量进行调节，无需大量硬件资源的支持并且无需构建Nginx(负载均衡器)，因此避免了因Nginx的重启耗时对服务器的平顺性和稳定性造成影响的情况发生，保证了服务器通过灰度发布进行实例升级时的平顺性和稳定性。

本申请可应用于智慧政务场景中，从而推动智慧城市的建设。

实施例二：

本实施例为上述实施例一的一种具体应用场景，通过本实施例，能够更加清楚、具体地阐述本发明所提供的方法。

下面，以运行有灰度发布升级方法的服务器，对所述服务器中同时具有灰度实例和非灰度实例的应用进行优雅上下线为例，来对本实施例提供的方法进行具体说明。需要说明的是，本实施例只是示例性的，并不限制本发明实施例所保护的范围。

图8是本发明一个实施例提供的一种灰度发布升级方法的具体方法流程图，该方法具体包括步骤S201至S208。

S201：接收升级请求，识别服务器中需要升级的应用并将其设为升级应用，将所述服务器中其他应用设为辅助应用；

其中，所述升级请求包括有需要升级实例的应用的编号。

本步骤中，提取所述升级请求中的编号，将服务器中与所述编号对应的应用设为升级应用，将服务器中其他应用设为辅助应用。

示例性地，假设服务器中包括应用A、应用B、应用C，升级请求中的编号为B，那么将服务器中应用B设为升级应用，将应用A和应用C设为辅助应用。

S202：将所述升级应用所接收到的请求消息切换到所述升级应用的非灰度实例上，下线所述升级应用的旧版本灰度实例，在所述升级应用中上线新版本的灰度实例。

示例性地，将应用B中的请求消息切换到应用B的非灰度实例上，使应用B的灰度实例上的请求消息为0，下线应用B的灰度实例；此时，请求消息对应用B的调用将完全路由到应用B的非灰度实例，因此，下线应用B的灰度实例将不会对请求消息调用应用B的实例产生影响，保证了实例下线的平顺性，以及服务器处理请求消息的稳定性。

在应用B中上线新版本的灰度实例，并更新所述应用B灰度实例的元数据版本号和系统版本号；其中，所述元数据版本号是指服务发现框架元数据版本号(Eureka metadataVersion)，所述系统版本号是指分布式版本控制系统版本号(git Version)，因此，将应用B的灰度实例Eureka metadata Version从0.0.1变为0.0.2；可选的，还可将应用B的灰度实例上运行的git版本号变为新版本灰度实例的版本号，如：从原版本的git版本号082472d，变为新版本灰度实例的版本号023181c，由于git是一个开源的分布式版本控制系统，可以有效、高速地处理从很小到非常大的项目版本管理，因此，通过修改git版本号也便于控制应用中实例是升级。

需要说明的是，由于应用B的灰度实例的元数据版本号为0.0.2，而网关中的配置版本号为0.0.1，使得应用B的灰度实例将脱离服务器中的所有调用链路，成为孤立的模块；因此，通过Spring Cloud框架下的多服务灰度实现，利用eureka元数据进行对应版本实例的选取，使用ribbon负载均衡的IRule负载均衡策略接口的实现：当进行新版本灰度实例上线时，非灰度实例正常工作，控制灰度实例优雅下线，即控制进入灰度实例的用户请求，并在完成已进入的用户请求后下线，实现提供24小时不间断的服务。

进而实现服务器在未建立新版本链路之前，应用B的灰度实例将不会被任何请求消息所调用，避免了因新版本的灰度实例因未被校验是否可用而直接被调用，导致服务器出现调用处理失败或混乱的情况出现，保证了服务器运行的平顺性。

S203：将所述辅助应用所接收到的请求消息切换到其自身的非灰度实例上，使所述升级应用和辅助应用的非灰度实例串联成为旧版本链路，并将所述旧版本链路上应用的元数据版本号设为所述旧版本链路的链路版本号。

示例性地，将应用A的请求消息切换到其自身的非灰度实例上，将应用C的请求消息切换到其自身的非灰度实例上，将应用A、应用B和应用C的非灰度实例串联成为旧版本链路。将应用A、或应用B、或应用C的非灰度实例的元数据版本号(Eureka metadata Version)0.0.1，设为所述旧版本链路的链路版本号0.0.1。

通过这种方法将服务器中所述升级应用和辅助应用的非灰度实例和灰度实例区分开来，以保证任何请求消息均会有一个可靠完整的旧版本链路进行调用，保证了服务器的稳定性。

S204：更新辅助应用中灰度实例的元数据版本号，将所述升级应用和辅助应用所述升级应用和辅助应用中的灰度实例串联成为新版本链路；

示例性地，将应用A和应用C中灰度实例的元数据版本号，修改为应用B的灰度实例的元数据版本号，例如：将应用A和应用C的灰度实例的版本号更新为：Eureka metadataVersion：0.0.2，使所述应用A、应用B和应用C的灰度实例因具有相同的元数据版本号(0.0.2)而串联形成新版本链路，及使所述应用A、应用B和应用C的非灰度实例因具有相同的元数据版本号(0.0.1)串联形成旧版本链路。

通过新版本链路作为用于请求消进行调用的独立链路，以便于对该链路进行验证，即使该链路中的新版本灰度实例出现错误，或新版本灰度实例与辅助应用的灰度实例无法兼容，也不会影响旧版本链路的正常运行，因此保证了服务器的稳定性。

S205：对所述新版本链路进行验证，判断所述新版本链路是否通过验证；若通过，则将所述新版本链路上应用的元数据版本号设为所述新版本链路的链路版本号；执行S206；若未通过，则发出升级失败信号。

为判断新版本链路是否是有效可用的，对新版本链路进行验证，以保证通过灰度发布的应用实例升级的有效运行；通常的，生产的请求消息因网关根据链路版本号，会一直将请求消息发送到旧版本链路上(由于网关内的配置版本号只有旧版本链路的链路版本号)，因此，此时的新版本链路将不会有任何请求消息。

需要说明的是，通过Spring Cloud框架下的多服务灰度实现，利用eureka元数据进行对应版本实例的选取，使用ribbon负载均衡的IRule负载均衡策略接口的实现：对新版本链路进行验证(如：内部逻辑验证和测试)。

其中，于图8中所述步骤S205包括：

S51：对所述新版本链路进行验证；

S52：判断所述新版本链路是否通过验证；

S53：若通过，则将所述新版本链路上应用的元数据版本号设为所述新版本链路的链路版本号；执行S206；

S54：若未通过，则发出升级失败信号。具体的，请参阅图9，对所述新版本链路进行验证，判断所述新版本链路是否通过验证的步骤，包括：

S205-1：提取网关接收到的请求消息。

网关是用于接收请求消息并将其路由至链路的计算机部件，由于网关中的配置版本号只有旧版本链路的链路版本号，因此网关不会将请求消息发送到新版本链路上，故需要从网关中随机提取任一请求消息并对其进行发送链路上的处理。

S205-2：在所述请求消息的请求头中增加测试版本号，其中，所述测试版本号与新版本链路的链路版本号一致。

示例性地，在请求消息(如：http请求)的请求头(header)增加测试版本号(testversion)，例如：使用http调用工具，修改http请求头header中的版本参数比如设置为0.0.2。

本步骤中，可使用postman组件实现在请求消息的请求头中增加测试版本号的技术效果，postman是一款网页调试工具的客户端，postman为用户提供强大的Web API&HTTP请求调试功能。postman能够发送任何类型的HTTP请求(GET,HEAD,POST,PUT..)，附带任何数量的参数+headers。

S205-3：根据所述测试版本号将所述请求消息发送至所述新版本链路。

由于请求消息的请求头中具有测试版本号，因此可以实现请求强制访问新版本链路(即：链路版本号为0.0.2的链路)的技术效果，进而实现验证新版本链路的目的。

S205-4：监测所述新版本链路在处理所述请求消息获得处理结果的过程中，是否生成实例化异常信息。

S205-5：若是，则判定所述新版本链路未通过验证，并将所述实例化异常信息上传至区块链。

S205-6：若否，则判定所述新版本链路通过验证。

基于C、C++、C#、python、java等计算机语言制作用于对请求消息进行实例化的实例，在出现问题或缺陷时，将无法生成正确的处理结果并且在处理过程中就会产生实例化异常信息；本步骤利用所述计算机语言的特性，监测所述新版本链路在处理请求消息并获得处理结果的过程中，是否会产生实例化异常信息，来判断新版本链路是否通过验证，以保证新版本链路的有效性和可靠性。

需要说明的是，基于C、C++、C#、python、java等计算机语言制作的实例，如果无法对请求消息进行实例化，或者其自身运行出现问题时，会产生实例化异常信息，这部分技术属于现有技术，故不再此赘述。

需要说明的是，基于实例化异常信息得到对应的摘要信息，具体来说，摘要信息由实例化异常信息进行散列处理得到，比如利用sha256s算法处理得到。将摘要信息上传至区块链可保证其安全性和对用户的公正透明性。用户设备可以从区块链中下载得该摘要信息，以便查证实例化异常信息是否被篡改。本示例所指区块链是分布式数据存储、点对点传输、共识机制、加密算法等计算机技术的新型应用模式。区块链(Blockchain)，本质上是一个去中心化的数据库，是一串使用密码学方法相关联产生的数据块，每一个数据块中包含了一批次网络交易的信息，用于验证其信息的有效性(防伪)和生成下一个区块。区块链可以包括区块链底层平台、平台产品服务层以及应用服务层等。

S206：将旧版本链路上的请求消息逐步切换至新版本链路，直至所有请求消息均切换至所述新版本链路。

为使升级服务器的非灰度实例能够优雅下线，将旧版本链路上的请求消息逐步切换至新版本链路，因此，下线应用B的非灰度实例将不会对请求消息调用应用B的实例产生影响，保证了实例下线的平顺性，以及服务器处理请求消息的稳定性。

所述请求消息至少由一个请求报文构成。

具体地，请参阅图10，将旧版本链路上的请求消息逐步切换至新版本链路的步骤，包括：

S61：接收请求报文，判断所述请求报文中是否具有指定版本号；

S62：若是，则将所述请求报文发送至链路版本号与所述指定版本号一致的链路；

S63：若否，则将所述请求报文发送至预设的版本计算器，所述版本计算器按照预设的权重规则分配所述请求报文，使旧版本链路上的请求消息逐步切换至新版本链路。其中，所述指定版本号处于所述请求报文的http报文头中。

示例性地，假如请求报文的http报文头中具有指定版本号0.0.1，那么将所述请求报文发送至链路版本号为0.0.1的旧版本链路；假如请求报文的http报文头中不具有指定版本号，那么将所述请求报文发送至预设的版本计算器，所述版本计算器将按照预设的权重规则对各链路的发送量进行分配，并将分配好的请求消息分别发送至各链路。

需要说明的是：通过Spring Cloud框架下的多服务灰度实现，利用eureka元数据进行对应版本实例的选取，使用ribbon负载均衡的IRule负载均衡策略接口的实现：将旧版本链路上的请求消息逐步切换至所述新版本链路，并实时关注生产环境日志，直至所有请求消息均切换至所述新版本链路为止，以确保新版本链路能够完全成功处理请求消息。

具体的，所述权重规则包括至少一个时间段及与所述时间段对应的权重比例。

示例性地，所述权重规则包括：对第一时间段内接收到的请求消息按照9:1的权重比例，分配旧版本链路的链路版本号和新版本链路的链路版本号；对第二时间段内接收到的请求消息按照7:3的权重比例，进行分配旧版本链路的链路版本号和新版本链路的链路版本号；对第三时间段内接收到的请求消息按照5:5的权重比例，分配旧版本链路的链路版本号和新版本链路的链路版本号；对第四时间段内接收到的请求消息按照3:7的权重比例，分配旧版本链路的链路版本号和新版本链路的链路版本号；对第五时间段内接收到的请求消息按照0:10的权重比例，分配旧版本链路的链路版本号和新版本链路的链路版本号。

进一步地，所述版本计算器按照预设的权重规则分配所述请求报文的步骤，包括：

S206-1：所述版本计算器自接收到第一个请求消息开始计时，并识别接收到的请求消息所处的时间段，按照该时间段对应的权重比例分配所述请求消息的发送版本号。

示例性地，所述版本计算器判断所述请求消息所处的时间段是第二时间段，那么这个请求消息有70％的概率会被分配旧版本链路的链路版本号，有30％的概率会被分配新版本链路的链路版本号。

S206-2：将所述请求消息发送至与其发送版本号对应的链路。

将发送版本号与各链路的链路版本号进行比对，获取与所述发送版本号一致的链路版本号，将所述请求消息发送至所述链路版本号所对应的链路。

S207：下线所述升级应用中的非灰度实例，并在所述升级应用中上线新版本的非灰度实例，将所述新版本链路中升级应用的请求消息逐步切换至所述新版本的非灰度实例；

示例性地，在应用B中上线新版本的非灰度实例，并更新所述应用B非灰度实例的元数据版本号和系统版本号；其中，所述元数据版本号是指服务发现框架元数据版本号(Eureka metadata Version)，所述系统版本号是指分布式版本控制系统版本号(gitVersion)，因此，将应用B的非灰度实例Eureka metadata Version从0.0.1变为0.0.2；可选的，还可将应用B的非灰度实例上运行的git版本号变为新版本灰度实例的版本号，如：从原版本的git版本号082472d，变为新版本灰度实例的版本号023181c，由于git是一个开源的分布式版本控制系统，可以有效、高速地处理从很小到非常大的项目版本管理，因此，通过修改git版本号也便于控制应用中实例是升级。

需要说明的是：通过Spring Cloud框架下的多服务灰度实现，利用eureka元数据进行对应版本实例的选取，使用ribbon负载均衡的IRule负载均衡策略接口的实现：将非灰度实例下线，进行非灰度实例整条链路的版本更新上线，直至完成非灰度实例和灰度实例的版本更新。

S208：更新所述辅助应用中的非灰度实例的元数据版本号，及更新网关中的配置版本号使其与所述辅助应用中更新后的元数据版本号对应。

为使网关能够将请求消息路由到所有升级后的灰度实例和非灰度实例，更新所述辅助应用中的非灰度实例的元数据版本号，以实现服务器中所有应用的所有实例在版本号上的全面升级，以便于网关在链路上的路由。

示例性地，将应用A和应用C中非灰度实例的元数据版本号，修改为应用B的非灰度实例的元数据版本号，将网关中的配置版本号修改为应用B的非灰度实例的元数据版本号，使其与所述辅助应用中更新后的元数据版本号对应例如：将应用A和应用C的非灰度实例的版本号更新为：Eureka metadata Version：0.0.2，将网关的配置版本号更新为：Eurekametadata Version：0.0.2；

使所述应用A、应用B和应用C的非灰度实例和灰度实例，与网关的配置版本号具有相同的元数据版本号(0.0.2)，实现服务器中所有应用的所有实例在版本号上的全面升级，以便于网关在链路上的路由，保证了路由请求消息的平顺稳定。

实施例三：

请参阅图11，本实施例的一种基于云技术的灰度发布升级装置1，用于同时具有灰度实例和非灰度实例的应用进行优雅上下线，包括：

升级识别模块11，用于接收升级请求，识别服务器中需要升级的应用并将其设为升级应用，将所述服务器中其他应用设为辅助应用；其中，所述升级请求包括有需要升级实例的应用的编号；

切换升级模块12，用于将所述升级应用所接收到的请求消息切换到所述升级应用的非灰度实例上，下线所述升级应用的旧版本灰度实例，在所述升级应用中上线新版本的灰度实例；

切换串联模块13，用于将所述辅助应用所接收到的请求消息切换到其自身的非灰度实例上，使所述升级应用和辅助应用的非灰度实例串联成为旧版本链路；

更新串联模块14，用于更新辅助应用中灰度实例的元数据版本号，将所述升级应用和所述辅助应用中的灰度实例串联成为新版本链路；

下线切换模块17，用于下线所述升级应用中的非灰度实例，并在所述升级应用中上线新版本的非灰度实例，将所述新版本链路中升级应用的请求消息逐步切换至所述新版本的非灰度实例。

可选的，所述灰度发布升级装置1还包括：

链路验证模块15，用于对所述新版本链路进行验证，判断所述新版本链路是否通过验证；若通过，则将所述新版本链路上应用的元数据版本号设为所述新版本链路的链路版本号；若未通过，则发出升级失败信号。

可选的，所述灰度发布升级装置1还包括：

消息切换模块16，用于将旧版本链路上的请求消息逐步切换至新版本链路，直至所有请求消息均切换至所述新版本链路。

可选的，所述灰度发布升级装置1还包括：

更新版本号模块18，用于更新所述辅助应用中的非灰度实例的元数据版本号，及更新网关中的配置版本号使其与所述辅助应用中更新后的元数据版本号对应。

本发明基于云服务的云计算技术领域，通过识别服务器中需要升级的应用并将其设为升级应用，将所述服务器中其他应用设为辅助应用；将所述升级应用的请求消息切换到所述升级应用的非灰度实例上以进行流量分流，下线所述升级应用的旧版本灰度实例，在所述升级应用中上线新版本的灰度实例；将所述辅助应用中的请求消息切换到其自身的非灰度实例上以进行流量分流，使所述升级应用和辅助应用的非灰度实例串联成为旧版本链路；更新辅助应用中灰度实例的元数据版本号，将所述升级应用和所述辅助应用中的灰度实例串联成为新版本链路；下线所述升级应用中的非灰度实例，并在所述升级应用中上线新版本的非灰度实例，将所述新版本链路中升级应用的请求消息逐步切换至所述新版本的非灰度实例以进行流量分流，因此，本发明通过切换所述升级应用和辅助应用中的灰度实例和非灰度实例实现请求消息的负载调配，以实现服务器中应用实例的优雅上线和优雅下线，进而保证了服务器的平顺性和稳定性。

实施例四：

为实现上述目的，本发明还提供一种计算机系统，该计算机系统包括多个计算机设备3，实施例三的灰度发布升级装置1的组成部分可分散于不同的计算机设备中，计算机设备可以是执行程序的智能手机、平板电脑、笔记本电脑、台式计算机、机架式服务器、刀片式服务器、塔式服务器或机柜式服务器(包括独立的服务器，或者多个服务器所组成的服务器集群)等。本实施例的计算机设备至少包括但不限于：可通过系统总线相互通信连接的存储器31、处理器32，如图12所示。需要指出的是，图12仅示出了具有组件-的计算机设备，但是应理解的是，并不要求实施所有示出的组件，可以替代的实施更多或者更少的组件。

本实施例中，存储器31(即可读存储介质)包括闪存、硬盘、多媒体卡、卡型存储器(例如，SD或DX存储器等)、随机访问存储器(RAM)、静态随机访问存储器(SRAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、可编程只读存储器(PROM)、磁性存储器、磁盘、光盘等。在一些实施例中，存储器31可以是计算机设备的内部存储单元，例如该计算机设备的硬盘或内存。在另一些实施例中，存储器31也可以是计算机设备的外部存储设备，例如该计算机设备上配备的插接式硬盘，智能存储卡(Smart Media Card,SMC)，安全数字(Secure Digital,SD)卡，闪存卡(Flash Card)等。当然，存储器31还可以既包括计算机设备的内部存储单元也包括其外部存储设备。本实施例中，存储器31通常用于存储安装于计算机设备的操作系统和各类应用软件，例如实施例三的灰度发布升级装置的程序代码等。此外，存储器31还可以用于暂时地存储已经输出或者将要输出的各类数据。

处理器32在一些实施例中可以是中央处理器(Central Processing Unit，CPU)、控制器、微控制器、微处理器、或其他数据处理芯片。该处理器32通常用于控制计算机设备的总体操作。本实施例中，处理器32用于运行存储器31中存储的程序代码或者处理数据，例如运行灰度发布升级装置，以实现实施例一的灰度发布升级方法。

实施例五：

为实现上述目的，本发明还提供一种计算机可读存储系统，其包括多个存储介质，如闪存、硬盘、多媒体卡、卡型存储器(例如，SD或DX存储器等)、随机访问存储器(RAM)、静态随机访问存储器(SRAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、可编程只读存储器(PROM)、磁性存储器、磁盘、光盘、服务器、App应用商城等等，其上存储有计算机程序，程序被处理器32执行时实现相应功能。本实施例的计算机可读存储介质用于存储灰度发布升级装置，被处理器32执行时实现实施例一和实施例二的灰度发布升级方法。

上述本发明实施例序号仅仅为了描述，不代表实施例的优劣。

通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到上述实施例方法可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件，但很多情况下前者是更佳的实施方式。

以上仅为本发明的优选实施例，并非因此限制本发明的专利范围，凡是利用本发明说明书及附图内容所作的等效结构或等效流程变换，或直接或间接运用在其他相关的技术领域，均同理包括在本发明的专利保护范围内。

Claims (10)

1.一种灰度发布升级方法，用于同时具有灰度实例和非灰度实例的应用进行优雅上下线，其特征在于，包括：

接收升级请求，识别服务器中需要升级的应用并将其设为升级应用，将所述服务器中其他应用设为辅助应用；其中，所述升级请求包括有需要升级实例的应用的编号；

将所述升级应用所接收到的请求消息切换到所述升级应用的非灰度实例上，下线所述升级应用的旧版本灰度实例，在所述升级应用中上线新版本的灰度实例；

将所述辅助应用所接收到的请求消息切换到其自身的非灰度实例上，使所述升级应用和所述辅助应用的非灰度实例串联成为旧版本链路；

更新辅助应用中灰度实例的元数据版本号，将所述升级应用和所述辅助应用中的灰度实例串联成为新版本链路；

下线所述升级应用中的非灰度实例，并在所述升级应用中上线新版本的非灰度实例，将所述新版本链路中升级应用的请求消息逐步切换至所述新版本的非灰度实例。

2.根据权利要求1所述的灰度发布升级方法，其特征在于，将所述升级应用和所述辅助应用中的灰度实例串联成为新版本链路之后，包括：

对所述新版本链路进行验证，判断所述新版本链路是否通过验证；

若通过，则将所述新版本链路上应用的元数据版本号设为所述新版本链路的链路版本号；

若未通过，则发出升级失败信号。

3.根据权利要求2所述的灰度发布升级方法，其特征在于，对所述新版本链路进行验证，判断所述新版本链路是否通过验证的步骤，包括：

提取网关接收到的请求消息；

在所述请求消息的请求头中增加测试版本号，其中，所述测试版本号与新版本链路的链路版本号一致；

根据所述测试版本号将所述请求消息发送至所述新版本链路；

监测所述新版本链路在处理所述请求消息获得处理结果的过程中，是否生成实例化异常信息；若是，则判定所述新版本链路未通过验证，并将所述实例化异常信息上传至区块链；若否，则判定所述新版本链路通过验证。

4.根据权利要求1所述的灰度发布升级方法，其特征在于，将所述升级应用和所述辅助应用中的灰度实例串联成为新版本链路之后，包括：

将旧版本链路上的请求消息逐步切换至新版本链路，直至所有请求消息均切换至所述新版本链路。

5.根据权利要求4所述的灰度发布升级方法，其特征在于，所述请求消息至少由一个请求报文构成；

将旧版本链路上的请求消息逐步切换至新版本链路的步骤，包括：

接收请求报文，判断所述请求报文中是否具有指定版本号；若是，则将所述请求报文发送至链路版本号与所述指定版本号一致的链路；

若否，则将所述请求报文发送至预设的版本计算器，所述版本计算器按照预设的权重规则分配所述请求报文，使旧版本链路上的请求消息逐步切换至新版本链路。

6.根据权利要求5所述的灰度发布升级方法，其特征在于，所述权重规则包括至少一个时间段及与所述时间段对应的权重比例；

所述版本计算器按照预设的权重规则分配所述请求报文的步骤，包括：所述版本计算器自接收到第一个请求消息开始计时，并识别接收到的请求消息所处的时间段，按照该时间段对应的权重比例分配所述请求消息的发送版本号；

将所述请求消息发送至与其发送版本号对应的链路。

7.根据权利要求1所述的灰度发布升级方法，其特征在于，将所述新版本链路中升级应用的请求消息逐步切换至所述新版本的非灰度实例之后，包括：

更新所述辅助应用中的非灰度实例的元数据版本号，及更新网关中的配置版本号使其与所述辅助应用中更新后的元数据版本号对应。

8.一种灰度发布升级装置，用于同时具有灰度实例和非灰度实例的应用进行优雅上下线，其特征在于，包括：

升级识别模块，用于接收升级请求，识别服务器中需要升级的应用并将其设为升级应用，将所述服务器中其他应用设为辅助应用；其中，所述升级请求包括有需要升级实例的应用的编号；

切换升级模块，用于将所述升级应用所接收到的请求消息切换到所述升级应用的非灰度实例上，下线所述升级应用的旧版本灰度实例，在所述升级应用中上线新版本的灰度实例；

切换串联模块，用于将所述辅助应用所接收到的请求消息切换到其自身的非灰度实例上，使所述升级应用和所述辅助应用的非灰度实例串联成为旧版本链路；

更新串联模块，用于更新辅助应用中灰度实例的元数据版本号，将所述升级应用和所述辅助应用中的灰度实例串联成为新版本链路；

下线切换模块，用于下线所述升级应用中的非灰度实例，并在所述升级应用中上线新版本的非灰度实例，将所述新版本链路中升级应用的请求消息逐步切换至所述新版本的非灰度实例。

9.一种计算机系统，其包括至少一个计算机设备，各计算机设备包括存储器、处理器以及存储在存储器上并可在处理器上运行的计算机程序，其特征在于，所述计算机设备的处理器执行所述计算机程序时共同实现权利要求1至7任一项所述灰度发布升级方法的步骤。

10.一种计算机可读存储介质，其包括多个存储介质，各存储介质上存储有计算机程序，其特征在于，所述多个存储介质存储的所述计算机程序被处理器执行时共同实现权利要求1至7任一项所述灰度发布升级方法的步骤。

Images