CN113722107B - 云产品管控服务部署方法、装置、设备和存储介质 - Google Patents

Abstract

本申请提供一种云产品管控服务部署方法、装置、设备和存储介质，该方法包括：确定在私有云中的需要部署的目标云产品的管控服务；根据管控服务在公有云中的访问量信息和在私有云中的访问量信息，确定在私有云中部署管控服务所需的第一资源；若私有云中的可用资源不能满足第一资源，则根据管控服务所包含的多个功能组件的类别，对管控服务进行压缩处理，以确定在私有云中部署管控服务所需的第二资源；若私有云中的可用资源满足第二资源，则在私有云中部署经压缩处理后的管控服务。在将公有云中云产品的管控服务部署在用户私有云的过程中，通过对管控服务进行压缩处理以降低其占用的资源，同时保持管控服务在私有云中与公有云中提供功能的一致性。

Description

云产品管控服务部署方法、装置、设备和存储介质

技术领域

本发明涉及云计算技术领域，尤其涉及一种云产品管控服务部署方法、装置、设备和存储介质。

背景技术

随着云计算的不断发展，云服务提供商已经可以为广大用户提供多种不同的云服务产品，比如虚拟机、数据库等云产品。为保证不同云产品的正常运行，需要为不同云产品设计对应的管控服务，以用于在云端网络架构中实现对相应云产品的构建、配置、扩展等管理。

云端网络架构可以分为公有云和私有云（也可以称为专有云），现有很多云产品都是在公有云中开发出的。随着用户对自身产生数据的掌控力度需求的提高，越来越多的用户提出了部署私有云的需求。用户根据自身需求可以选择需要使用的云产品，那么为了保证所选择的云产品在用户的私有云环境中的正常运行，需要在用户的私有云中部署所选择云产品的管控服务。但对专有云用户来说，只有用户实际用到的云产品服务才有价值，用户希望其管控服务占用的资源尽可能的减少。

由于一般公有云和私有云采用的是同一套开发架构，用户也希望两者能提供一致的功能，这样就需要将很多公有云中云产品的管控服务输出到专有云进行部署。

发明内容

本发明实施例提供一种云产品管控服务部署方法、装置、设备和存储介质，用以实现公有云中云产品的管控服务在用户专有云中的低成本部署。

第一方面，本发明实施例提供一种云产品管控服务部署方法，所述方法包括：

确定在私有云中的需要部署的目标云产品的管控服务；

根据所述管控服务在公有云中的访问量信息和在所述私有云中的访问量信息，确定在所述私有云中部署所述管控服务所需的第一资源；

若所述私有云中的可用资源不能满足所述第一资源，则根据所述管控服务所包含的多个功能组件的类别，对所述管控服务进行压缩处理，以确定在所述私有云中部署所述管控服务所需的第二资源；

若所述私有云中的可用资源满足所述第二资源，则在所述私有云中部署经所述压缩处理后的管控服务。

第二方面，本发明实施例提供一种云产品管控服务部署装置，所述装置包括：

确定模块，用于确定在私有云中的需要部署的目标云产品的管控服务；

处理模块，用于根据所述管控服务在公有云中的访问量信息和在所述私有云中的访问量信息，确定在所述私有云中部署所述管控服务所需的第一资源；以及，若所述私有云中的可用资源不能满足所述第一资源，则根据所述管控服务所包含的多个功能模块的类别，对所述管控服务进行压缩处理，以确定在所述私有云中部署所述管控服务所需的第二资源；

部署模块，用于若所述私有云中的可用资源满足所述第二资源，则在所述私有云中部署经所述压缩处理后的管控服务。

第三方面，本发明实施例提供一种服务器，包括：存储器、处理器、通信接口；其中，所述存储器上存储有可执行代码，当所述可执行代码被所述处理器执行时，使所述处理器至少可以实现如第一方面所述的云产品管控服务部署方法。

第四方面，本发明实施例提供了一种非暂时性机器可读存储介质，所述非暂时性机器可读存储介质上存储有可执行代码，当所述可执行代码被服务器的处理器执行时，使所述处理器至少可以实现如第一方面所述的云产品管控服务部署方法。

在本发明实施例中，当需要将公有云中的某些云产品（称为目标云产品）在用户的私有云中进行部署时，除了这些目标云产品本身提供的相关服务功能外，还需要在用户的私有云中部署目标云产品的管控服务以保证目标云产品在用户私有云中的正常使用。为进行目标云产品的管控服务在用户私有云中的部署，首先，需要根据目标云产品的管控服务在公有云中的访问量信息和在私有云中的访问量信息，确定在该私有云中部署其管控服务所需的第一资源。若私有云中的可用资源不能满足第一资源，则根据目标云产品的管控服务中所包含的多个功能组件的类别，对该管控服务进行压缩处理，以确定在私有云中部署该管控服务所需的第二资源，如果私有云中的可用资源满足第二资源，则在私有云中部署经压缩处理后的管控服务。其中，压缩处理一般会使得管控服务所提供的功能基本不受影响，但是管控服务中包含的功能组件的数量得到降低，从而降低管控服务在用户私有云中所占用的资源量，实现公有云中目标云产品的管控服务在用户私有云中的低成本部署。

附图说明

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

图1为本发明实施例提供的一种云产品管控服务部署方法的流程图；

图2为本发明实施例提供的一种私有组件的示意图；

图3为本发明实施例提供的一种公共组件的示意图；

图4为本发明实施例提供的一种轻量替代组件的示意图；

图5为本发明实施例提供的一种应用混布组件的示意图；

图6为本发明实施例提供的一种压缩前管控服务的组成示意图；

图7为本发明实施例提供的一种压缩后管控服务的组成示意图；

图8为本发明实施例提供的一种云产品管控服务部署装置的结构示意图；

图9为与图8所示实施例提供的云产品管控服务部署装置对应的电子设备的结构示意图。

具体实施方式

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

下面结合附图对本发明的一些实施方式作详细说明。在各实施例之间不冲突的情况下，下述的实施例及实施例中的特征可以相互组合。另外，下述各方法实施例中的步骤时序仅为一种举例，而非严格限定。

这里先介绍一个概念：私有云输出——将公有云中完整的云平台（也称为云产品）进行产品化集成，自动部署到用户的数据中心中。

随着云计算服务的私有云输出，云产品的管控服务必不可少的需要输出到用户的中心机房，并且要占用部分资源。同时因为很多时候公有云和私有云是采用同一套架构开发的，用户也希望两者能提供一致的功能，这样就需要将很多公有云中云产品的管控服务按需输出到用户私有云中进行部署。

在需要将公有云中云产品的管控服务部署在用户的私有云环境中时，基于部署资源成本降低的价值点出发，力争用最小的输出资源成本，实现和公有云一致的核心功能。也就是说，一方面要几乎不影响管控服务所提供的功能，即管控服务在私有云中提供的功能与在公有云中提供的功能是一致的，另一方面要降低管控服务在用户的私有云中所占用的资源。这是因为对私有云用户来说，某云产品本身以及其管控服务占用的资源都是公摊的，即共同占用私有云中的资源，但是只有用户实际用到的云计算服务（即云产品本身提供的服务）才是最有价值的，用户希望管控服务占用的资源尽可能的减少。

同时对云产品来说，也希望快速的将公有云已有的能力快速集成输出，提升适配的效率，同时尽量满足用户对云产品功能、部署成本的要求，如果大幅度改动现有的微服务部署架构，会极大提升部署成本。

在上述云产品功能、资源压缩、研发效率的多重要求下，本方案应运而生。

本发明实施例提供的方案可以由某电子设备执行，该电子设备可以是服务器，也可以是用户终端。负责私有云部署的相关工作人员通过在该电子设备上执行相关的部署操作，以便最终确定需要为用户部署的目标云产品的管控服务的组成以及其在用户的私有云中需要占用的资源。

图1为本发明实施例提供的一种云产品管控服务部署方法的流程图，如图1所示，该方法可以包括如下步骤：

101、确定在私有云中的需要部署的目标云产品的管控服务。

102、根据管控服务在公有云中的访问量信息和在私有云中的访问量信息，确定在私有云中部署该管控服务所需的第一资源。

103、若私有云中的可用资源不能满足第一资源，则根据管控服务所包含的多个功能组件的类别，对管控服务进行压缩处理，以确定在私有云中部署管控服务所需的第二资源。

104、若私有云中的可用资源满足第二资源，则在私有云中部署经压缩处理后的管控服务。

在实际应用中，私有云的用户一般是企业、机构等团体，当用户向云服务提供商提出为自己部署专属于自己的私有云时，会告知云服务提供商自己所需使用到的云产品，称为目标云产品，比如为虚拟机、数据库等云产品。与虚拟机对应的管控服务比如可以提供创建虚拟机，对虚拟机进行相关参数配置等功能；与数据库对应的管控服务比如可以提供日志管理、数据存储与查询等功能。

云服务提供商在得知用户需要部署的目标云产品后，可以将目标云产品的管控服务部署到用户使用的私有云中。当然，目标云产品本身提供的相关功能在用户私有云中也会进行部署，这部分部署不属于本发明实施例关注的重点，不展开描述。

由于用户的私有云中包含的计算、存储等资源是有限的，这些资源需要优先保证目标云产品本身提供的相关功能的完整部署，因此，在部署目标云产品的管控服务的时候，需要尽量减少该管控服务对私有云中资源的占用。

为了在用户的私有云中部署目标云产品的管控服务，首先，可以基于目标云产品本身提供的相关功能的部署情况以及私有云可以提供的全部资源，设置私有云中管控服务可用的资源，比如，可用资源可以是私有云的全部资源中除部署目标云产品本身提供的功能所用资源外剩余的全部或部分资源。

另外，根据目标云产品的管控服务在公有云中的访问量信息及其在用户的私有云中的访问量信息，确定在该私有云中部署目标云产品的管控服务所需的第一资源。

实际应用中，目标云产品的管控服务在公有云中的访问量往往远大于在用户的私有云中的访问量，因为在公有云中该目标云产品可以被若干用户访问，而在私有云中仅能够被对应的用户访问。因此，目标云产品的管控服务在公有云中所占用的资源往往远大于在私有云中所占用的资源。可选地，可以根据目标云产品的管控服务在公有云中的访问量及其在用户的私有云中的访问量确定一个比例系数，进而根据目标云产品的管控服务在公有云中所占用的资源量以及该比例系数，确定在用户的私有云中部署目标云产品的管控服务所需的第一资源。

其中，目标云产品的管控服务在私有云中的访问量可以由私有云用户设定，而目标云产品的管控服务在公有云中的访问量可以统计获得。

需要说明的是，在云服务架构中，会包含若干机器节点，每个机器节点中可以使用的计算芯片可以不同，比如CPU、GPU、FPGA、CPLD、ARM，等等。而不同规格的计算芯片的性能是有所不同的，因此，为了能够准确度量公有云和私有云中的上述资源情况，可以预先测定不同计算芯片的性能之间的映射关系，比如以某种规格的CPU为基准（假设该规格CPU的性能为100%），其他规格的计算芯片的性能在此基础上乘以一个系数作为其他计算芯片的性能指标，比如ARM芯片是该基准CPU芯片性能的0.6*100%=60%。因此，上述各种资源中关于计算资源的统计都采用该基准CPU芯片的性能作为度量指标来描述，比如私有云中的可用资源包括35个基准CPU，第一资源包括50个基准CPU。这里仅以计算芯片为例进行了说明，存储资源同理。

如果发现上述私有云中的可用资源不满足该第一资源的需求，即可用资源小于第一资源，则需要对目标云产品的管控服务进行压缩处理，以降低其占用的资源量。

概括来说，该压缩处理的原则是：在不影响管控服务所能提供的功能的同时，降低管控服务对资源的占用量。本实施例中，可以结合目标云产品的管控服务中包括的各功能组件的类别，来对该管控服务进行压缩处理。

实际应用中，管控服务可以包括多个子服务，比如包括日志管理子服务，账号管理子服及鉴权管理子服务，等等。每个子服务可以认为对应有一个功能模块，而每个功能模块可以由一个或多个功能组件构成。一个功能模块中包含的多个功能组件相互配合、相互依赖以提供对应的子服务功能。

可选地，所述类别包括如下至少一种：各云产品的管控服务私有的私有组件，不同云产品的管控服务共用的提供同一功能的公共组件，可由其他更轻量的组件替代的轻量替代组件，可与其他组件混合部署的应用混布组件。

下面分别示例性说明上述不同组件类别的含义。

如图2中所示，假设有两个云产品的管控服务分别表示为管控服务A和管控服务B，管控服务A中包括ApiServer组件和一个zookeeper组件x，管控服务B中包括RegionMaster组件和一个zookeeper组件x。在图2所示的情形下，管控服务A与管控服务B各自具有相同的一个zookeeper组件x，即这个zookeeper组件x被两个管控服务私有。因此，这个zookeeper组件x可以认为是一个私有组件。由此可知，私有组件，完全被某个云产品的管控服务使用，并且功能相同的功能组件在不同云产品间重复部署。其中，图中的箭头表示的是功能组件之间的依赖关系。

如图3中所示，假设有两个云产品的管控服务分别表示为管控服务A和管控服务B，管控服务A中包括ApiServer组件，管控服务B中包括RegionMaster组件。并假设这两个管控服务都会使用到zookeeper子服务，并且假设其中包括一个zookeeper组件x，则如图3中所示，ApiServer组件和RegionMaster组件均依赖于这个zookeeper组件x，因此这个zookeeper组件x便是这两个管控服务的公共组件。由此可知，公共组件，会提供公共的服务，该公共的服务被不同云产品共享。

如图4中所示，假设有两个云产品的管控服务分别表示为管控服务A和管控服务B，管控服务A中包括ApiServer组件，管控服务B中包括RegionMaster组件。并假设这两个管控服务都会使用到标准日志子服务，如图4中所示，假设标准日志服务由图中示意的六个功能组件构成。另外，如图4中所示，可以构建一个轻量日志服务，该轻量日志服务由图中示意的两个功能组件构成，并假设这两个功能组件所需占用的资源量小于标准日志服务中的六个功能组件所需占用的资源量。因此，构成轻量日志服务的两个功能组件将作为标准日志服务的轻量替代模块。由此可知，轻量替代模块，为某些重量级的服务提供轻量化的实现，减少功能组件数量的同时可以降低各功能组件占用的资源量。

如图5中所示，假设有两个云产品的管控服务分别表示为管控服务A和管控服务B，管控服务A中包括ApiServer组件，管控服务B中包括RegionMaster组件。并假设这两个管控服务都会使用到账号与鉴权服务这两个子服务，如图5中所示，假设一种实现账号与鉴权服务的部署方式是：独立部署，即构成账号服务与鉴权服务的多个功能组件分别部署在不同容器内，这多个容器可以设置在不同的机器中。另外，如图5中所示，另一种账号与鉴权服务的部署方式是：应用混布部署，即将这两个子服务各自包含的功能组件通过特定的软件处理后混合部署在同一个容器内。在图5中，账号与鉴权服务假设实现为java程序，则图中示意的jvm混布是对两个子服务相关功能组件的混布结果，另外，job混布是对另外其他服务相关功能组件的混布结果，由此可知，多种不同服务（即功能模块）对应的功能组件可以合并部署在一个容器内。

以上介绍了管控服务中定义的多种功能组件的类别，实际应用中，在向用户的私有云中部署目标云产品的管控服务时，可以先获取该管控服务包含的各功能模块，以及每个功能模块的组成情况，之后，相关人员可以为其中各个功能模块和/或功能组件进行类别标签的标记，其中，对某功能模块标记为某个类别意味着该功能模块中包含的各功能组件都具有该类别标记。

因此，需要说明的是，本发明实施例中所说的功能组件的类别也可以是功能模块的类别，因此本发明实施例中所描述的对功能组件的处理同样可以适用于功能模块。其中，以功能模块的粒度进行分类属于粗分类，以功能组件的粒度进行分类属于细分类，在以功能组件的粒度进行分类时，针对同一功能模块中包含的多个功能组件可以被进行不同类型的处理，比如某些功能组件转换为公共组件，有些功能组件被轻量化组件替代，而有些功能组件不变。

基于此，在一可选实施例中，根据目标云产品的管控服务所包含的多个功能组件的类别，对该管控服务进行压缩处理，包括：若确定目标云产品的管控服务中包含的第一功能组件与另一云产品的管控服务中包含的第二功能组件提供相同功能，则确定目标云产品的管控服务与另一云产品的管控服务共用第二功能组件，删除第一功能组件。

这里假设的是将私有组件转为公有组件的情形，即第一功能组件与第二功能组件功能相同，那么可以择一地选择只用这两个功能组件中的一个即可。

具体地，假设目标云产品的管控服务表示为管控服务R，上述另一云产品的管控服务表示为管控服务P，假设管控服务P中的功能组件p1预先被标记为公共组件，管控服务R中的功能组件r1被标记为私有组件，且在用户的私有云中也需要部署管控服务P，则在确定管控服务R中的功能组件r1与该公共组件p1具有相同功能时，可以将管控服务R中的功能组件r1删除，并将管控服务R中依赖该功能组件r1的功能组件配置为依赖该公共组件p1。上述是假设管控服务P中有与管控服务R中某功能组件提供相同功能的一个公共组件的情况，反之亦然。

实际应用中，每个功能组件可以具有相关的功能描述信息，据此可以判定两个功能组件是否提供相同功能。上述举例中仅以两个功能组件的粒度进行了举例说明，可以理解的是，当分类粒度采用功能模块这个粒度时，整个功能模块中的各个组件即功能模块都会进行上述处理。

在另一可选实施例中，根据目标云产品的管控服务所包含的多个功能组件的类别，对管控服务进行压缩处理，包括：若确定该管控服务中包含对应于轻量替代组件的第三功能组件，则确定与第三功能组件对应的目标替代组件，在私有云中部署该目标功能组件以替换第三功能组件。

这里假设的是目标云产品的管控服务中存在被标记为轻量替代组件这个类别的功能组件的情形，某个功能组件被标记为该类别，意味着存在比它占用资源少的功能组件可以替换使用。

实际应用中，假设目标云产品的管控服务中原本包括功能组件1和功能组件2，这两个功能组件分别提供不同的微服务，并假设云服务提供商还具有一个功能组件3，该功能组件3所能提供的微服务覆盖了功能组件1和功能组件2所提供的微服务，因此，功能组件1和功能组件2将被替换为轻量化的功能组件3，不仅降低了目标云产品中管控服务中的功能组件数量，还降低了对资源的占用量。在该举例中，功能组件1和功能组件2都会被标记为轻量替代组件，另外，除了类别标签外，功能组件上还可以具有所提供的功能（即微服务）的描述，以便确定出替代它的功能组件。

在另一可选实施例中，根据目标云产品的管控服务所包含的多个功能组件的类别，对管控服务进行压缩处理，还包括：若确定该管控服务中包含对应于应用混布组件的至少两个功能组件，则将所述至少两个功能组件部署在私有云中的同一容器组内，所述至少两个功能组件对应于不同的功能模块。

该实施例中提供的压缩方案是将不同功能模块混布在同一个容器内，以使得这些功能模块共用分配给该容器的资源，提高资源利用率。因为在云架构中，一个机器节点中可以包含若干个容器组（pod），每个容器组内包含一个或多个容器，机器节点中资源的分配是按照容器组—容器的维度进行分配的，相比于不同功能模块被独立部署在同一机器节点内的不同容器组或容器内，或者独立部署在不同机器节点内，将多个功能模块部署在一个容器内会使得资源利用率得到明显提升，因为为保证容器内功能模块的可靠运行，分配个每个容器的资源一般都是有冗余的，多个容器冗余的资源会更多。

实际应用中，工作人员可以针对某个功能模块A1标记为应用混布标签，针对另一个功能模块A2也标记为应用混布标签，具体地，可以标记为与功能模块A1做应用混布，即除了标记应用混布标签外，还标记上与哪个功能模块一起做应用混布。基于此，便可以将功能模块A1和功能模块A2中包含的全部功能组件混布于一个容器内，且保证不同功能模块、功能组件能够正常运行。

上述举例的是针对功能模块粒度进行应用混布，实际上，也可以针对功能组件粒度进行。一个功能模块中可以包括多个功能组件，有些功能组件比较重要，视为核心功能组件，因此，针对一个功能模块来说，可以对其中包含的多个功能组件进行差异化处理，比如核心功能组件不做特别处理，保持不变，而该功能模块中的非核心功能组件可以与另一功能模块中的非核心组件混布在同一个容器内。

这里假设将来自于不同功能模块的至少两个功能组件混布于一个容器内，进一步可选地，针对该容器内不同功能组件来说，还可以由工作人员在混布时设置各自对应的权重系数，该权重系数反映相应功能组件的重要程度，在已知为该容器分配的总资源的情况下，可以根据该权重系数确定该至少两个功能组件各自对应的资源占比，以实现每个功能组件按照分配给它的资源进行工作。

以上介绍了几种对目标云产品的管控服务进行压缩处理的方式，经过上述压缩处理后，相比于压缩之前，管控服务所占用的资源量将得到降低，结合具体的压缩处理情况，可以确定出经过压缩处理后管控服务所需的第二资源。如果上述私有云中的可用资源已经大于该第二资源，则可以在私有云中部署该经压缩处理后的管控服务即可。反之，如果私有云中的可用资源已经小于该第二资源即可用资源不满足第二资源，则还可以采用其他方式来进一步降低管控服务对用户的私有云资源的占用。

比如，可选地，可以进一步确定经压缩处理后的管控服务中包含的非核心功能组件，将所述非核心功能组件配置为可选部署项，其中，可选部署项指示所述非核心功能组件不需部署或被使用时再部署。实际应用中，根据压缩处理后管控服务中包含的各个功能模块、功能组件之间的依赖关系以及每个功能组件所提供的功能，可以确定出哪些功能组件只有在特定情况下才会被使用，而一般不常用；或者是哪些功能组件的运行正常与否对依赖它的其他功能组件影响不大，可以将这些功能组件设定为非核心功能组件，并将其配置为可选部署项。由于管控服务中的全部功能组件往往不会在同时都需要运行，所以对于一些设置为可选部署项的功能组件，可以在需要调用的时候再进行安装部署，这样可以避免对计算及存储资源的长期占用。

如果之后私有云的可用资源仍旧不能满足目标云产品的管控服务的部署需求，那么可以对用户的私有云进行硬件升级，比如更换一些计算性能比较高的计算芯片，更高大容量的内存条，等等。

为便于理解上文中对管控服务的压缩处理效果，下面结合图6和图7示例性说明压缩过程。

如图6中所示，假设某云产品的管控服务X和另一云产品的管控服务Y中包括图中示意的共14个功能组件。在图中假设情形下，宏观上看，一共存在两个功能依赖链路，一个由功能组件A2引出，另一个由功能组件B1引出，最长依赖链路上的功能组件数量为10个，即由功能组件A2引出的依赖链路上一共存在10个被依赖的功能组件。

图7中示意的是对图6中的两个管控服务的压缩结果。宏观上看，一共有一条功能依赖链路，由功能组件A2引出，共存在6个被依赖的功能组件。

对比图6和图7可知，一方面，功能组件的数量被减少，另一方面，最长依赖链路的长度有所降低。从而对资源的占用以及部署灵活性都有提高。

具体来说，压缩过程涉及如下方面：

1、私有组件转公共组件，以减少不同云产品的管控服务重复自建相同的功能组件：在图6和图7中，假设功能组件A7与功能组件B7功能相同，所以进行去重处理，仅保留其中一个作为两个管控服务的公共组件，图中示意的是保留功能组件A7。另外，假设功能组件A6对功能组件A7具有较强的依赖，因此可选地，在将功能组件A7转为公共组件后，与可以将功能组件A6也作为公共组件与功能组件A7一起部署为公共服务模块。

2、应用混布，各类java应用混布：在图6和图7中，假设功能组件A6、功能组件A7、功能组件A2和功能组件C1都对应于java应用，则可以将这四个功能组件合并部署于一个容器内，共享资源开销。需要说明的是，图6中示意的功能组件A1～A7、功能组件B1、功能组件B2、功能组件B7可以视为是功能模块，对应于一个功能模块中仅包括一个功能组件的情形。另外，图7中还示意出将另一种类型（job）的应用所涉及到的功能组件（service test,dbinit）也混布在这个容器中。

3、轻量化替代：在图6和图7中，假设功能组件A8、功能组件A9、功能组件A10和功能组件A11构成对应于标准日志服务的功能模块，功能组件C1和功能组件C2构成对应于轻量日志服务的功能模块，则可以以轻量日志服务替代标准日志服务。另外，如图6中所示，由于管控服务X与管控服务Y都需要调用标准日志服务，因此，替换成的轻量日志服务也被设置为公共服务模块。

4、功能组件可选部署：在图6和图7中，假设功能组件B1和功能组件B2是非核心组件，则可以可选部署这两个功能组件。

综上，在将公有云中云产品的管控服务部署在用户私有云的过程中，通过对管控服务进行压缩处理，可以降低其对资源的占用，同时保持私有云中部署的管控服务与其在公有云中提供的功能的一致性。

以下将详细描述本发明的一个或多个实施例的云产品管控服务部署装置。本领域技术人员可以理解，这些装置均可使用市售的硬件组件通过本方案所教导的步骤进行配置来构成。

图8为本发明实施例提供的一种云产品管控服务部署装置的结构示意图，如图8所示，该装置包括：确定模块11、处理模块12、部署模块13。

确定模块11，用于确定在私有云中的需要部署的目标云产品的管控服务。

处理模块12，用于根据所述管控服务在公有云中的访问量信息和在所述私有云中的访问量信息，确定在所述私有云中部署所述管控服务所需的第一资源；以及，若所述私有云中的可用资源不能满足所述第一资源，则根据所述管控服务所包含的多个功能模块的类别，对所述管控服务进行压缩处理，以确定在所述私有云中部署所述管控服务所需的第二资源。

部署模块13，用于若所述私有云中的可用资源满足所述第二资源，则在所述私有云中部署经所述压缩处理后的管控服务。

可选地，所述类别包括如下至少一种：各云产品的管控服务私有的私有组件，不同云产品的管控服务共用的提供同一功能的公共组件，可由其他更轻量的组件替代的轻量替代组件，可与其他组件混合部署的应用混布组件。

可选地，所述处理模块12具体可以用于：若确定所述目标云产品的管控服务中包含的第一功能组件与另一云产品的管控服务中包含的第二功能组件提供相同功能，则确定所述目标云产品的管控服务与所述另一云产品的管控服务共用所述第二功能组件，删除所述第一功能组件。

可选地，所述处理模块12具体可以用于：若确定所述管控服务中包含对应于轻量替代组件的第三功能组件，则确定与所述第三功能组件对应的目标替代组件，在所述私有云中部署所述目标功能组件以替换所述第三功能组件。

可选地，所述处理模块12具体可以用于：若确定所述管控服务中包含对应于应用混布组件的至少两个功能组件，则将所述至少两个功能组件部署在所述私有云中的同一容器内，所述至少两个功能组件对应于不同的功能模块。

可选地，所述处理模块12具体可以用于：确定为所述容器分配的总资源；根据所述至少两个功能组件的重要程度，确定所述至少两个功能组件在所述总资源中分别对应的资源占比。

可选地，所述处理模块12还可以用于：若所述私有云中的可用资源不能满足所述第二资源，则确定经所述压缩处理后的管控服务中包含的非核心功能组件；将所述非核心功能组件配置为可选部署项，所述可选部署项指示所述非核心功能组件不需部署或被使用时再部署。

图8所示装置可以执行前述实施例中的步骤，详细的执行过程和技术效果参见前述实施例中的描述，在此不再赘述。

在一个可能的设计中，上述图8所示云产品管控服务部署装置的结构可实现为一电子设备。如图9所示，该电子设备可以包括：处理器21、存储器22、通信接口23。其中，存储器22上存储有可执行代码，当所述可执行代码被处理器21执行时，使处理器21至少可以实现如前述实施例中的云产品管控服务部署方法。

另外，本发明实施例提供了一种非暂时性机器可读存储介质，所述非暂时性机器可读存储介质上存储有可执行代码，当所述可执行代码被服务器的处理器执行时，使所述处理器至少可以实现如前述实施例中提供的云产品管控服务部署方法。

以上所描述的装置实施例仅仅是示意性的，其中所述作为分离部件说明的网元可以是或者也可以不是物理上分开的。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。本领域普通技术人员在不付出创造性的劳动的情况下，即可以理解并实施。

通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到各实施方式可借助加必需的通用硬件平台的方式来实现，当然也可以通过硬件和软件结合的方式来实现。基于这样的理解，上述技术方案本质上或者说对现有技术做出贡献的部分可以以计算机产品的形式体现出来，本发明可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质（包括但不限于磁盘存储器、CD-ROM、光学存储器等）上实施的计算机程序产品的形式。

最后应说明的是：以上实施例仅用以说明本发明的技术方案，而非对其限制；尽管参照前述实施例对本发明进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本发明各实施例技术方案的精神和范围。

Claims (10)

1.一种云产品管控服务部署方法，其特征在于，包括：

确定在私有云中的需要部署的目标云产品的管控服务；

根据所述管控服务在公有云中的访问量信息和在所述私有云中的访问量信息，确定在所述私有云中部署所述管控服务所需的第一资源；

若所述私有云中的可用资源不能满足所述第一资源，则根据所述管控服务所包含的多个功能组件的类别，对所述管控服务的功能组件进行压缩处理，以确定在所述私有云中部署所述管控服务所需的第二资源；

若所述私有云中的可用资源满足所述第二资源，则在所述私有云中部署经所述压缩处理后的管控服务。

2.根据权利要求1所述的方法，其特征在于，所述类别包括如下至少一种：各云产品的管控服务私有的私有组件，不同云产品的管控服务共用的提供同一功能的公共组件，可由其他更轻量的组件替代的轻量替代组件，可与其他组件混合部署的应用混布组件。

3.根据权利要求2所述的方法，其特征在于，所述根据所述管控服务所包含的多个功能组件的类别，对所述管控服务的功能组件进行压缩处理，包括：

若确定所述目标云产品的管控服务中包含的第一功能组件与另一云产品的管控服务中包含的第二功能组件提供相同功能，则确定所述目标云产品的管控服务与所述另一云产品的管控服务共用所述第二功能组件，删除所述第一功能组件。

4.根据权利要求2所述的方法，其特征在于，所述根据所述管控服务所包含的多个功能组件的类别，对所述管控服务的功能组件进行压缩处理，包括：

若确定所述管控服务中包含对应于轻量替代组件的第三功能组件，则确定与所述第三功能组件对应的目标替代组件，在所述私有云中部署所述目标替代组件以替换所述第三功能组件。

5.根据权利要求2所述的方法，其特征在于，所述根据所述管控服务所包含的多个功能组件的类别，对所述管控服务的功能组件进行压缩处理，包括：

若确定所述管控服务中包含对应于应用混布组件的至少两个功能组件，则将所述至少两个功能组件部署在所述私有云中的同一容器内，所述至少两个功能组件对应于不同的功能模块。

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

确定为所述容器分配的总资源；

根据所述至少两个功能组件的重要程度，确定所述至少两个功能组件在所述总资源中分别对应的资源占比。

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

若所述私有云中的可用资源不能满足所述第二资源，则确定经所述压缩处理后的管控服务中包含的非核心功能组件；

将所述非核心功能组件配置为可选部署项，所述可选部署项指示所述非核心功能组件不需部署或被使用时再部署。

8.一种云产品管控服务部署装置，其特征在于，包括：

确定模块，用于确定在私有云中的需要部署的目标云产品的管控服务；

处理模块，用于根据所述管控服务在公有云中的访问量信息和在所述私有云中的访问量信息，确定在所述私有云中部署所述管控服务所需的第一资源；以及，若所述私有云中的可用资源不能满足所述第一资源，则根据所述管控服务所包含的多个功能模块的类别，对所述管控服务的功能组件进行压缩处理，以确定在所述私有云中部署所述管控服务所需的第二资源；

部署模块，用于若所述私有云中的可用资源满足所述第二资源，则在所述私有云中部署经所述压缩处理后的管控服务。

9.一种电子设备，其特征在于，包括：存储器、处理器、通信接口；其中，所述存储器上存储有可执行代码，当所述可执行代码被所述处理器执行时，使所述处理器执行如权利要求1至7中任一项所述的云产品管控服务部署方法。

10.一种非暂时性机器可读存储介质，其特征在于，所述非暂时性机器可读存储介质上存储有可执行代码，当所述可执行代码被电子设备的处理器执行时，使所述处理器执行如权利要求1至7中任一项所述的云产品管控服务部署方法。

Images