CN109787858A - 一种批量发布服务的方法及终端 - Google Patents

Abstract

本发明公开了一种批量发布服务的方法及终端，通过采集服务间请求调用的数据和依赖关系，生成服务依赖关系图，根据接收的待发布服务列表和所述服务依赖关系图生成发布依赖定向图，计算所述发布依赖定向图的拓扑序列，根据所述拓扑序列发布服务，可以避免多个存在互相依赖关系的服务进行测试和发布时出现脚本失败的问题，保证服务在进行自动化测试时调用依赖服务的接口版本一致，实现批量服务平滑、顺利的发布。

Description

一种批量发布服务的方法及终端

技术领域

本发明涉及运维技术领域，尤其是涉及一种批量发布服务的方法及终端。

背景技术

目前有很多用于发布的技术，例如：

方案1、蓝绿发布

蓝绿发布是在不停止老版本服务的前提下，发布新版本服务然后进行测试，确认新版本服务没有问题后将流量切到新版本，然后删除老版本实例。这种方案对数据库后端的要求较高，环境切换时需要妥当处理未完成的业务和新业务，由于需要同时启动两套环境，需有基础设置支持，成本较高。

方案2、滚动发布

滚动发布一般是取出一个或多个服务进行停服，执行更新，并重新将其投入使用，往复数遍直到集群中所有实例更新成新版本。这种方案没有一个确定正确的环境，发布过程中便修改了现有的环境，发现问题时，回滚耗时较长。由于是逐步更新，在上线代码时也会短暂出现新老版本不一致的情况，对于上线要求较高的场景，还需要克服兼容问题。

方案3、灰度发布

灰度发布是指在黑与白之间，能够平滑过渡的一种发布方式。AB test就是一种灰度发布方式，让一部分用户继续用A，一部分用户开始用B，如果用户对B没有什么反对意见，那么逐步扩大范围，把所有用户都迁移到B上面来。灰度发布可以保证整体系统的稳定，在初始灰度的时候就可以发现、调整问题，以保证其影响度。

方案4、金丝雀发布

金丝雀发布是在灰度发布基础上，对初始灰度的服务增加冒烟测试的过程。发布过程中从原有负载列表中移除“金丝雀”服务，对其进行升级，然后对应用进行测试，将测试通过的应用重新添加到负载列表，并升级剩余服务；但在金丝雀发布方案中仍存在一些缺陷，例如当需要发布多个互相存在依赖关系的服务时，即进行批量发布服务时，若没有按照服务间的依赖关系进行服务的测试并发布，将导致脚本执行失败，影响服务平滑、顺利的发布。

发明内容

本发明所要解决的技术问题是：提供一种批量发布服务的方法及终端，能够实现批量服务平滑、顺利的发布。

为了解决上述技术问题，本发明采用的一种技术方案为：

一种批量发布服务的方法，包括步骤：

S1、采集服务间请求调用的数据和依赖关系，生成服务依赖关系图；

S2、接收待发布服务列表，根据所述待发布服务列表和所述服务依赖关系图生成发布依赖定向图；

S3、计算所述发布依赖定向图的拓扑序列，根据所述拓扑序列发布服务。

为了解决上述技术问题，本发明采用的另一种技术方案为：

一种批量发布服务的终端，包括存储器、处理器及存储在存储器上并可在所述处理器上运行的计算机程序，所述处理器执行所述计算机程序时实现以下步骤：

S1、采集服务间请求调用的数据和依赖关系，生成服务依赖关系图；

S2、接收待发布服务列表，根据所述待发布服务列表和所述服务依赖关系图生成发布依赖定向图；

S3、计算所述发布依赖定向图的拓扑序列，根据所述拓扑序列发布服务。

本发明的有益效果在于：通过采集服务间请求调用的数据和依赖关系，生成服务依赖关系图，根据接收的待发布服务列表和所述服务依赖关系图生成发布依赖定向图，计算所述发布依赖定向图的拓扑序列，根据所述拓扑序列发布服务，可以避免多个存在互相依赖关系的服务进行测试和发布时出现脚本失败的问题，保证服务在进行自动化测试时调用依赖服务的接口版本一致，实现批量服务平滑、顺利的发布。

附图说明

图1为本发明实施例的一种批量发布服务的方法的步骤流程图；

图2为本发明实施例的一种批量发布服务的终端的结构示意图；

图3为本发明实施例的一种服务依赖关系图；

图4为本发明实施例的一种批量发布服务的方法的步骤流程图；

图5为本发明实施例二的一个小型电商平台系统的结构示意图；

图6为本发明实施例二的一个小型电商平台系统的服务依赖关系图；

图7为本发明实施例二的一个小型电商平台系统的发布依赖定向图；

标号说明：

1、一种批量发布服务的终端； 2、存储器； 3、处理器。

具体实施方式

为详细说明本发明的技术内容、所实现目的及效果，以下结合实施方式并配合附图予以说明。

本发明最关键的构思在于:计算根据待发布服务列表和服务依赖关系图生成的发布依赖定向图的拓扑序列，根据所述拓扑序列发布服务。

请参照图1，一种批量发布服务的方法，包括步骤：

S1、采集服务间请求调用的数据和依赖关系，生成服务依赖关系图；

S2、接收待发布服务列表，根据所述待发布服务列表和所述服务依赖关系图生成发布依赖定向图；

S3、计算所述发布依赖定向图的拓扑序列，根据所述拓扑序列发布服务。

从上述描述可知，本发明的有益效果在于：通过采集服务间请求调用的数据和依赖关系，生成服务依赖关系图，根据接收的待发布服务列表和所述服务依赖关系图生成发布依赖定向图，计算所述发布依赖定向图的拓扑序列，根据所述拓扑序列发布服务，可以避免多个存在互相依赖关系的服务进行测试和发布时出现脚本失败的问题，保证服务在进行自动化测试时调用依赖服务的接口版本一致，实现批量服务平滑、顺利的发布。

进一步的，所述服务依赖关系图为有向无环图，所述服务依赖关系图中的顶点为服务，所述顶点的出边为所述服务与其他服务的依赖关系；

所述步骤S2中根据所述待发布服务列表和所述服务依赖关系图生成发布依赖定向图具体为：

S21、判断所述待发布服务列表中的服务是否在所述服务依赖关系图中存在对应顶点，若是，则执行S22，若否，则执行S23；

S22、在所述服务依赖关系图中找到与所述服务对应的顶点，将所述顶点加入所述发布依赖定向图；

在所述服务依赖关系图中获取所述顶点的出边，将所述出边加入所述发布依赖定向图，并执行步骤S24；

S23、将所述服务作为一个孤立点加入所述发布依赖定向图，并执行步骤S24；

S24、判断所述待发布服务列表中是否还存在未加入所述发布依赖定向图的服务，若是，则返回S21，若否，则执行S3。

由上述描述可知，在所述服务依赖关系图中获取待发布服务列表中的服务对应的顶点与出边，可以提高工作效率。

进一步的，所述步骤S3中计算所述发布依赖定向图的拓扑序列具体为：

S301、选择所述发布依赖图中的任意一个所述出边为0的顶点，将所述顶点添加到拓扑序列末尾，并在所述发布依赖图中移除所述顶点以及所述顶点的所有入边；

S302、判断所述发布依赖定向图中是否还存在未移除的顶点，若是，则返回S301。

由上述描述可知，根据所述发布依赖图中服务之间的依赖关系计算拓扑序列，后续再根据所述拓扑序列批量发布服务，可以避免批量测试并发布服务时出现当前服务依赖的服务尚未发布导致脚本失败的问题，保证了批量服务的顺利发布，保证了批量发布服务的成功率，减少不必要的错误。

进一步的，每个服务包括第一实例和第二实例；

通过负载均衡器对每个服务配置正式域名和灰度域名；

所述正式域名指向所述服务的所有实例，所述灰度域名指向所述服务的第一实例；

所述步骤S2之前还包括：

存储每个服务对应的测试脚本；

所述步骤S3中根据所述拓扑序列发布服务具体为：

S311、按照所述拓扑序列的顺序获取待发布服务，将所述待发布服务的第一实例从所述正式域名的指向中移除；

S312、获取所述待发布列表中的服务对应的代码版本，从代码仓库获取与所述代码版本对应的代码，并将所述代码构建至所述待发布服务的第一实例；

S313、判断所述第一实例启动后，自动执行所述待发布服务对应的测试脚本；

根据所述测试脚本的执行情况判断所述待发布服务的第一实例是否发布成功，若否，则发起通知；

若是，判断所述拓扑序列中是否存在未发布的服务，若是，则返回S31，若否，则将所有发布成功的服务的第一实例加回正式域名的指向，并将所有发布成功的服务的第二实例从所述正式域名指向中移除，将每个发布成功的服务的第一实例中与所述代码版本对应的代码构建至所述服务的第二实例。

由上述描述可知，按照所述拓扑序列的顺序对待发布服务进行自动化测试和发布，根据测试脚本的执行情况判断所述服务是否发布成功，可以避免因测试脚本出错或可容忍问题误判所述服务发布失败的情况，保证了只有在所述服务本身出错的时候判定所述服务发布失败，提高了判断的准确性。

进一步的，在所述步骤S2和步骤S3之间还包括：

移除所述发布依赖定向图中没有指向后置顶点的出边。

由上述描述可知，在计算所述发布依赖定向图的拓扑序列之前，移除所述发布依赖定向图中没有指向后置顶点的出边，可以保证所述发布依赖定向图中各个服务依赖关系的完整性。

请参照图2，一种批量发布服务的终端，包括存储器、处理器及存储在存储器上并可在所述处理器上运行的计算机程序，所述处理器执行所述计算机程序时实现以下步骤：

S1、采集服务间请求调用的数据和依赖关系，生成服务依赖关系图；

S2、接收待发布服务列表，根据所述待发布服务列表和所述服务依赖关系图生成发布依赖定向图；

S3、计算所述发布依赖定向图的拓扑序列，根据所述拓扑序列发布服务。

从上述描述可知，本发明的有益效果在于：通过采集服务间请求调用的数据和依赖关系，生成服务依赖关系图，根据接收的待发布服务列表和所述服务依赖关系图生成发布依赖定向图，计算所述发布依赖定向图的拓扑序列，根据所述拓扑序列发布服务，可以避免多个存在互相依赖关系的服务进行测试和发布时出现脚本失败的问题，保证服务在进行自动化测试时调用依赖服务的接口版本一致，实现批量服务平滑、顺利的发布。

进一步的，所述服务依赖关系图为有向无环图，所述服务依赖关系图中的顶点为服务，所述顶点的出边为所述服务与其他服务的依赖关系；

所述步骤S2中根据所述待发布服务列表和所述服务依赖关系图生成发布依赖定向图具体为：

S21、判断所述待发布服务列表中的服务是否在所述服务依赖关系图中存在对应顶点，若是，则执行S22，若否，则执行S23；

S22、在所述服务依赖关系图中找到与所述服务对应的顶点，将所述顶点加入所述发布依赖定向图；

在所述服务依赖关系图中获取所述顶点的出边，将所述出边加入所述发布依赖定向图，并执行步骤S24；

S23、将所述服务作为一个孤立点加入所述发布依赖定向图，并执行步骤S24；

S24、判断所述待发布服务列表中是否还存在未加入所述发布依赖定向图的服务，若是，则返回S21，若否，则执行S3。

由上述描述可知，在所述服务依赖关系图中获取待发布服务列表中的服务对应的顶点与出边，可以提高工作效率。

进一步的，所述步骤S3中计算所述发布依赖定向图的拓扑序列具体为：

S301、选择所述发布依赖图中的任意一个所述出边为0的顶点，将所述顶点添加到拓扑序列末尾，并在所述发布依赖图中移除所述顶点以及所述顶点的所有入边；

S302、判断所述发布依赖定向图中是否还存在未移除的顶点，若是，则返回S301。

由上述描述可知，根据所述发布依赖图中服务之间的依赖关系计算拓扑序列，后续再根据所述拓扑序列批量发布服务，可以避免批量测试并发布服务时出现当前服务依赖的服务尚未发布导致脚本失败的问题，保证了批量服务的顺利发布，保证了批量发布服务的成功率，减少不必要的错误。

进一步的，每个服务包括第一实例和第二实例；

通过负载均衡器对每个服务配置正式域名和灰度域名；

所述正式域名指向所述服务的所有实例，所述灰度域名指向所述服务的第一实例；

所述步骤S2之前还包括：

存储每个服务对应的测试脚本；

所述步骤S3中根据所述拓扑序列发布服务具体为：

S311、按照所述拓扑序列的顺序获取待发布服务，将所述待发布服务的第一实例从所述正式域名的指向中移除；

S312、获取所述待发布列表中的服务对应的代码版本，从代码仓库获取与所述代码版本对应的代码，并将所述代码构建至所述待发布服务的第一实例；

S313、判断所述第一实例启动后，自动执行所述待发布服务对应的测试脚本；

根据所述测试脚本的执行情况判断所述待发布服务的第一实例是否发布成功，若否，则发起通知；

若是，判断所述拓扑序列中是否存在未发布的服务，若是，则返回S31，若否，则将所有发布成功的服务的第一实例加回正式域名的指向，并将所有发布成功的服务的第二实例从所述正式域名指向中移除，将每个发布成功的服务的第一实例中与所述代码版本对应的代码构建至所述服务的第二实例。

由上述描述可知，按照所述拓扑序列的顺序对待发布服务进行自动化测试和发布，根据测试脚本的执行情况判断所述服务是否发布成功，可以避免因测试脚本出错或可容忍问题误判所述服务发布失败的情况，保证了只有在所述服务本身出错的时候判定所述服务发布失败，提高了判断的准确性。

进一步的，在所述步骤S2和步骤S3之间还包括：

移除所述发布依赖定向图中没有指向后置顶点的出边。

由上述描述可知，在计算所述发布依赖定向图的拓扑序列之前，移除所述发布依赖定向图中没有指向后置顶点的出边，可以保证所述发布依赖定向图中各个服务依赖关系的完整性。

实施例一

请参照图1、图3和图4，一种批量发布服务的方法，本实施例是以运维系统的角度来描述，包括步骤：

S1、采集服务间请求调用的数据和依赖关系，生成服务依赖关系图；

其中，通过采集模块基本的运维监控工具监控服务的运行状态，并采集服务间请求调用的数据；

将服务的代码统一存储在代码仓库，便于管理；

所述服务依赖关系图为有向无环图，所述服务依赖关系图中的顶点为服务，所述顶点的出边为所述服务与其他服务的依赖关系，如图3所示，服务A调用服务G的接口，即服务A依赖于服务G，在图上表示为服务A有一条出边指向服务G；

由测试人员为每个服务创建自动化测试脚本，存储每个服务对应的测试脚本，用于金丝雀发布时的测试环节；

S2、接收待发布服务列表，根据所述待发布服务列表和所述服务依赖关系图生成发布依赖定向图；

其中，所述待发布服务列表由运维人员确认，所述待发布服务列表包括服务信息和代码版本信息；

具体地，接收并存储所述待发布服务列表；

S21、判断所述待发布服务列表中的服务是否在所述服务依赖关系图中存在对应顶点，若是，则执行S22，若否，则执行S23；

S22、在所述服务依赖关系图中找到与所述服务对应的顶点，将所述顶点加入所述发布依赖定向图；

在所述服务依赖关系图中获取所述顶点的出边，将所述出边加入所述发布依赖定向图，并执行步骤S24；

S23、将所述服务作为一个孤立点加入所述发布依赖定向图，并执行步骤S24；

具体地，若该服务在所述服务依赖关系图中不存在对应顶点，则认为该服务与其他服务不存在依赖关系，将该服务作为一个孤立点加入所述发布依赖定向图；

S24、判断所述待发布服务列表中是否还存在未加入所述发布依赖定向图的服务，若是，则返回S21，若否，则执行S3；

移除所述发布依赖定向图中没有指向后置顶点的出边，保证图中所有的出边都有指向后置顶点；

存储所述待发布服务列表服务的发布依赖定向图；

S3、计算所述发布依赖定向图的拓扑序列，根据所述拓扑序列发布服务。

其中，所述发布依赖定向图是一个有向无环图，并且可以是一个非连通图；

具体地，根据拓扑排序算法计算所述发布依赖定向图的拓扑序列，所述拓扑序列是一个线性序列，在这个序列中，一个服务调用到的其他所有服务，都排在这个服务的后面，这样可以保证在发布一个服务时，这个服务的依赖服务都已被发布；

将所述拓扑序列的顺序作为服务发布的顺序，所述拓扑序列的顺序可以不唯一，只需要将有依赖关系的服务按先后顺序发布即可，保证金丝雀发布过程中执行自动化测试的服务依赖的服务已经被提前发布过，确保自动化测试执行不受服务发布的影响，对于不存在依赖关系的服务，则没有先后顺序要求。

具体的拓扑序列计算过程如下：

S301、选择所述发布依赖图中的任意一个所述出边为0的顶点，将所述顶点添加到拓扑序列末尾，并在所述发布依赖图中移除所述顶点以及所述顶点的所有入边；

S302、判断所述发布依赖定向图中是否还存在未移除的顶点，若是，则返回S301；

通过循环S301和S302步骤直至所述发布依赖定向图中的所有顶点均被移除，这时得到的顶点序列也就是拓扑序列，先被移除的顶点就是后续先发布的服务；

其中，每个服务至少包括2个实例，优选地，每个服务包括第一实例和第二实例，以保证在执行金丝雀发布的过程中，线上应用可以正常访问；

至少具备1个负载均衡器，通过所述负载均衡器对每个服务配置正式域名和灰度域名；

所述正式域名指向所述服务的所有实例，所述灰度域名指向所述服务的第一实例，所述灰度域名指向的实例为灰度实例；所述灰度域名对内网开放，用于执行金丝雀发布的自动化测试用例；

所述正式域名和灰度域名指向的实例通过使用不同的配置文件确定其他服务的域名，确保在互相访问时访问的是同一个环境的其他服务实例，发布过程中，服务的灰度域名指向的实例只访问其他服务的灰度域名；通常使用配置中心来管理所述配置文件；

具体通过发布模块和编排模块执行的发布过程如下：

S311、按照所述拓扑序列的顺序获取待发布服务，将所述待发布服务的第一实例从所述正式域名的指向中移除；

S312、获取所述待发布列表中的服务对应的代码版本，从代码仓库获取与所述代码版本对应的代码，并将所述代码构建至所述待发布服务的第一实例；

S313、通过运维监控工具获取所述待发布服务的第一实例运行情况，在判断所述第一实例启动后，通过自动化测试模块自动执行所述待发布服务对应的测试脚本；

根据所述测试脚本的执行情况判断所述待发布服务的第一实例是否发布成功；

若所述测试脚本执行成功，则认为所述待发布服务的第一实例发布成功，继续执行后续步骤；

若所述测试脚本执行失败，则通过通知模块通知测试人员人工介入审核，若测试人员在审核模块判断执行所述测试脚本失败原因是测试脚本问题或可容忍的问题等，不会影响本次发布，则审核通过，判定所述待发布服务的第一实例发布成功，继续执行后续步骤；

若测试人员在审核模块判断执行脚本失败原因是重大代码缺陷等，会影响本次发布，则审核未通过，中断后续步骤，通知所述待发布服务的开发人员发布失败的消息，所述消息中包含发布失败的具体信息，所述具体信息包括发布失败的服务和执行失败的自动化测试脚本，所述待发布服务的开发人员根据所述发布失败的消息修正代码问题，将修正后的代码推送到代码仓库，并告知运维人员，运维人员通过运维系统从中断的所述待发布服务开始，返回步骤S312继续之前的构建；

在所述待发布服务的第一实例发布成功后，判断所述拓扑序列中是否存在未发布的服务，若是，则返回S311继续所述拓扑序列中下一个待发布服务的发布，例如本次待发布服务A发布完成后继续下一个待发布服务B的发布，不断循环，直至所有待发布服务的第一实例均发布完成，这时则通过调整所述负载均衡器的对应配置，并行将所有发布成功的服务的第一实例加回正式域名的指向，并将所有发布成功的服务的第二实例从所述正式域名指向中移除，将每个发布成功的服务的第一实例中与所述代码版本对应的代码构建至所述服务的第二实例；

重复上述步骤，直至所述待发布服务列表中的所有服务的所有实例发布完成；

由于所述待发布服务的第一实例即灰度实例是按所述拓扑序列的顺序发布，可以保证后发布的服务所依赖的本次新增/变更的接口已经发布，从而保证执行灰度实例的自动化测试不受影响，不出现依赖的接口还没有发布的情况。

实施例二

将实施例一所述的方法应用于具体的场景，在一个小型电商平台系统：

请参照图5，所述小型电商平台系统由SCM、OMS、频道页、会员中心、购物车服务、产品展示、搜索、采购服务、库存服务、会员服务、订单服务和产品服务共12个服务组成，每个服务均包括两个实例，服务之间存在依赖关系，批量发布所述小型电商平台系统的服务时的运维系统有以下步骤：

S1、采集服务间请求调用的数据和依赖关系，生成服务依赖关系图，所述服务依赖关系图如图6所示；

其中，通过基本的运维监控工具监控服务的运行状态，并采集服务间请求调用的数据；

将服务的代码统一存储在代码仓库，便于管理；

由测试人员为每个服务创建自动化测试脚本，存储每个服务对应的测试脚本，用于金丝雀发布时的测试环节；

一次版本发布中，需要对OMS、会员中心、库存服务、会员服务和产品服务进行接口升级，因此，所示待发布服务列表包括OMS、会员中心、库存服务、会员服务和产品服务这5个服务，其中，OMS此次功能调整依赖于库存服务的一个新接口；

S2、接收运维管理员添加的待发布服务列表，根据所述待发布服务列表和所述服务依赖关系图生成发布依赖定向图，具体过程与实施例一中的过程相同，将所述服务依赖关系图中OMS、会员中心、库存服务、会员服务和产品服务对应的顶点及所述顶点涉及的出边加入所述发布依赖定向图，生成的所述发布依赖定向图如图7所示；

S3、计算所述发布依赖定向图的拓扑序列，根据所述拓扑序列发布服务；

具体地，计算所述发布依赖定向图得到拓扑序列，计算过程与实施例一中的过程相同，对于不存在依赖关系的多个服务没有先后顺序的要求，而对于存在依赖关系的则要按先后顺序发布，例如OMS调用库存服务的一个新接口，如果库存服务没有先发布，则OMS在调用所述库存服务接口时就会报错；

由于会员服务、库存服务和产品服务三者都没有出边，因此任意移除三者之中的一个均是可行的，优选地，所示拓扑序列为会员服务，产品服务，库存服务，会员中心，OMS；

按照所述拓扑序列的顺序发布了会员服务和产品服务的灰度实例，具体的发布过程与实施例一相同；

在发布库存服务灰度实例的过程中执行自动化测试脚本失败，通知测试人员人工介入审核，测试人员确认失败原因为测试脚本问题，审核通过，继续后续操作，即发布会员中心和OMS的灰度实例；

在发布OMS灰度实例的过程中，执行自动化脚本失败，通知测试人员人工介入审核，测试人员确认是代码存在问题无法通过脚本测试，审核未通过，通知OMS的开发人员发布失败的消息，所述消息包括发布失败的OMS服务及执行失败的自动化测试脚本，OMS开发人员根据错误信息对代码进行调整后重新提交到代码仓库，并告知运维人员。运维人员在运维系统上执行继续发布，重新发布OMS灰度实例后，自动化脚本执行成功；

按照所述拓扑序列的顺序继续对会员服务、产品服务、库存服务、会员中心和OMS的其余实例执行批量发布。

实施例三

请参照图2，一种批量发布服务的终端1，包括存储器2、处理器3及存储在存储器2上并可在所述处理器3上运行的计算机程序，所述处理器3执行所述计算机程序时实现实施例一中的各个步骤。

综上所述，本发明提供的一种批量发布服务的方法及终端，通过采集服务间请求调用的数据和依赖关系，生成服务依赖关系图，根据接收的待发布服务列表和所述服务依赖关系图生成发布依赖定向图，移除所述发布依赖定向图中没有指向后置顶点的出边，计算所述发布依赖定向图的拓扑序列，根据所述拓扑序列发布服务，每个服务包括第一实例和第二实例，判断所述待发布服务的第一实例启动后，自动执行所述待发布服务对应的测试脚本，根据所述测试脚本的执行情况判断所述待发布服务的第一实例是否发布成功进行相应的操作，可以避免多个存在互相依赖关系的服务进行测试和发布时出现脚本失败的问题，保证所述发布依赖定向图中各个服务依赖关系的完整性，保证服务在进行自动化测试时调用依赖服务的接口版本一致，可以避免因测试脚本出错或可容忍问题误判所述服务发布失败的情况，保证了只有在所述服务本身出错的时候判定所述服务发布失败，提高了判断的准确性，实现批量服务平滑、顺利的发布。

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

Claims (10)

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

S1、采集服务间请求调用的数据和依赖关系，生成服务依赖关系图；

S2、接收待发布服务列表，根据所述待发布服务列表和所述服务依赖关系图生成发布依赖定向图；

S3、计算所述发布依赖定向图的拓扑序列，根据所述拓扑序列发布服务。

2.根据权利要求1所述的一种批量发布服务的方法，其特征在于，所述服务依赖关系图为有向无环图，所述服务依赖关系图中的顶点为服务，所述顶点的出边为所述服务与其他服务的依赖关系；

所述步骤S2中根据所述待发布服务列表和所述服务依赖关系图生成发布依赖定向图具体为：

S21、判断所述待发布服务列表中的服务是否在所述服务依赖关系图中存在对应顶点，若是，则执行S22，若否，则执行S23；

S22、在所述服务依赖关系图中找到与所述服务对应的顶点，将所述顶点加入所述发布依赖定向图；

在所述服务依赖关系图中获取所述顶点的出边，将所述出边加入所述发布依赖定向图，并执行步骤S24；

S23、将所述服务作为一个孤立点加入所述发布依赖定向图，并执行步骤S24；

S24、判断所述待发布服务列表中是否还存在未加入所述发布依赖定向图的服务，若是，则返回S21，若否，则执行S3。

3.根据权利要求2所述的一种批量发布服务的方法，其特征在于，所述步骤S3中计算所述发布依赖定向图的拓扑序列具体为：

S301、选择所述发布依赖图中的任意一个所述出边为0的顶点，将所述顶点添加到拓扑序列末尾，并在所述发布依赖图中移除所述顶点以及所述顶点的所有入边；

S302、判断所述发布依赖定向图中是否还存在未移除的顶点，若是，则返回S301。

4.根据权利要求3所述的一种批量发布服务的方法，其特征在于，每个服务包括第一实例和第二实例；

通过负载均衡器对每个服务配置正式域名和灰度域名；

所述正式域名指向所述服务的所有实例，所述灰度域名指向所述服务的第一实例；

所述步骤S2之前还包括：

存储每个服务对应的测试脚本；

所述步骤S3中根据所述拓扑序列发布服务具体为：

S311、按照所述拓扑序列的顺序获取待发布服务，将所述待发布服务的第一实例从所述正式域名的指向中移除；

S312、获取所述待发布列表中的服务对应的代码版本，从代码仓库获取与所述代码版本对应的代码，并将所述代码构建至所述待发布服务的第一实例；

S313、判断所述第一实例启动后，自动执行所述待发布服务对应的测试脚本；

根据所述测试脚本的执行情况判断所述待发布服务的第一实例是否发布成功，若否，则发起通知；

若是，判断所述拓扑序列中是否存在未发布的服务，若是，则返回S31，若否，则将所有发布成功的服务的第一实例加回正式域名的指向，并将所有发布成功的服务的第二实例从所述正式域名指向中移除，将每个发布成功的服务的第一实例中与所述代码版本对应的代码构建至所述服务的第二实例。

5.根据权利要求1所述的一种批量发布服务的方法，其特征在于，在所述步骤S2和步骤S3之间还包括：

移除所述发布依赖定向图中没有指向后置顶点的出边。

6.一种批量发布服务的终端，包括存储器、处理器及存储在存储器上并可在所述处理器上运行的计算机程序，其特征在于，所述处理器执行所述计算机程序时实现以下步骤：

S1、采集服务间请求调用的数据和依赖关系，生成服务依赖关系图；

S2、接收待发布服务列表，根据所述待发布服务列表和所述服务依赖关系图生成发布依赖定向图；

S3、计算所述发布依赖定向图的拓扑序列，根据所述拓扑序列发布服务。

7.根据权利要求6所述的一种批量发布服务的终端，其特征在于，所述服务依赖关系图为有向无环图，所述服务依赖关系图中的顶点为服务，所述顶点的出边为所述服务与其他服务的依赖关系；

所述步骤S2中根据所述待发布服务列表和所述服务依赖关系图生成发布依赖定向图具体为：

S21、判断所述待发布服务列表中的服务是否在所述服务依赖关系图中存在对应顶点，若是，则执行S22，若否，则执行S23；

S22、在所述服务依赖关系图中找到与所述服务对应的顶点，将所述顶点加入所述发布依赖定向图；

在所述服务依赖关系图中获取所述顶点的出边，将所述出边加入所述发布依赖定向图，并执行步骤S24；

S23、将所述服务作为一个孤立点加入所述发布依赖定向图，并执行步骤S24；

S24、判断所述待发布服务列表中是否还存在未加入所述发布依赖定向图的服务，若是，则返回S21，若否，则执行S3。

8.根据权利要求7所述的一种批量发布服务的终端，其特征在于，所述步骤S3中计算所述发布依赖定向图的拓扑序列具体为：

S301、选择所述发布依赖图中的任意一个所述出边为0的顶点，将所述顶点添加到拓扑序列末尾，并在所述发布依赖图中移除所述顶点以及所述顶点的所有入边；

S302、判断所述发布依赖定向图中是否还存在未移除的顶点，若是，则返回S301。

9.根据权利要求8所述的一种批量发布服务的终端，其特征在于，每个服务包括第一实例和第二实例；

通过负载均衡器对每个服务配置正式域名和灰度域名；

所述正式域名指向所述服务的所有实例，所述灰度域名指向所述服务的第一实例；

所述步骤S2之前还包括：

存储每个服务对应的测试脚本；

所述步骤S3中根据所述拓扑序列发布服务具体为：

S311、按照所述拓扑序列的顺序获取待发布服务，将所述待发布服务的第一实例从所述正式域名的指向中移除；

S312、获取所述待发布列表中的服务对应的代码版本，从代码仓库获取与所述代码版本对应的代码，并将所述代码构建至所述待发布服务的第一实例；

S313、判断所述第一实例启动后，自动执行所述待发布服务对应的测试脚本；

根据所述测试脚本的执行情况判断所述待发布服务的第一实例是否发布成功，若否，则发起通知；

若是，判断所述拓扑序列中是否存在未发布的服务，若是，则返回S31，若否，则将所有发布成功的服务的第一实例加回正式域名的指向，并将所有发布成功的服务的第二实例从所述正式域名指向中移除，将每个发布成功的服务的第一实例中与所述代码版本对应的代码构建至所述服务的第二实例。

10.根据权利要求6所述的一种批量发布服务的终端，其特征在于，在所述步骤S2和步骤S3之间还包括：

移除所述发布依赖定向图中没有指向后置顶点的出边。