CN112130880A - 微服务的发布方法、装置、计算机设备及存储介质 - Google Patents

Abstract

本申请涉及数字医疗领域，涉及医院管理，公开了一种微服务的发布方法，包括：根据待发布的微服务之间的调用关系确定发布顺序；根据发布顺序依次获取微服务作为目标微服务；依次获取目标微服务对应的实例，并对获取到的实例进行升级，其中，在实例进行升级时，将实例从负载均衡策略中去掉；对升级后的实例进行健康检查；在升级后的实例通过健康检查时，将升级后的实例加入负载均衡策略中，并依次对目标微服务对应的其他实例进行升级；当目标微服务对应的所有实例升级完成后，获取发布顺序中的下一个微服务进行发布。本申请避免了微服务在升级发布的过程中导致系统功能无法正常运行的情况发生。

Description

微服务的发布方法、装置、计算机设备及存储介质

技术领域

本申请涉及医疗应用程序管理，尤其涉及一种微服务的发布方法、微服务的发布装置、计算机设备以及计算机可读存储介质。

背景技术

微服务架构是采用单应用程序开发一套小型服务，在医疗服务管理中，每种应用程序均以各自的进程运行，并与轻量级机制进行通信，这些微服务是围绕业务功能构建的，通过全自动部署机制进行独立部署和集中化管理。目前在微服务升级发布的过程中，当正在发布的微服务被其他微服务所依赖时，会出现短暂的系统不可用情况发生，从而导致其下游微服务的可用性也都会大大折扣，严重的甚至会出现发布某个微服务之后导致下游微服务完全瘫痪的情况。例如当前的很多的医院的系统中，均必须做到预约后才能进行诊断治疗。而如果在系统正常运行时，突然升级其中的预约功能，导致用户不能进行预约，进而无法进行后续的正常看病流程。

上述内容仅用于辅助理解本申请的技术方案，并不代表承认上述内容是现有技术。

发明内容

本申请的主要目的在于提供一种微服务的发布方法、微服务的发布装置、计算机设备以及计算机可读存储介质，旨在解决微服务在升级发布的过程中导致系统功能无法正常运行的问题。

为实现上述目的，本申请提供一种微服务的发布方法，所述微服务的发布方法包括以下步骤：

根据待发布的微服务之间的调用关系确定发布顺序；

根据所述发布顺序依次获取所述微服务作为目标微服务；

确定所述目标微服务对应的负载均衡策略；

依次获取所述目标微服务对应的实例，并对获取到的实例进行升级，其中，在所述实例进行升级时，将所述实例从所述负载均衡策略中去掉；

对升级后的实例进行健康检查；

在升级后的实例通过健康检查时，将所述升级后的实例加入所述负载均衡策略中，并依次对所述目标微服务对应的其他实例进行升级；

当所述目标微服务对应的所有实例升级完成后，获取所述发布顺序中的下一个微服务作为所述目标微服务进行发布。

进一步地，所述对升级后的实例进行健康检查的步骤之后，还包括：

在升级后的实例未通过健康检查时，将所述目标微服务恢复到升级前的版本。

进一步地，所述在升级后的实例未通过健康检查时，将所述目标微服务恢复到升级前的版本的步骤之后，还包括：

获取未通过健康检查的实例的检查数据；

利用神经网络模型对所述检查数据进行分析，所述神经网络模型基于多个检查数据样本，以及所述检查数据样本对应的健康检查失败原因进行训练得到的；

获取所述神经网络模型分析得到的健康检查失败原因，以及所述健康检查失败原因对应的置信值，生成分析结果并输出。

进一步地，所述在升级后的实例未通过健康检查时，将所述目标微服务恢复到升级前的版本的步骤之后，还包括：

检测未发布的其他微服务是否与发布失败的微服务存在依赖关系；

若否，根据所述发布顺序依次获取未发布的其他微服务，作为所述目标微服务并进行发布。

进一步地，所述根据待发布的微服务之间的调用关系确定发布顺序的步骤包括：

根据待发布的微服务之间的调用关系，确定所述微服务之间的影响程度；

根据所述影响程度确定所述微服务之间的发布顺序，其中，影响程度越小的微服务在所述发布顺序中排序越前。

进一步地，所述依次获取所述目标微服务对应的实例，并对获取到的实例进行升级的步骤包括：

在所述目标微服务对应的实例中，依次获取业务状态为空闲状态的实例，并对获取到的实例进行升级。

进一步地，所述根据待发布的微服务之间的调用关系确定发布顺序的步骤之前，还包括：

检测到微服务查询页面中有被选中的微服务时，显示所述微服务与其他微服务的调用关系，以及所述微服务对应的应用信息；

检测到针对所述微服务的发布指令时，将所述微服务作为待发布的微服务。

为实现上述目的，本申请还提供一种微服务的发布装置，所述微服务的发布装置包括：

排序模块，用于根据待发布的微服务之间的调用关系确定发布顺序；

获取模块，用于根据所述发布顺序依次获取所述微服务作为目标微服务；

确定模块，用于确定所述目标微服务对应的负载均衡策略；

升级模块，用于依次获取所述目标微服务对应的实例，并对获取到的实例进行升级，其中，在所述实例进行升级时，将所述实例从所述负载均衡策略中去掉；

检查模块，用于对升级后的实例进行健康检查；

处理模块，用于在升级后的实例通过健康检查时，将所述升级后的实例加入所述负载均衡策略中，并依次对所述目标微服务对应的其他实例进行升级；

发布模块，用于当所述目标微服务对应的所有实例升级完成后，获取所述发布顺序中的下一个微服务作为所述目标微服务进行发布。

为实现上述目的，本申请还提供一种计算机设备，所述计算机设备包括：

所述计算机设备包括存储器、处理器及存储在所述存储器上并可在所述处理器上运行的微服务的发布程序，所述微服务的发布程序被所述处理器执行时实现如上述微服务的发布方法的步骤。

为实现上述目的，本申请还提供一种计算机可读存储介质，所述计算机可读存储介质上存储有微服务的发布程序，所述微服务的发布程序被处理器执行时实现如上述微服务的发布方法的步骤。

本申请提供的微服务的发布方法、微服务的发布装置、计算机设备以及计算机可读存储介质，实现规避多个微服务发布时，由于无有效的发布最优路径，导致发布过程出现验收不通过而增加线上排障时间和发布实际耗用时间，而本申请方案的实施则可直接提升运维发布效率和研发验收效率，同时利用优雅服务升级的模式可实现业务零中断，避免了微服务在升级发布的过程中导致系统功能无法正常运行的情况发生。

附图说明

图1为本申请一实施例中微服务的发布方法步骤示意图；

图2为本申请一实施例中微服务的发布装置示意框图；

图3为本申请一实施例的计算机设备的结构示意框图。

本申请目的的实现、功能特点及优点将结合实施例，参照附图做进一步说明。

具体实施方式

为了使本申请的目的、技术方案及优点更加清楚明白，以下结合附图及实施例，对本申请进行进一步详细说明。应当理解，此处描述的具体实施例仅仅用以解释本申请，并不用于限定本申请。

为了解决微服务在升级发布的过程中导致系统功能无法正常运行的问题，本申请提出了微服务的发布方法，所述方法应用于数字医疗技术领域，所述方法进一步应用于数字医疗的医疗应用程序管理技术领域。

参照图1，在一实施例中，所述微服务的发布方法包括：

步骤S10、根据待发布的微服务之间的调用关系确定发布顺序。

本实施例中，实施例终端可为计算机设备。

可选的，当终端检测到当前存在多个待发布的微服务时，则先根据这些待发布的微服务之间的调用关系，确定这些微服务的发布顺序。

可选的，终端配置有管理数据库(Configuration Management Database,CMDB)，CMDB是一个逻辑数据库，包含了配置项全生命周期的信息以及配置项之间的关系(包括物理关系、实时通信关系、非实时通信关系和依赖关系)。

可选的，CMDB中存储有各个微服务核心的调用关系信息，以及包括基本的微服务自身的应用信息(如部署方式、运行环境信息、编译方式等)、负载均衡类型、微服务之间依赖程度(是否涉及关键路径)、健康检查等信息，还包含各类环境中每个微服务的实际部署信息，如环境、主机IP(微服务所部署的实例的IP地址)、负载均衡链接地址等信息。

需要说明的是，一个完整的微服务系统包含多个微服务，各个微服务之间存在互相调用的情况，会形成一个调用链。

所述微服务系统，是指数字医疗的微服务系统。

在调用链中，下游微服务功能的实现，需要依赖上游微服务(即下游微服务需要调用上游微服务的功能)。且当下游微服务关键功能的实现，需要调用上游微服务时，则下游微服务与上游微服务之间的依赖程度为强依赖；当下游微服务某些边缘非关键功能的实现，需要调用上游微服务时，则下游微服务与上游微服务之间的依赖程度为弱依赖。

例如，若某个C服务的关键功能的实现，需要调用B服务，则C服务和B服务之间的调用关系为C服务依赖于B服务，C服务属于B服务的下游微服务，且B服务相对于C服务的依赖程度为强依赖；若某个C服务的某些边缘非关键功能，需要调用A服务来实现，则C服务和A服务之间的调用关系为C服务依赖于A服务，A服务属于C服务的上游微服务，且A服务相对于C服务的依赖程度为弱依赖。例如，在某个医院的微服务系统中，交费这一微服务，需要调用医生的门诊服务，获取医生对于用户的门诊服务的诊断信息，才能调用相应的收费清单，从而，下游的交费服务依赖于上游的门诊服务，因此，交费服务与门诊服务之间的依赖程序为强依赖。而如果门诊服务结束后，门诊结果为休息静养，并不需要使用药物，用户没有必要进行取药，因此，门诊服务与取药服务之间的依赖程序为弱依赖。

可选的，终端获取待发布的多个微服务之间的调用关系，确定微服务之间的影响程度。

其中，在调用关系对应的调用链中，上游微服务的影响程度小于下游微服务的影响程度。例如，C服务依赖于B服务，B服务属于C服务的上游微服务，而B服务又依赖于A服务，B服务为A服务的下游微服务，此时A服务的影响程度小于B服务，而B服务的影响程度又小于C服务。

可选的，当多个微服务之间不存在直接的依赖关系时(例如这些微服务在调用链中属于并列的链路)，则根据这些微服务(上游微服务)与共同的下游微服务之间的依赖程度，确定其对应的影响程度。其中，共同的下游微服务对应的依赖程度越低，则该上游微服务的影响程度越小。

例如，C服务依赖于B服务，且C服务还依赖于A服务，但B服务和A服务之间不存在直接的依赖关系(或者说调用关系)，两者只是同为C服务的上游微服务，那么当C服务与B服务的依赖程度为强依赖时，而C服务与A服务的依赖程度为弱依赖时，则A服务的影响程度小于B服务。

可选的，当多个微服务之间不存在直接的依赖关系，且不存在共同的下游微服务时(或者与共同下游微服务之间的依赖程度相同时)，分别获取这些微服务的功能实现需要调用的所有微服务的数量作为依赖数(即其需要依赖的所有微服务的数量)。微服务的依赖数越小，需要调用的其他微服务的数量越小，则该微服务的影响程度越低。

需要说明的是，微服务的依赖数，可根据该微服务与微服务系统中所有微服务之间的调用关系得到。

可选的，在得到各个待发布的微服务之间的影响程度后，根据微服务对应的影响程度确定微服务的发布顺序，其中，微服务对应的影响程度越低，则该微服务在发布顺序中排序越前。

步骤S20、根据所述发布顺序依次获取所述微服务作为目标微服务。

在确定多个待发布的微服务之间的发布顺序后，从发布顺序中排序最前的微服务开始，依次获取待发布的微服务作为目标微服务，并对目标微服务进行发布，每次发布一个目标微服务。

应当理解的是，当待发布的微服务只有一个时，则直接将待发布的微服务作为目标微服务，并执行步骤S30。

步骤S30、确定所述目标微服务对应的负载均衡策略。

在目标微服务发布的过程中，先确定目标微服务对应的负载均衡策略。

可选的，从CMDB获取目标微服务的负载均衡类型及地址信息，确定目标微服务对应的负载均衡策略。

应当理解的是，为了适应系统不同场景或业务需求，系统中往往配置有多套负载均衡策略，根据目标微服务的负载均衡类型及负载均衡链接地址，可以得到与该目标微服务所匹配的负载均衡策略。

其中，微服务的负载均衡类型有Nginx、F5(Load Balance)等，新型微服务特有的Eureka、Nacos等。

步骤S40、依次获取所述目标微服务对应的实例，并对获取到的实例进行升级，其中，在所述实例进行升级时，将所述实例从所述负载均衡策略中去掉。

应当理解的是，一个微服务可部署多个与之对应的微服务实例，例如，将某个微服务部署在两个机房，包括观澜机房和西丽机房，观澜机房简称gl，西丽机房简称xl，gl机房和xl机房各部署4个微服务实例，这样在一个机房中，一个微服务就对应部署了4个实例了。其中，微服务所对应的实例可根据CMDB中的微服务实际部署信息得到。

可选的，依次获取目标微服务对应的实例(每次至少获取一个实例)，并将获取到的实例从目标实例对应的负载均衡策略中去掉(即暂时禁用，不允许该实例被调用)。为了保持实例的独立性和方便实例调用及被调用，实例会设置有相应的API接口(ApplicationProgramming Interface，应用程序接口)，根据目标微服务所匹配的负载均衡策略，在实例即将升级时，将该实例与负载均衡的API接口禁用，暂时将实例从目标微服务所适用的负载均衡策略中去掉，同时禁止该实例的监控告警，然后升级该实例。而目标微服务的其他实例则保持不变，依然是处于目标微服务对应的负载均衡策略中，以及有监控告警。

当实例从负载均衡策略中去掉后，当正在发布的目标微服务被其他微服务调用时，负载均衡策略在确定调用请求的路径时，就不会再考虑已去掉的实例(即正在升级的实例)，而是将请求指向目标微服务的其他实例(即暂时未升级的实例或已升级完成的实例)，以使目标微服务功能的正常调用不受影响，从而减少该目标微服务发布时对下游微服务的影响。

可选的，对目标微服务的实例的获取，可以是逐个逐个地获取实例进行升级。当目标微服务对应的实例数量比较多时，也可以是先对实例进行分批处理，然后按批次将批次内的实例从目标微服务对应的负载均衡策略中去掉，并禁止当前批次的实例的监控告警，接着对当前批次内的实例进行升级。

步骤S50、对升级后的实例进行健康检查。

可选的，在实例升级后，对升级后的实例进行健康检查。

可选的，健康检查可以是利用自动化测试工具对当前测试环境下的升级后的实例进行用例测试，更具体地，通过调用这些升级后的实例对应的API接口进行功能测试。测试脚本可预先设计，具体内容可根据当前测试的实例的多个功能逻辑来进行设计，不同的功能逻辑对应有不同的测试脚本。而一个测试脚本又可包括多个测试用例，这些测试用例可利用不同的边界取值等，测试升级后的实例各个功能是否正常(如测试实例输出值与预估值是否一致)。

步骤S60、在升级后的实例通过健康检查时，将所述升级后的实例加入所述负载均衡策略中，并依次对所述目标微服务对应的其他实例进行升级。

步骤S70、当所述目标微服务对应的所有实例升级完成后，获取所述发布顺序中的下一个微服务作为所述目标微服务进行发布。

可选的，当升级后的实例通过健康检查时，重新将通过健康检查的实例加入目标微服务对应的负载均衡策略中，并恢复对该实例的监控告警。

进一步地，当目标微服务还存在未升级的实例时，获取对下一个实例(或者下一批实例)进行升级，且对实例进行升级的过程中，将实例从负载均衡策略中暂时去掉，以及禁止监控告警。然后对升级后的实例进行健康检查，并将通过健康检查的实例加入目标微服务对应的负载均衡策略中，并恢复对该实例的监控告警，以此类推，直至所述目标微服务对应的所有实例升级完成并通过健康检查。

当目标微服务对应的所有实例升级完成并通过健康检查时，则该目标微服务的当前版本发布结束。然后获取发布顺序中，下一个待升级的微服务作为目标微服务，并对其进行发布(执行步骤S30-步骤S60)，直至所有待升级的微服务发布结束。

可选的，在执行S10步骤之前，每次微服务发布时，还可以先检测当前时段是否处于可发布时段内，若是，则在可发布时段内进行微服务的发布；若否，则暂时不进行微服务的发布。

其中，可发布时段可以是根据实际情况需要设置的(如深夜时段)，也可以是根据应用的历史访问数据确定的(确定访问人数最少的时段，或者确定待发布的目标微服务被调用的频次最低的时段)。这样可以降低微服务发布过程对用户使用应用的影响。

这样，可以规避多个微服务发布时，由于无有效的发布最优路径，导致发布过程出现验收不通过而增加线上排障时间和发布实际耗用时间，或者因忽略了微服务在调用链中的影响程度，使得发布某个服务之后导致下游服务完全瘫痪的情况发生。而本申请方案的实施，可直接提升运维发布效率和研发验收效率的同时，利用优化的手段，对医院的应用程序综合管理，还通过利用优雅服务升级的模式实现业务零中断，避免了微服务在升级发布的过程中导致系统功能无法正常运行的情况发生。

在一实施例中，在上述实施例基础上，所述对升级后的实例进行健康检查的步骤之后，还包括：

步骤S80、在升级后的实例未通过健康检查时，将所述目标微服务恢复到升级前的版本。

本实施例中，当目标微服务对应的实例中，如果升级后的实例未通过健康检查，则进行版本回滚，将目标微服务恢复到升级前的版本，并将当前检查不通过的实例重新加入到目标微服务对应负载均衡中，并恢复对实例的监控告警。同时，判定目标微服务升级发布失败，版本发布结束。

可选的，若实例健康检查不通过，则收集并记录检查失败的实例对应的检查数据，其中，检查数据包括业务逻辑信息、报错信息等。

示范性地，在运行测试脚本对实例进行健康检查的过程中，如果有某一条或多条测试用例运行失败，则说明该测试用例所测试实例对应的目标微服务的API接口调用可能存在问题，或者是该目标微服务本身的功能代码可能存在Bug等。于是，将收集并记录与该测试用例有关的API接口以及各API接口之间的业务逻辑等信息，以及其他展示测试失败的报错信息，作为检查数据。

然后将检查数据输出给测试人员，测试人员将进行人工判断发布失败的微服务具体是哪里出现Bug并主导对其进行修复等操作。检查数据的输出可通过邮件、弹框消息等多种方式通知相关测试人员。

这样，可以方便测试人员查找微服务发布失败的原因。

在一实施例中，在上述实施例基础上，所述在升级后的实例未通过健康检查时，将所述目标微服务恢复到升级前的版本的步骤之后，还包括：

步骤S90、获取未通过健康检查的实例的检查数据。

步骤S91、利用神经网络模型对所述检查数据进行分析，所述神经网络模型基于多个检查数据样本，以及所述检查数据样本对应的健康检查失败原因进行训练得到的。

步骤S92、获取所述神经网络模型分析得到的健康检查失败原因，以及所述健康检查失败原因对应的置信值，生成分析结果并输出。

本实施例中，终端预先训练有神经网络模型，神经网络模型基于多个健康检查失败的实例对应的检查数据样本(其数量可以是穷尽所有导致健康检查失败的可能)，以及检查数据样本对应的健康检查失败原因进行多次迭代训练后得到的。

检查数据样本对应的健康检查失败原因，可以是工程师预先在各个检查数据样本中标注后，检查数据样本输入至神经网络模型中进行训练的。

可选的，终端获取到未通过健康检查的实例的检查数据后，将检查数据输入到训练好的神经网络模型中，利用神经网络模型对所述检查数据进行分析。

当神经网络模型分析完成后，会输出检查数据对应的健康检查失败原因，以及所述健康检查失败原因对应的置信值。

当然，健康检查失败原因对应的置信值，可由其对应的训练样本数占比决定；也可以是工程师在训练样本中标注每个测试失败原因对应的概率，然后经神经网络模型训练后得到的。

可选的，终端获取神经网络模型输出的健康检查失败原因和置信值，生成分析结果并输出至测试人员的关联终端，以方便测试人员查找微服务发布失败的原因。

在一实施例中，在上述实施例基础上，所述在升级后的实例未通过健康检查时，将所述目标微服务恢复到升级前的版本的步骤之后，还包括：

步骤S100、检测未发布的其他微服务是否与发布失败的微服务存在依赖关系；

步骤S101、若否，获取未发布的其他微服务作为所述目标微服务进行发布。

本实施例中，在当前发布的目标微服务发布失败后，检测剩余未发布的其他微服务中，是否与目标微服务存在依赖关系。主要检测未发布的其他微服务的功能实现是否依赖于目标微服务。

若检测到其他未发布的微服务与发布失败的微服务之间不存在依赖关系，则依次获取未发布的其他微服务作为目标微服务，并对其进行发布(执行步骤S30-步骤S60)，直至所有待升级的微服务发布结束。

若检测到其他未发布的微服务与发布失败的微服务之间存在依赖关系，则停止其他微服务的发布。

这样，在减少发布失败的微服务对其他未发布的微服务的影响的同时，通过自动检测未发布的其他微服务是否可以继续发布，可以提高微服务发布的效率。

在一实施例中，在上述实施例基础上，所述依次获取所述目标微服务对应的实例，并对获取到的实例进行升级的步骤包括：

步骤S41、在所述目标微服务对应的实例中，依次获取业务状态为空闲状态的实例，并对获取到的实例进行升级。

本实施例中，在对当前发布的目标微服务对应的实例进行依次升级和健康检查时，实例升级的次序可以是动态的，终端可先检测这些待升级的实例的业务状态是否为空闲状态，优先获取处于空闲状态的实例进行升级；另外，处于繁忙状态的实例可暂时存放在临时列表中，当其空闲后再从列表中取出升级。

进一步地，当终端依次获取所有处于空闲状态的实例进行升级，并在实例升级后通过健康检查时，若其他未升级的实例仍处于繁忙状态，则生成镜像实例，逐个将繁忙实例执行的实时数据迁移至镜像实例，使处于繁忙状态的实例变为空闲状态，然后对实时数据迁移后的实例(此时实例处于空闲状态)进行升级和健康检查。

或者，终端在区分出空闲实例和繁忙实例这两个升级批次后，在第一批次先对所有空闲实例进行统一升级并通过健康检查后，在第二批次依次将繁忙实例的实时数据迁移至镜像实例，然后进行升级和健康检查。

这样，可以尽可能降低目标微服务升级对用户访问或其他目标微服务调用的影响。

在一实施例中，在上述实施例基础上，所述根据待发布的微服务之间的调用关系确定发布顺序的步骤之前，还包括：

步骤S110、检测到微服务查询页面中有被选中的微服务时，显示所述微服务与其他微服务的调用关系，以及所述微服务对应的应用信息；

步骤S111、检测到针对所述微服务的发布指令时，将所述微服务作为待发布的微服务。

本实施例中，终端以CMDB作为数据支撑，提供有微服务查询页面，用于供用户查询各个微服务的相关信息。

可选的，当用户选择某个微服务选项时，终端判定检测到微服务查询页面中有被选中的微服务，则获取该微服务与其他微服务的调用关系和所述微服务对应的应用信息，并将获取到的信息在微服务查询页面中显示。

其中，微服务与其他微服务的调用关系可以包括选中的微服务与上下游微服务的调用关系、上下游微服务的数量及上下游微服务的依赖程度(或者影响程度)等信息。

这样终端可快速展示出被选中的目标微服务的上下游服务关系、上下游服务数量及上下游服务影响程度等信息，实现目标微服务发布风险的可视化，在发布前方便用户评估待发布服务对下游服务的影响数量及影响程度，为发布申请方和发布审批方做发版决策提供强有力的数据支撑。

而用户基于微服务查询页面了解到各微服务的相关信息后，可进一步针对选中的微服务发出发布指令，终端即可获取发布指令所针对的微服务作为待发布的微服务。应当理解的是，用户可以基于至少一个微服务发出发布指令。

这样可以方便用户在了解微服务相关信息的同时，方便用户快速确定待发布的微服务。

参照图2，本申请实施例中还提供一种微服务的发布装置10，包括：

排序模块11，用于根据待发布的微服务之间的调用关系确定发布顺序；

获取模块12，用于根据所述发布顺序依次获取所述微服务作为目标微服务；

确定模块13，用于确定所述目标微服务对应的负载均衡策略；

升级模块14，用于依次获取所述目标微服务对应的实例，并对获取到的实例进行升级，其中，在所述实例进行升级时，将所述实例从所述负载均衡策略中去掉；

检查模块15，用于对升级后的实例进行健康检查；

处理模块16，用于在升级后的实例通过健康检查时，将所述升级后的实例加入所述负载均衡策略中，并依次对所述目标微服务对应的其他实例进行升级；

发布模块17，用于当所述目标微服务对应的所有实例升级完成后，获取所述发布顺序中的下一个微服务作为所述目标微服务进行发布。

参照图3，本申请实施例中还提供一种计算机设备，该计算机设备可以是服务器，其内部结构可以如图3所示。该计算机设备包括通过系统总线连接的处理器、存储器、网络接口和数据库。其中，该计算机设计的处理器用于提供计算和控制能力。该计算机设备的存储器包括非易失性存储介质、内存储器。该非易失性存储介质存储有操作系统、计算机程序和数据库。该内存储器为非易失性存储介质中的操作系统和计算机程序的运行提供环境。该计算机设备的数据库用于微服务的发布程序。该计算机设备的网络接口用于与外部的终端通过网络连接通信。该计算机程序被处理器执行时以实现一种微服务的发布方法。

本领域技术人员可以理解，图3中示出的结构，仅仅是与本申请方案相关的部分结构的框图，并不构成对本申请方案所应用于其上的计算机设备的限定。

此外，本申请还提出一种计算机可读存储介质，所述计算机可读存储介质包括微服务的发布程序，所述微服务的发布程序被处理器执行时实现如以上实施例所述的微服务的发布方法的步骤。可以理解的是，本实施例中的计算机可读存储介质可以是易失性可读存储介质，也可以为非易失性可读存储介质。

综上所述，为本申请实施例中提供的微服务的发布方法、微服务的发布装置、计算机设备和存储介质，可以规避多个微服务发布时，由于无有效的发布最优路径，导致发布过程出现验收不通过而增加线上排障时间和发布实际耗用时间，或者因忽略了微服务在调用链中的影响程度，使得发布某个服务之后导致下游服务完全瘫痪的情况发生。而本申请方案的实施，可直接提升运维发布效率和研发验收效率的同时，还通过利用优雅服务升级的模式实现业务零中断，避免了微服务在升级发布的过程中导致系统功能无法正常运行的情况发生。

本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流程，是可以通过计算机程序来指令相关的硬件来完成，所述的计算机程序可存储于一非易失性计算机可读取存储介质中，该计算机程序在执行时，可包括如上述各方法的实施例的流程。其中，本申请所提供的和实施例中所使用的对存储器、存储、数据库或其它介质的任何引用，均可包括非易失性和/或易失性存储器。非易失性存储器可以包括只读存储器(ROM)、可编程ROM(PROM)、电可编程ROM(EPROM)、电可擦除可编程ROM(EEPROM)或闪存。易失性存储器可包括随机存取存储器(RAM)或者外部高速缓冲存储器。作为说明而非局限，RAM通过多种形式可得，诸如静态RAM(SRAM)、动态RAM(DRAM)、同步DRAM(SDRAM)、双速据率SDRAM(SSRSDRAM)、增强型SDRAM(ESDRAM)、同步链路(Synchlink)DRAM(SLDRAM)、存储器总线(Rambus)直接RAM(RDRAM)、直接存储器总线动态RAM(DRDRAM)、以及存储器总线动态RAM(RDRAM)等。

需要说明的是，在本文中，术语“包括”、“包含”或者其任何其它变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、装置、物品或者方法不仅包括那些要素，而且还包括没有明确列出的其它要素，或者是还包括为这种过程、装置、物品或者方法所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括该要素的过程、装置、物品或者方法中还存在另外的相同要素。

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

Claims (10)

1.一种微服务的发布方法，其特征在于，包括：

根据待发布的微服务之间的调用关系确定发布顺序；

根据所述发布顺序依次获取所述微服务作为目标微服务；

确定所述目标微服务对应的负载均衡策略；

依次获取所述目标微服务对应的实例，并对获取到的实例进行升级，其中，在所述实例进行升级时，将所述实例从所述负载均衡策略中去掉；

对升级后的实例进行健康检查；

在升级后的实例通过健康检查时，将所述升级后的实例加入所述负载均衡策略中，并依次对所述目标微服务对应的其他实例进行升级；

当所述目标微服务对应的所有实例升级完成后，获取所述发布顺序中的下一个微服务作为所述目标微服务进行发布。

2.如权利要求1所述的微服务的发布方法，其特征在于，所述对升级后的实例进行健康检查的步骤之后，还包括：

在升级后的实例未通过健康检查时，将所述目标微服务恢复到升级前的版本。

3.如权利要求2所述的微服务的发布方法，其特征在于，所述在升级后的实例未通过健康检查时，将所述目标微服务恢复到升级前的版本的步骤之后，还包括：

获取未通过健康检查的实例的检查数据；

利用神经网络模型对所述检查数据进行分析，所述神经网络模型基于多个检查数据样本，以及所述检查数据样本对应的健康检查失败原因进行训练得到的；

获取所述神经网络模型分析得到的健康检查失败原因，以及所述健康检查失败原因对应的置信值，生成分析结果并输出。

4.如权利要求2所述的微服务的发布方法，其特征在于，所述在升级后的实例未通过健康检查时，将所述目标微服务恢复到升级前的版本的步骤之后，还包括：

检测未发布的其他微服务是否与发布失败的微服务存在依赖关系；

若否，根据所述发布顺序依次获取未发布的其他微服务，作为所述目标微服务并进行发布。

5.如权利要求1所述的微服务的发布方法，其特征在于，所述根据待发布的微服务之间的调用关系确定发布顺序的步骤包括：

根据待发布的微服务之间的调用关系，确定所述微服务之间的影响程度；

根据所述影响程度确定所述微服务之间的发布顺序，其中，影响程度越小的微服务在所述发布顺序中排序越前。

6.如权利要求1所述的微服务的发布方法，其特征在于，所述依次获取所述目标微服务对应的实例，并对获取到的实例进行升级的步骤包括：

在所述目标微服务对应的实例中，依次获取业务状态为空闲状态的实例，并对获取到的实例进行升级。

7.如权利要求1-6中任一项所述的微服务的发布方法，其特征在于，所述根据待发布的微服务之间的调用关系确定发布顺序的步骤之前，还包括：

检测到微服务查询页面中有被选中的微服务时，显示所述微服务与其他微服务的调用关系，以及所述微服务对应的应用信息；

检测到针对所述微服务的发布指令时，将所述微服务作为待发布的微服务。

8.一种微服务的发布装置，其特征在于，包括：

排序模块，用于根据待发布的微服务之间的调用关系确定发布顺序；

获取模块，用于根据所述发布顺序依次获取所述微服务作为目标微服务；

确定模块，用于确定所述目标微服务对应的负载均衡策略；

升级模块，用于依次获取所述目标微服务对应的实例，并对获取到的实例进行升级，其中，在所述实例进行升级时，将所述实例从所述负载均衡策略中去掉；

检查模块，用于对升级后的实例进行健康检查；

处理模块，用于在升级后的实例通过健康检查时，将所述升级后的实例加入所述负载均衡策略中，并依次对所述目标微服务对应的其他实例进行升级；

发布模块，用于当所述目标微服务对应的所有实例升级完成后，获取所述发布顺序中的下一个微服务作为所述目标微服务进行发布。

9.一种计算机设备，其特征在于，所述计算机设备包括存储器、处理器及存储在所述存储器上并可在所述处理器上运行的微服务的发布程序，所述微服务的发布程序被所述处理器执行时实现如权利要求1至7中任一项所述的微服务的发布方法的步骤。

10.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质上存储有微服务的发布程序，所述微服务的发布程序被处理器执行时实现如权利要求1至7中任一项所述的微服务的发布方法的步骤。

Images