CN108182068A

CN108182068A - 基于微服务的部署交付件的生成方法及装置、存储介质

Info

Publication number: CN108182068A
Application number: CN201711429206.6A
Authority: CN
Inventors: 陈军; 罗国兵; 张红
Original assignee: Hangzhou Dt Dream Technology Co Ltd
Current assignee: Hangzhou Dt Dream Technology Co Ltd
Priority date: 2017-12-26
Filing date: 2017-12-26
Publication date: 2018-06-19
Anticipated expiration: 2037-12-26
Also published as: CN110704061A; CN110704061B; CN108182068B

Abstract

本申请提供一种基于微服务的部署交付件的生成方法及装置、存储介质，该方法可以包括：根据预定义的业务需求拆分服务得到若干模块，每个模块提供至少一个服务；针对每个模块编译独立的实现包，并发布至实现包集合中；当有实际业务需求时，从所述实现包集合中获取所述实际业务需求包含的各个模块对应的实现包；将获取到的实现包聚合成部署包，以生成对应于所述实际业务需求的部署交付件。通过本申请的技术方案，可以在服务拆分的粒度不受限制的情况下，按业务需求自由聚合出指定数量的部署交付件。同时，可以在不同的业务场景下复用同一模块的实现包。

Description

基于微服务的部署交付件的生成方法及装置、存储介质

技术领域

本申请涉及微服务系统技术领域，尤其涉及一种基于微服务的部署交付件的生成方法及装置、存储介质。

背景技术

在构建微服务系统时，服务拆分是设计阶段重要的部分。在开发阶段，可以按功能来拆分服务至相应的模块(每个模块提供特定的服务)，并由开发人员编译出各个模块的部署包。服务拆分的粒度越细，每个模块实现的功能就越简单，从而使得开发的复杂程度越低，可以充分体现微服务开发的优势。而在部署运维阶段，将部署包作为部署交付件进行部署和运维。当服务拆分的粒度较细时，大量的部署交付件将导致部署和运维的难度较大。因此，从部署运维的角度来看，应尽量减少部署交付件的数量。综上，服务拆分面临着一个矛盾：开发时服务拆分的粒度越细越好；而在部署运维时部署交付件的数量越少越好。

在相关技术中，为了降低部署运维的压力，通过平衡拆分和交付的利弊，将服务拆分的粒度控制在一定的合理范围内。

然而，对服务拆分粒度的妥协提高了开发的复杂程度，导致并不能发挥出微服务系统在开发过程中的优势，降低了开发效率。同时，服务之间的组合不够灵活自由，难以在不同的业务场景下复用基础模块代码。

发明内容

有鉴于此，本申请提供一种基于微服务的部署交付件的生成方法及装置、计算机可读存储介质，可以在服务拆分的粒度不受限制的情况下，按业务需求自由聚合出指定数量的部署交付件。

为实现上述目的，本申请提供技术方案如下：

根据本申请的第一方面，提出了一种基于微服务的部署交付件的生成方法，包括：

根据预定义的业务需求拆分服务得到若干模块，每个模块提供至少一个服务；

针对每个模块编译独立的实现包，并发布至实现包集合中；

当有实际业务需求时，从所述实现包集合中获取所述实际业务需求包含的各个模块对应的实现包；

将获取到的实现包聚合成部署包，以生成对应于所述实际业务需求的部署交付件。

根据本申请的第二方面，提出了一种基于微服务的部署交付件的生成装置，包括：

拆分单元，根据预定义的业务需求拆分服务得到若干模块，每个模块提供至少一个服务；

编译单元，针对每个模块编译独立的实现包，并发布至实现包集合中；

获取单元，当有实际业务需求时，从所述实现包集合中获取所述实际业务需求包含的各个模块对应的实现包；

聚合单元，将获取到的实现包聚合成部署包，以生成对应于所述实际业务需求的部署交付件。

根据本申请的第三方面，提出了一种计算机可读存储介质，其上存储有计算机指令，该指令被处理器执行时实现如上述技术方案中任一项所述方法的步骤。

由以上技术方案可见，本申请通过将开发层和交付层分离，在开发时服务拆分的粒度不受限制，可以在开发层根据预定义的业务需求拆分服务至相应的模块并编译各个模块的实现包，各个实现包之间相互独立，降低了开发难度。在交付时，可以在交付层按照实际业务需求将所需的模块对应的实现包聚合成部署包，以用于生成该业务的部署交付件，实现对实现包的自由组合和按需引用，提升了生成部署交付件的效率。同时，可以在不同的业务场景下复用同一模块的实现包。

附图说明

图1是本申请一示例性实施例示出的一种基于微服务的部署交付件的生成方法的流程图。

图2是本申请一示例性实施例示出的另一种基于微服务的部署交付件的生成方法的流程图。

图3是本申请一示例性实施例示出的聚合实现包的示意图。

图4是本申请一示例性实施例示出的一种电子设备的结构示意图。

图5是本申请一示例性实施例示出的一种基于微服务的部署交付件的生成装置的框图。

具体实施方式

这里将详细地对示例性实施例进行说明，其示例表示在附图中。下面的描述涉及附图时，除非另有表示，不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本申请相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本申请的一些方面相一致的装置和方法的例子。

在本申请使用的术语是仅仅出于描述特定实施例的目的，而非旨在限制本申请。在本申请和所附权利要求书中所使用的单数形式的“一种”、“所述”和“该”也旨在包括多数形式，除非上下文清楚地表示其他含义。还应当理解，本文中使用的术语“和/或”是指并包含一个或多个相关联的列出项目的任何或所有可能组合。

应当理解，尽管在本申请可能采用术语第一、第二、第三等来描述各种信息，但这些信息不应限于这些术语。这些术语仅用来将同一类型的信息彼此区分开。例如，在不脱离本申请范围的情况下，第一信息也可以被称为第二信息，类似地，第二信息也可以被称为第一信息。取决于语境，如在此所使用的词语“如果”可以被解释成为“在……时”或“当……时”或“响应于确定”。

在构建微服务系统时，服务拆分是设计阶段重要的部分。在开发阶段，可以按功能来拆分服务至相应的模块，并由开发人员编译出各个模块的部署包。服务拆分的粒度越细，每个模块实现的功能就越简单。一方面，每个模块独立维护代码，开发人员无需关心整体架构，只需要关心每个模块提供的服务接口，从而更有利于控制质量和进度，加快开发的速度。另一方面，模块拆分得越细，其代码权限控制的粒度也越细，可以更好地利用微服务开发的优势。而在部署运维阶段，将部署包作为部署交付件进行部署和运维。当服务拆分的粒度较细时，微服务系统的运维成本与部署交付件的数量呈正相关，大量的部署交付件将导致部署和运维的难度较大。一方面，大规模部署交付件的系统对配置管理、日志管理、监控与故障报警等技术手段有较高的依赖。另一方面，服务间的依赖管理与版本控制、大量部署交付件的版本管理与持续交付都存在较大挑战。因此，从部署运维的角度来看，应尽量减少部署交付件的数量。综上，服务拆分面临着一个矛盾：开发时服务拆分的粒度越细越好；而在部署运维时部署交付件的数量越少越好。

在相关技术中，采取“折中”的妥协方式，将服务拆分的粒度控制在一定的合理范围内，以此降低部署运维的压力。然而，对服务拆分粒度的妥协提高了开发的复杂程度，导致并不能发挥出微服务系统在开发过程中的优势，降低了开发效率。同时，服务之间的组合不够灵活自由，难以在不同的业务场景下复用基础模块代码。

因此，本申请通过对生成部署交付件的方式予以改进，以解决相关技术中存在的上述技术问题，可以在服务拆分的粒度不受限制的情况下，按业务需求自由聚合出指定数量的部署交付件。下面结合实施例进行详细说明。

图1是本申请一示例性实施例示出的一种基于微服务的部署交付件的生成方法的流程图。如图1所示，该方法应用于开发人员侧的客户端，可以包括以下步骤：

步骤102，根据预定义的业务需求拆分服务得到若干模块，每个模块提供至少一个服务。

步骤104，针对每个模块编译独立的实现包，并发布至实现包集合中。

步骤106，当有实际业务需求时，从所述实现包集合中获取所述实际业务需求包含的各个模块对应的实现包。

步骤108，将获取到的实现包聚合成部署包，以生成对应于所述实际业务需求的部署交付件。

在本实施例中，将开发层和交付层分离，预先在开发层上按照预定义的业务需求(服务拆分的粒度不受限制)拆分服务至各个模块并编译出相应的实现包；而在交付层上，不使用开发层编译出的部署包(由实现包与所依赖的运行库打包生成，用于运行测试)，而是将待聚合业务(即对应于实际业务需求的业务)包含的各个模块对应的实现包进行聚合得到该业务对应的部署包，以用于生成实际业务需求对应的部署交付件。通过上述生成部署交付件的方式，既可以使得服务拆分的粒度不受限制，又可以按业务需求自由聚合出指定数量的部署交付件。

由于将开发层和交付层分离，本申请涉及以下问题：

1、分离部署包与实现包

由于在交付层并不直接使用开发层编译出的部署包，可以将各个模块的实现包与部署包分开，同时各个模块的实现包被发布至本地私有仓库中，以便于版本控制和交付层的依赖管理。

2、支持多数据源

在拆分服务后，由于在开发阶段需要独立运行测试各个模块对应的实现包(即由实现包与所依赖的运行库打包生成相应的部署包用于运行测试)，针对每一模块可以配置有相应的数据库，数据库用于相应的模块读写相关数据。通过针对每一模块配置相应的数据库，可以降低后续聚合业务的复杂度，提升聚合的效率。当然，数据库的数量可根据实际情况灵活配置。例如，还可以针对每两个模块配置一数据库，或者针对所有模块配置同一数据库；本申请并不对此进行限制。而在后续聚合业务时，为了降低其复杂度，数据驱动框架需要支持多数据源配置。同时，在发起数据库操作时，数据源需要使用模块标识来区分。

基于对多数据源的支持，为了保证开发团队对数据库的透明访问(即各开发团队使用的数据库配置在生产环境中同时存在，可以采用传统仅存在单个模块的数据库的访问配置和访问模式)，支持聚合发布，以及提供对多个数据源兼容的能力，可以基于动态代理技术，根据各模块配置将数据库访问按照模块数据库配置隔离，由代理类负责管理各模块和数据库配置的对应关系，从而实现针对多数据源的透明访问。例如，业务S包含模块A和模块B，在业务S上线之前，模块A和模块B由各自独立的开发团队开发实施，模块A和模块B基于不同的数据库配置，由代理类配置模块的包名与数据库的对应关系；那么，在业务S发起数据库操作时，根据该对应关系即可确定出相应的数据库。

3、统一第三方数据包的版本

不同的模块之间都存在聚合的可能，而不同的模块很可能依赖相同的第三方数据包。因此，为了提升聚合的效率，可以对第三方数据包的版本进行统一约束，即不同的模块所依赖的相同第三方数据包的版本相同。基于上述统一版本的机制，所有第三方数据包的统一版本可由顶层数据包来声明；进而可以通过以下方式描述任一模块依赖的第三方数据包的版本：声明采用的顶层数据包的版本，以及所述任一模块所依赖的数据包。通过仅声明顶层数据包的版本即可描述任一模块所依赖的数据包的版本，而无需分别描述各个数据包的版本，从而提高了声明第三方数据包的版本的效率，有利于加快后续聚合的效率。

4、识别服务之间的调用关系

微服务系统存在大量服务之间的调用关系，待聚合业务在聚合后所调用的服务的来源可能发生变化，待聚合业务包含的模块调用的服务可能由外部调用变化为内部调用。因此，可以在执行聚合操作之前，确定对应于所述实际业务需求的业务调用来自内部模块的内部调用服务，以及调用来自外部模块的外部调用服务；其中，在所述部署交付件运行时，所述内部调用服务被采取本地调用流程调用，所述外部调用服务被采取远程调用流程调用。通过对外部、内部调用服务的确定，可以避免来自内部模块的内部调用服务被采取远程调用流程调用，从而提高了后续部署交付件运行时调用服务的效率。

具体的，可以先合并各个模块的提供服务子列表以生成聚合后的提供服务列表，提供服务子列表用于记录相应的模块提供的服务，所述提供服务列表用于记录所述待聚合业务提供的服务，以及合并各个模块的调用服务子列表以生成聚合后的调用服务列表，调用服务子列表用于记录相应的模块调用的服务，所述调用服务列表用于记录所述待聚合业务调用的服务；再确定所述提供服务列表与所述调用服务列表中相同的重复服务，并将所述重复服务作为所述内部调用服务，以及将所述调用服务列表中区别于所述重复服务的其他服务作为所述外部调用服务。

为了便于理解，下面以java开发为例，结合附图对本申请的技术方案进行进一步说明。在实现基于本申请的技术方案时，可以分为两个阶段的处理过程：1)第一阶段：设计阶段；2)第二阶段：聚合阶段；下面分别对这两个阶段进行详细描述。

1)设计阶段

在设计阶段，可由开发人员在开发层上根据预定义的业务需求将服务拆分至相应的模块，拆分的粒度可以尽量细，每一模块提供至少一个服务。例如，可以将服务拆分至电商、订单、会员、商品、优惠、支付、退货、退款等模块。在拆分服务后，再将每个模块交给不同的开发团队编译生成实现包(在本实施例中均为jar包)，并发布至实现包集合中，各个团队间只需关心彼此接口的依赖。每个模块在开发时，可以将实现包与所依赖的运行库打包生成相应的部署包(在本实施例中均为war包)用于运行测试。当然，拆分的粒度(即预定义的业务需求)可由开发人员根据实际情况灵活设定，本申请并不对此进行限制。

2)聚合阶段

基于在设计阶段对模块的实现包的编译，可以按照待聚合业务的实际业务需求选取所包含的模块的实现包，以聚合出待聚合业务的部署包。请参见图2，图2是本申请一示例性实施例示出的另一种基于微服务的部署交付件的生成方法的流程图。如图2所示，该方法应用于开发人员侧的客户端，可以包括以下步骤：

步骤202，获取实现包。

在本实施例中，可以按照实际业务需求，获取待聚合业务包含的各个模块对应的实现包。其中，待聚合业务包含的各个模块的实现包由开发人员在设计阶段预先编译生成。举例而言，假定待聚合业务为“购买商品”，那么可以获取模块“商品”、“优惠”、“支付”的实现包。

步骤204，确定内、外部调用服务。

在本实施例中，确定待聚合业务(即对应于实际业务需求的业务)调用来自内部模块的内部调用服务，以及调用来自外部模块的外部调用服务。

步骤206，维护服务声明文件。

在本实施例中，待聚合业务在聚合后所调用的服务的来源可能发生变化，待聚合业务包含的模块调用的服务可能由外部调用变化为内部调用。因此，可以在执行聚合操作之前识别内部调用服务和外部调用服务。其中，在后续待聚合业务的部署交付件运行时，内部调用服务被采取本地调用流程调用，外部调用服务被采取远程调用流程调用。通过对内部、外部调用服务的识别，可以避免来自内部模块的内部调用服务被采取远程调用流程调用，从而提高了后续部署交付件运行时调用服务的效率。

举例而言，假定业务1包含模块A、B、D，各个模块提供和调用服务的情况如表1所示：

模块	提供服务子列表	调用服务子列表
			A	a.service_1	b.service_2
B	b.service_1、b.service_2	/
			D	/	c.service_1

表1

那么，在聚合前，模块A的服务配置文件为：

Provider:a.service_1；

Consumer:b.service_2。

模块B的服务配置文件为：

Provider:b.service_1、b.service_2。

模块D的服务配置文件为：

Consumer:c.service_1。

其中，“Provider”代表模块提供的服务；“Consumer”代表模块调用来自外部模块的外部调用服务。

通过合并各个模块的提供服务子列表可以得到提供服务列表：a.service_1、b.service_1、b.service_2；合并各个模块的调用服务子列表得到调用服务列表：b.service_2、c.service_1。其中，可以确定提供服务列表与调用服务列表中相同的重复服务为b.service_2。那么，在聚合后的业务1中，内部调用服务为b.service_2，外部调用服务为c.service_1。同时，在聚合前模块A调用b.service_2需采取远程调用流程；而在聚合后，由于模块A与模块B处于同一业务内，模块A调用b.service_2只需采取本地调用流程。

基于上述识别过程可得，聚合后业务1的服务声明文件为：

Provider：a.service_1、b.service_1、b.service_2；

Consumer:c.service_1。

步骤208，将实现包聚合成部署包。

在本实施例中，在交付层实施聚合的操作，将获取的实现包与各个实现包所依赖的运行库共同打包聚合成待聚合业务的部署包。通过使用待聚合业务包含的各个模块对应的实现包进行聚合得到该业务的部署包，以用于生成待聚合业务对应的部署交付件，既可以使得服务拆分的粒度不受限制，又可以按业务需求自由聚合出指定数量的部署交付件，实现对实现包的自由组合和按需引用，提升了生成部署交付件的效率。同时，可以在不同的业务场景下复用同一模块的实现包。

举例而言，如图3所示，承接于上述举例，假定业务2包含模块A、C。那么，可以通过获取模块A、B、D的实现包并与模块A、B、D的实现包所依赖的运行库共同打包聚合成业务1的部署包1；通过获取模块A、C的实现包并与模块A、C的实现包所依赖的运行库共同打包聚合成业务2的部署包2。其中，在业务1和业务2中均使用了模块A的实现包。

在本申请的技术方案中，由于将开发层和交付层分离，本申请涉及以下问题：

1、分离部署包与实现包

由于在交付层并不直接使用开发层编译出的部署包，可以将各个模块的实现包与部署包分开，同时各个模块的实现包(即实现包集合中的实现包)被发布至本地私有仓库中，以便于版本控制和交付层的依赖管理。例如，可以将图3中模块A、B、C、D的jar包统一发布至maven库中。

2、支持多数据源

可以针对每一模块配置相应的数据库，数据库用于相应的模块读写相关数据。通过针对每一模块配置相应的数据库，可以降低后续聚合业务的复杂度，提升聚合的效率。当然，数据库的数量可根据实际情况灵活配置。例如，还可以针对每两个模块配置一数据库，或者针对所有模块配置同一数据库；本申请并不对此进行限制。

举例而言，如图3所示，业务1聚合了A、B、D三个模块，针对模块A、B、D分别配置数据库A、B、D以用于读写相关的数据。需要说明的是，在设计阶段开发人员需要将各个实现包(实现包a、b、d)与所依赖的运行库打包生成相应的部署包(部署包a、b、d)用于运行测试，此时将使用数据库A、B、D；而在聚合后运行业务1时，运行对应业务1的部署包1同样需要使用数据库A、B、D分别读写模块A、B、D的相关数据。同时，业务1在运行时需要建立3个数据库连接，连接池可以分别命名为sql-factory-a、sql-factory-b、sql-factory-c，在业务A发起数据库操作时，可以通过指定连接池名来区分不同模块的数据库。同理，对应于业务2，配置和使用数据库的方式与业务1类似，在此不再赘述。

基于上述对多数据源的支持，为了保证开发团队对数据库的透明访问(即各开发团队使用的数据库配置在生产环境中同时存在，可以采用传统仅存在单个模块的数据库的访问配置和访问模式)，支持聚合发布，以及提供对多个数据源兼容的能力，可以基于动态代理技术，根据各模块配置将数据库访问按照模块数据库配置隔离，由代理类负责管理各模块和数据库配置的对应关系，从而实现针对多数据源的透明访问。

举例而言，业务1包含模块A、模块B和模块D，在业务1上线之前，模块A、模块B和模块D由各自独立的开发团队开发实施，模块A、模块B和模块D基于不同的数据库配置，由代理类配置如表2所示的模块的包名与数据库的对应关系：

模块	模块的包名	数据库
			模块A	a.b.a	A
模块B	a.b.b	B
			模块D	a.b.d	D

表2

那么，在业务1发起数据库操作时，先确定包含的各个模块的包名，并根据确定出的包名以及表2中的对应关系确定出相应的数据库，再对确定出的数据库进行数据访问即可。

3、统一第三方数据包的版本

不同的模块之间都存在聚合的可能，而不同的模块很可能依赖相同的第三方数据包。因此，为了提升聚合的效率，可以对第三方数据包的版本进行统一约束，即待聚合的不同模块所依赖的相同第三方数据包的版本相同。具体的，第三方数据包的版本可统一在顶层维护和管理，所有模块均依赖顶层数据包来声明第三方数据包的版本，而每个模块仅声明所依赖的第三方数据包，不声明该数据包的版本。

举例而言，假定业务Q包含模块A、模块B、模块C，各模块依赖第三方数据包的配置情况如表3所示：

	模块A	模块B	模块C
				数据包a	1.0版本	2.0版本	1.1版本
数据包b	1.0版本	/	1.0版本
				数据包c	1.0版本	/	2.1版本
数据包d	/	1.0版本	1.1版本

表3

当模块A、模块B、模块C聚合成业务Q时，第三方数据包的版本汇总情况如下：

数据包a存在1.0、2.0和1.1三个版本；

数据包b存在1.0一个版本；

数据包c存在1.0和2.1两个版本；

数据包d存在1.0和1.1两个版本。

可见，除数据包b以外，其它数据包都存在版本冲突问题。

那么，可通过顶层数据包来声明全局的第三方数据包的统一版本。比如，顶层数据包1.0版本可声明全局的第三方数据包统一采用的版本如下：数据包a-2.0版本；数据包b-1.0版本；数据包c-1.0版本；数据包d-1.1版本。需要说明的是，各个第三方数据包的统一版本可根据实际情况灵活设定，本申请并不对此进行限制；同时，顶层数据包也可存在多个不同的版本，以用于声明不同的“统一版本”。

基于上述顶层数据包的声明，各个模块依赖的第三方数据包的描述如下：

模块A：顶层数据包-1.0版本；数据包a；数据包b；数据包c；

模块B：顶层数据包-1.0版本；数据包a；数据包d；

模块C：顶层数据包-1.0版本；数据包a；数据包b；数据包c；数据包d。

以模块A为例说明：模块A依赖了顶层数据包1.0版本、数据包a2.0版本、数据包b1.0版本、数据包c1.0版本；但是在针对模块A依赖的第三方数据包的描述中，除声明了顶层数据包的版本外，其他数据包的版本继承自该顶层数据包，无需再声明各自使用的版本。通过仅声明顶层数据包的版本即可描述任一模块所依赖的数据包的版本，而无需分别描述各个数据包的版本，从而提高了声明第三方数据包的版本的效率，有利于加快后续聚合的效率。

图4示出了根据本申请的一示例性实施例的电子设备的结构示意图。请参考图4，在硬件层面，该电子设备包括处理器402、内部总线404、网络接口406、内存408以及非易失性存储器410，当然还可能包括其他业务所需要的硬件。处理器402从非易失性存储器410中读取对应的计算机程序到内存408中然后运行，在逻辑层面上形成基于微服务的部署交付件的生成装置。当然，除了软件实现方式之外，本申请并不排除其他实现方式，比如逻辑器件抑或软硬件结合的方式等等，也就是说以下处理流程的执行主体并不限定于各个逻辑单元，也可以是硬件或逻辑器件。

请参考图5，在软件实施方式中，该基于微服务的部署交付件的生成装置可以包括拆分单元501、编译单元502、获取单元503和聚合单元504。其中：

拆分单元501，根据预定义的业务需求拆分服务得到若干模块，每个模块提供至少一个服务；

编译单元502，针对每个模块编译独立的实现包，并发布至实现包集合中；

获取单元503，当有实际业务需求时，从所述实现包集合中获取所述实际业务需求包含的各个模块对应的实现包；

聚合单元504，将获取到的实现包聚合成部署包，以生成对应于所述实际业务需求的部署交付件。

可选的，所述实现包集合中的实现包被发布至本地私有仓库中。

可选的，针对每一模块配置有相应的数据库，数据库用于相应的模块读写相关数据，由代理类配置各模块的包名与数据库的对应关系；所述方法还包括：

第一确定单元505，当任一业务发起数据库操作时，确定所述任一业务包含的各个模块的包名；

第二确定单元506，根据确定出的包名和所述对应关系确定相应的数据库；

访问单元507，对确定出的数据库进行数据访问。

可选的，不同的模块所依赖的相同第三方数据包的版本相同；所有第三方数据包的统一版本由顶层数据包来声明；通过以下方式描述任一模块依赖的第三方数据包的版本：

声明采用的顶层数据包的版本，以及所述任一模块所依赖的数据包。

可选的，还包括：

第三确定单元508，在执行聚合操作之前，确定对应于所述实际业务需求的业务调用来自内部模块的内部调用服务，以及调用来自外部模块的外部调用服务；

其中，在所述部署交付件运行时，所述内部调用服务被采取本地调用流程调用，所述外部调用服务被采取远程调用流程调用。

可选的，所述确定单元508具体用于：

合并各个模块的提供服务子列表以生成聚合后的提供服务列表，提供服务子列表用于记录相应的模块提供的服务，所述提供服务列表用于记录所述待聚合业务提供的服务；

合并各个模块的调用服务子列表以生成聚合后的调用服务列表，调用服务子列表用于记录相应的模块调用的服务，所述调用服务列表用于记录所述待聚合业务调用的服务；

确定所述提供服务列表与所述调用服务列表中相同的重复服务，并将所述重复服务作为所述内部调用服务，以及将所述调用服务列表中区别于所述重复服务的其他服务作为所述外部调用服务。

上述装置中各个单元的功能和作用的实现过程具体详见上述方法中对应步骤的实现过程，在此不再赘述。

对于装置实施例而言，由于其基本对应于方法实施例，所以相关之处参见方法实施例的部分说明即可。以上所描述的装置实施例仅仅是示意性的，其中所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本申请方案的目的。本领域普通技术人员在不付出创造性劳动的情况下，即可以理解并实施。

在示例性实施例中，还提供了一种包括指令的非临时性计算机可读存储介质，例如包括指令的存储器，上述指令可由基于微服务的部署交付件的生成装置的处理器执行以完成上述方法，该方法可以包括：

针对每个模块编译独立的实现包，并发布至实现包集合中；

当任一业务发起数据库操作时，确定所述任一业务包含的各个模块的包名；

根据确定出的包名和所述对应关系确定相应的数据库；

对确定出的数据库进行数据访问。

可选的，还包括：

在执行聚合操作之前，确定对应于所述实际业务需求的业务调用来自内部模块的内部调用服务，以及调用来自外部模块的外部调用服务；

可选的，所述确定对应于所述实际业务需求的业务调用来自内部模块的内部调用服务，以及调用来自外部模块的外部调用服务，包括：

其中，所述非临时性计算机可读存储介质可以是ROM、随机存取存储器(RAM)、CD-ROM、磁带、软盘和光数据存储设备等，本申请并不对此进行限制。

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

Claims

1.一种基于微服务的部署交付件的生成方法，其特征在于，包括：

针对每个模块编译独立的实现包，并发布至实现包集合中；

2.根据权利要求1所述的方法，其特征在于，所述实现包集合中的实现包被发布至本地私有仓库中。

3.根据权利要求1所述的方法，其特征在于，针对每一模块配置有相应的数据库，数据库用于相应的模块读写相关数据，由代理类配置各模块的包名与数据库的对应关系；所述方法还包括：

根据确定出的包名和所述对应关系确定相应的数据库；

对确定出的数据库进行数据访问。

4.根据权利要求1所述的方法，其特征在于，不同的模块所依赖的相同第三方数据包的版本相同；所有第三方数据包的统一版本由顶层数据包来声明；通过以下方式描述任一模块依赖的第三方数据包的版本：

5.根据权利要求1所述的方法，其特征在于，还包括：

6.根据权利要求5所述的方法，其特征在于，所述确定对应于所述实际业务需求的业务调用来自内部模块的内部调用服务，以及调用来自外部模块的外部调用服务，包括：

7.一种基于微服务的部署交付件的生成装置，其特征在于，包括：

8.根据权利要求7所述的装置，其特征在于，所述实现包集合中的实现包被发布至本地私有仓库中。

9.根据权利要求7所述的装置，其特征在于，针对每一模块配置有相应的数据库，数据库用于相应的模块读写相关数据，由代理类配置各模块的包名与数据库的对应关系；所述方法还包括：

第一确定单元，当任一业务发起数据库操作时，确定所述任一业务包含的各个模块的包名；

第二确定单元，根据确定出的包名和所述对应关系确定相应的数据库；

访问单元，对确定出的数据库进行数据访问。

10.根据权利要求7所述的装置，其特征在于，不同的模块所依赖的相同第三方数据包的版本相同；所有第三方数据包的统一版本由顶层数据包来声明；通过以下方式描述任一模块依赖的第三方数据包的版本：

11.根据权利要求7所述的装置，其特征在于，还包括：

第三确定单元，在执行聚合操作之前，确定对应于所述实际业务需求的业务调用来自内部模块的内部调用服务，以及调用来自外部模块的外部调用服务；

12.根据权利要求11所述的装置，其特征在于，所述确定单元具体用于：

13.一种计算机可读存储介质，其上存储有计算机指令，其特征在于，该指令被处理器执行时实现如权利要求1-6中任一项所述方法的步骤。