一种根据服务角色的进行应用部署的方法及装置与流程

本申请实施例涉及应用部署技术领域，尤其涉及一种根据服务角色的进行应用部署的方法及装置。

背景技术：

目前，软件应用主要分微服务架构和单服务应用。微服务架构适用于大型的应用，应用中的各个模块单独一个服务，可以提供强大的处理能力。单服务应用适用于访问量不高的应用，物理机资源有限的场景，应用中的所有模块都在同一个服务实例。

如果是微服务架构的应用，如果因为资源有限的情况下，需要在一台服务器上部署整个服务，则会导致资源占用高，也失去了微服务的意义。单服务应用则无法处理大型分分布式场景。两者都无法做到灵活配置、灵活适配各种场景。如果要切换两种部署模式，需要对程序进行重新编译打包，非常不灵活。因此，设计一种能够根据服务器数量进行应用快速部署的方式成为本领域技术人员亟待解决的技术问题。

技术实现要素：

本申请实施例提供一种根据服务角色的进行应用部署的方法及装置，对于应用程序，只需要一次编译交付应用之后，可以适应所有的部署环境和场景，无论部署环境和部署场景如何变化，均无需再次调整代码，需要重新进行交付。

在第一方面，本申请实施例提供了一种根据服务角色的进行应用部署的方法，包括：

将程序组件封装成相应的功能模块；

通过角色管理模块进行角色定义并为所述功能模块与所述角色配置对应的依赖关系；

接收用户选择的应用服务需求并根据所述应用服务需求匹配相应的目标角色；

根据所述目标角色以及所述依赖关系调用加载对应的功能模块通过运行相应的程序代码以进行服务部署。

进一步的，所述接收用户选择的应用服务需求并根据所述应用服务需求匹配相应的目标角色，还包括：

根据所述应用服务需求设置相应的目标角色和角色分布。

进一步的，所述应用服务需求包括业务需求、服务器数量、集群容错要求和环境并发量中的一种或多种。

进一步的，在所述将程序组件封装成相应的功能模块之后，还包括：

提供可供开发人员编辑的配置文件，其中所述配置文件为每个功能模块提供用于启用所述功能模块的选项，使得所述功能模块可根据软件项目实例的需要而被选择性地启用。

进一步的，所述角色包括计算控制器、存储控制器、网络控制器、计算节点、存储节点和网络节点。

进一步的，所述将程序组件封装成相应的功能模块，包括：

将针对所述程序组件的相应示例代码封装到相应的功能模块。

进一步的，所述应用服务需求包括服务器数量，所述接收用户选择的应用服务需求并根据所述应用服务需求匹配相应的目标角色，包括：

当用户选择的服务器数量为1个时，在相应服务器匹配应用服务所需的所有目标角色；或，

当用户选择的服务器数量为多个时，根据所述服务器数量将应用服务所需目标角色分散设置于相应服务器处。

在第二方面，本申请实施例提供了一种根据服务角色的进行应用部署的装置，包括：

封装模块：用于将程序组件封装成相应的功能模块；

依赖配置模块：用于通过角色管理模块进行角色定义并为所述功能模块与所述角色配置对应的依赖关系；

匹配模块：用于接收用户选择的应用服务需求并根据所述应用服务需求匹配相应的目标角色；

加载模块：用于根据所述目标角色以及所述依赖关系调用加载对应的功能模块通过运行相应的程序代码以进行服务部署。

在第三方面，本申请实施例提供了一种电子设备，包括：

存储器以及一个或多个处理器；

所述存储器，用于存储一个或多个程序；

当所述一个或多个程序被所述一个或多个处理器执行，使得所述一个或多个处理器实现如第一方面所述的根据服务角色的进行应用部署的方法。

在第四方面，本申请实施例提供了一种包含计算机可执行指令的存储介质，所述计算机可执行指令在由计算机处理器执行时用于执行如第一方面所述的根据服务角色的进行应用部署的方法。

本申请实施例通过将应用程序封装成相应的功能模块，并通过角色管理模块进行角色定义进而为相应的功能模块与对应的角色配置依赖关系；使得所有模块都在同一应用服务中，启动时直接根据启动参数选择需要启动的模块，而无需进行重新编译。本申请实施例的方案一个应用程序就可以使用于分布式微服务架构和小型程序单服务架构。并且可以在两种模式见灵活切换，无论部署环境部署场景如何变化，都无需再调整代码，无需重新交付。

附图说明

图1是本申请实施例提供的一种根据服务角色的进行应用部署的方法的流程图；

图2是本申请实施例提供的服务需求与角色匹配的流程示意图；

图3是本申请实施例提供的单服务器单服务的部署结构示意图；

图4是本申请实施例提供的多服务器分布式的部署结构示意图；

图5是本申请实施例提供的一种根据服务角色的进行应用部署的装置的结构示意图；

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

具体实施方式

为了使本申请的目的、技术方案和优点更加清楚，下面结合附图对本申请具体实施例作进一步的详细描述。可以理解的是，此处所描述的具体实施例仅仅用于解释本申请，而非对本申请的限定。另外还需要说明的是，为了便于描述，附图中仅示出了与本申请相关的部分而非全部内容。在更加详细地讨论示例性实施例之前应当提到的是，一些示例性实施例被描述成作为流程图描绘的处理或方法。虽然流程图将各项操作(或步骤)描述成顺序的处理，但是其中的许多操作可以被并行地、并发地或者同时实施。此外，各项操作的顺序可以被重新安排。当其操作完成时所述处理可以被终止，但是还可以具有未包括在附图中的附加步骤。所述处理可以对应于方法、函数、规程、子例程、子程序等等。

现有的如果因为资源有限的情况下，需要在一台服务器上部署整个服务，则会导致资源占用高，也失去了微服务的意义。单服务应用则无法处理大型分分布式场景。两者都无法做到灵活配置、灵活适配各种场景。如果要切换两种部署模式，需要对程序进行重新编译打包，非常不灵活。基于此，本申请实施例通过将应用程序封装成相应的功能模块，并通过角色管理模块进行角色定义进而为相应的功能模块与对应的角色配置依赖关系；使得所有模块都在同一应用服务中，启动时直接根据启动参数选择需要启动的模块，而无需进行重新编译。本申请实施例的方案一个应用程序就可以使用于分布式微服务架构和小型程序单服务架构。并且可以在两种模式见灵活切换，无论部署环境部署场景如何变化，都无需再调整代码，无需重新交付。

图1给出了本申请实施例提供的一种根据服务角色的进行应用部署的方法的流程图，本实施例中提供的根据服务角色的进行应用部署的方法可以由根据服务角色的进行应用部署的设备执行，该根据服务角色的进行应用部署的设备可以通过软件和/或硬件的方式实现，该根据服务角色的进行应用部署的设备可以是两个或多个物理实体构成，也可以是一个物理实体构成。一般而言，该根据服务角色的进行应用部署的设备可以是电脑，手机，平板或服务器等。

下述以服务器为执行根据服务角色的进行应用部署的方法的设备为例，进行描述。参照图1，该根据服务角色的进行应用部署的方法具体包括：

s101：将程序组件封装成相应的功能模块。

进行封装时，可以将单个的程序组件封装成相应的功能模块，也可以将多个程序组件封装成相应的功能模块，使得每个功能模块包括对应的程序组件、以及针对该程序组件的开发配置。具体开发人员可依据实际情况进行设置。

示例性的，所述将程序组件封装成相应的功能模块，包括：

将针对所述程序组件的相应示例代码封装到相应的功能模块。通过封装相应的示例性代码到相应的功能模块以供开发人员参考。

更为优选的，在所述将程序组件封装成相应的功能模块之后，还包括：

提供可供开发人员编辑的配置文件，其中所述配置文件为每个功能模块提供用于启用所述功能模块的选项，使得所述功能模块可根据软件项目实例的需要而被选择性地启用。

本实施例中提及的配置文件是可以将多个功能模块进行打包捆绑的配置内容，比如可以将认证模块、数据库模块配置到一起或者将数据分析模块与数据库模块配置到一起来实现进一步的模块配置。

s102：通过角色管理模块进行角色定义并为所述功能模块与所述角色配置对应的依赖关系。

在一般的应用中，主要是通过maven，gradle等工具进行模块的配置。但是编译的时候已经做好了依赖，无法做到在运行中动态切换选择。本发明第一步，需要通过程序开发一个角色模块管理的模块。在这个模块中重新定义角色、功能模块以及角色配置模块的依赖关系。通过重新进行角色定义便于进行功能模块的对应。

本申请实施例的方案中，应用是指整个应用程序。服务是指一个应用程序的实例。角色是指应用程序中模块的集合，这些模块共同提供这个角色的能力。一个服务可以配置多个角色。因此，在进行具体设计时，不单单可以通过控制端来进行角色命名，比如计算节点、存储节点、网络节点等，还可以通过业务端来进行角色命名，比如管理角色、服务角色、物流角色、展示角色等等。具体情况开发人员可以不同服务需求来进行适应性调整设置。

示例性的，例如针对于一个云平台系统，整个云平台系统就是一个应用；所述角色包括计算控制器、存储控制器、网络控制器、计算节点、存储节点和网络节点，所述为所述功能模块与所述角色配置对应的依赖关系，包括：

为所述功能模块与计算控制器、存储控制器、网络控制器、计算节点、存储节点和网络节点配置对应的依赖关系。

由于云平台系统主要是提供计算存储服务的，所以在进行角色定义时，主要将其抽象为计算节点和存储节点等角色。在上述示例中，关于角色的定义为：计算控制器负责虚拟机相关功能模块、存储控制器负责存储块设备相关功能模块、网络控制器负责网络设备相关功能模块、计算节点存放虚拟机、存储节点存放存储块设备、网络节点存放网络设备。通过对上述角色进行定义也使得便于对相应的功能模块进行区分。但是在实际实施时不单单有上述几种类型的角色，还可以由其他的角色构成，比如购物网站，也可以由多种不同的角色设置，比如用户管理角色、数据存储角色、物流管理角色等等。具体角色定义需要依据实际情况来进行设置。

本申请实施例提供的整个云平台系统就是一个应用，应用的程序包是cloud.jar。则运行一个cloud.jar就是一个服务。其中定义的角色就是其中的计算控制器、存储控制器、网络控制器、计算节点、存储节点、网络节点等。模块是指，计算控制器中用到了数据库模块，认证模块等。定义完角色，将对应的功能模块与相应的角色完成依赖配置即可。本实施例中提及的一个服务cloud.jar进程，这个服务可配置一个或多个角色。整个云平台又一个或多个服务构成提供能力。

本实施例中提及的依赖指的是：在包括多个模块或组件的项目中，各模块或组件之间可能存在大量依赖关系，即一个模块或组件的执行需要另外一个或多个模块或组件的支持，一个模块或组件所包括的依赖可以包括例如其执行所依赖的模块或组件的标识。进行依赖管理时主要采用maven进行依赖管理，maven可以避免去搜索所有所需库的需求。maven通过读取项目文件(pom.xml)，找出它们项目之间的依赖关系。我们需要做的只是在每个项目的pom中定义好直接的依赖关系。

采用maven进行依赖管理主要有如下几种方式：1、依赖调节，决定当多个手动创建的版本同时出现时，哪个依赖版本将会被使用。如果两个依赖版本在依赖树里的深度是一样的时候，第一个被声明的依赖将会被使用。2、依赖管理，直接的指定手动创建的某个版本被使用。例如当一个模块c在自己的依赖管理模块包含模块b，即b依赖于a，那么a即可指定在b被引用时所使用的版本。3、依赖范围，包含在构建过程每个阶段的依赖。依赖范围可以包括编译阶段。供应阶段、运行阶段、测试阶段、系统阶段和导入阶段。4、依赖排除、任何可传递的依赖都可以通过"exclusion"元素被排除在外。举例说明，a依赖b，b依赖c，因此a可以标记c为"被排除的"。5、依赖可选，任何可传递的依赖可以被标记为可选的，通过使用"optional"元素。例如：a依赖b，b依赖c。因此，b可以标记c为可选的，这样a就可以不再使用c。

s103：接收用户选择的应用服务需求并根据所述应用服务需求匹配相应的目标角色。

也即是用户在启动应用服务程序时选需要启动的目标角色。更为优选的，图2是本申请实施例提供的服务需求与角色匹配的流程示意图，如图2所示，所述接收用户选择的应用服务需求并根据所述应用服务需求匹配相应的目标角色，还包括：

s1031：接收用户选择的应用服务需求；

s1032根据所述应用服务需求设置相应的目标角色和角色分布。

启动时根据物理机实际环境、业务的具体需求选择不同的服务数量，不同的角色分布。不同的用户有不同的需求，通过应用服务需求可以设置相应的角色和角色分布；比如，当用户采用多台服务器，且需要对各个模块进行分布化处理时；则将不同的模块对应的角色设置于不同的服务器处来进行角色分布，并且也可以在两个不同的服务器处设置相同的控制角色来提高方案的容错性。

示例性的，所述应用服务需求包括业务需求、服务器数量、集群容错要求和环境并发量中的一种或多种。

应用程序在步骤s102会配置哪些角色是可以选择的，而在启动应用服务程序的时候，可以根据实际场景，例如服务器数量、集群容错要求、环境的并发量等来选择在哪些服务器启动多少个服务，每个服务启用哪些角色。

例如，启用一个云平台时候可以选择在服务器1启动一个服务器，角色是计算控制器、存储控制器、网络控制器。在服务器2启动一个服务，角色是计算节点。也可以在同一台服务器上，只启动一个服务包括所有的角色。这个只需要修改启动参数即可，无需修改代码，无需重新编译。启动参数指的也即是务需求、服务器数量、集群容错要求和环境并发量。

示例性的，所述应用服务需求包括服务器数量，所述接收用户选择的应用服务需求并根据所述应用服务需求匹配相应的目标角色，包括：

当用户选择的服务器数量为1个时，在相应服务器匹配相应的应用服务所需的所有目标角色；或，

当用户选择的服务器数量为多个时，根据所述服务器数量将应用服务所需目标角色分散设置于相应服务器处。

上述为当服务器数量不同时，进行具体的应用服务部署的结构示意图。图3是本申请实施例提供的单服务器单服务的部署结构示意图，如图3所示，其为单服务器单服务的部署结构示意图，其中，s1、s2和s3表示功能模块，三个功能模块配置在一起共同组成相应的角色，通过该角色提供相应的服务。由于采用的是单服务器，因此，是通过角色将所有功能模块加载至相应的服务器处。

图4是本申请实施例提供的多服务器分布式的部署结构示意图，如图4所示，其为多服务器分布式的部署结构示意图。其中，s1表示一角色，s2表示一角色，s3表示一角色，s1、s2和s3配置成一角色；由于采用是多个服务器，所以各个角色可以采用分布式设置的方式，并且通过不同的模块来提供不同的服务。由上可以知晓，根据不同的情况，最终得到的部署结构差异也较为明显。

s104：根据所述目标角色以及所述依赖关系调用加载对应的功能模块通过运行相应的程序代码以进行服务部署。

为了实现本申请实施例的方案，所有模块的代码都在同一个应用中。所以启动的时候需要根据步骤s102的配置，由应用的角色模块管理模块去决定加载哪些模块、代码以及相关配置。除了上述进行角色分配的方式之外，还可以根据各个功能模块进行应用打包的方式来进行操作。但是上述操作需要根据不同的场景多次编译成不同的应用程序包，例如在图4中就需要针对s1,s2,s3,s1+s2+s3四种配置的编译，输出四种应用程序。但是上述方案存在有一个缺陷，也即是模块越多，可能存在组合就复杂，而且一旦打包后，就不能改变。与本申请实施例中采用的对其进行角色进行依赖限定的方式并不相同。采用角色依赖的方式，可以使得所有的模块都在同一个应用中，启动的时候可以直接根据启动参数选择要启动的模块。而不需要重新编译。一个应用程序就可以使用于分布式微服务架构和小型程序单服务架构。并且可以在两种模式见灵活切换。

本申请实施例通过将应用程序封装成相应的功能模块，并通过角色管理模块进行角色定义进而为相应的功能模块与对应的角色配置依赖关系；使得所有模块都在同一应用服务中，启动时直接根据启动参数选择需要启动的模块，而无需进行重新编译。本申请实施例的方案一个应用程序就可以使用于分布式微服务架构和小型程序单服务架构。并且可以在两种模式见灵活切换，无论部署环境部署场景如何变化，都无需再调整代码，无需重新交付。

在上述实施例的基础上，图5为本申请实施例提供的一种根据服务角色的进行应用部署的装置的结构示意图。参考图5，本实施例提供的根据服务角色的进行应用部署的装置具体包括：

封装模块21：用于将程序组件封装成相应的功能模块；

依赖配置模块22：用于通过角色管理模块进行角色定义并为所述功能模块与所述角色配置对应的依赖关系；

匹配模块23：用于接收用户选择的应用服务需求并根据所述应用服务需求匹配相应的目标角色；

加载模块24：用于根据所述目标角色以及所述依赖关系调用加载对应的功能模块通过运行相应的程序代码以进行服务部署。

本申请实施例通过将应用程序封装成相应的功能模块，并通过角色管理模块进行角色定义进而为相应的功能模块与对应的角色配置依赖关系；使得所有模块都在同一应用服务中，启动时直接根据启动参数选择需要启动的模块，而无需进行重新编译。本申请实施例的方案一个应用程序就可以使用于分布式微服务架构和小型程序单服务架构。并且可以在两种模式见灵活切换，无论部署环境部署场景如何变化，都无需再调整代码，无需重新交付。

本申请实施例提供的根据服务角色的进行应用部署的装置可以用于执行上述实施例提供的根据服务角色的进行应用部署的方法，具备相应的功能和有益效果。

图6是本申请实施例提供的一种电子设备的结构示意图，参照图6，该电子设备包括：处理器31、存储器32、通信模块33、输入装置34及输出装置35。该电子设备中处理器31的数量可以是一个或者多个，该电子设备中的存储器32的数量可以是一个或者多个。该电子设备的处理器31、存储器32、通信模块33、输入装置34及输出装置35可以通过总线或者其他方式连接。

存储器32作为一种计算机可读存储介质，可用于存储软件程序、计算机可执行程序以及模块，如本申请任意实施例所述的根据服务角色的进行应用部署的方法对应的程序指令/模块(例如，根据服务角色的进行应用部署的装置中的封装模块21、依赖配置模块22、匹配模块23和加载模块24)。存储器32可主要包括存储程序区和存储数据区，其中，存储程序区可存储操作系统、至少一个功能所需的应用程序；存储数据区可存储根据设备的使用所创建的数据等。此外，存储器32可以包括高速随机存取存储器，还可以包括非易失性存储器，例如至少一个磁盘存储器件、闪存器件、或其他非易失性固态存储器件。在一些实例中，存储器可进一步包括相对于处理器远程设置的存储器，这些远程存储器可以通过网络连接至设备。上述网络的实例包括但不限于互联网、企业内部网、局域网、移动通信网及其组合。

通信模块33用于进行数据传输。

处理器31通过运行存储在存储器32中的软件程序、指令以及模块，从而执行设备的各种功能应用以及数据处理，即实现上述的根据服务角色的进行应用部署的方法。

输入装置34可用于接收输入的数字或字符信息，以及产生与设备的用户设置以及功能控制有关的键信号输入。输出装置35可包括显示屏等显示设备。

上述提供的电子设备可用于执行上述实施例提供的根据服务角色的进行应用部署的方法，具备相应的功能和有益效果。

本申请实施例还提供一种包含计算机可执行指令的存储介质，所述计算机可执行指令在由计算机处理器31执行时用于执行一种根据服务角色的进行应用部署的方法，该根据服务角色的进行应用部署的方法包括：

将程序组件封装成相应的功能模块；

通过角色管理模块进行角色定义并为所述功能模块与所述角色配置对应的依赖关系；

接收用户选择的应用服务需求并根据所述应用服务需求匹配相应的目标角色；

根据所述目标角色以及所述依赖关系调用加载对应的功能模块通过运行相应的程序代码以进行服务部署。

存储介质——任何的各种类型的存储器设备或存储设备。术语“存储介质”旨在包括：安装介质，例如cd-rom、软盘或磁带装置；计算机系统存储器或随机存取存储器，诸如dram、ddrram、sram、edoram，兰巴斯(rambus)ram等；非易失性存储器，诸如闪存、磁介质(例如硬盘或光存储)；寄存器或其它相似类型的存储器元件等。存储介质可以还包括其它类型的存储器或其组合。另外，存储介质可以位于程序在其中被执行的第一计算机系统中，或者可以位于不同的第二计算机系统中，第二计算机系统通过网络(诸如因特网)连接到第一计算机系统。第二计算机系统可以提供程序指令给第一计算机用于执行。术语“存储介质”可以包括驻留在不同位置中(例如在通过网络连接的不同计算机系统中)的两个或更多存储介质。存储介质可以存储可由一个或多个处理器31执行的程序指令(例如具体实现为计算机程序)。

当然，本申请实施例所提供的一种包含计算机可执行指令的存储介质，其计算机可执行指令不限于如上所述的根据服务角色的进行应用部署的方法，还可以执行本申请任意实施例所提供的根据服务角色的进行应用部署的方法中的相关操作。

上述实施例中提供的根据服务角色的进行应用部署的装置、存储介质及电子设备可执行本申请任意实施例所提供的根据服务角色的进行应用部署的方法，未在上述实施例中详尽描述的技术细节，可参见本申请任意实施例所提供的根据服务角色的进行应用部署的方法。

上述仅为本申请的较佳实施例及所运用的技术原理。本申请不限于这里所述的特定实施例，对本领域技术人员来说能够进行的各种明显变化、重新调整及替代均不会脱离本申请的保护范围。因此，虽然通过以上实施例对本申请进行了较为详细的说明，但是本申请不仅仅限于以上实施例，在不脱离本申请构思的情况下，还可以包括更多其他等效实施例，而本申请的范围由权利要求的范围决定。