CN112256359A - 微服务合并方法、装置、电子设备及可读存储介质 - Google Patents

Abstract

本申请提供一种微服务合并方法、装置、电子设备及可读存储介质，方法包括：将项目配置编译打包为各个微服务JAR文件；将各所述微服务JAR文件中的至少两个微服务JAR文件加载到类装载器中，实现在一个进程内。这样，相较于现有技术而言，通过本申请实施例的方案，可以将实现在一个进程内所有微服务看作一个更大的微服务，从而只需要分配一个微服务的硬件资源即可，占用资源少；同时只需要针对该进程进行监控布置即可，降低了监控的压力；同时，合并后微服务调用链得以降低，缓解了问题排查效率低的问题；此外，合并后各微服务之间通讯就变成了进程内的通讯，从减少了流量，降低了对于系统网络硬件的冲击。

Description

微服务合并方法、装置、电子设备及可读存储介质

技术领域

本申请涉及微服务技术领域，具体而言，涉及一种微服务合并方法、装置、电子设备及可读存储介质。

背景技术

随着信息时代的蓬勃发展，系统复杂度越来越高，处理的数据量也越来越大。单体架构在规模比较小的情况下工作情况良好，但是随着系统规模的扩大，它暴露出来的问题也越来越多。规模扩大对系统的水平扩展能力提出了极高的要求，微服务应用应运而生。而所谓微服务，就是以较小的功能集作为独立的服务进行部署，模块间调用通过服务调用完成。

当下的微服务模式，主要是将过去一个耦合在一起的大项目、整体式的部署，转变成了多个高内聚的小项目，分别进行的微服务部署。随着业务的发展，在微服务集群内的服务越来越多，从而产生了一系列的新问题。比如：

随着微服务越来越多，每个新增的微服务，都需要一整套的高可用方案，都需要分配一定的硬件资源，从而导致占用的资源越来越多；类似的，由于微服务越来越多，需要监控的内容也越来越多，对监控的压力也越来越大；类似的，由于服务越来越多，一个接口的调用链可能达到3层或4层或者更多，导致问题的排查低效，定位和修复的速度不够快，影响用户体验；此外，由于微服务越来越多，原本进程内通讯更多的变成网络端通讯，会对系统的网络硬件造成一定的冲击。

发明内容

本申请实施例的目的在于提供一种微服务合并方法、装置、电子设备及可读存储介质，用以缓解随着微服务的增多而带来的上述问题。

本申请实施例提供了一种微服务合并方法，包括：将项目配置编译打包为各个微服务JAR文件；将各所述微服务JAR文件中的至少两个微服务JAR文件加载到类装载器中，实现在一个进程内。

在上述实现过程中，通过将项目配置编译打包成为各个微服务JAR文件，然后通过将各微服务JAR文件加载到类装载器中，实现在一个进程内，从而使得在一个进程中，可以同时实现运行在该进程内的所有微服务的功能。即实现了对于微服务的合并。这样，相较于现有技术而言，通过本申请实施例的方案，可以将实现在一个进程内所有微服务看作一个更大的微服务，从而只需要分配一个微服务的硬件资源即可，占用资源少；同时只需要针对该进程进行监控布置即可，降低了监控的压力；同时，合并后微服务调用链得以降低，缓解了问题排查效率低的问题；此外，合并后各微服务之间通讯就变成了进程内的通讯，从而减少了流量，降低了对于系统网络硬件的冲击。

进一步地，所述将项目配置编译打包为各个微服务JAR文件，包括：针对项目配置中的每一个类、依赖和配置文件进行编译；按照以下方式打包项目中编译好的各文件：判断当前文件是否为第三方依赖JAR文件或框架依赖JAR文件；若当前文件为第三方依赖JAR文件，将当前文件放置到预设的第三方依赖目录中；若当前文件为框架依赖JAR文件，将当前文件放置到预设的框架依赖目录中。

在本申请实施例中，针对项目配置中的每一个类、依赖和配置文件进行编译后，逐个文件地进行识别，将第三方依赖JAR文件和框架依赖JAR文件放置到相应的目录中，实现依赖分类和小包保存，从而在需要修改依赖时，可以仅替换掉相应的依赖JAR文件，而不用重构整个微服务对应的子项目。

进一步地，所述方法还包括：在所述当前文件不为第三方依赖JAR文件和框架依赖JAR文件时，判断当前文件是否为所述项目的功能模块，或为所述项目的启动模块；若所述当前文件为所述功能模块，将所述当前文件放置到预设的功能模块目录中；若所述当前文件为所述启动模块，将所述当前文件放置到预设的启动模块目录中。

类似的，通过将功能模块和启动模块的JAR文件放置到相应的目录中，实现业务模块分类和小包保存，从而在需要修改业务模块时，可以仅替换掉相应的业务模块JAR文件，而不用重构整个微服务对应的子项目。

进一步地，在判断当前文件是否为第三方依赖JAR文件或框架依赖JAR文件之前，所述方法还包括：判断所述当前文件的类型；确定所述当前文件为JAR文件。

进一步地，所述方法还包括：在判断出所述当前文件为配置文件时，将所述配置文件与已获取到的配置文件进行配置合并并去重，得到新的配置文件；所述新的配置文件放置在预设的配置文件目录中。

通过上述实现过程，可以实现对于项目的配置文件的集成并去重，从而可以为在实现合并后的微服务提供配置的同时，降低配置文件量，降低打包出的项目大小，减轻运行负担，提高启动效率。

进一步地，所述方法还包括：在判断出所述当前文件为非JAR格式的类文件时，将所述类文件打包为JAR文件，并重新判断所述当前文件的类型。

应当理解的是，在实际应用过程中，除了直接下载得到的依赖类(为JAR文件)外，往往还会存在有工程师自己写的类(可能是依赖类，也可以是实现业务模块的类)，此时可以将其打包为JAR文件，从而按照前述方式处理，从而保证方案的可靠性。

进一步地，在确定所述当前文件为JAR文件之后，判断当前文件是否为第三方依赖JAR文件或框架依赖JAR文件之前，所述方法还包括：确定所述当前文件未被处理过。

在实际应用过程中，同一子项目中，或者不同子项目中，可能会存在有同一个JAR文件。那么通过上述过程，即可实现对于已处理过的文件夹的放弃，从而避免针对同一JAR文件进行多次重复保存，从而可以有效降低保存的JAR文件量，进而降低打包出的项目大小，减轻运行负担，提高启动效率。

进一步地，在将项目配置编译打包为各个微服务JAR文件之前，所述方法还包括：将微服务的代码地址配置在项目配置中。

在上述实现过程中，通过代码仓库的方式，实现了微服务代码与项目之间的分离，仅在项目配置中配置微服务的代码地址供项目调用，从而不会改变微服务高内聚低耦合的特性。

进一步地，将微服务的代码地址配置在项目配置中，包括：创建ALLINONE项目；在项目的配置中添加所述微服务的代码地址；在根项目的依赖配置文件中添加子项目；在所述子项目中添加所述微服务的依赖。

在上述实现过程中，通过专门的子项目来集成各微服务的依赖，从而可以通过一个子项目来实现对于所有微服务之间的依赖关系的管理，从而可以实现将微服务间的网络调用转换为进程内调用，确保各微服务能够在一个进程内被实现。

进一步地，所述方法还包括：在所述子项目中添加所述微服务的依赖的版本，以使所述微服务优先根据所述版本的依赖进行运行。

在实际应用过程中，微服务可能具有多个依赖版本。为了解决依赖版本的调用冲突，在本申请实施例中可以在子项目中添加微服务的依赖的版本，从而优先基于子项目中的版本的依赖进行运行。

本申请实施例中还提供了一种微服务合并装置，包括：编译打包模块和实现模块；所述编译打包模块，用于将项目配置编译打包为各个微服务JAR文件；所述实现模块，用于将各所述微服务JAR文件中的至少两个微服务JAR文件加载到类装载器中，实现在一个进程内。

本申请实施例中还提供了一种电子设备，包括：处理器、存储器及通信总线；所述通信总线用于实现所述处理器和存储器之间的连接通信；所述处理器用于执行存储器中存储的一个或者多个程序，以实现上述任一种的方法。

本申请实施例中还提供了一种可读存储介质，其特征在于，所述可读存储介质存储有一个或者多个程序，所述一个或者多个程序可被一个或者多个处理器执行，以实现上述任一种的方法。

附图说明

为了更清楚地说明本申请实施例的技术方案，下面将对本申请实施例中所需要使用的附图作简单地介绍，应当理解，以下附图仅示出了本申请的某些实施例，因此不应被看作是对范围的限定，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他相关的附图。

图1为本申请实施例提供的一种微服务合并方法的流程示意图；

图2为本申请实施例提供的一种微服务合并的示意图；

图3为本申请实施例提供的一种编译打包流程的流程示意图；

图4为本申请实施例提供的一种微服务合并装置的结构示意图；

图5为本申请实施例提供的一种电子设备的结构示意图。

具体实施方式

下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行描述。

实施例一：

缓解随着微服务的增多而带来的各式各样的问题，在本申请实施例中提供了一种微服务合并方法。

参见图1所示，本申请实施例中所提供的微服务合并方法包括：

S101：将项目配置编译打包为各个微服务JAR文件。

在本申请实施例中，可以基于ALLINONE的编译组件实现对于项目配置的编译打包。

为此，在本申请实施例中，可以先创建ALLINONE项目，并将需要合并的微服务的代码或代码地址配置在项目配置中。

示例性的，在本申请实施例中，可以通过Maven命令基于代码生成器创建ALLINONE项目。

而在创建ALLINONE项目后，可以在根项目的依赖配置文件中添加子项目，进而在该子项目的pom.xml(依赖配置文件)中集成各微服务的依赖，从而通过该子项目来实现依赖的冲突解决，以及将不同微服务之间的网络间调用转换为进程内调用，确保各微服务可以在一个进程内实现。

在本申请实施例中，而为了能够解决依赖冲突(在实际应用中，可能存在不同的微服务的某一或某些依赖文件的名称(由于依赖文件常为JAR包，即JAR文件的形式，因此依赖文件的名称也称该JAR包的包名)，从而导致调用时可能出现调用错误的情况，即可能存在依赖冲突)，在将各微服务的依赖添加到该子项目的依赖配置文件中时，可以采用依赖文件的包名加上对应的微服务名的形式，来构成各依赖文件在该子项目中的唯一标识，从而避免出现调用错误的情况。

应理解，采用依赖文件的包名加上对应的微服务名的形式来作为各依赖文件在该子项目中的唯一标识仅是一种可行的实施方式，除此之外还可以采用其余可实现各依赖文件与相应微服务对应可识别的方式实现保存，在本申请实施例中不做限制。比如可以通过为每个微服务配置不同的唯一标识号段，并根据号段重新为各依赖文件分配唯一标识等方式实现。

此外，在实际应用过程中，微服务可能具有多个依赖版本。为了解决依赖版本的调用冲突，在本申请实施例中可以在该子项目中添加微服务的依赖的版本，从而优先基于该子项目中的版本的依赖进行运行。

在本申请实施例中，该子项目可以为ALLINONE项目的server(服务)子项目。需要说明的是，ALLINONE项目的server子项目为ALLINONE项目的启动器，最先被启动且运行。在ALLINONE项目中，还可以具有其他子项目，这些其他子项目可以是各个微服务对应的子项目，从而使得工程师可以按照传统方式配置微服务到项目中，区别仅在于server子项目会将配置的微服务的子项目的依赖，集成到自身的依赖配置文件中。

需要理解的是，在本申请实施例中，还可以在server子项目的java目录下，添加包路径\Source.java类，从而来初始化一些启动操作。

在本申请实施例中，在ALLINONE项目中配置好微服务以及相关依赖后，可以针对项目配置中的每一个类、依赖和配置文件进行编译，然后进入打包流程。

在打包流程中，可以遍历项目中的每一个编译好的类、依赖和配置文件，从而以下方式进行打包：

可以判断当前文件是否为第三方依赖JAR文件或框架依赖JAR文件；

若当前文件为第三方依赖JAR文件，则可以将当前文件放置到预设的第三方依赖目录中，比如target\boot\common目录中。

若当前文件为框架依赖JAR文件，则可以将当前文件放置到预设的框架依赖目录中，比如target\boot\framework目录中。

需要理解的是，在项目中，除了依赖文件为JAR文件外，还存在有业务模块也是JAR文件。而业务模块包括功能模块(即实现微服务业务处理功能的业务模块)和启动模块(实现微服务启动的模块)，因此，在本申请实施例中，还可以判断当前文件是否为功能模块，或者为启动模块。从而在当前文件为功能模块时，将当前文件放置到预设的功能模块目录中；在当前文件为启动模块时，将当前文件放置到预设的启动模块目录中。

应当理解的是，在实际应用过程中，同一子项目中，或者不同子项目中，可能会存在有同一个JAR文件，若全部都进行保存，那么会导致打包后的项目非常大。故而，在本申请实施例中，在对当前的JAR文件进行分组保存之前，可以先判断当前JAR文件是否已经被处理过(比如可以判断之前是否已经处理过相同包名的JAR文件)，若处理过，则可以略过该JAR文件，若未处理过，则按照前述方式进行分组保存，从而可以有效降低保存的JAR文件量，进而降低打包出的项目大小，减轻运行负担，提高启动效率。

应当理解的是，前述处理是针对JAR文件的处理，但是在实际项目的配置中，并非所有文件都是JAR文件。比如配置文件，工程师自己写的类文件等，这些文件可能不是JAR格式的文件。而对于这些文件，则不能直接按照上述方式执行。

为此，在本申请实施例中，可以先判断当前文件的类型，然后根据当前文件的类型，执行不同的操作。

示例性的，在当前文件的类型为JAR文件时，则可以执行前述操作。

在当前文件的类型为配置文件时，则可以将当前的配置文件与之前以获取到的配置文件进行合并去重，从而得到新的配置文件。

需要说明的是，在本申请实施例中，对于配置文件而言，在获取到之后会将其与之前已进行过合并去重的配置文件进行比对，从而再次进行合并去重，得到新的配置文件。

例如，假设当前获取到的配置文件所对应的配置项，在之前已被获取到过对应的配置文件，那么则可以丢弃该配置文件。如果当前获取到的配置文件所对应的配置项，在之前没有获取到过对应的配置文件，则可以保留该配置文件保存至预设的配置文件目录中，从而与之前所保存的配置文件一起，构成新的配置文件。

在当前文件的类型为非JAR格式的类文件时，则可以将该类文件封装为JAR文件，并重新判断当前文件的类型，从而按照前述对JAR文件的处理方式进行处理。

S102：将各微服务JAR文件中的至少两个微服务JAR文件加载到类装载器中，实现在一个进程内。

在本申请实施例中，对于依赖已被集成到了server子项目中的微服务而言，由于server子项目是ALLINONE的启动器，故而其启动后，其内所有的依赖对应的微服务JAR文件均可被加载到ClassLoader(类装载器)中，从而实现在一个进程内，包含多个微服务的功能。

在实际应用过程中，若工程师希望剔除掉某些微服务(即在一个进程内，不实现某些微服务)，则可以通过在server子项目中剔除掉该微服务相关的依赖即可。此时，虽然项目中仍旧配置有该微服务，但是ALLINONE的启动器不会再扫描到该微服务的依赖，进而不会将该微服务的JAR文件加载到类装载器中。

当然，在本申请实施例中，也可以按照现有的微服务去除方式，删除掉整个项目中与该微服务相关的内容，在本申请实施例中并不做限定。

需要说明的是，本申请实施例所描述的方案可以由工程师人工操作实现，但是也可以通过配置相应的执行器(比如将上述流程通过代码或软件配置到电脑等电子设备中，从而自动实现)。

本申请实施例的方案，通过将项目配置编译打包成为各个微服务JAR文件，然后通过将各微服务JAR文件加载到类装载器中，实现在一个进程内，从而使得在一个进程中，可以同时实现运行在该进程内的所有微服务的功能。即实现了对于微服务的合并。这样，相较于现有技术而言，通过本申请实施例的方案，可以将实现在一个进程内所有微服务看作一个更大的微服务，从而只需要分配一个微服务的硬件资源即可，占用资源少；同时只需要针对该进程进行监控布置即可，降低了监控的压力；同时，合并后微服务调用链得以降低，缓解了问题排查效率低的问题；此外，合并后各微服务之间通讯就变成了进程内的通讯，从而减少了流量，降低了对于系统网络硬件的冲击。

此外，在本申请实施例的方案中，项目中可以配置的是微服务的代码地址，从而代码和项目仍旧是分离的，不会改变微服务高内聚低耦合的特性。此外，本申请的方案并未改变微服务的开发模式，仅是将各微服务的依赖集成到了启动器中，且将项目中的文件采用最小JAR包的形式分类打包保存，并不会改变微服务开发的既有习惯与对应的权限框架，因此不会影响开发。此外，采用本申请的方案，微服务可分可和，既可以按照传统方式以单个微服务的形式部署(此时，希望单独部署的相关微服务不按照前述方式加入到ALLINONE项目中，实现到一个进程内)，也可以将几个微服务合成一个项目部署(即按照前述方式实施)，应用场景广泛。

实施例二：

本实施例结合实施例一的介绍，通过一种具体的微服务合并过程来对本申请实施例的方案进行进一步示例说明。

参见图2所示，工程师可以选择需要合并的微服务，将其代码地址配置到ALLINONE项目的配置中，通过ALLINONE编译组件将ALLINONE项目，编译打包为各个微服务JAR文件以及配置集合，然后启动ALLINONE启动器(本实施例中为子项目winning-xxx-allinone-server)，扫描各个微服务JAR文件，并加载到ClassLoader内，从而实现在一个进程内，包含这多个微服务的功能。

示例性的，首先可以进行ALLINONE项目编排流程，包括：

1通过Maven命令基于winning-aio-archetype创建ALLINONE项目。代码如下：

mvnarchetype:generate-DarchetypeGroupId＝com.winning.archetype-DarchetypeCatalog＝local-DarchetypeArtifactId＝aio-DarchetypeVersion＝1.0-SNAPSHOT-DgroupId＝com.winning-DartifactId＝xxx-Dversion＝1.0.0-SNAPSHOT-Dpackage＝com.winning.xxx

前述代码中：mvn表示maven命令，archetype:generate表示生成一个项目，-DarchetypeGroupId＝com.winning.archetype-DarchetypeCatalog＝local-DarchetypeArtifactId＝aio-DarchetypeVersion＝1.0-SNAPSHOT表示生成一个1.0-SNAPSHOT版本的com.winning.archetype.aio项目，项目生成器去本地查找-DgroupId＝com.winning-DartifactId＝xxx-Dversion＝1.0.0-SNAPSHOT-Dpackage＝com.winning.xxx生成的项目包名为com.winning.xxx，版本为1.0.0-SNAPSHOT，groupId为com.winning，artifactId为xxx。

2通过gitsubmodule命令添加要集成的微服务。代码如下：

gitsubmodule add https://git仓库

代码表示在项目配置中添加微服务的代码地址(https://git仓库)。

3在根项目的pom.xml中间添加子项目。代码如下：

<modules>(添加子项目)

<module>winning-xxx</module>(添加名称为winning-xxx的子项目)

</modules>(添加结束)

4在子项目winning-xxx-allinone-server的pom.xml中间添加要集成的微服务的依赖。代码如下：

<dependencies>(依赖集合)

<dependency>(依赖)

<groupId>com.winning</groupId>(groupId为com.winning)

<artifactId>winning-xxx-server</artifactId>(artifactId为winning-xxx-server)

<version>1.0.0</version>(版本为1.0.0)

</dependency>

</dependencies>

需要理解的是，可以在子项目winning-xxx-allinone-server的pom.xml中间可以指定依赖的版本，从而使得指定的依赖版本为第一优先级的依赖版本。比如上述代码中，第一优先级的依赖版本即为“1.0.0”。

应理解，在子项目winning-xxx-allinone-server的pom.xml中间添加要集成的微服务的依赖时，也可以不指定依赖版本。也即前述代码中，“<version>1.0.0</version>”也可以不存在。

此外，在本申请实施例中，还可以在子项目winning-xxx-allinone-server的\src\main\java目录(该目录为Maven中用于存放java代码的标准目录)下添加包路径\Source.java类，从而可以初始化工程师所需设置的启动操作。

此外，如果需要剔除某个微服务，则可以通过如下命令实现该微服务的剔除：

rm-rf子项目目录(删除子项目目录及源码)；

vi.gitmodules(删除项目目录下.gitmodules文件中子项目相关条目)；

vi.git/config(删除配置项中子项目相关条目)；

rm.git/module/*(删除项目下的子项目目录)；

gitrm--cached删除子项目名称。

然后，可以进行ALLINONE项目编译打包流程，参见图3所示，包括：

1通过Maven命令进入编译打包流程：

mvn clean package-U-Dmaven.test.skip＝true-Dmaven.javadoc.skip＝true-Dmaven.compile.fork＝true-Dskip.springboot.package＝true-T 6C

前述代码中：clean表示清理上一次的编译缓存，package表示编译打包，-U表示强制更新依赖，-Dmaven.test.skip＝true表示跳过测试，-Dmaven.javadoc.skip＝true表示跳过生成文档，-Dmaven.compile.fork＝true表示交叉编译选项开启，-Dskip.springboot.package＝true表示不执行springboot的打包流程，-T 6C表示多线程编译，以6个cpu(Central Processing Unit/Processor，中央处理器)核心进行。

2将编译的类与配置文件按照标准放置在target/classes目录。

需要说明，target是用来存放项目构建后的文件的目录，classes是target目录下用来存放编译的class文件的目录。

3文件打包：

3.1遍历所有编译好的文件。

3.1.1遍历到当前文件；

3.1.2判定当前文件是否为配置文件；

3.1.2.1在当前文件为配置文件时：

3.1.2.1.1将配置合并并去重；

3.1.2.1.2将这个合并的配置放置到target\boot\property目录中；

3.1.2.1.3跳转到3.1.1处理下一个遍历到的文件。

3.1.2.2在当前文件不为配置文件时：

3.1.2.2.1跳转到3.1.3。

3.1.3判定当前文件是否为依赖JAR文件。

3.1.3.1在当前文件为依赖JAR文件时：

3.1.3.1.1跳转到3.1.5。

3.1.3.1在当前文件不为依赖JAR文件时：

3.1.3.1.1跳转到3.1.4。

3.1.4判定当前文件是否为类文件；

3.1.4.1在当前文件为类文件时：

3.1.4.1.1将类文件打包到一个JAR文件里；

3.1.4.1.2跳转到3.1.5。

3.1.3.1在当前文件不为类文件时：

3.1.4.2.1跳转到3.1.1处理下一个遍历到的文件。

3.1.5JAR处理流程：

3.1.5.1判断这个JAR文件之前是否处理过；

3.1.5.1.1若处理过：

3.1.5.1.1.1忽略这个JAR文件，然后跳转到3.1.1处理下一个遍历到的文件。

3.1.5.1.2若未处理过：

3.1.5.1.2.1判断该JAR文件是否为第三方依赖；

3.1.5.1.2.1.1若为第三方依赖：

3.1.5.1.2.1.1.1将这个JAR文件放置到target\boot\common目录中；

3.1.5.1.2.1.1.2跳转到3.1.1处理下一个遍历到的文件。

3.1.5.1.2.1.1若不为第三方依赖，跳转到3.1.5.1.2.2。

3.1.5.1.2.2判断该JAR文件是否为框架依赖；

3.1.5.1.2.2.1若为框架依赖：

3.1.5.1.2.2.1.1将这个JAR文件放置到target\boot\framework目录中；

3.1.5.1.2.2.1.2跳转到3.1.1处理下一个遍历到的文件。

3.1.5.1.2.2.1若不为框架依赖，跳转到3.1.5.1.2.3。

3.1.5.1.2.3判断该JAR文件是否为功能模块；

3.1.5.1.2.3.1若为功能模块：

3.1.5.1.2.1.1.1将这个JAR文件放置到target\boot\module目录中；

3.1.5.1.2.1.1.2跳转到3.1.1处理下一个遍历到的文件。

3.1.5.1.2.3.1若不为功能模块，跳转到3.1.5.1.2.4。

3.1.5.1.2.4判断该JAR文件是否为ALLINONE项目的启动模块；

3.1.5.1.2.4.1若是：

3.1.5.1.2.1.1.1将这个JAR文件放置到target\boot\main目录中；

3.1.5.1.2.1.1.2跳转到3.1.1处理下一个遍历到的文件。

3.1.5.1.2.4.1若否：

3.1.5.1.2.4.1.1忽略这个JAR文件，然后跳转到3.1.1处理下一个遍历到的文件。

3.1.2遍历结束，ALLINONE编译打包流程结束。

需要说明的是，前述针对第三方依赖、框架依赖、功能模块和启动模块的判断顺序可以调整，并不限定必须按照前述判断顺序进行判断。

通过本实施例的方案，微服务的码仓库依旧是与项目分离的，不会改变微服务高内聚低耦合的特性；项目的开发态依旧是微服务模式，不会改变开发时的既有习惯与权限框架，而运行态可以将多个微服务合并成一个进程，从而给极大的降低部署成本；同时由于多个微服务合并成一个进程，因此可以将实现在一个进程内所有微服务看作一个更大的微服务，从而只需要分配一个微服务的硬件资源即可，占用资源少；同时只需要针对该进程进行监控布置即可，降低了监控的压力；同时，合并后微服务调用链得以降低，缓解了问题排查效率低的问题；此外，合并后各微服务之间通讯就变成了进程内的通讯，从而减少了流量，降低了对于系统网络硬件的冲击。

实施例三：

基于同一发明构思，本申请实施例中还提供一种微服务合并装置100。请参阅图4所示，图4示出了采用图1所示的微服务合并方法的微服务合并装置100。应理解，装置100具体的功能可以参见上文中的描述，为避免重复，此处适当省略详细描述。装置100包括至少一个能以软件或固件的形式存储于存储器中或固化在装置100的操作系统中的软件功能模块。具体地：

参见图4所示，微服务合并装置100包括：编译打包模块101和实现模块102。其中：

所述编译打包模块101，用于将项目配置编译打包为各个微服务JAR文件；

所述实现模块102，用于将各所述微服务JAR文件中的至少两个微服务JAR文件加载到类装载器中，实现在一个进程内。

在本申请实施例中，所述编译打包模块101，具体用于针对项目配置中的每一个类、依赖和配置文件进行编译；按照以下方式打包项目中编译好的各文件：判断当前文件是否为第三方依赖JAR文件或框架依赖JAR文件；若当前文件为第三方依赖JAR文件，将当前文件放置到预设的第三方依赖目录中；若当前文件为框架依赖JAR文件，将当前文件放置到预设的框架依赖目录中。

在本申请实施例中，所述编译打包模块101，具体还用于在所述当前文件不为第三方依赖JAR文件和框架依赖JAR文件时，判断当前文件是否为所述项目的功能模块，或为所述项目的启动模块；若所述当前文件为所述功能模块，将所述当前文件放置到预设的功能模块目录中；若所述当前文件为所述启动模块，将所述当前文件放置到预设的启动模块目录中。

在本申请实施例中，所述编译打包模块101还用于在判断当前文件是否为第三方依赖JAR文件或框架依赖JAR文件之前，判断所述当前文件的类型；确定所述当前文件为JAR文件。

在本申请实施例中，所述编译打包模块101还用于在判断出所述当前文件为配置文件时，将所述配置文件与已获取到的配置文件进行配置合并并去重，得到新的配置文件；所述新的配置文件放置在预设的配置文件目录中。

在本申请实施例中，所述编译打包模块101还用于在判断出所述当前文件为非JAR格式的类文件时，将所述类文件打包为JAR文件，并重新判断所述当前文件的类型。

在本申请实施例中，所述编译打包模块101还用于在确定所述当前文件为JAR文件之后，判断当前文件是否为第三方依赖JAR文件或框架依赖JAR文件之前，确定所述当前文件未被处理过。

在本申请实施例中，微服务合并装置100还可以包括配置模块。所述配置模块用于在将项目配置编译打包为各个微服务JAR文件之前，将微服务的代码地址配置在项目配置中。

在本申请实施例中，所述配置模块具体用于创建ALLINONE项目；在项目的配置中添加所述微服务的代码地址；在根项目的依赖配置文件中添加子项目；在所述子项目中添加所述微服务的依赖。

在本申请实施例中，所述配置模块还用于在所述子项目中添加所述微服务的依赖的版本，以使所述微服务优先根据所述版本的依赖进行运行。

需要理解的是，出于描述简洁的考量，部分实施例一中描述过的内容在本实施例中不再赘述。

实施例四：

本实施例提供了一种电子设备，参见图5所示，其包括处理器501、存储器502以及通信总线503。其中：

通信总线503用于实现处理器501和存储器502之间的连接通信。

处理器501用于执行存储器502中存储的一个或多个程序，以实现上述实施例一和/或实施例二中的方法。

可以理解，图5所示的结构仅为示意，电子设备还可包括比图5中所示更多或者更少的组件，或者具有与图5所示不同的配置。例如，电子设备可以为服务器或终端。

本实施例还提供了一种可读存储介质，如软盘、光盘、硬盘、闪存、U盘、SD(SecureDigital Memory Card，安全数码卡)卡、MMC(Multimedia Card，多媒体卡)卡等，在该可读存储介质中存储有实现上述各个步骤的一个或者多个程序，这一个或者多个程序可被一个或者多个处理器执行，以实现上述实施例一和/或实施例二中的方法。在此不再赘述。

在本申请所提供的实施例中，应该理解到，所揭露装置和方法，可以通过其它的方式实现。以上所描述的装置实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，又例如，多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些通信接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。

另外，作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。

再者，在本申请各个实施例中的各功能模块可以集成在一起形成一个独立的部分，也可以是各个模块单独存在，也可以两个或两个以上模块集成形成一个独立的部分。

在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。

在本文中，多个是指两个或两个以上。

以上所述仅为本申请的实施例而已，并不用于限制本申请的保护范围，对于本领域的技术人员来说，本申请可以有各种更改和变化。凡在本申请的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本申请的保护范围之内。

Claims (13)

1.一种微服务合并方法，其特征在于，包括：

将项目配置编译打包为各个微服务JAR文件；

将各所述微服务JAR文件中的至少两个微服务JAR文件加载到类装载器中，实现在一个进程内。

2.如权利要求1所述的微服务合并方法，其特征在于，所述将项目配置编译打包为各个微服务JAR文件，包括：

针对项目配置中的每一个类、依赖和配置文件进行编译；

按照以下方式打包项目中编译好的各文件：

判断当前文件是否为第三方依赖JAR文件或框架依赖JAR文件；

若当前文件为第三方依赖JAR文件，将当前文件放置到预设的第三方依赖目录中；

若当前文件为框架依赖JAR文件，将当前文件放置到预设的框架依赖目录中。

3.如权利要求2所述的微服务合并方法，其特征在于，所述方法还包括：

在所述当前文件不为第三方依赖JAR文件和框架依赖JAR文件时，判断当前文件是否为所述项目的功能模块，或为所述项目的启动模块；

若所述当前文件为所述功能模块，将所述当前文件放置到预设的功能模块目录中；

若所述当前文件为所述启动模块，将所述当前文件放置到预设的启动模块目录中。

4.如权利要求2所述的微服务合并方法，其特征在于，在判断当前文件是否为第三方依赖JAR文件或框架依赖JAR文件之前，所述方法还包括：

判断所述当前文件的类型；

确定所述当前文件为JAR文件。

5.如权利要求4所述的微服务合并方法，其特征在于，所述方法还包括：

在判断出所述当前文件为配置文件时，将所述配置文件与已获取到的配置文件进行配置合并并去重，得到新的配置文件；所述新的配置文件放置在预设的配置文件目录中。

6.如权利要求4所述的微服务合并方法，其特征在于，所述方法还包括：

在判断出所述当前文件为非JAR格式的类文件时，将所述类文件打包为JAR文件，并重新判断所述当前文件的类型。

7.如权利要求4所述的微服务合并方法，其特征在于，在确定所述当前文件为JAR文件之后，判断当前文件是否为第三方依赖JAR文件或框架依赖JAR文件之前，所述方法还包括：

确定所述当前文件未被处理过。

8.如权利要求1-7任一项所述的微服务合并方法，其特征在于，在将项目配置编译打包为各个微服务JAR文件之前，所述方法还包括：

将微服务的代码地址配置在项目配置中。

9.如权利要求8所述的微服务合并方法，其特征在于，将微服务的代码地址配置在项目配置中，包括：

创建ALLINONE项目；

在项目的配置中添加所述微服务的代码地址；

在根项目的依赖配置文件中添加子项目；

在所述子项目中添加所述微服务的依赖。

10.如权利要求9所述的微服务合并方法，其特征在于，所述方法还包括：

在所述子项目中添加所述微服务的依赖的版本，以使所述微服务优先根据所述版本的依赖进行运行。

11.一种微服务合并装置，其特征在于，包括：编译打包模块和实现模块；

所述编译打包模块，用于将项目配置编译打包为各个微服务JAR文件；

所述实现模块，用于将各所述微服务JAR文件中的至少两个微服务JAR文件加载到类装载器中，实现在一个进程内。

12.一种电子设备，其特征在于，包括：处理器、存储器及通信总线；

所述通信总线用于实现所述处理器和存储器之间的连接通信；

所述处理器用于执行存储器中存储的一个或者多个程序，以实现如权利要求1至10任一项所述的方法。

13.一种可读存储介质，其特征在于，所述可读存储介质存储有一个或者多个程序，所述一个或者多个程序可被一个或者多个处理器执行，以实现如权利要求1至10任一项所述的方法。

Images