CN110018913A

CN110018913A - 应用合并部署方法、装置、设备及计算机可读存储介质

Info

Publication number: CN110018913A
Application number: CN201811446341.6A
Authority: CN
Inventors: 曹杰
Original assignee: Alibaba Group Holding Ltd
Current assignee: Advanced New Technologies Co Ltd; Advantageous New Technologies Co Ltd
Priority date: 2018-11-29
Filing date: 2018-11-29
Publication date: 2019-07-16
Anticipated expiration: 2038-11-29
Also published as: CN110018913B

Abstract

本公开实施例提供应用合并部署方法、装置、设备及计算机可读存储介质。应用合并部署方法包括：将多个应用部署在同一容器中；响应于多个应用的启动，记录多个应用中的每一应用发布和调用的服务的服务列表；当多个应用的启动完毕时，针对每一应用的服务列表中的发布和调用的服务确定多个应用中是否存在另一应用提供相匹配的服务；当针对一个应用的服务列表中的发布和调用的服务确定多个应用中存在另一应用提供相匹配的服务时，将一个应用调用另一应用所提供的匹配服务的调用关系绑定，可以将多个应用部署在同一容器中，容器内的一个应用进行服务调用时直接调用容器中的另一应用发布的服务，避免RPC调用导致的损耗。

Description

应用合并部署方法、装置、设备及计算机可读存储介质

技术领域

本公开实施例涉及计算机技术领域，尤其涉及应用合并部署方法、装置、设备及计算机可读存储介质。

背景技术

在计算机***中应用最初运行时，用户量与数据量都比较小，此时可以使用单一应用提供所有服务。当用户量不断上升，业务复杂度也不断上升时，单一应用部署所有功能将使得应用变得越来越臃肿，应用的维护也将面临巨大挑战。此时，可以采用面向服务的架构(Service Oriented Architecture，SOA)，将应用按照服务维度拆分成多个应用，应用之间采用远程过程调用(Remote Procedure Call，RPC)协议进行通信。

图1示出了相关技术中的RPC调用的过程。

如图1所示，在一次典型的RPC调用过程中，在客户端，业务在配置RPC调用时，返回的其实是一个代理对象，在代理对象中RPC框架会进行各种处理逻辑，例如限流计算、路由寻址、拼接传输对象、序列化成二进制之后进行网络传输等。当数据传输到服务端时，服务端首先需要将接口与参数信息进行反序列化，然后寻找实现类，反射调用实现类并返回结果。在返回结果时，这里又将涉及到一次数据的序列化以及网络传输。

经测试，RPC框架的这些处理逻辑平均将耗费1ms左右时间，也就是说将一次单机调用转换为一次RPC调用平均将增加1ms响应时间。或许某些人觉得这1ms时间无足轻重，但是随着服务化划分粒度越来越细，用户的一次操作可能涉及到几十上百的RPC调用。当这几十上百个1ms堆积在一起时，就不得不引起注意了。除了对响应时间的影响，将一次进程内调用转换为RPC调用还会占用更高CPU资源，这是因为对象的序列化与反序列化都属于CPU密集型操作。

因此，SOA架构在解决了单一应用不断臃肿问题的同时引入了以下两个问题：

1、RPC通信导致损耗：在拆分为SOA架构后，将会把一次***内的调用转换为***间的RPC调用，RPC调用与***内调用相比将增加CPU资源损耗、网络通信耗时等。

2、服务划分的粒度过细：在实践SOA架构时，服务划分粒度过细将导致应用负载偏低，无法有效使用机器资源。

发明内容

有鉴于此，本公开第一方面提供了一种应用合并部署方法，包括：

将多个应用部署在同一容器中；

响应于所述多个应用的启动，记录所述多个应用中的每一应用发布和调用的服务的服务列表；

当所述多个应用的启动完毕时，针对所述每一应用的所述服务列表中的发布和调用的服务确定所述多个应用中是否存在另一应用提供相匹配的服务；

当针对一个应用的服务列表中的发布和调用的服务确定所述多个应用中存在另一应用提供相匹配的服务时，将一个应用调用所述另一应用所提供的匹配服务的调用关系绑定。

本公开第二方面提供了一种应用合并部署装置，包括：

部署模块，被配置为将多个应用部署在同一容器中；

记录模块，被配置为响应于所述多个应用的启动，记录所述多个应用中的每一应用发布和调用的服务的服务列表；

确定模块，被配置为当所述多个应用的启动完毕时，针对所述每一应用的所述服务列表中的发布和调用的服务确定所述多个应用中是否存在另一应用提供相匹配的服务；

绑定模块，被配置为当针对一个应用的服务列表中的发布和调用的服务确定所述多个应用中存在另一应用提供相匹配的服务时，将一个应用调用所述另一应用所提供的匹配服务的调用关系绑定。

本公开第三方面提供了一种电子设备，包括存储器和处理器；其中，所述存储器用于存储一条或多条计算机指令，其中，所述一条或多条计算机指令被所述处理器执行以实现以下步骤：

将多个应用部署在同一容器中；

本公开第四方面提供了一种计算机可读存储介质，其上存储有计算机指令，该计算机指令被处理器执行时实现如第一方面所述的方法。

在本公开实施方式中，通过将多个应用部署在同一容器中；响应于所述多个应用的启动，记录所述多个应用中的每一应用发布和调用的服务的服务列表；当所述多个应用的启动完毕时，针对所述每一应用的所述服务列表中的发布和调用的服务确定所述多个应用中是否存在另一应用提供相匹配的服务；当针对一个应用的服务列表中的发布和调用的服务确定所述多个应用中存在另一应用提供相匹配的服务时，将一个应用调用所述另一应用所提供的匹配服务的调用关系绑定，可以将多个应用部署在同一容器中，容器内的一个应用进行服务调用时直接调用容器中的另一应用发布的服务，避免RPC调用导致的损耗。因此，可以降低RPC通信导致的网络通信耗时和CPU资源损耗，并且解决了SOA架构中服务划分粒度过细所导致的应用负载偏低的问题，有效利用及其资源。而且，在同一容器中部署多个应用便于统一规划流量，能够达到削峰填谷的效果，并且运维人员只需要关注整个***的流量，可以方便地进行容量评估。

本公开的这些方面或其他方面在以下实施例的描述中会更加简明易懂。

附图说明

为了更清楚地说明本公开实施例或相关技术中的技术方案，下面将对示例性实施例或相关技术描述中所需要使用的附图作一简单地介绍，显而易见地，下面描述中的附图是本公开的一些示例性实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1示出根据本公开一实施方式的应用合并部署方法的流程图；

图2示出根据本公开一实施方式的应用合并部署方法的流程图；

图3示出根据本公开另一实施方式的应用合并部署方法的流程图；

图4示出根据本公开一实施方式的应用合并部署方法的步骤S204的示例的流程图；

图5示出根据本公开一实施方式的应用合并部署方法的步骤S201的示例的流程图；

图6示出根据本公开一实施方式的应用合并部署方法的应用场景示例的示意图；

图7示出根据本公开另一实施方式的应用合并部署方法的应用场景示例的示意图；

图8示出根据本公开另一实施方式的应用合并部署方法的应用场景示例的示意图；

图9示出根据本公开另一实施方式的应用合并部署装置的结构框图；

图10示出根据本公开一实施方式的电子设备的结构框图；

图11是适于用来实现根据本公开一实施方式的应用合并部署方法的计算机***的结构示意图。

具体实施方式

为了使本技术领域的人员更好地理解本公开方案，下面将结合本公开示例性实施例中的附图，对本公开示例性实施例中的技术方案进行清楚、完整地描述。

在本公开的说明书和权利要求书及上述附图中的描述的一些流程中，包含了按照特定顺序出现的多个操作，但是应该清楚了解，这些操作可以不按照其在本文中出现的顺序来执行或并行执行，操作的序号如101、102等，仅仅是用于区分开各个不同的操作，序号本身不代表任何的执行顺序。另外，这些流程可以包括更多或更少的操作，并且这些操作可以按顺序执行或并行执行。需要说明的是，本文中的“第一”、“第二”等描述，是用于区分不同的消息、设备、模块等，不代表先后顺序，也不限定“第一”和“第二”是不同的类型。

下面将结合本公开示例性实施例中的附图，对本公开示例性实施例中的技术方案进行清楚、完整地描述，显然，所描述的示例性实施例仅仅是本公开一部分实施例，而不是全部的实施例。基于本公开中的实施例，本领域技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本公开保护的范围。.

图2示出根据本公开一实施方式的应用合并部署方法的流程图。该方法可以包括步骤S201、S202和S203和S204。

在步骤S201中，将多个应用部署在同一容器中。

在步骤S202中，响应于多个应用的启动，记录多个应用中的每一应用发布和调用的服务的服务列表。

在步骤S203中，当多个应用的启动完毕时，针对每一应用的服务列表中的发布和调用的服务确定多个应用中是否存在另一应用提供相匹配的服务。

在步骤S204中，当针对一个应用的服务列表中的发布和调用的服务确定多个应用中存在另一应用提供相匹配的服务时，将一个应用调用另一应用所提供的匹配服务的调用关系绑定。

在本公开的一个实施例中，容器(Docker)是一个开源的应用容器引擎，让开发者可以打包他们的应用以及依赖包到一个可移植的容器中，然后发布到设备上，也可以实现虚拟化。本公开的实施例通过对多个应用合并部署，将多个应用部署在同一容器中，在应用启动过程中读取应用发布与调用的服务列表，当发现两个应用之间发布与引用的服务相匹配时，将替换应用的RPC代理，服务调用时直接调用当前进程发布的服务，避免RPC调用。

在本公开实施方式中，通过将多个应用部署在同一容器中；响应于多个应用的启动，记录多个应用中的每一应用发布和调用的服务的服务列表；当多个应用的启动完毕时，针对每一应用的服务列表中的发布和调用的服务确定多个应用中是否存在另一应用提供相匹配的服务；当针对一个应用的服务列表中的发布和调用的服务确定多个应用中存在另一应用提供相匹配的服务时，将一个应用调用另一应用所提供的匹配服务的调用关系绑定，可以将多个应用部署在同一容器中，容器内的一个应用进行服务调用时直接调用容器中的另一应用发布的服务，避免RPC调用导致的损耗。因此，可以降低RPC通信导致的网络通信耗时和CPU资源损耗，并且解决了SOA架构中服务划分粒度过细所导致的应用负载偏低的问题，有效利用及其资源。而且，在同一容器中部署多个应用便于统一规划流量，能够达到削峰填谷的效果，并且运维人员只需要关注整个***的流量，可以方便地进行容量评估。

以下参照图6描述本公开一实施方式的应用合并部署方法的应用场景。

图6示出根据本公开一实施方式的应用合并部署方法的应用场景示例的示意图。

如图6所示，应用按照服务功能进行划分为应用A和应用B。部署时能够将应用A和应用B部署在一起。当发现部署在一起的应用A和应用B有相应的发布和调用的服务的服务列表发布时，应该避免通过RPC调用未与应用A和应用B合并部署的应用C，而是直接调用合并部署的应用发布的服务，例如，进行JVM(Java虚拟机)调用。这就是合并部署需要解决的问题。

如图6所示，应用A和应用B启动时记录每个应用发布和调用的服务的服务列表。当应用A和应用B启动完毕，针对应用A调用的服务在其他应用中寻找有没有发布匹配的服务。此时，找到应用B发布匹配服务，此时可以将应用A调用应用B发布的匹配服务的调用关系进行绑定，例如，进行JVM绑定。此时，当发现存在应用A调用应用B发布的服务的绑定关系时，替换默认RPC代理逻辑。即，当应用A的客户端代码进行调用时，应用A将强制走当前进程部署的其他应用发布的服务，避免RPC调用。因此，当合并部署的应用发现相应服务并替换RPC代理逻辑成功后，代理对象将直接调用当前进程另一应用的实现类代码，避免了路由寻址、序列化反序列化以及网络传输等处理逻辑。

当然，当未发现容器中存在发布有与应用A需要调用的服务的另一应用的绑定关系时，则应用A在代理对象未发现与应用A存在例如JVM绑定关系的另一应用，则可以通过RPC框架进行各种处理逻辑，例如，调用应用C发布的服务。

以下参照图3描述根据本公开另一实施方式的应用合并部署方法。

图3示出根据本公开另一实施方式的应用合并部署方法的流程图。与图1所示的实施方式的不同之处在于，图3所示的实施方式还包括步骤S301、S302和S303。

在步骤S301中，响应于当前应用调用另一应用发布的服务的请求，检测部署有当前应用的容器中是否存在针对所述服务的调用关系绑定的另一应用。

在步骤S302中，响应于部署有当前应用的容器中存在针对所述服务的调用关系绑定的另一应用的检测结果，当前应用调用另一应用所提供的所述服务。

在步骤S303中，响应于部署有当前应用的容器中不存在针对所述服务的调用关系绑定的另一应用的检测结果，当前应用针对所述服务发起远程过程调用。

以下参照图4描述根据本公开一实施方式的应用合并部署方法的步骤S204的一个示例。

图4示出根据本公开一实施方式的应用合并部署方法的步骤S204的示例的流程图。步骤S204包括步骤S401和S402。

在步骤S401中，检测一个应用调用另一应用所提供的匹配服务的调用关系是否具有与调用服务超时相关的属性。

在步骤S402中，当检测到一个应用调用另一应用所提供的匹配服务的调用关系具有与调用服务超时相关的属性时，激活为一个应用调用另一应用所提供的匹配服务的调用关系设置的超时检测功能。

在本公开的一个实施例中，RPC调用转为合并部署的应用的内部服务调用默认是在当前线程同步执行的。这将导致针对RPC调用配置的超时时间不生效，一些非关键调用耗时过大将直接影响***响应时间。为了解决这个问题，合并部署支持RPC调用转合并部署的应用的内部服务调用异步化。出于性能考虑，异步化默认是不开启的，因为频繁切换线程本身就会影响响应时间。当应用需要RPC转合并部署的应用的内部服务调用异步化的能力时，用户需要在调用服务上增加与调用服务超时相关的属性，例如，timeout-in-multiple＝true属性。通过对应用合并部署将该任务提交线程池，如果在超时时间没有执行完毕，在当前线程抛出超时异常信息，例如，TimeoutException。此时，由业务决定是忽略异常继续执行或者直接抛错。

以下参照图5描述根据本公开一实施方式的应用合并部署方法的步骤S201的一个示例。

图5示出根据本公开一实施方式的应用合并部署方法的步骤S201的示例的流程图。步骤S201包括步骤S501和S502。

在步骤S501中，针对部署在同一容器多个应用中的每一应用创建各自的加载器。

在步骤S502中，在同一容器中通过多个应用中的每一应用各自的加载器加载应用。

在本公开的一个实施例中，当多个应用部署在同一容器中时，每个应用的依赖都是不确定的。某些情况下，可能出现不同应用依赖了同一个文件包(例如，JAR包)的不同版本。如果使用同一加载器(例如，ClassLoader)加载这些不同应用，必然会出现大量未找到相应文件的报错(例如，ClassNotFoundException及NoSuchMethodException)。为了解决这个问题，可以针对部署在同一容器多个应用中的每一应用创建各自的加载器。例如，可以在应用容器底层基于OSGI((Open Service Gateway Initiative)类隔离技术，为每个应用创建不同的ClassLoader加载，保证了代码隔离性，避免了ClassNotFoundException及NoSuchMethodException。

图7示出根据本公开另一实施方式的应用合并部署方法的应用场景示例的示意图。如图7所示，针对合并部署的多个应用中的每一应用应用1至应用n创建各自的加载器ClassLoader。

在本公开的一个实施例中，步骤S101包括：将多个应用部署在同一容器中并且每一应用绑定到不同的域名。

在本公开的一个实施例中，除了文件包(例如，JAR包)隔离，将多个应用部署在同一容器上还可能发生请求冲突。例如，当用户请求/user/register地址时，需要准确判断需要将请求转发应用A还是应用B。例如，Tomcat服务器天然支持多域名配置，可以将应用A绑定在applicationA.alipay.com，将应用B绑定在applicationB.alipay.com，当用户请求http://applicationA.alipay.com/user/register时会将请求转发应用A处理，请求http://applicationB.alipay.com/user/register会转发应用B处理，解决了请求冲突问题。

如图7所示，针对合并部署的多个应用中的每一应用应用1至应用n，在加载业务代码后，每一应用绑定到不同的host。

在本公开的一个实施例中，部署在同一容器多个应用包括至少一个门面应用和至少一个非门面应用，其中，仅允许至少一个门面应用向容器以外的应用发布服务，并且至少一个非门面应用发布的服务仅允许所述容器内的应用调用。

图8示出根据本公开另一实施方式的应用合并部署方法的应用场景示例的示意图。

如图8所示，当仅存在单一应用时，用户向***请求服务，***返回结果。当采用SOA架构时，将应用按照服务维度拆分成多个应用，应用之间采用RPC协议进行通信。整个***的入口依然是唯一的，但是应用却变成了多个应用。在进行合并部署时，只有整个合并部署的门面***A才会对外发布服务，非门面***B、非门面***C和非门面***D不发布服务。非门面***B、非门面***C和非门面***D的服务只能供合并部署的内部***进行进程内的调用。这样设计后，对于合并部署的***以外的外部***来说，整个合并部署的***就像一个门面***单应用。

需要注意的是，合并部署对门面***个数没有限制，上面的例子展示了一个单门面***的例子，事实上合并部署也支持多个门面***。

在本公开的实施例中，将多个***合并部署在一起，也更利于***的容量评估。以支付业务为例，银行卡、账户余额、余额理财、信用支付等本质上都是支付手段。在每个应用单独部署时，每个应用都需要单独进行容量评估，为了应对每种支付手段的峰值，每个应用都会进行冗余部署，但是每种支付手段的峰值不可能同时到达。余额理财应用出现峰值的时候信用支付应用可能并非峰值。全部应用都按照最高峰值申请资源的话就会对整体资源造成浪费。如果将所有支付***都合并部署在一起，统一规划流量，就能够达到削峰填谷的效果。在对***进行运维时，只需要关注整个***的支付量，而不需要关注某种具体支付方式的支付量，可以更方便地进行容量评估。

在实际应用本公开的实施例的方案时，与单应用之间使用RPC通信相比，使用合并部署的应用之后，每次用户请求能够节省超过30ms，降低CPU使用率超过15％，节省了超过2000台物理机。在内部人员实际使用根据本公开的实施例的方案的管理***时，发现管理***普遍具有访问量小、负载低的特点。在使用合并部署应用之前，每个***都会占用一台2C4G的机器，进行合并部署改造之后，合并9个***，只占用一台4C8G的机器，节省资源超过了75％。

图9示出根据本公开另一实施方式的应用合并部署装置的结构框图。该装置可以包括获部署模块901、记录模块902、确定模块903和绑定模块904。

部署模块901被配置为将多个应用部署在同一容器中。

记录模块902被配置为响应于多个应用的启动，记录多个应用中的每一应用发布和调用的服务的服务列表。

确定模块903被配置为当多个应用的启动完毕时，针对每一应用的服务列表中的发布和调用的服务确定多个应用中是否存在另一应用提供相匹配的服务。

绑定模块904被配置为当针对一个应用的服务列表中的发布和调用的服务确定多个应用中存在另一应用提供相匹配的服务时，将一个应用调用另一应用所提供的匹配服务的调用关系绑定。

以上描述了应用合并部署装置的内部功能和结构，在一个可能的设计中，该应用合并部署装置的结构可实现为应用合并部署设备，如图10中所示，该处理设备1000可以包括处理器1001以及存储器1002。

所述存储器1002用于存储支持应用合并部署装置执行上述任一实施例中应用合并部署方法的程序，所述处理器1001被配置为用于执行所述存储器1002中存储的程序。

所述存储器1002用于存储一条或多条计算机指令，其中，所述一条或多条计算机指令被所述处理器1001执行以实现以下步骤：

将多个应用部署在同一容器中；

在本公开的一个实施例中，所述一条或多条计算机指令还被所述处理器执行以实现以下步骤：

响应于当前应用调用另一应用发布的服务的请求，检测部署有所述当前应用的容器中是否存在针对所述服务的调用关系绑定的另一应用；

响应于部署有所述当前应用的容器中存在针对所述服务的调用关系绑定的另一应用的检测结果，所述当前应用调用所述另一应用所提供的所述服务。

响应于部署有所述当前应用的容器中不存在针对所述服务的调用关系绑定的另一应用的检测结果，所述当前应用针对所述服务发起远程过程调用。

在本公开的一个实施例中，所述当针对一个应用的服务列表中的发布和调用的服务确定所述多个应用中存在另一应用提供相匹配的服务时，将一个应用调用所述另一应用所提供的匹配服务的调用关系绑定，包括：

检测一个应用调用另一应用所提供的匹配服务的调用关系是否具有与调用服务超时相关的属性；

当检测到一个应用调用另一应用所提供的匹配服务的调用关系具有与调用服务超时相关的属性时，激活为一个应用调用另一应用所提供的匹配服务的调用关系设置的超时检测功能。

在本公开的一个实施例中，所述将多个应用部署在同一容器中，包括：

针对部署在所述同一容器多个应用中的每一应用创建各自的加载器；

在所述同一容器中通过所述多个应用中的每一应用各自的加载器加载应用。

将多个应用部署在同一容器中并且每一应用绑定到不同的域名。

在本公开的一个实施例中，部署在所述同一容器多个应用包括至少一个门面应用和至少一个非门面应用，其中，仅允许所述至少一个门面应用向所述容器以外的应用发布服务，并且所述至少一个非门面应用发布的服务仅允许所述容器内的应用调用。

所述处理器1001用于执行前述各方法步骤中的全部或部分步骤。

其中，所述应用合并部署设备的结构中还可以包括通信接口，用于应用合并部署设备与其他设备或通信网络通信。

本公开示例性实施例还提供了一种计算机存储介质，用于储存所述应用合并部署装置所用的计算机软件指令，其包含用于执行上述任一实施例中应用合并部署方法所涉及的程序。

如图11所示，计算机***1100包括中央处理单元(CPU)1101，其可以根据存储在只读存储器(ROM)1102中的程序或者从存储部分1108加载到随机访问存储器(RAM)1103中的程序而执行上述图2所示的实施方式中的各种处理。在RAM1103中，还存储有***1100操作所需的各种程序和数据。CPU1101、ROM1102以及RAM1103通过总线1104彼此相连。输入/输出(I/O)接口1105也连接至总线1104。

以下部件连接至I/O接口1105：包括键盘、鼠标等的输入部分1106；包括诸如阴极射线管(CRT)、液晶显示器(LCD)等以及扬声器等的输出部分1107；包括硬盘等的存储部分1108；以及包括诸如LAN卡、调制解调器等的网络接口卡的通信部分1109。通信部分1109经由诸如因特网的网络执行通信处理。驱动器1110也根据需要连接至I/O接口1105。可拆卸介质1111，诸如磁盘、光盘、磁光盘、半导体存储器等等，根据需要安装在驱动器1110上，以便于从其上读出的计算机程序根据需要被安装入存储部分1108。

特别地，根据本公开的实施方式，上文参考图2描述的方法可以被实现为计算机软件程序。例如，本公开的实施方式包括一种计算机程序产品，其包括有形地包含在及其可读介质上的计算机程序，所述计算机程序包含用于执行图2的数据处理方法的程序代码。在这样的实施方式中，该计算机程序可以通过通信部分1109从网络上被下载和安装，和/或从可拆卸介质1111被安装。

附图中的流程图和框图，图示了按照本公开各种实施方式的***、方法和计算机程序产品的可能实现的体系架构、功能和操作。在这点上，路程图或框图中的每个方框可以代表一个模块、程序段或代码的一部分，所述模块、程序段或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意，在有些作为替换的实现中，方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如，两个接连地表示的方框实际上可以基本并行地执行，它们有时也可以按相反的顺序执行，这依所涉及的功能而定。也要注意的是，框图和/或流程图中的每个方框、以及框图和/或流程图中的方框的组合，可以用执行规定的功能或操作的专用的基于硬件的***来实现，并且/或者可以用专用硬件与计算机指令的组合来实现。

描述于本公开实施方式中所涉及到的单元或模块可以通过软件的方式实现，也可以通过硬件的方式来实现。所描述的单元或模块也可以设置在处理器中，这些单元或模块的名称在某种情况下并不构成对该单元或模块本身的限定。

作为另一方面，本公开还提供了一种计算机可读存储介质，该计算机可读存储介质可以是上述实施方式中所述装置中所包含的计算机可读存储介质；也可以是单独存在，未装配入设备中的计算机可读存储介质。计算机可读存储介质存储有一个或者一个以上程序，所述程序被一个或者一个以上的处理器用来执行描述于本公开的方法。

以上描述仅为本公开的较佳实施例以及对所运用技术原理的说明。本领域技术人员应当理解，本公开中所涉及的发明范围，并不限于上述技术特征的特定组合而成的技术方案，同时也应涵盖在不脱离所述发明构思的情况下，由上述技术特征或其等同特征进行任意组合而形成的其它技术方案。例如上述特征与本公开中公开的(但不限于)具有类似功能的技术特征进行互相替换而形成的技术方案。

Claims

1.一种应用合并部署方法，其特征在于，包括：

将多个应用部署在同一容器中；

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

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

4.根据权利要求1所述的方法，其特征在于，所述当针对一个应用的服务列表中的发布和调用的服务确定所述多个应用中存在另一应用提供相匹配的服务时，将一个应用调用所述另一应用所提供的匹配服务的调用关系绑定，包括：

5.根据权利要求1所述的方法，其特征在于，所述将多个应用部署在同一容器中，包括：

6.根据权利要求1所述的方法，其特征在于，所述将多个应用部署在同一容器中，包括：

7.根据权利要求1所述的方法，其特征在于，部署在所述同一容器多个应用包括至少一个门面应用和至少一个非门面应用，其中，仅允许所述至少一个门面应用向所述容器以外的应用发布服务，并且所述至少一个非门面应用发布的服务仅允许所述容器内的应用调用。

8.一种应用合并部署装置，其特征在于，包括：

部署模块，被配置为将多个应用部署在同一容器中；

9.一种电子设备，其特征在于，包括存储器和处理器；其中，所述存储器用于存储一条或多条计算机指令，其中，所述一条或多条计算机指令被所述处理器执行以实现以下步骤：

将多个应用部署在同一容器中；

10.根据权利要求9所述的电子设备，其特征在于，所述一条或多条计算机指令还被所述处理器执行以实现以下步骤：

11.根据权利要求10所述的电子设备，其特征在于，所述一条或多条计算机指令还被所述处理器执行以实现以下步骤：

12.根据权利要求9所述的电子设备，其特征在于，所述当针对一个应用的服务列表中的发布和调用的服务确定所述多个应用中存在另一应用提供相匹配的服务时，将一个应用调用所述另一应用所提供的匹配服务的调用关系绑定，包括：

13.根据权利要求9所述的电子设备，其特征在于，所述将多个应用部署在同一容器中，包括：

14.根据权利要求9所述的电子设备，其特征在于，所述将多个应用部署在同一容器中，包括：

15.根据权利要求9所述的电子设备，其特征在于，部署在所述同一容器多个应用包括至少一个门面应用和至少一个非门面应用，其中，仅允许所述至少一个门面应用向所述容器以外的应用发布服务，并且所述至少一个非门面应用发布的服务仅允许所述容器内的应用调用。

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