本申请属于微服务，具体涉及一种对多个微服务进行合并部署的方法和系统。
背景技术：
1、微服务架构技术在突破单体硬件资源瓶颈、可水平伸缩高可用、厘清业务领域边界高内聚可扩展、可并行推进开发，微服务生态活跃度高、基础设施的开源组件丰富完善可复用等方面具有前所未有的优势，因此在saas平台型企业和云端产品中得到了广泛的应用。
2、一般情况，划分完业务领域后java后端服务大多采用微服务方式进行开发，同时为了使得saas在线服务具备高可用高并发特性，企业大多以可水平扩展的集群方式部署微服务实例。一方面saas平台产品的业务功能逐渐增多产品线逐步扩充，支撑产品的微服务个数逐渐增多、微服务间调用关系越来越复杂、微服务部署所需硬件资源越来越多、排错越来越困难；另一方面在tob服务市场，核心企业对数据安全对网络安全的要求越来越高，对saas平台性科技企业提出了在核心企业自有数据中心及有限硬件条件下进行产品私有化部署的要求，原有云端的高并发高可用高稳定目标下的微服务部署体系存在对硬件资源需求大、部署复杂度高、排错困难、运维成本高的问题，在企业侧本地部署场景下问题被放大，这对竞争优势的保持是一个负面影响。
3、企业私有部署时，服务请求量小，硬件资源有限，小而全是核心诉求，部署进程的个数越少越好。保留云端微服务个数仅减少本地副本数是虽然是一种节约资源的方式，但效果不理想，无法满足客户要求，更理想的方式是能够按需进行微服务合并减少微服务个数。从微服务代码开发规范入手、从微服务架构注册发现中心入手，从进程间和进程内请求链路转变入手，设计一套方法、装置，在本地私有化部署场景下，结合单租户请求量小的特点，将一些微服务按照一定关系进行分类组合，将同一类的微服务合并在一起进行部署，从而减少进程数减少部署复杂度是可行的。
4、现有技术中，如何对多个微服务进行合并部署，存在几种技术路线：
5、在一种技术路线中，从编译前的源代码开始，将原有微服务源代码中的启动类文件删除后将源代码合并到一个新git项目中，新增新启动类文件，修改合并配置文件，修改合并pom文件管理公共三方jar包依赖，新命名微服务名称，编译打包完成合并。在另一种技术路线中，从编译后的jar包构建物开始，将原有微服务jar包解压拆开，将jar包里面编译完成的文件按照class文件、配置文件、资源文件、3方依赖jar包等文件类型分类汇集并删除原有各微服务启动类class文件，将原有多个微服务的配置信息进行合并，引入一个公共新启动类文件，最后重新压缩组包一个新的大jar包文件，完成微服务合并。在文件归类汇集上存在手动识别归类和程序自动识别归类两种自动化程度不同的多种手段。在3方jar包依赖冲突的排除上一般由人工完成。在配置文件信息合并上存在使用文本编辑软件手动合并和使用自制配置文件读写工具辅助人工合并等多种手段。此外，还可以基于springframework框架的应用上下文application context生命周期管理技术和类加载器技术，将主体壳微服务作为主应用，将被合并微服务作为子应用，以多个应用上下文方式分别进行加载，以壳微服务的主容器和多个微服务的子容器在一个进程中监听多个端口号并在注册中心中分别注册微服务名的方式将多个微服务合并到一起，这会使用到applicationcontext、applicationcontextaware、smartlifecycle、environment、springapplicationbuilder等技术。
6、然而，基于将微服务源代码合并在一起的微服务合并技术，缺点是违反高内聚原则，源代码从一套变为两套，后续功能迭代需要维护两遍，易出错。基于将微服务单体jar包拆包后所得文件分类汇聚后再组成一个大jar的微服务合并技术，由于新的大jar包在注册中心里以一个新的名称出现，原有微服务的调用方为了继续能请求到接口服务，需要修改自身配置信息或者需要修改中间层nginx反向代理配置信息才能继续访问到等缺点。基于同时加载主子容器将微服务合并在一起的微服务合并技术，由于多个applicationcontext实例以及类加载器的隔离性等原因、存在网络端口不能复用、子容器间的接口调用依然是普通http网络请求无法转换为进程内类间函数调用、启动停止耗时长等缺点。
7、申请内容
8、本申请实施例的目的是提供一种对多个微服务进行合并部署的方法和系统，以解决现有技术无法有效地合并部署微服务的缺陷。
9、为了解决上述技术问题，本申请是这样实现的：
10、第一方面，提供了一种对多个微服务进行合并部署的方法，包括以下步骤：
11、将每个所述微服务编译打包为4个jar包，并将所述4个jar包发布到maven仓库中，所述4个jar包为starter包、api包、core包和startup包；
12、创建壳微服务，通过所述壳微服务按需组合依赖所述maven仓库中的jar包，将所述多个微服务的配置信息合并于所述壳微服务的配置文件中，并将所述壳微服务打包成可启动的springboot型jar包；
13、初始化数据库，启动所述壳微服务，并实施业务测试项。
14、第二方面，提供了一种对多个微服务进行合并部署的系统，包括：
15、编译模块，用于将每个所述微服务编译打包为4个jar包，并将所述4个jar包发布到maven仓库中，所述4个jar包为starter包、api包、core包和startup包；
16、合并模块，用于创建壳微服务，通过所述壳微服务按需组合依赖所述maven仓库中的jar包，将所述多个微服务的配置信息合并于所述壳微服务的配置文件中，并将所述壳微服务打包成可启动的springboot型jar包；
17、测试模块，用于初始化数据库，启动所述壳微服务，并实施业务测试项。
18、本申请实施例通过壳微服务按需组合依赖多个微服务的jar包以及合并多个微服务的配置信息，对多个微服务合并部署，能够实现部署方式的灵活配置，短缩调用链路，减少网络流量和微服务部署成本，并降低链路复杂度和排错难度。
技术实现思路
1.一种对多个微服务进行合并部署的方法，其特征在于，包括以下步骤：
2.根据权利要求1所述的方法，其特征在于，所述将每个所述微服务编译打包为4个jar包，并将所述4个jar包发布到maven仓库中，具体包括：
3.根据权利要求2所述的方法，其特征在于，所述将每个微服务对外提供的api接口原有的仅支持跨进程feign http请求调用改造为既支持跨进程feign http调用也支持同进程类间函数调用，具体包括：
4.根据权利要求1所述的方法，其特征在于，所述startup包内含微服务启动时需要的启动类和配置文件，直接依赖所述starter包；所述starter包内含配置微服务包扫描路径的configuration类，直接依赖所述core包；所述core包内含微服务全部controller层以下业务代码和mapper资源文件，直接依赖所述api包；所述api包内含微服务对外提供api接口的interface定义和数据model模型定义。
5.根据权利要求1所述的方法，其特征在于，所述壳微服务包括pom文件、parent组件、影子服务组件、bootstrap应用配置文件和启动类；
6.一种对多个微服务进行合并部署的系统，其特征在于，包括：
7.根据权利要求6所述的系统，其特征在于，
8.根据权利要求7所述的系统，其特征在于，
9.根据权利要求6所述的系统，其特征在于，所述startup包内含微服务启动时需要的启动类和配置文件，直接依赖所述starter包；所述starter包内含配置微服务包扫描路径的configuration类，直接依赖所述core包；所述core包内含微服务全部controller层以下业务代码和mapper资源文件，直接依赖所述api包；所述api包内含微服务对外提供api接口的interface定义和数据model模型定义。
10.根据权利要求6所述的系统，其特征在于，所述壳微服务包括pom文件、parent组件、影子服务组件、bootstrap应用配置文件和启动类；
