具体实施方式

目前，在按照测试任务测试不同微服务应用之间的调用行为之前，需要预先部署当前所测试的所有微服务应用。但由于不同测试任务所测试的微服务应用可能相同，因此同一微服务应用可能需要部署多次，占用了较多计算机资源，造成资源浪费。

鉴于目前所存在的上述问题，本申请提出了微服务应用部署方案，该方案可以节约微服务应用测试所占用的计算机资源。

为了便于理解，先对本申请所适用的物理框架进行介绍。

如图1所示，图1为本申请适用的物理架构示意图。在图1中，具有微服务应用部署功能的系统或程序可以运行于服务器，该服务器通过网络从其他终端设备中获取测试任务、测试任务所测试的各个微服务应用等。该服务器在获取到用于测试微服务应用之间调用行为的测试任务后，首先确定测试任务所测试的各个微服务应用的版本标识；然后基于各个版本标识在已部署应用库中查询各个微服务应用；若未查询到各个微服务应用中的目标微服务应用，则部署目标微服务应用至已部署应用库，并对目标微服务应用标注相应的目标版本标识，从而基于已部署应用库执行测试任务，对已部署应用库中所部署的微服务应用实现了复用。

如图可知，该服务器可以与多个设备建立通信连接，服务器从这些设备中获取测试任务、测试任务所测试的各个微服务应用等。服务器中设有已部署应用库。当然，已部署应用库也可以设置于其他设备。服务器获得测试任务和相应的待测微服务应用后，先查询已部署应用库，从而可确定出当前测试任务所测试的各个微服务应用哪些已经部署完成，哪些需要新部署，从而仅部署需要新部署的部分微服务应用，之后基于已部署应用库完成当前测试任务。图1中示出了多种终端设备，在实际场景中可以有更多或更少种类的终端设备参与到微服务应用部署的过程中，具体数量和种类因实际场景而定，此处不做限定，另外，图1中示出了一个服务器，但在实际场景中，也可以有多个服务器的参与，具体服务器数量因实际场景而定。

应当注意的是，本实施例提供的微服务应用部署方法可以离线进行，即服务器本地存储有测试任务、测试任务所测试的各个微服务应用、以及已部署应用库，其可以直接利用本申请提供的方案完成测试任务。

可以理解的是，上述具有微服务应用部署功能的系统或程序也可以运行于个人终端设备，也可以作为云端服务程序的一种，具体运作模式因实际场景而定，此处不做限定。其中，终端设备可以是固定终端，也可以是移动终端。示例性的，固定终端可以是台式计算机等，移动终端可以是智能手机、IPAD、手提电脑、可穿戴设备、车载设备等。

结合以上共性，请参见图2，图2为本申请实施例提供的第一种微服务应用部署方法流程图。如图2所示，该微服务应用部署方法可以包括以下步骤：

S201、获取用于测试微服务应用之间调用行为的测试任务。

微服务应用之间可以互相调用，对这种调用行为进行测试是微服务应用的重要测试内容。

若获取到任一个测试任务，则该测试任务所需要测试的微服务应用的个数、名称、版本均已明确，同时所需要测试的不同微服务应用之间的调用关系也已明确。在测试这些微服务应用之间的调用行为之前，首先需要将这些微服务应用部署在一个计算机设备(如服务器)上，并使这些微服务应用在计算机设备上正常运行。

S202、确定测试任务所测试的各个微服务应用的版本标识。

在本实施例中，微服务应用的版本标识中既包括微服务应用的名称，又包括微服务应用的版本编号，因此基于一个版本标识可分辨出唯一的一个微服务应用。一般地，同一名称的微服务应用可能存在多个版本。例如：针对微服务应用A而言，同时存在A1和A2两个版本，其中的“A1”和“A2”即为版本标识，其中“A”为微服务应用的名称，“1”和“2”为微服务应用的版本编号。

在一种具体实施方式中，确定测试任务所测试的各个微服务应用的版本标识，包括：获取测试任务对应的测试需求表；查询测试需求表，以确定各个微服务应用的版本标识。其中，测试需求表中记录有测试任务的ID，测试任务所测试的各个微服务应用的版本标识，以及不同微服务应用之间的调用关系，因此查询测试需求表，可以明确各个微服务应用的版本标识，也就明确了当前所测试的微服务应用有哪些。

S203、基于各个版本标识在已部署应用库中查询各个微服务应用。

在测试微服务应用之间的调用行为之前，首先需要将所需的微服务应用部署在一个计算机设备(如服务器)上，并使这些微服务应用在计算机设备上正常运行。此时这些微服务应用所部署的计算机设备即为测试设备，该计算机设备所具备的网络配置、软硬件配置等环境即为测试环境。

在本实施例中，已部署应用库设置于测试设备(如服务器)上，已部署应用库中包括多个已经部署在测试设备中的微服务应用，这些微服务应用可以是历史测试任务所测试的微服务应用，也可以是未经过测试的新微服务应用。已部署应用库中的每个微服务应用均标注有相应的版本标识，且同一个微服务应用仅在已部署应用库中有一个。也即：同一个版本标识仅在已部署应用库中有一个。

在一种具体实施方式中，基于各个版本标识在已部署应用库中查询各个微服务应用，包括：将各个版本标识确定为查询关键字；基于查询关键字遍历已部署应用库。由于同一个版本标识仅在已部署应用库中有一个，因此可以基于版本标识在已部署应用库中查询各个微服务应用，若在已部署应用库中查到当前所测微服务应用的版本标识，则表明该微服务应用已经部署在测试设备上，此时就无需再部署该微服务应用；但若是在已部署应用库中没有查到当前所测微服务应用的版本标识，则表明该微服务应用还没有部署在测试设备上，此时就需要部署该微服务应用。其中，遍历已部署应用库的方式可以采用常用遍历方式，如深度优先遍历、广度优先遍历等。

S204、若未查询到各个微服务应用中的目标微服务应用，则部署目标微服务应用至已部署应用库，对目标微服务应用标注相应的目标版本标识，以便基于已部署应用库执行测试任务。

本实施例在获取到用于测试微服务应用之间调用行为的测试任务后，首先确定测试任务所测试的各个微服务应用的版本标识；然后基于各个版本标识在已部署应用库中查询各个微服务应用；若未查询到各个微服务应用中的目标微服务应用，则部署目标微服务应用至已部署应用库，并对目标微服务应用标注相应的目标版本标识，之后可基于已部署应用库执行测试任务。若是在已部署应用库中查询到各个微服务应用中的某个应用，则可以直接使用已部署应用库中的该应用。故部署未查询到的目标微服务应用后，当前测试任务所测试的所有微服务应用均已经部署在已部署应用库中，因此可以基于已部署应用库执行当前测试任务。目标微服务应用为测试任务所测试的各个微服务应用中的任意微服务应用。

需要说明的是，若测试设备同时获取到多个测试任务，则该测试设备可以并行处理这些测试任务，即并行执行S201-S204，从而可以提高测试效率。

可见，本实施例在执行当前测试任务之前，先基于版本标识查询已部署应用库，可确定出当前测试任务所测试的各个微服务应用哪些已经部署完成，哪些需要新部署，从而仅部署需要新部署的部分微服务应用(即目标微服务应用)，因此当前需要部署的微服务应用数量得到了降低，且可以利用已部署应用库中的原微服务应用执行当前测试任务，从而实现了微服务应用的复用。如此一来，同一微服务应用仅需要在已部署应用库中部署一个，故所部署的微服务应用占用的计算机资源得到了减少，节约了微服务应用测试所占用的计算机资源。

请参见图3，图3为本申请实施例提供的第二种微服务应用部署方法流程图。如图3所示，该微服务应用部署方法可以包括以下步骤：

S301、获取用于测试微服务应用之间调用行为的测试任务；

S302、确定测试任务所测试的各个微服务应用的版本标识；

S303、基于各个版本标识在已部署应用库中查询各个微服务应用；

S304、判断是否查到目标微服务应用；若是，则执行S306；若否，则执行S305；

S305、部署目标微服务应用至已部署应用库，并对目标微服务应用标注相应的目标版本标识，并执行S306；

S306、判断目标微服务应用是否查询完毕；若是，则执行S308；若否，则执行S307；

S307、查询下一目标微服务应用，并执行S304；

S308、获取测试任务对应的链路标识；

S309、对已部署应用库中的各个微服务应用添加链路标识；

S310、基于链路标识测试各个微服务应用之间的调用行为，以完成测试任务。

在本实施例中，目标微服务应用指当前测试任务所测试的任一个微服务应用。链路标识可以认为是当前测试任务对应的调用链路的ID，基于链路标识可以明确服务调用方和服务被调用方之间的关系，从而确定不同微服务应用之间的路由关系，以形成调用链路。微服务应用之间进行调用时，主动进行调用的微服务应用称为服务调用方。被调用的微服务应用称为服务被调用方，也称为服务提供方。例如：当前测试任务所测试的微服务应用包括ABC，且这些微服务应用之间的调用关系为：A调用B，B调用C，因此A和B均可以称为服务调用方，B和C也都可以称为服务被调用方。

在一种具体实施方式中，基于链路标识测试各个微服务应用之间的调用行为，包括：确定各个微服务应用中的服务调用方和服务被调用方；获取服务调用方携带的链路标识；根据链路标识将服务调用方，路由至携带有链路标识的、服务被调用方，以使服务调用方调用服务被调用方。

调用过程中，服务调用方需要向测试设备中的注册中心进行注册，在注册过程中携带链路标识，从而注册中心可基于链路标识将服务调用方路由至携带有链路标识的、服务被调用方，从而完成服务调用。

由于链路标识与测试任务对应，且为了复用已部署应用库中的各个微服务应用，可以在测试任务执行完成后，删除为各个微服务应用添加的链路标识，以避免该链路标识干扰其他测试任务，还能够释放存储空间。

链路标识与应用的版本编号一般不同。当然，二者也可以相同，当二者相同时，为避免因二者相同而导致路由过程出现问题，可以用不同字段对二者进行区分。如：针对任意微服务应用R，用m表示链路标识，用n表示版本编号，该微服务应用可记录为Rn,m。那么若微服务应用名称为A，且A在已部署应用库中表示为A1，为其添加链路标识后，A在已部署应用库中表示为A1,1。其中第一个“1”表示版本编号，第二个“1”表示链路标识。

当然，也可以设置默认微服务应用，这些默认微服务应用可以不携带链路标识，只携带版本标识。此时在调用过程中，若服务调用方或服务被调用方携带的链路标识为空，则表明其为默认微服务应用。

可见，本实施例在执行当前测试任务之前，先基于版本标识查询已部署应用库，可确定出当前测试任务所测试的各个微服务应用哪些已经部署完成，哪些需要新部署，从而仅部署需要新部署的部分微服务应用(即目标微服务应用)，因此当前需要部署的微服务应用数量得到了降低，且可以利用已部署应用库中的原微服务应用执行当前测试任务，从而实现了微服务应用的复用。如此一来，同一微服务应用仅需要在已部署应用库中部署一个，故所部署的微服务应用占用的计算机资源得到了减少，节约了微服务应用测试所占用的计算机资源。

由于已部署应用库中可以包括历史测试任务所测试的微服务应用，也可以包括未经过测试的新微服务应用，因此已部署应用库可以在执行测试任务的过程中更新，也可以在处理测试任务之前更新。更新已部署应用库具体包括：接收更新所述已部署应用库的操作请求；所述操作请求包括：为已部署应用库添加微服务应用的请求，对已部署应用库中的任意已部署应用进行替换、删除或修改的请求；根据所述操作请求更新所述已部署应用库。

请参见图4，为了更清楚地介绍已部署应用库的更新步骤，本实施例提供了一种已部署应用库更新方法，该方法可以包括以下步骤：

S401、接收更新已部署应用库的操作请求；

S402、确定操作请求对应的操作行为；

S403、根据操作行为对已部署应用库中的任意已部署应用进行替换、删除或修改，和/或为已部署应用库添加微服务应用。

由于操作请求包括：为已部署应用库添加微服务应用的请求，对已部署应用库中的任意已部署应用进行替换、删除或修改的请求，故可以根据操作行为对已部署应用库中的任意已部署应用进行替换、删除或修改，和/或为已部署应用库添加微服务应用。例如：已部署应用库中有已部署应用：D2、E1、F2，那么可以对D2、E1、F2进行替换、删除或修改，同时还可以往已部署应用库中添加G1、G2等新微服务应用。为已部署应用库添加微服务应用即：部署新微服务应用至已部署应用库。后续若有测试任务需要测试G1、G2，就可以直接使用已部署应用库中的G1、G2，而不用再部署。

可见，本实施例提供的已部署应用库可以灵活更新，从而满足多种类型的测试任务，提高了测试效率。由于不同测试任务都可以使用已部署应用库，即实现了应用复用，故可以节约计算机资源。

下面通过具体的应用场景实例描述，来介绍本申请提供的一种微服务应用测试方案。该测试方案包括：测试服务器、测试客户端以及已部署应用库。

请参见图5，该测试方案包括如下步骤：

S501、测试客户端发送测试任务至测试服务器；

S502、测试服务器获取测试任务，并确定测试任务所测试的各个微服务应用的版本标识；

S503、测试服务器基于各个版本标识在已部署应用库中查询各个微服务应用；

其中，若测试服务器未查到某一微服务应用，则部署该微服务应用至已部署应用库，并对该微服务应用标注相应的版本标识，然后查询下一个微服务应用；若查到某一微服务应用，则继续查询下一个微服务应用；直至测试任务所测试的所有微服务应用均已查询过。

S504、若测试任务所测试的各个微服务应用均已部署于已部署应用库，则测试服务器调用已部署应用库中的各个微服务应用完成当前测试任务；

S505、向测试客户端返回测试完成的通知消息。

在实际测试任务中，所需要测试的各个微服务应用的版本编号可能相同。且可以设置默认使用的微服务应用。例如：当某一应用没有新版本时，设置默认使用基础版本。据此，可有如下示例：

假设已部署应用库一共有ABCDEF六个微服务应用。当前需要处理三个测试任务，每个测试任务均需要测试ABCDEF这六个，但其中所测应用的版本有的不同，有的相同。ABCDEF均为基础版本的微服务应用。

第一个测试任务需要测试的应用：A->B1->C1->D->E1->F，其链路标识可设定为1，同时1也是版本编号。

第二个测试任务需要测试的应用：A->B2->C->D2->E2->F，其链路标识可设定为2，同时2也是版本编号。

第三个测试任务需要测试的应用：A->B->C3->D->E->F3，其链路标识可设定为3，同时3也是版本编号。

那么在执行第一个测试任务时，就可以仅部署B1、C1和E1。在执行第二个测试任务时，就可以仅部署B2、D2和E2。在执行第三个测试任务时，就可以仅部署C3和F3。在测试完成后，还可以删除新部署的这些微服务应用，以释放磁盘资源。

在该示例中，第一个测试任务的执行过程可包括：获取第一个测试任务后，基于1查询已部署应用库，此时查不到B1、C1和E1，故部署B1、C1和E1；部署B1、C1和E1后，当前测试任务所需要测试的微服务应用均已经存在于已部署应用库，此时确定链路标识为1，那么已部署应用库中标注有1的应用(B1、C1和E1)可直接被确定。由于当前测试任务需要测试ABCDEF，因此需要确定A、D和F用哪个版本。在本示例中，ABCDEF均为基础版本的微服务应用，默认当不存在标注有1的A、D和F时，直接使用A、D和F本身，故而可确定调用链路A->B1->C1->D->E1->F，从而完成测试。

在上述示例中，链路标识与版本编号相同，但没有用不同字段进行区分，而是设置了默认使用的基础版本，并且默认在找不到与版本编号和链路标识相同的同名应用时，直接使用同名的基础版本。当然，基础版本也可以标注版本编号，如：test。

第二个和第三个测试任务的执行过程可参照上述第一个测试任务的执行过程，在此不再赘述。这三个测试任务可以并行执行。

请参见图6，链路标识可称为特性环境标识，如图6中的特性环境1、特性环境2、特性环境3。图6中的主干环境包括ABCDEF这六个基础版本的微服务应用。此时，特性环境1、特性环境2和特性环境3不仅用于区别不同测试任务，也用于区别不同测试任务中所测的不同应用。

可见，本实施例具有如下技术效果：约定特性环境标识，可以据此确定调用链路，免去人工配置的繁琐，节约人力。针对任一个测试需求(即测试任务)，仅需要部署个别应用。多个测试需求可以同时进行，不再需要重复部署同一应用，实现了公共应用的共享，节约了资源。在测试任务结束后回收新部署的应用所占用的资源，可提高资源利用率。基于此方案可以实现测试任务的无限扩展，对需求的并行开发和测试能够做到无限的支持，且无需代码侵入性。

据此可设计一套特性环境管理系统，根据测试需求设定的特性环境标识，分别路由调用不同的应用，从而达到每个版本的应用只部署一个，且多个调用关系交叠的需求同时可用，同时在测试需求完成后回收资源，保留主干环境，从而节约服务器资源。

请参见图7，图7为本申请实施例提供的一种微服务应用部署装置示意图，包括：

获取模块701，用于获取用于测试微服务应用之间调用行为的测试任务；

确定模块702，用于确定测试任务所测试的各个微服务应用的版本标识；

查询模块703，用于基于各个版本标识在已部署应用库中查询各个微服务应用；

部署模块704，用于若未查询到各个微服务应用中的目标微服务应用，则部署目标微服务应用至已部署应用库，并对目标微服务应用标注相应的目标版本标识，以便基于已部署应用库执行测试任务；所述目标微服务应用为所述各个微服务应用中的任意微服务应用。

在一种具体实施方式中，确定模块具体用于：

获取测试任务对应的测试需求表；查询测试需求表，以确定各个微服务应用的版本标识。

在一种具体实施方式中，查询模块具体用于：

将各个版本标识确定为查询关键字；基于查询关键字遍历已部署应用库。

在一种具体实施方式中，还包括基于已部署应用库执行测试任务的测试模块，测试模块包括：

获取单元，用于获取测试任务对应的链路标识；

添加单元，用于对已部署应用库中的各个微服务应用添加链路标识；

调用单元，用于基于链路标识测试各个微服务应用之间的调用行为，以完成测试任务。

在一种具体实施方式中，调用单元包括：

确定子单元，用于确定各个微服务应用中的服务调用方和服务被调用方；

获取子单元，用于获取服务调用方携带的链路标识；

调用子单元，用于根据链路标识将服务调用方，路由至携带有链路标识的、服务被调用方，以使服务调用方调用服务被调用方。

在一种具体实施方式中，测试模块还包括：

删除单元，用于若测试任务执行完成，则删除为各个微服务应用添加的链路标识。

在一种具体实施方式中，还包括：

接收模块，用于接收更新已部署应用库的操作请求；操作请求包括：为已部署应用库添加应用，对已部署应用库中的任意已部署应用进行替换、删除或修改的请求；

更新模块，用于根据操作请求更新已部署应用库。

其中，关于本实施例中各个模块、单元更加具体的工作过程可以参考前述实施例中公开的相应内容，在此不再进行赘述。

可见，本实施例提供了一种微服务应用部署装置，该装置降低了当前需要部署的微服务应用的数量，且同一微服务应用仅需要在已部署应用库中部署一个，故节约了计算机资源。

进一步的，本申请实施例还提供了一种电子设备。其中，上述电子设备既可以是如图8所示的服务器50，也可以是如图9所示的终端60。图8和图9均是根据一示例性实施例示出的电子设备结构图，图中的内容不能被认为是对本申请的使用范围的任何限制。

图8为本申请实施例提供的一种服务器的结构示意图。该服务器50，具体可以包括：至少一个处理器51、至少一个存储器52、电源53、通信接口54、输入输出接口55和通信总线56。其中，所述存储器52用于存储计算机程序，所述计算机程序由所述处理器51加载并执行，以实现前述任一实施例公开的微服务应用部署中的相关步骤。

本实施例中，电源53用于为服务器50上的各硬件设备提供工作电压；通信接口54能够为服务器50创建与外界设备之间的数据传输通道，其所遵循的通信协议是能够适用于本申请技术方案的任意通信协议，在此不对其进行具体限定；输入输出接口55，用于获取外界输入数据或向外界输出数据，其具体的接口类型可以根据具体应用需要进行选取，在此不进行具体限定。

另外，存储器52作为资源存储的载体，可以是只读存储器、随机存储器、磁盘或者光盘等，其上所存储的资源包括操作系统521、计算机程序522及数据523等，存储方式可以是短暂存储或者永久存储。

其中，操作系统521用于管理与控制服务器50上的各硬件设备以及计算机程序522，以实现处理器51对存储器52中数据523的运算与处理，其可以是Windows Server、Netware、Unix、Linux等。计算机程序522除了包括能够用于完成前述任一实施例公开的微服务应用部署方法的计算机程序之外，还可以进一步包括能够用于完成其他特定工作的计算机程序。数据523除了可以包括测试任务等数据外，还可以包括应用程序的开发商信息等数据。

图9为本申请实施例提供的一种终端的结构示意图，该终端60具体可以包括但不限于智能手机、平板电脑、笔记本电脑或台式电脑等。

通常，本实施例中的终端60包括有：处理器61和存储器62。

其中，处理器61可以包括一个或多个处理核心，比如4核心处理器、8核心处理器等。处理器61可以采用DSP(Digital Signal Processing，数字信号处理)、FPGA(Field－Programmable Gate Array，现场可编程门阵列)、PLA(Programmable Logic Array，可编程逻辑阵列)中的至少一种硬件形式来实现。处理器61也可以包括主处理器和协处理器，主处理器是用于对在唤醒状态下的数据进行处理的处理器，也称CPU(Central ProcessingUnit，中央处理器)；协处理器是用于对在待机状态下的数据进行处理的低功耗处理器。在一些实施例中，处理器61可以在集成有GPU(Graphics Processing Unit，图像处理器)，GPU用于负责显示屏所需要显示的内容的渲染和绘制。一些实施例中，处理器61还可以包括AI(Artificial Intelligence，人工智能)处理器，该AI处理器用于处理有关机器学习的计算操作。

存储器62可以包括一个或多个计算机可读存储介质，该计算机可读存储介质可以是非暂态的。存储器62还可包括高速随机存取存储器，以及非易失性存储器，比如一个或多个磁盘存储设备、闪存存储设备。本实施例中，存储器62至少用于存储以下计算机程序621，其中，该计算机程序被处理器61加载并执行之后，能够实现前述任一实施例公开的由终端侧执行的微服务应用部署方法中的相关步骤。另外，存储器62所存储的资源还可以包括操作系统622和数据623等，存储方式可以是短暂存储或者永久存储。其中，操作系统622可以包括Windows、Unix、Linux等。数据623可以包括但不限于测试任务、微服务应用。

在一些实施例中，终端60还可包括有显示屏63、输入输出接口64、通信接口65、传感器66、电源67以及通信总线68。

本领域技术人员可以理解，图9中示出的结构并不构成对终端60的限定，可以包括比图示更多或更少的组件。

进一步的，本申请实施例还公开了一种存储介质，所述存储介质中存储有计算机可执行指令，所述计算机可执行指令被处理器加载并执行时，实现前述任一实施例公开的微服务应用部署方法。关于该方法的具体步骤可以参考前述实施例中公开的相应内容，在此不再进行赘述。

需要指出的是，上述仅为本申请的较佳实施例，并不用以限制本申请，凡在本申请的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本申请的保护范围之内。

本说明书中各个实施例采用递进的方式描述，每个实施例重点说明的都是与其它实施例的不同之处，各个实施例之间相同或相似部分互相参见即可。对于实施例公开的装置而言，由于其与实施例公开的方法相对应，所以描述的比较简单，相关之处参见方法部分说明即可。

本文中应用了具体个例对本申请的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本申请的方法及其核心思想；同时，对于本领域的一般技术人员，依据本申请的思想，在具体实施方式及应用范围上均会有改变之处，综上所述，本说明书内容不应理解为对本申请的限制。