CN114398043A - 应用部署方法和装置、电子设备及存储介质 - Google Patents

Abstract

本发明实施例提供了一种应用部署方法和装置、电子设备及存储介质。所述应用部署方法包括：基于应用程序的多个微服务，配置多个容器对象，每个容器对象至少配置有对应的微服务的主方法；启动所述多个容器对象的容器；通过所述多个微服务各自的主方法，加载所述多个微服务。在本发明实施例的方案中，多个容器对象基于多个微服务配置，使得能够以容器对象的方式管理微服务，提高了微服务管理的灵活性，无需对微服务重新配置。另外，容器对象中配置了对应的微服务的主方法，从而能够通过启动加载容器对象的方式加载主方法，进而加载微服务，减小了微服务的部署难度，提高了微服务的部署效率。

Description

应用部署方法和装置、电子设备及存储介质

技术领域

本发明实施例涉及计算机技术领域，尤其涉及一种应用部署方法和装置、电子设备及存储介质。

背景技术

微服务是一种在服务端将单体应用拆分为多个微服务的方式,能够针对每个微服务进行独立技术选型、独立开发、独立部署、独立运维，同时多个微服务能够相互协调、相互配合、最终实现应用程序的功能。

基于微服务的特性，将单体应用拆分成多个可独立部署的微服务，实现了核心逻辑和扩展服务之间解耦合，例如，在一个微服务的服务逻辑或功能的更新时，无需影响到其他微服务的代码和实现逻辑。

但是，在一些场景中，用户仅需要多个微服务中的部分微服务而不需要其他微服务，使得对全部的多个微服务进行部署造成了服务资源的浪费。此外，由于多个微服务的部署是有机的整体，简单地将其分拆为部分微服务会导致了系统级的风险，对部分微服务重新进行部署的工作量又过大，因此，需要一种高效的应用部署方法，能够兼顾服务资源和部署效率。

发明内容

有鉴于此，本发明实施例提供一种微服务开发框架、应用启动与开发方法、电子设备及存储介质，以至少部分解决上述问题。

根据本发明实施例的第一方面，提供了一种应用部署方法，包括：基于应用程序的多个微服务，配置多个容器对象，每个容器对象至少配置有对应的微服务的主方法；启动所述多个容器对象的容器；通过所述多个微服务各自的主方法，加载所述多个微服务。

在本发明的另一些实施例中，所述基于应用程序的多个微服务，配置多个容器对象，包括：将应用程序的多个微服务封装为多个插件，每个插件至少配置有对应的微服务的主方法；基于所述多个插件，配置多个容器对象。

在本发明的另一些实施例中，所述容器的配置程序包括与所述多个容器对象关联的调用节点，所述启动所述多个容器对象的容器，加载所述多个插件，包括：启动所述容器的配置程序，并且在到达所述调用节点时，开始加载所述多个插件；在完成所述多个插件的加载时，继续加载所述配置程序，从而提高了多个容器对象的部署效率。

在本发明的另一些实施例中，所述调用节点包括所述多个容器对象各自的注释。所述在到达所述调用节点时，开始加载所述多个插件，包括：在到达所述调用节点时，通过各个注释对应的调用关系，加载所述多个插件，从而进一步提高了容器对象的部署效率。

在本发明的另一些实施例中，所述多个插件包括第一插件和第二插件，所述微服务开发框架允许所述第一插件和所述第二插件访问所述容器的资源数据，并且禁止所述第二插件访问所述第一插件在不可访问状态下的资源数据，从而实现了多个微服务之间的解耦。

在本发明的另一些实施例中，所述第一插件配置成处于可访问状态，所述微服务开发框架允许所述第二插件访问处于所述第一插件的资源数据，从而提高了插件间的数据调用的灵活性。

在本发明的另一些实施例中，所述可访问状态通过所述第一插件中标记可访问注释来指示，从而提高了微服务的开发和部署效率。

在本发明的另一些实施例中，所述容器的资源数据包括所述多个微服务的共用类信息、共用对象信息、共用调用逻辑中的至少一者，并且每个插件的资源数据包括相应的微服务的类信息和对象信息，从而在减少多个微服务耦合性的同时提高了多个微服务的开发和部署效率。

根据本发明实施例的第二方面，提供了一种应用部署装置，包括：配置模块，基于应用程序的多个微服务，配置多个容器对象，每个容器对象至少配置有对应的微服务的主方法；第一加载模块，启动所述多个容器对象的容器；第二加载模块，通过所述多个微服务各自的主方法，加载所述多个微服务。

根据本发明实施例的第三方面，提供了一种电子设备，包括：处理器、存储器、通信接口和通信总线，所述处理器、所述存储器和所述通信接口通过所述通信总线完成相互间的通信；所述存储器用于存放至少一可执行指令，所述可执行指令使所述处理器执行如第一方面所述的方法对应的操作。

根据本发明实施例的第四方面，提供了一种计算机存储介质，其上存储有计算机程序，该程序被处理器执行时实现如第一方面所述的方法。

在本发明实施例的方案中，多个容器对象基于多个微服务配置，使得能够以容器对象的方式管理微服务，提高了微服务管理的灵活性，无需对微服务重新配置。另外，容器对象中配置了对应的微服务的主方法，从而能够通过启动加载容器对象的方式加载主方法，进而加载微服务，减小了微服务的部署难度，提高了微服务的部署效率。

附图说明

为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明实施例中记载的一些实施例，对于本领域普通技术人员来讲，还可以根据这些附图获得其他的附图。

图1为一个示例的应用部署方法的步骤流程图。

图2为根据本发明的一个实施例的应用部署方法的步骤流程图。

图3A为根据本发明的另一实施例的应用部署方法的示意性框图。

图3B为根据本发明的另一实施例的应用部署方法的插件化配置。

图4为根据本发明的另一实施例的应用部署方法的示意图。

图5为根据本发明的另一实施例的应用部署装置的结构框图。

图6为根据本发明的另一实施例的电子设备的结构示意图。

具体实施方式

为了使本领域的人员更好地理解本发明实施例中的技术方案，下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅是本发明实施例一部分实施例，而不是全部的实施例。基于本发明实施例中的实施例，本领域普通技术人员所获得的所有其他实施例，都应当属于本发明实施例保护的范围。

下面结合本发明实施例附图进一步说明本发明实施例具体实现。

将应用程序的服务分拆为多个微服务进行方式保证了大量的C端(custom)用户的访问需求，也节省了应用程序的后台维护成本。

例如，可以利用SpringBoot执行微服务的部署，提高了微服务的部署效率。SpringBoot能够加速搭建和开发过程，由于在面对较大并发数据访问时，微服务架构提高了开发和维护各种应用功能的效率。例如，可以将多个微服务分别部署到多个服务器中，以便对多个微服务的代码进行单独的开发、维护或改进。多个服务器可以具有独立的软件资源(例如，操作系统等)和硬件资源(例如，处理器、内存等)。可以在各个服务器中对相应的微服务配置与其他微服务程序进行通信的若干接口，并且基于服务器的通信接口之间的各个微服务之间的通信交互和资源共享。图1示出了一个示例的微服务的部署方法。在步骤S102中，初始SpringBoot，并且配置微服务的主方法和容器对象，容器对象中包括微服务的主方法所调用的类和方法。在步骤S104中，在SpringBoot中，加载微服务的主方法。在步骤S106中，SpringBoot利用自身的诸如注释等便捷调用机制，调用容器对象，完成微服务的整个程序的加载。

但是对于B端用户而言，对特定的应用程序的需求不尽相同。对于开发过程而言，满足不同客户需求的微服务也会交织在一起，随着B端客户的需求不断增多，使得应用的微服务的代码维护变得异常低效。具体而言，在应用程序的并发访问量较高的情况下，服务端会有若干微服务实现特定的应用功能，但是在应用程序的并发访问量不高的情况下，多个微服务的部署方式增加了部署成本和维护成本，浪费了配置资源。

图2为根据本发明的一个实施例的应用部署方法的步骤流程图。图2的应用部署方法可以采用微服务开发框架实现，微服务开发框架包括但不限于SpringBoot。微服务开发框架配置有容器，容器中的容器对象可以提供微服务所调用的资源，容器与应用程序的多个微服务关联。本发明实施例的方案可以适用于任意适当的具有数据处理能力的设备，包括但不限于：诸如公有云、私有云和混合云的服务端、或者任何具有微服务开发或运行能够力的设备。

本实施例的应用部署方法包括：

S2100：基于应用程序的多个微服务，配置多个容器对象，每个容器对象至少配置有对应的微服务的主方法。

应理解，插件可以是某种格式的文件包，例如，JAR格式的文件包。微服务开发框架能够对文件包进行拆包，获取里面的数据。另外，容器的容器对象可以配置成上述格式的文件包。微服务开发框架这样的文件包实现了程序开发的模块化和模块之间的解耦。另外，微服务开发框架配置有基于文件包的调用机制，文件包中的数据可以通过注释的方式实现访问或调用。调用机制采用多个层级的基本调用模板实现，并且对外向用户暴露注释接口，注释可以通过特定的符号以及资源名称实现，资源名称包括方法名、变量名、类名称等。

例如，可以启动诸如SpringBoot的微服务开发框架，在微服务开发框架中创建容器。在微服务开发框架进行微服务开发时，该容器可以存放诸如微服务的多个功能模块的共用资源。在本示例中，在进行应用程序开发时，该容器可以存放诸如多个微服务的共用资源。

还应理解，本实施例的应用部署方法还可以将应用程序拆分为多个微服务。例如，基于应用程序中的服务场景或模块，将应用程序拆分为多个微服务。

S2200：启动多个容器对象的容器。

应理解，通过插件的方式将微服务的主方法作为多个容器对象注册到容器中，容器反过来引导主方法的加载，进一步开启了每个微服务的加载。

例如，在配置容器对象之前，首先配置容器或者创建一个新的容器。然后，将多个微服务的程序配置为相应的插件，并且将多个微服务与容器关联。配置了容器后，可以启动该容器的加载过程。

S2300：通过多个微服务各自的主方法，加载多个微服务。

应理解，在开始微服务的主方法的加载之后，会再次调用微服务所需的资源，这些资源可以作为容器对象配置在上述的容器中，也可以配置在其他容器中。

还应理解，可以在加载容器的过程中，多个插件关联到容器的配置程序中。在一个示例中，可以对每个微服务的主方法初始化，初始化完成后即可继续容器的加载，主方法初始化完成的微服务可以在容器加载完成之后继续主方法的加载，直到多个微服务部署完成。在另一示例中，可以在微服务的主方法运行完成之后，继续容器的加载，直到多个微服务部署完成。

例如，容器与应用程序的多个微服务之间的关联关系可以为基于诸如相同关键词的标识。例如，可以将容器加载时的目标运行节点中添加与多个微服务的程序相同的函数名称字段。可以基于关联关系实现加载流程的跳转，并且中止当前的容器的加载，并且在多个微服务加载完成之后，继续容器的加载。

在本发明实施例的方案中，多个容器对象基于多个微服务配置，使得能够以容器对象的方式管理微服务，提高了微服务管理的灵活性，无需对微服务重新配置。另外，容器对象中配置了对应的微服务的主方法，从而能够通过启动加载容器对象的方式加载主方法，进而加载微服务，减小了微服务的部署难度，提高了微服务的部署效率。

在本发明的另一些实现方式中，基于应用程序的多个微服务，配置多个容器对象，包括：将应用程序的多个微服务封装为多个插件，每个插件至少配置有对应的微服务的主方法；基于多个插件，配置多个容器对象。

另外，多个微服务可以为应用程序中所有微服务集合的子集，多个微服务可以为任意的，因此，本发明实施例提高了微服务部署的灵活性和个性化。

换言之，通过单个微服务开发框架实现了多个插件在同一硬件资源和软件资源中的部署，在启动应用时，多个微服务对应的个插件与容器中的资源数据能够加载到同一软件资源中的内存中，实现了各个插件之间的紧耦合，节省了通信资源和存储资源。

此外，通过微服务开发框架执行多个插件的加载，无需将部分客户定制化需求委托给三方独立开发商进行开发，也无需开发开发源码，保证了数据安全。

此外，微服务开发框架为SpringBoot框架，由此，SpringBoot框架为一种高效的微服务开发框架，利用该开发框架实现了与现有框架的兼容。在利用SpringBoot进行启动时，使用SpringBoot加载SpringBoot插件的方式兼容了现有的框架，对后台开发者或维护者而言，无需学习新的框架，没有改变开发习惯。

此外，当应用程序的工程为SpringBoot工程时，在数据包管理上依然可以使用Spring框架中的Maven、Gradle进行依赖管理，进一步提高了对框架的兼容性。

此外，在SpringBoot插件中可以利用诸如@Shareable的注解来导出Spring框架中的Bean服务给其它插件调用，共用的类或者资源可以放在SpringBoot容器中进行加载，诸如后台开发者或维护者的使用者不需要关心底层的JAVA类加载器(ClassLoader)的细节，实现了用户无感知。

此外，由于各个SpringBoot插件可以合并在一起部署，解决了微服务方式的网络交互和大量微服务管理问题，实现了各个微服务之间的紧耦合。例如，在排查访问故障时只需要关注一个应用即可，无需基于不同服务器之间的通信链路实现数据调用。

在本发明的另一些实现方式中，所述容器的配置程序包括与所述多个容器对象关联的调用节点。所述启动所述多个容器对象的容器，加载所述多个插件，包括：启动所述容器的配置程序，并且在到达所述调用节点时，开始加载所述多个插件；在完成所述多个插件的加载时，继续加载所述配置程序。

具体地，在加载每个微服务时，首先加载微服务的主方法，主方法可以调用作为容器的共用资源的类和方法，也可以调用没有作为共用资源的容器对象，即，作为私有类或私有对象的第三容器对象。当每个微服务的主方法初始化完成后，即可以完成个性化应用的部署。应理解，在启动容器时，可以先初始化各个微服务的主方法，然后继续容器的加载逻辑，继续容器的加载逻辑无需等到各个微服务加载完成。另外，也可以将容器配置成各个微服务的主方法加载完成之后再继续容器的加载逻辑，在这种情况下，完成容器的加载，即完成了多个微服务的部署。

在本发明的另一些实现方式中，所述调用节点包括所述多个容器对象各自的注释，所述在到达所述调用节点时，开始加载所述多个插件，包括：在到达所述调用节点时，通过各个注释对应的调用关系，加载所述多个插件。

在本发明的另一些实现方式中，所述多个插件包括第一插件和第二插件，所述微服务开发框架允许所述第一插件和所述第二插件访问所述容器的资源数据，并且禁止所述第二插件访问所述第一插件在不可访问状态下的资源数据。

可替代地，所述第一插件配置成处于可访问状态，所述微服务开发框架允许所述第二插件访问处于所述第一插件的资源数据。具体地，所述可访问状态通过所述第一插件中标记可访问注释来指示。更具体地，SpringBoot容器中的诸如类信息等资源、以及Spring上下文是可以被各个SpringBoot插件共享。在每个SpringBoot插件之间，类信息等资源以及Spring上下文是相互隔离。如果多个SpringBoot插件需要共用一些类和资源，可以将这些类和资源放在SpringBoot容器中，如果某一SpringBoot插件需要提供将Spring框架中的SpringBean暴露给其它SpringBoot插件调用，则可以在Bean上添加诸如@Shareable的注解。

图3A为根据本发明的另一实施例的应用部署方法的示意性框图。如图3A所示，

在步骤S210中，微服务开发框架启动容器，并且执行步骤S220。具体而言，作为容器的容器可以按照SpringBoot的启动微服务的方式进行启动。

在步骤S220中，微服务开发框架加载容器的相关逻辑，并且执行步骤S230。具体而言，SpringBoot容器启动的Spring流程的目标运行节点(中间某个环节)进行SpringBoot插件加载。

进一步地，步骤S230中三个子步骤：在步骤231中，插件启动；在步骤232中，插件加载逻辑；在步骤233中，插件启动完成，并且执行步骤S240。换言之，SpringBoot插件加载过程可以按照独立的SpringBoot微服务的运行方式加载。

在步骤S240中，在插件启动完成后，微服务开发框架继续加载容器的逻辑，并且执行步骤250中。当所有SpringBoot插件加载完成后，可以进行SpringBoot容器的基于目标运行节点的未完成的加载逻辑处理。

在步骤S250中，微服务开发框架完成容器的启动。应理解，当容器加载完成后，整个应用程序的启动完成。

图3B为根据本发明的另一实施例的应用部署方法的插件化配置。微服务开发框架可以将应用程序的各个功能配置成包括核心底座200和定制插件2000两个主要部分。

其中，核心底座200包括容器201和共用插件202和203。定制插件2000包括定制插件2001、2002和2003。

例如，通用的核心底座200可以是应用程序的核心和通用逻辑模块。例如，容器201中包括的共用类信息、和/或共用插件202和203。容器201以及共用插件202和203可以对外提供对应的服务，并可以定义由各个定制插件2001、2002或2003调用的抽象接口。

此外，定制插件2001、2002或2003可以是根据应用的服务特性进行定制的逻辑模块，其可以使用核心通用底座200提供的各种服务，也可以通过提供服务来扩展核心底座200的功能。一般而言，核心底座200中的共用插件202和203在部署的时候是必选的，而定制插件2001、2002和2003是可选的，选择不同的服务定制插件对应提供的服务功能将会不同。例如，定制插件2001可以与共用插件202进行组合实现应用中的日期消息提醒功能。定制插件2003中的在线购物功能可以与共用插件204中的通讯录功能进行组合实现购物分享功能。

在另一些实现方式中，第一插件中标记的可访问注释指示可访问状态。由此，通过可访问注释，提高了可访问状态配置的便捷性，无需更改微服务的代码的调用逻辑。

在另一些实现方式中，容器的资源数据包括多个微服务的共用类信息、共用对象信息、共用调用逻辑中的至少一者。例如，容器的资源数据包括容器的共用资源、以及共用插件，容器的共用资源包括但不限于与账户信息、应用界面设置等相关的类和方法。共用插件包括但不限于：通讯录插件、日历服务插件等。另外，每个插件的资源数据包括该微服务的类信息和对象信息，例如，服务定制插件包括但不限于：消息服务插件、工作协同插件、用户信息插件、支付服务插件、在线购物插件等。

图4为根据本发明的另一实施例的应用部署方法的示意图。

S410：SpringBoot启动容器时，加载多个容器对象。具体地，多个容器对象包括服务定制插件各自的第一容器对象，还配置有至少一个共用插件的至少一个第二容器对象以及每个插件所调用的第三容器对象。

S420：SpringBoot启动每个微服务各自的主方法。应理解，多个微服务对应于多个服务定制插件。

S430：SpringBoot通过容器的第三容器对象，加载微服务。

应理解，上述的第一容器对象、第二容器对象和第三容器对象可以配置在同一容器中，也可以配置在不同容器中。

更具体地，在传统的微服务部署方案中，账户信息功能、应用界面设置功能、通讯录功能、日历服务功能、消息服务功能、工作协同功能、支付服务功能、在线购物功能等每个功能都作为一个微服务部署。

然而，在一种定制化微服务的示例中，对于支付服务功能、在线购物功能等电子商务功能不是必要的，而消息服务功能、工作协同功能是必要的。在本发明实施例的方案中，可以将相应的消息微服务和工作协同微服务统一部署，而不用重新配置上述功能的程序，例如，可以采用消息微服务的代码和工作协同微服务的代码分别封装成插件，作为微服务开发框架的容器中的各个容器对象，即，上述的第一容器对象。

另外，还可以将账户信息功能、应用界面设置功能实现为容器的共用资源，或者共用插件。共用插件可以作为上述的第二容器对象。共用资源与共用插件的区别在于：共用资源可以是诸如类、方法等能够被调用的资源，其生存周期较长，可以被共用插件中的方法或微服务插件的方法调用；共用插件是指可以与微服务插件进行组合构成某种功能。通常，一共用插件中的方法只能被与其组合的其他微服务插件调用，不能被与其没有组合关系的微服务插件或其他共用插件调用。例如，日历功能与消息服务功能可以组合在一起实现日期提醒功能，消息服务功能中可以配置有日期提醒的方法。当然，日历功能还可以与其他微服务进行组合。

应理解，不同的微服务插件也可以进行组合，并且组合中的不同微服务插件的方法可以互相调用，参与到这样的组合的微服务插件的数据较少，可以通过上述的注释等方式实现了不同微服务插件中的数据访问或数据共享。与共用插件能够进行组合的微服务插件数量较多，种类也较多，将共用插件部署为容器的共用资源，使得与其组合的微服务插件无需通过诸如注释的调用格式访问共用插件，无需对传统微服务的配置程序作较大变动，极大地提高了部署效率。

另外，诸如消息服务、工作协同等功能之间可能存在需要调用的类或方法，但是它们之间又不需要组合在一起形成某种功能，这种情况下，仍然可以采用微服务开发框架中的注释，在不同微服务插件中进行访问。例如，在消息服务中，希望为用户提供在即时消息窗口中提供在线文件编辑和预览功能，则只需要消息服务中调用工作协同中的文档共享方法，因为，在工作协同功能可以具有自身的交互界面，用于在线会议等场景。而在消息服务场景与工作协同组合在一起，其实现方式与用户界面都不相同，将两个功能或两个插件组合在一起不会产生显著的部署效率。这时，是需要在工作协同的插件中提供消息服务可以调用的文档共享方法接口即可，应理解，由于微服务开发框架本身提供了注释的调用机制，极大地方便了这种接口调用效率，使得在对已经完成配置的微服务程序改动很小的情况下，进一步提高了多个微服务的个性化部署效率。

进一步地，在加载每个微服务时，首先加载微服务的主方法，主方法可以调用作为容器的共用资源的类和方法，也可以调用没有作为共用资源的容器对象，即，作为私有类或私有对象的第三容器对象。当每个微服务的主方法初始化完成后，即可以完成个性化应用的部署。应理解，在启动容器时，可以先初始化各个微服务的主方法，然后继续容器的加载逻辑，继续容器的加载逻辑无需等到各个微服务加载完成。另外，也可以将容器配置成各个微服务的主方法加载完成之后再继续容器的加载逻辑，在这种情况下，完成容器的加载，即完成了多个微服务的部署。

图5为根据本发明的另一实施例的微服务开发框架的结构框图。微服务开发框架配置有存储应用程序的单个微服务的共用资源的容器，容器与应用程序的多个微服务关联。本发明实施例的方案可以适用于任意适当的具有数据处理能力的设备，包括但不限于：诸如公有云、私有云和混合云的服务端、或者任何具有微服务开发或运行能够力的设备。

图5的微服务开发框架包括：

配置模块510，基于应用程序的多个微服务，配置多个容器对象，每个容器对象至少配置有对应的微服务的主方法。

第一加载模块520，启动所述多个容器对象的容器。

第二加载模块530，通过所述多个微服务各自的主方法，加载所述多个微服务。

在本发明实施例的方案中，多个容器对象基于多个微服务配置，使得能够以容器对象的方式管理微服务，提高了微服务管理的灵活性，无需对微服务重新配置。另外，容器对象中配置了对应的微服务的主方法，从而能够通过启动加载容器对象的方式加载主方法，进而加载微服务，减小了微服务的部署难度，提高了微服务的部署效率。

另外，多个微服务可以为应用程序中所有微服务集合的子集，多个微服务可以为任意的，因此，本发明实施例提高了微服务部署的灵活性和个性化。

在本发明的另一些实施例中，配置模块具体用于：将应用程序的多个微服务封装为多个插件，每个插件至少配置有对应的微服务的主方法，并且基于所述多个插件，配置多个容器对象。

在本发明的另一些实施例中，所述容器的配置程序包括与所述多个容器对象关联的调用节点，第一加载模块具体用于：启动所述容器的配置程序，并且在到达所述调用节点时，开始加载所述多个插件；在完成所述多个插件的加载时，继续加载所述配置程序，从而提高了多个容器对象的部署效率。

在本发明的另一些实施例中，所述调用节点包括所述多个容器对象各自的注释。第一加载模块具体用于：在到达所述调用节点时，通过各个注释对应的调用关系，加载所述多个插件，从而进一步提高了容器对象的部署效率。

在本发明的另一些实施例中，所述多个插件包括第一插件和第二插件，所述微服务开发框架允许所述第一插件和所述第二插件访问所述容器的资源数据，并且禁止所述第二插件访问所述第一插件在不可访问状态下的资源数据，从而实现了多个微服务之间的解耦。

在本发明的另一些实施例中，所述第一插件配置成处于可访问状态，所述微服务开发框架允许所述第二插件访问处于所述第一插件的资源数据，从而提高了插件间的数据调用的灵活性。

在本发明的另一些实施例中，所述可访问状态通过所述第一插件中标记可访问注释来指示，从而提高了微服务的开发和部署效率。

在本发明的另一些实施例中，所述容器的资源数据包括所述多个微服务的共用类信息、共用对象信息、共用调用逻辑中的至少一者，并且每个插件的资源数据包括相应的微服务的类信息和对象信息，从而在减少多个微服务耦合性的同时提高了多个微服务的开发和部署效率。

本实施例的装置用于实现前述多个方法实施例中相应的方法，并具有相应的方法实施例的有益效果，在此不再赘述。此外，本实施例的装置中的各个模块的功能实现均可参照前述方法实施例中的相应部分的描述，在此亦不再赘述。

参照图6，示出了根据本发明的另一实施例的电子设备的结构示意图，本发明具体实施例并不对电子设备的具体实现做限定。

如图6所示，该电子设备可以包括：处理器(processor)602、通信接口(Communications Interface)604、存储器(memory)606、以及通信总线608。

其中：

处理器602、通信接口604、以及存储器606通过通信总线608完成相互间的通信。

通信接口604，用于与其它电子设备或服务器进行通信。

处理器602，用于执行程序610，具体可以执行上述方法实施例中的相关步骤。

具体地，程序610可以包括程序代码，该程序代码包括计算机操作指令。

处理器602可能是处理器CPU，或者是特定集成电路ASIC(Application SpecificIntegrated Circuit)，或者是被配置成实施本发明实施例的一个或多个集成电路。智能设备包括的一个或多个处理器，可以是同一类型的处理器，如一个或多个CPU；也可以是不同类型的处理器，如一个或多个CPU以及一个或多个ASIC。

存储器606，用于存放程序610。存储器606可能包含高速RAM存储器，也可能还包括非易失性存储器(non-volatile memory)，例如至少一个磁盘存储器。

程序610具体可以用于使得处理器502执行以下操作：基于应用程序的多个微服务，配置多个容器对象，每个容器对象至少配置有对应的微服务的主方法；启动所述多个容器对象的容器；通过所述多个微服务各自的主方法，加载所述多个微服务。

此外，程序610中各步骤的具体实现可以参见上述方法实施例中的相应步骤和单元中对应的描述，在此不赘述。所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的设备和模块的具体工作过程，可以参考前述方法实施例中的对应过程描述，在此不再赘述。

需要指出，根据实施的需要，可将本发明实施例中描述的各个部件/步骤拆分为更多部件/步骤，也可将两个或多个部件/步骤或者部件/步骤的部分操作组合成新的部件/步骤，以实现本发明实施例的目的。

上述根据本发明实施例的方法可在硬件、固件中实现，或者被实现为可存储在记录介质(诸如CD ROM、RAM、软盘、硬盘或磁光盘)中的软件或计算机代码，或者被实现通过网络下载的原始存储在远程记录介质或非暂时机器可读介质中并将被存储在本地记录介质中的计算机代码，从而在此描述的方法可被存储在使用通用计算机、专用处理器或者可编程或专用硬件(诸如ASIC或FPGA)的记录介质上的这样的软件处理。可以理解，计算机、处理器、微处理器控制器或可编程硬件包括可存储或接收软件或计算机代码的存储组件(例如，RAM、ROM、闪存等)，当所述软件或计算机代码被计算机、处理器或硬件访问且执行时，实现在此描述的方法。此外，当通用计算机访问用于实现在此示出的方法的代码时，代码的执行将通用计算机转换为用于执行在此示出的方法的专用计算机。

本领域普通技术人员可以意识到，结合本文中所公开的实施例描述的各示例的单元及方法步骤，能够以电子硬件、或者计算机软件和电子硬件的结合来实现。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本发明实施例的范围。

以上实施方式仅用于说明本发明实施例，而并非对本发明实施例的限制，有关技术领域的普通技术人员，在不脱离本发明实施例的精神和范围的情况下，还可以做出各种变化和变型，因此所有等同的技术方案也属于本发明实施例的范畴，本发明实施例的专利保护范围应由权利要求限定。

Claims (11)

1.一种应用部署方法，包括：

基于应用程序的多个微服务，配置多个容器对象，每个容器对象至少配置有对应的微服务的主方法；

启动所述多个容器对象的容器；

通过所述多个微服务各自的主方法，加载所述多个微服务。

2.根据权利要求1所述的方法，其中，所述基于应用程序的多个微服务，配置多个容器对象，包括：

将应用程序的多个微服务封装为多个插件，每个插件至少配置有对应的微服务的主方法；

基于所述多个插件，配置多个容器对象。

3.根据权利要求2所述的方法，其中，所述容器的配置程序包括与所述多个容器对象关联的调用节点，

所述启动所述多个容器对象的容器，包括：

启动所述容器的配置程序，并且在到达所述调用节点时，开始加载所述多个插件；

在完成所述多个插件的加载时，继续加载所述配置程序。

4.根据权利要求3所述的方法，其中，所述调用节点包括所述多个容器对象各自的注释，

所述在到达所述调用节点时，开始加载所述多个插件，包括：

在到达所述调用节点时，通过各个注释对应的调用关系，加载所述多个插件。

5.根据权利要求2所述的方法，其中，所述多个插件包括第一插件和第二插件，所述微服务开发框架允许所述第一插件和所述第二插件访问所述容器的资源数据，并且禁止所述第二插件访问所述第一插件在不可访问状态下的资源数据。

6.根据权利要求5所述的方法，其中，所述第一插件配置成处于可访问状态，所述微服务开发框架允许所述第二插件访问处于所述第一插件的资源数据。

7.根据权利要求6所述的方法，其中，所述可访问状态通过所述第一插件中标记可访问注释来指示。

8.根据权利要求5所述的方法，其中，所述容器的资源数据包括所述多个微服务的共用类信息、共用对象信息、共用调用逻辑中的至少一者，并且每个插件的资源数据包括相应的微服务的类信息和对象信息。

9.一种应用部署装置，包括：

配置模块，基于应用程序的多个微服务，配置多个容器对象，每个容器对象至少配置有对应的微服务的主方法；

第一加载模块，启动所述多个容器对象的容器；

第二加载模块，通过所述多个微服务各自的主方法，加载所述多个微服务。

10.一种电子设备，包括：处理器、存储器、通信接口和通信总线，所述处理器、所述存储器和所述通信接口通过所述通信总线完成相互间的通信；

所述存储器用于存放至少一可执行指令，所述可执行指令使所述处理器执行如权利要求1-8中任一项所述的方法对应的操作。

11.一种计算机存储介质，其上存储有计算机程序，该程序被处理器执行时实现如权利要求1-8中任一所述的方法。

Images