一种约束配置方法、装置及电子设备与流程

本申请涉及计算机技术领域，具体而言，涉及一种约束配置方法、装置及电子设备。

背景技术：

目前在大规模部署交付场景中，从单节点服务部署到大规模集群部署，从单一的业务部署场景到纷繁复杂的应用场景，企业对集群快速部署及配置功能需求越发急切。在配置功能中，有一项特别重要的功能即是对约束条件进行配置。目前，对于约束条件的配置非常繁琐，需要在上层的前端页面中写入相应的约束代码，并匹配对应的后端服务进程才能实现对约束条件的配置，配置过程十分麻烦；同时由于在人力资源上需要前端人员和后端人员的共同投入，因此人力成本高。

技术实现要素：

本申请实施例的目的在于提供一种约束配置方法、装置及电子设备，用以解决相关技术中，对于约束条件的配置非常繁琐，需要上层的前端页面和后端服务进程一起配合才能实现对约束条件的配置，配置过程十分麻烦，人力成本高的问题。

本申请实施例提供了一种约束配置方法，包括：生成底层约束项配置文件；所述底层约束项配置文件中记录有约束条件；将所述底层约束项配置文件映射到前端页面，使得所述前端页面具有与所述约束条件对应的约束功能。

在上述实现过程中，通过生成记录有约束条件的底层约束项配置文件，进而将底层约束项配置文件映射到前端页面上，从而使得前端页面与底层约束项配置文件关联。这样前端页面在进行管控时，则会按照底层约束项配置文件中的约束条件进行管控，即前端页面会具有与底层约束项配置文件相应的约束功能。通过上述实现过程，只需要将约束条件写成底层约束项配置文件形式，再将底层约束项配置文件映射到前端页面即可实现对约束条件的配置，整个过程十分简单，同时也不需要前端人员和后端人员的投入，降低了人力成本。

进一步地，所述将所述底层约束项配置文件映射到前端页面包括：预设的后端服务进程获取所述底层约束项配置文件；将所述底层约束项配置文件发送给所述前端页面。

在上述实现过程中，通过预设的后端服务进程来获取底层约束项配置文件，再将底层约束项配置文件发送给前端页面，即实现了底层约束项配置文件到前端页面的映射，保证了底层约束项配置文件到前端页面的映射有效性。

进一步地，所述后端服务进程在获取所述底层约束项配置文件后，将所述底层约束项配置文件发送给所述前端页面之前，还包括：将所述底层约束项配置文件转换为前端页面所能识别的格式；所述将所述底层约束项配置文件发送给所述前端页面包括：将格式转换后的所述底层约束项配置文件发送给所述前端页面。

在上述实现过程中，后端服务进程在获取到底层约束项配置文件后，即可将底层约束项配置文件进行格式转换，转换为前端页面所能识别的格式，这样在将底层约束项配置文件发送给前端页面时，即可保证前端页面一定可以识别，进而保证映射的成功率。

进一步地，所述后端服务进程在获取所述底层约束项配置文件后，将所述底层约束项配置文件发送给所述前端页面之前，还包括：对所述底层约束项配置文件进行语法校验，并确定校验通过。

在上述实现过程中，后端服务进程在获取到底层约束项配置文件后，即可对底层约束项配置文件进行语法校验，只要在通过时才将底层约束项配置文件发送给前端页面，从而保证底层约束项配置文件的合规性与准确性，避免由于底层约束项配置文件在生成过程中出现错误、且错误文件被执行后出现系统错误的情况的发生。

进一步地，所述底层约束项配置文件的格式为以下任意一种格式：yaml(yamlain'tmarkuplanguage，另一种标记语言)格式、json(javascriptobjectnotation，javascript对象简谱)格式、xml(extensiblemarkuplanguage，可扩展标记语言)格式。

在上述实现过程中，底层约束项配置文件的格式可以为yaml格式、json格式、xml格式等，通过这些格式来实现底层约束项配置文件的生成，实现简单、容易，可编辑性强。

进一步地，所述在所述生成底层约束项配置文件之前，还包括：获取待配置的约束条件；所述生成底层约束项配置文件包括：基于获取到的所述待配置的约束条件，按照预设生成规则自动生成所述底层约束项配置文件。

在上述实现过程中，预先在设备中设定好底层约束项配置文件的生成规则，进而用户只需要输入待配置的约束条件，设备即可自动按照预设生成规则自动生成底层约束项配置文件，从而节约用户对底层约束项配置文件的配置时间，提高配置效率。

进一步地，在所述将所述底层约束项配置文件映射到前端页面之后，还包括：获取针对所述底层约束项配置文件的修改数据；根据所述修改数据修改所述底层约束项配置文件，得到经修改底层约束项配置文件；将所述经修改底层约束项配置文件映射到所述前端页面。

在上述实现过程中，用户可以直接对底层约束项配置文件进行修改，设备在获取针对底层约束项配置文件的修改数据后，即可根据修改数据修改底层约束项配置文件，得到经修改底层约束项配置文件，再将经修改底层约束项配置文件映射到前端页面，即可实现对约束条件的修改。通过这种方式来实现对约束条件的修改，简单方便易实现。修改过程可以无需开发人员投入，仅通过一个交付人员或者运维人员对底层文件的编辑、修改，就可以完成对约束条件的重新配置，真正做到使用人员与开发人员的分离，提升了使用便利性。

进一步地，在所述将所述底层约束项配置文件映射到前端页面之后，还包括：在检测到所述底层约束项配置文件中的某一约束条件未满足时，发送用于提示该约束条件未被满足的提示信息。

在上述实现过程中，在某一约束条件未满足时，可以提示用户具体是哪一个约束条件未满足，从而方便用户进行问题定位，进而进行后续的调整。避免在出现问题之后还需要用户手动去筛查具体是什么约束条件未满足的情况的发生，提升了用户体验。

本申请实施例还提供了一种约束配置装置，包括：文件生成模块，用于生成底层约束项配置文件；所述底层约束项配置文件中记录有约束信息；映射处理模块，用于将所述底层约束项配置文件映射到前端页面，使得所述前端页面具有与所述约束条件对应的约束功能。

在上述实现结构中，通过生成记录有约束条件的底层约束项配置文件，进而将底层约束项配置文件映射到前端页面上，从而使得前端页面与底层约束项配置文件关联。这样前端页面在进行管控时，则会按照底层约束项配置文件中的约束条件进行管控，即前端页面会具有与底层约束项配置文件相应的约束功能。通过上述实现过程，只需要将约束条件写成底层约束项配置文件形式，再将底层约束项配置文件映射到前端页面即可实现对约束条件的配置，整个过程十分简单，同时也不需要前端人员和后端人员的投入，降低了人力成本。

进一步地，所述映射处理模块包括：后端服务进程获取模块和后端服务进程发送模块；所述后端服务进程获取模块用于，通过预设的后端服务进程获取所述底层约束项配置文件；所述后端服务进程发送模块用于，通过所述后端服务进程将底层约束项配置文件发送给所述前端页面。

在上述实现结构中，通过预设的后端服务进程来获取底层约束项配置文件，再将底层约束项配置文件发送给前端页面，即实现了底层约束项配置文件到前端页面的映射，保证了底层约束项配置文件到前端页面的映射有效性。

进一步地，所述映射处理模块还包括：格式转换模块；所述格式转换模块用于，在所述后端服务进程获取模块通过所述后端服务进程获取所述底层约束项配置文件之后，在所述后端服务进程发送模块通过所述后端服务进程将底层约束项配置文件发送给所述前端页面之前，将所述底层约束项配置文件转换为前端页面所能识别的格式；所述后端服务进程发送模块具体用于，通过所述后端服务进程将格式转换后的所述底层约束项配置文件发送给所述前端页面。

在上述实现结构中，后端服务进程在获取到底层约束项配置文件后，即可将底层约束项配置文件进行格式转换，转换为前端页面所能识别的格式，这样在将底层约束项配置文件发送给前端页面时，即可保证前端页面一定可以识别，进而保证映射的成功率。

进一步地，所述映射处理模块还包括：校验模块；所述校验模块用于，在所述后端服务进程获取模块通过所述后端服务进程获取所述底层约束项配置文件之后，在所述后端服务进程发送模块通过所述后端服务进程将底层约束项配置文件发送给所述前端页面之前，对所述底层约束项配置文件进行语法校验，并确定校验通过。

在上述实现结构中，后端服务进程在获取到底层约束项配置文件后，即可对底层约束项配置文件进行语法校验，只要在通过时才将底层约束项配置文件发送给前端页面，从而保证底层约束项配置文件的合规性与准确性，避免由于底层约束项配置文件在生成过程中出现错误、且错误文件被执行后出现系统错误的情况的发生。

进一步地，所述底层约束项配置文件的格式为以下任意一种格式：yaml格式、json格式、xml格式。

在上述实现结构中，底层约束项配置文件的格式可以为yaml格式、json格式、xml格式等，通过这些格式来实现底层约束项配置文件的生成，实现简单、容易，可编辑性强。

进一步地，所述约束配置装置还包括：约束项获取模块；所述约束项获取模块用于，在所述文件生成模块生成底层约束项配置文件之前，获取待配置的约束条件；所述文件生成模块具体用于，基于获取到的所述待配置的约束条件，按照预设生成规则自动生成所述底层约束项配置文件。

在上述实现结构中，通过预先设定好底层约束项配置文件的生成规则，从而使得用户只需要输入待配置的约束条件，即可自动按照预设生成规则自动生成底层约束项配置文件。节约了用户对底层约束项配置文件的配置时间，提高配置效率。

进一步地，所述约束配置装置还包括：修改数据获取模块和文件修改模块；所述修改数据获取模块，用于获取针对所述底层约束项配置文件的修改数据；文件修改模块，用于根据所述修改数据修改所述底层约束项配置文件，得到经修改底层约束项配置文件；所述映射处理模块还用于，将所述经修改底层约束项配置文件映射到所述前端页面。

在上述实现结构中，用户可以直接对底层约束项配置文件进行修改，设备在获取针对底层约束项配置文件的修改数据后，即可根据修改数据修改底层约束项配置文件，得到经修改底层约束项配置文件，再将经修改底层约束项配置文件映射到前端页面，即可实现对约束条件的修改。通过这种方式来实现对约束条件的修改，简单方便易实现。修改过程可以无需开发人员投入，仅通过一个交付人员或者运维人员对底层文件的编辑、修改，就可以完成对约束条件的重新配置，真正做到使用人员与开发人员的分离，提升了使用便利性。

进一步地，所述约束配置装置还包括：检测模块和提示模块；所述检测模块用于，检测底层约束项配置文件中约束条件是否被满足；所述提示模块用于，在所述检测模块检测到底层约束项配置文件中的某一约束条件未满足时，发送用于提示该约束条件未被满足的提示信息。

在上述实现结构中，在某一约束条件未满足时，可以提示用户具体是哪一个约束条件未满足，从而方便用户进行问题定位，进而进行后续的调整。避免在出现问题之后还需要用户手动去筛查具体是什么约束条件未满足的情况的发生，提升了用户体验。

本申请实施例还提供了一种电子设备，包括处理器、存储器及通信总线；所述通信总线用于实现处理器和存储器之间的连接通信；所述处理器用于执行存储器中存储的一个或者多个程序，以实现上述任意一种的约束配置方法的步骤。

在上述实现过程中，通过电子设备的处理器来执行上述约束配置方法的步骤，可以实现约束条件的配置简单化，同时也不需要前端人员和后端人员的投入，降低了人力成本。

本申请实施例中还提供了一种计算机存储介质，所述计算机存储介质存储有一个或者多个程序，所述一个或者多个程序可被一个或者多个处理器执行，以实现上述任意一种约束配置方法的步骤。

附图说明

为了更清楚地说明本申请实施例的技术方案，下面将对本申请实施例中所需要使用的附图作简单地介绍，应当理解，以下附图仅示出了本申请的某些实施例，因此不应被看作是对范围的限定，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他相关的附图。

图1为本申请实施例提供的一种约束配置方法的基本流程示意图；

图2为本申请实施例提供的一种层级示意图；

图3为本申请实施例提供的一种前端页面生成约束功能的流程示意图；

图4为本申请实施例提供的一种约束配置装置的基本框图；

图5为本申请实施例提供的一种可选的约束配置装置的结构框图；

图6为本申请实施例提供的一种较具体的约束配置装置的结构框图；

图7为本申请实施例提供的一种更具体的约束配置装置的结构框图；

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

具体实施方式

下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行描述。

应注意到：相似的标号和字母在下面的附图中表示类似项，因此，一旦某一项在一个附图中被定义，则在随后的附图中不需要对其进行进一步定义和解释。同时，在本申请的描述中，术语“第一”、“第二”等仅用于区分描述，而不能理解为指示或暗示相对重要性。

实施例一

请参看图1，图1为本申请实施例提供的一种约束配置方法的基本流程示意图，包括：

s101：生成底层约束项配置文件；

应当理解的是，本申请实施例中所生成的底层约束项配置文件是系统配置文件的一种，用于对约束条件进行配置。在本申请实施例中，底层约束项配置文件中记录有约束条件，即在底层约束项配置文件中记录有至少一个约束项及其所应当满足的约束条件到底是什么。例如：在底层约束项配置文件中可以记录有控制节点的数量大于等于3，网络节点的数量大于等于2，计算节点的数量大于等于1，存储节点的数量大于等于3等等。前述示例中，控制节点的数量、网络节点的数量、计算节点的数量、存储节点的数量即为约束项，即约束项为需要进行约束的对象。而“控制节点的数量大于等于3”、“网络节点的数量大于等于2”，“计算节点的数量大于等于1”，“存储节点的数量大于等于3”即为各约束项对应的约束条件。而约束条件即为约束项所需满足的限定条件。

应当理解的是，本申请实施例中的约束项包括但不限于：节点约束项、单节点内的硬件约束项、环境约束项等等。如上述的“控制节点的数量”、“网络节点的数量”、“计算节点的数量”、“存储节点的数量”等即为节点约束项；而单节点内的硬件约束项可以是某个节点的某个或某些硬件条件，如cpu数量、内存数量、磁盘大小、网卡速率、网口数量等等；而环境约束项即是指产品运行环境中所需进行约束的对象，如网关连接情况、外网接通情况、可用节点数量等等。

需要注意的是，根据产品的功能的不同，需要进行配置的约束项，及其对应的约束条件即可能不同。例如对于执行a功能的产品，其所需要进行限制的约束项可能是a1、a2、a3，其所需对应配置的约束条件为a11、a21、a31，而对于执行b功能的产品，其所需要进行限制的约束项可能是b1、b2、b3，其所需对应配置的约束条件为b11、b21、b31。需要说明的是，可能存在所需要进行限制的约束项相同，但是约束项的约束条件不同的情况，例如，对于执行c功能的产品，设其所需要进行限制的约束项为c1、c2、c3，其所需对应配置的约束条件为c11、c21、c31，而对于执行d功能的产品，其所需要进行限制的约束项同样为c1、c2、c3，其所需对应配置的约束条件却为c41、c51、c61。因此，在本申请实施例中，约束项及具体的约束条件可以由工程师根据实际需求进行确定。

特别需要说明的是，在实际运用中，可以将不同的约束项的约束条件写入不同的底层约束项配置文件中，从而为每一个约束项都分别生成一个底层约束项配置文件。在实际运用中，也可以将多个约束项的约束条件写入同一个底层约束项配置文件中，这样最终生成的约束项配置文件的个数就会大大降低，从而降低系统文件的冗余度，更有利于系统文件的管理。例如可以将所有约束项的约束条件都写入一个底层约束项配置文件中，这样仅会生成一个底层约束项配置文件，从而极大地降低了系统文件的冗余度。

需要说明的是，在本申请实施例中，可以由工程师按照实际需求编写底层约束项配置文件，从而使得设备按照工程师的编写生成底层约束项配置文件。

可选的，为了降低工程师的工作量，本申请实施例中可以预先设定好生成规则，进而工程师只需要输入待配置的约束条件，设备即可根据预设的生成规则自动生成记录该约束条件的底层约束项配置文件。示例性的，可以预先在设备中设定好生成模板，进而在获取到用户输入的待配置的约束条件后，即可先根据设定好生成模板生成对应约束项的模板文件，再将约束条件填充入模板文件中即可得到底层约束项配置文件。这样工程师即只需要根据实际需求确定出需要配置约束项及其对应的约束条件，进而输入约束条件(参见上述对约束条件的示例所示，可见约束条件中可解析出对应的约束项)给设备，设备即可自动生成记录该约束条件的底层约束项配置文件，从而极大地降低了工程师的工作量，提升了工作效率。

s102：将底层约束项配置文件映射到前端页面。

应当理解的是，在将底层约束项配置文件映射到前端页面后，前端页面(如管理页面)在进行产品管控时，即可按照底层约束项配置文件中约束条件的要求来对产品进行监管，在某一个约束条件不满足时，即会阻止产品进行下一步操作，保证了产品运行的合规性。即，通过将底层约束项配置文件映射到前端页面，即可使得前端页面具有根据约束条件对产品进行约束的功能。

本申请实施例中通过生成底层约束项配置文件，进而将底层约束项配置文件映射到前端页面的方式，使得前端页面能够根据底层约束项配置文件所记录的约束条件来实现对产品的约束，保证了产品运行的合规性，同时实现方式也很简单，不需要前端人员和后端人员的投入，人力成本低，因此本申请实施例所提供的约束配置方案具有很高的实际应用价值。

可选的，在本申请实施例中，设备在系统层面可以包括上层和底层两个部分，例如参见图2所示，上层即用于提供服务，而底层则作为上层的基础，为上层提供配置文件等基础文件，以保证上层的正常运作。在本申请实施例中，上层结构中又分为前端页面和后端服务进程。其中，前端页面用于面向用户提供页面服务，而后端服务进程则用于对前端页面提供支撑，保证前端页面的正常运作。

在本申请实施例中，可以通过预设的后端服务进程来获取底层约束项配置文件，再将获取到的底层约束项配置文件发送给前端页面，从而实现底层约束项配置文件到前端页面的映射。需要说明的是，本申请实施例中获取底层约束项配置文件发给前端页面的后端服务进程可以是前端页面自身的服务进程，也可以是单独设立的专门用于映射底层约束项配置文件的服务进程。事实上，只要预先设定好哪一个或哪几个后端服务进程可以执行获取底层约束项配置文件发给前端页面即可。还需要说明的是，本申请实施例中映射底层约束项配置文件的前端页面也是预先设定好的，例如可以为管理页面。

在本申请实施例中，预设的后端服务进程在获取到底层约束项配置文件之后，在将获取到的底层约束项配置文件发送给前端页面之前，还可以对底层约束项配置文件进行格式转换，将其转换为前端页面所能识别的格式。进而后端服务进程发送格式转换后的底层约束项配置文件发送给前端页面，从而保证前端页面可以进行有效的识别，保证了映射的成功率。

示例性的，本申请实施例中可以预先设定好待转换的格式(如json格式)，进而将底层约束项配置文件的格式转换为该待转换的格式。而待转换的格式应当为前端页面所能识别的格式。

在本申请实施例中，预设的后端服务进程在获取到底层约束项配置文件之后，在将获取到的底层约束项配置文件发送给前端页面之前，还可以对底层约束项配置文件进行语法校验，在语法校验通过后才发送底层约束项配置文件给前端页面。而如果语法校验未通过，则表明该底层约束项配置文件可能存在一定的语法错误，为了避免后续的无法识别或识别后无法执行甚至造成系统混乱的情况的出现，则不会发送底层约束项配置文件给前端页面。可选的，在语法校验未通过时，还可以发送用于提示该底层约束项配置文件语法错误的提示信息，从而提示用户对该底层约束项配置文件进行修改。需要说明的是，在本申请实施例中提示方式包括但不限于页面弹框提示、音频提示、警报灯提示等。

应当理解的是，上述预设的后端服务进程对于语法的校验方案和上述预设的后端服务进程对底层约束项配置文件进行格式转换的方案可以同时被采用。当然，也可以仅采用其中一种方案，如不进行语法校验等。

需要说明的是，在本申请实施例中，用于编辑底层约束项配置文件的语法可以采用自定义的语法，从而提供给使用者一种简单的语法编辑能力，保证底层约束项配置文件可以具有较高的可编辑性。当然，在本申请实施例中也可以将传统语法来实现。

还需要说明的是，在本申请实施例中，可以基于yaml格式、json格式、xml格式等格式来生成底层约束项配置文件。值得注意的是，在基于yaml格式生成底层约束项配置文件时，其语法校验时较为容易，便于机器实现。而基于json格式生成底层约束项配置文件时，由于json格式是页面可识别的格式，因此可以不需要进行格式转换，可以简化机器的执行流程。

应当理解的是，在实际应用过程中，可能会存在需要对约束条件进行修改的情况。在本申请实施例中，底层约束项配置文件会提供修改和编辑的权限，从使得用户可以通过对底层约束项配置文件的修改来实现对前端页面的约束功能的修改。

示例性的，可以在将底层约束项配置文件映射到前端页面之后，获取针对底层约束项配置文件的修改数据(修改数据可以由用户根据实际需要输入)，然后根据修改数据修改底层约束项配置文件，得到经修改底层约束项配置文件，进而再将经修改底层约束项配置文件映射到前端页面，从而实现对前端页面的约束功能的修改。需要说明的是，将经修改底层约束项配置文件映射到前端页面的过程，和将底层约束项配置文件映射到前端页面的过程一致，在此不再赘述。

应当明晰的是，基于相关技术中对约束的配置方式，在需要进行约束功能的修改时，也需要前端人员和后端人员的共同配合才能实现，对于人员有着特殊要求，同时还涉及到多方人员的协调配合，十分不便。而基于本申请实施例所提供的约束配置方法，可以直接对底层约束项配置文件进行修改，进而将修改后的底层约束项配置文件(即经修改底层约束项配置文件)映射到前端页面，即可实现对约束功能的修改，修改方式简单易操作，可行性高，同时还不需要前端人员和后端人员的投入，仅通过一个交付人员或者运维人员就可以实现对约束功能的修改工作，真正做到使用人员与开发人员的分离，人力成本低，便利性高，因此本申请实施例所提供的约束配置方案具有很高的实际应用价值。

在本申请实施例中，前端页面可以对约束条件是否满足进行监测，进而在监测到底层约束项配置文件中的某一约束条件未满足时，即发送用于提示该约束条件未被满足的提示信息。这样，通过自动提醒，用户即可知道具体是哪一个约束条件未满足，从而方便用户进行问题定位，进而进行后续的调整。避免在出现问题之后还需要用户手动去筛查具体是什么约束条件未满足的情况的发生，提升了用户体验。需要说明的是，在本申请实施例中提示方式包括但不限于页面弹框提示、音频提示、警报灯提示等。

综上所述，本申请实施例提供一种约束配置方法，通过生成记录有约束条件的底层约束项配置文件，进而将底层约束项配置文件映射到前端页面上，从而使得前端页面与底层约束项配置文件关联。这样前端页面在进行管控时，则会按照底层约束项配置文件中的约束条件进行管控，即前端页面会具有与底层约束项配置文件相应的约束功能。通过上述实现过程，只需要将约束条件写成底层约束项配置文件形式，再将底层约束项配置文件映射到前端页面即可实现对约束条件的配置，整个过程十分简单，同时也不需要前端人员和后端人员的投入，降低了人力成本。此外，本申请实施例所提供得约束配置方法可以直接对底层约束项配置文件进行修改，进而将修改后的底层约束项配置文件映射到前端页面，即可实现对前端页面约束功能的修改。修改方式简单易操作，可行性高，同时还不需要前端人员和后端人员的投入，仅通过一个交付人员或者运维人员就可以实现对约束功能的修改工作，真正做到使用人员与开发人员的分离，人力成本低，便利性高，具有很高的实际应用价值。

实施例二：

本实施例在实施例一的基础上，以一种较具体的约束生成及修改过程为例，为本申请做进一步示例说明。

参见图2所示，本实施例中包括前端页面01，可以根据03文件中的约束项信息，在页面上映射约束条件；后台进程服务02，可以读取03文件中的约束项条件，格式转换并语法校验后传输至前端页面01。底层配置文件03，允许编辑、修改、调整，可以通过对底层配置文件03的编辑、修改、调整，完成约束条件的写入和修改。

对于底层配置文件，可以使用自定义的定制语法来完成相关的设计，提供给使用者一种简单语法编辑能力，使其能如写代码一样完成相关约束条件的编辑与修改。

语法中主要包含变量与运算符：变量是用于标记约束对象的一种特殊变量，每一种要约束的资源将有一个唯一的变量用于标识，例如：

节点：

控制节点数量(controller_num)；

网络节点数量(network_num)；

计算节点数量(compute_num)；

存储节点数量(storage_num)；

等等。

单节点的硬件：

cpu数量(cpu_num)；

内存数量(men_num)；

磁盘大小(disk_size)；

网卡速率(nic_speed)；

网口数量(nic_num)；

等等。

环境：

网关检查(gateway_check)；

外网检查(outnet_check)；

可用节点数量(node_num)；

等等。

参见图3所示，图3为本实施例中提供的前端页面生成约束功能的流程示意图，包括：

s301：接收编写的底层配置文件生成底层约束项配置文件；

工程师在编辑修改底层配置文件时，可以先确定脚本中需要提供给前端页面的约束项及其对应的约束条件是什么；进而再基于确定出的约束项及其约束条件，基于yaml格式编辑修改底层配置文件。

s302：上层后端服务进程读取底层约束项配置文件，并进行语法校验，从而确保整体文件不存在语法错误，符合语法规范；

需要说明的是，在符合语法规范时会转入步骤s303，在不符合时，则会结束本次流程。

s303：将底层约束项配置文件由yaml格式转换为前后端通用的json格式；

s304：将转换后为json格式的底层约束项配置文件发送给前端页面；

s305：前端页面接收后端服务进程发送的json格式并解析，生成约束功能。

在前端页面生成约束功能后，当用户通过前端页面操作产品时，相应的操作将触发相关的约束，如：

控制节点数量小于设定阈值(约束条件为大于等于该阈值)时，将向用户提示该约束条件未满足，并无法进行下一步操作；

节点cpu数量小于设定阈值(约束条件为大于等于该阈值)时，将向用户提示该约束条件未满足，并无法进行下一步操作；

节点网口数量小于设定阈值(约束条件为大于等于该阈值)时，将向用户提示该约束条件未满足，并无法进行下一步操作；

等等。

综上，本实施例的上述方案，通过以底层系统文本格式的配置文件来写入约束条件，就可以直接通过底层配置文件实现对前端页面约束功能的配置。而通过配置文件来实现对约束的配置，无需开发人员投入，仅通过一个交付人员或者运维人员就可以通过文件编辑、修改、调整来完成约束的相关修改调整工作，真正做到使用人员与开发人员的分离，提升了产品的使用便利性，减少了开发时间和故障问题。

实施例三

参见图4所示，图4为本申请实施例提供的一种约束配置装置的基本框图，约束配置装置4包括：文件生成模块41和映射处理模块42。其中：

文件生成模块41，用于生成底层约束项配置文件；其中，

映射处理模块42，用于将底层约束项配置文件映射到前端页面，使得前端页面具有与层约束项配置文件中记录的约束条件对应的约束功能。

应当理解的是，本申请实施例中所生成的底层约束项配置文件是系统配置文件的一种，用于对约束条件进行配置。在本申请实施例中，底层约束项配置文件中记录有约束条件，即在底层约束项配置文件中记录有至少一个约束项及其所应当满足的约束条件到底是什么。例如：在底层约束项配置文件中可以记录有控制节点的数量大于等于3，网络节点的数量大于等于2，计算节点的数量大于等于1，存储节点的数量大于等于3等等。前述示例中，控制节点的数量、网络节点的数量、计算节点的数量、存储节点的数量即为约束项，即约束项为需要进行约束的对象。而“控制节点的数量大于等于3”、“网络节点的数量大于等于2”，“计算节点的数量大于等于1”，“存储节点的数量大于等于3”即为各约束项对应的约束条件。而约束条件即为约束项所需满足的限定条件。

应当理解的是，本申请实施例中的约束项包括但不限于：节点约束项、单节点内的硬件约束项、环境约束项等等。如上述的“控制节点的数量”、“网络节点的数量”、“计算节点的数量”、“存储节点的数量”等即为节点约束项；而单节点内的硬件约束项可以是某个节点的某个或某些硬件条件，如cpu数量、内存数量、磁盘大小、网卡速率、网口数量等等；而环境约束项即是指产品运行环境中所需进行约束的对象，如网关连接情况、外网接通情况、可用节点数量等等。

需要注意的是，根据产品的功能的不同，需要进行配置的约束项，及其对应的约束条件即可能不同。此外，还需要说明的是，还可能存在所需要进行限制的约束项相同，但是约束项的约束条件不同的情况。因此，在本申请实施例中，约束项及具体的约束条件可以由工程师根据实际需求进行确定。

特别需要说明的是，在本申请实施例中可以将不同的约束项的约束条件写入不同的底层约束项配置文件中，从而为每一个约束项都分别生成一个底层约束项配置文件。但是在本申请实施例中，也可以将多个约束项的约束条件写入一个底层约束项配置文件中，这样最终生成的约束项配置文件的个数就会大大降低，从而降低系统文件的冗余度，更有利于系统文件的管理。例如可以将所有约束项的约束条件都写入一个底层约束项配置文件中，这样仅会生成一个底层约束项配置文件，从而极大地降低了系统文件的冗余度。

需要说明的是，在本申请实施例中，可以由工程师按照实际需求编写底层约束项配置文件，从而使得设备按照工程师的编写生成底层约束项配置文件。但是这一方式对于工程师而言工作量较大，为了降低工程师的工作量，本申请实施例中可以预先设定好生成规则，进而工程师只需要告知待配置的约束条件具体是什么，约束配置装置4即可根据预设的生成规则自动生成记录该约束条件的底层约束项配置文件。示例性的，参见图5所示，约束配置装置4还可以包括约束项获取模块43；此时可以预先在约束配置装置4中设定好生成模板，进而在约束项获取模块43获取到待配置的约束条件后，文件生成模块41即可先根据设定好生成模板生成针对该约束条件对应的约束项的模板文件，再将约束条件填充入模板文件中即可得到底层约束项配置文件。这样工程师即只需要根据实际需求确定出需要配置约束项及其对应的约束条件，进而输入约束条件(参见上述对约束条件的示例所示，可见约束条件中可解析出对应的约束项)给设备，设备即可自动生成记录该约束条件的底层约束项配置文件，从而极大地降低了工程师的工作量，提升了工作效率。

应当理解的是，在映射处理模块42将底层约束项配置文件映射到前端页面后，前端页面(如管理页面)在进行产品管控时，即可按照底层约束项配置文件中约束条件的要求来对产品进行监管，在某一个约束不满足时，即会阻止产品进行下一步操作，保证了产品运行的合规性。即，通过将底层约束项配置文件映射到前端页面，即可使得前端页面具有根据约束条件对产品进行约束的功能。

本申请实施例中通过生成底层约束项配置文件，进而将底层约束项配置文件映射到前端页面的方式，使得前端页面能够根据底层约束项配置文件所记录的约束条件来实现对产品的约束，保证了产品运行的合规性，同时实现方式也很简单，不需要前端人员和后端人员的投入，人力成本低，因此本申请实施例所提供的约束配置方案具有很高的实际应用价值。

可选的，在本申请实施例中可以将整个系统分为上层和底层两个部分，例如参见图2所示，上层即用于提供服务，而底层则作为上层的基础，为上层提供配置文件等基础文件，以保证上层的正常运作。在本申请实施例中，上层结构中又分为前端页面和后端服务进程。其中，前端页面用于面向用户提供页面服务，而后端服务进程则用于对前端页面提供支撑，保证前端页面的正常运作。

在本申请实施例中，参见图7所示，映射处理模块42包括：后端服务进程获取模块421和后端服务进程发送模块422；后端服务进程获取模块421可以通过预设的后端服务进程来获取底层约束项配置文件，再由后端服务进程发送模块422将获取到的底层约束项配置文件发送给前端页面，从而实现底层约束项配置文件到前端页面的映射。需要说明的是，本申请实施例中获取底层约束项配置文件发给前端页面的后端服务进程可以是前端页面自身的服务进程，也可以是单独设立的专门用于映射底层约束项配置文件的服务进程。事实上，只要预先设定好哪一个或哪几个后端服务进程可以执行获取底层约束项配置文件发给前端页面即可。还需要说明的是，本申请实施例中映射底层约束项配置文件的前端页面也是预先设定好的，例如可以为管理页面，对于桌面、开机页面等则可以不用进行映射。

在本申请实施例中，参见图7所示，映射处理模块42还可以包括：格式转换模块423；后端服务进程获取模块421通过后端服务进程获取到底层约束项配置文件之后，后端服务进程发送模块422将获取到的底层约束项配置文件发送给前端页面之前，格式转换模块423还可以对底层约束项配置文件进行格式转换，将其转换为前端页面所能识别的格式。进而后端服务进程发送格式转换后的底层约束项配置文件发送给前端页面，从而保证前端页面可以进行有效的识别，保证了映射的成功率。

示例性的，本申请实施例中可以预先设定好待转换的格式(如json格式)，进而将底层约束项配置文件的格式转换为该待转换的格式。而待转换的格式应当为前端页面所能识别的格式。

在本申请实施例中，参见图7所示，映射处理模块42还可以包括：校验模块424；后端服务进程获取模块421通过后端服务进程获取到底层约束项配置文件之后，后端服务进程发送模块422将获取到的底层约束项配置文件发送给前端页面之前，校验模块424还可以对底层约束项配置文件进行语法校验，在语法校验通过后才发送底层约束项配置文件给前端页面。而如果语法校验未通过，则表明该底层约束项配置文件可能存在一定的语法错误，为了避免后续的无法识别或识别后无法执行甚至造成系统混乱的情况的出现，则不会发送底层约束项配置文件给前端页面。可选的，在语法校验未通过时，还可以发送用于提示该底层约束项配置文件语法错误的提示信息，从而提示用户对该底层约束项配置文件进行修改。需要说明的是，在本申请实施例中提示方式包括但不限于页面弹框提示、音频提示、警报灯提示等。

应当理解的是，上述预设的后端服务进程对于语法的校验方案和上述预设的后端服务进程对底层约束项配置文件进行格式转换的方案可以同时被采用。当然，也可以仅采用其中一种方案，如不进行语法校验等。

需要说明的是，在本申请实施例中，语法可以采用自定义的语法来实现，从而提供给使用者一种简单语法编辑能力，保证底层约束项配置文件可以具有较高的可编辑性。当然，在本申请实施例中也可以将传统语法来实现。

还需要说明的是，在本申请实施例中，可以基于yaml格式、json格式、xml格式等格式来生成底层约束项配置文件。值得注意的是，在基于yaml格式生成底层约束项配置文件时，其语法校验时较为容易，便于机器实现。而基于json格式生成底层约束项配置文件时，由于json格式是页面可识别的格式，因此可以不需要进行格式转换，可以简化机器的执行流程。

应当理解的是，在实际应用过程中，可能会存在需要对约束条件进行修改的情况。在本申请实施例中，底层约束项配置文件会提供修改和编辑的权限，从使得用户可以通过对底层约束项配置文件的修改来实现对前端页面的约束功能的修改。

示例性的，参见图6所示，约束配置装置4还可以包括：修改数据获取模块44和文件修改模块45。在将底层约束项配置文件映射到前端页面之后，修改数据获取模块44可以获取针对底层约束项配置文件的修改数据(修改数据可以由用户根据实际需要输入)，然后文件修改模块45根据修改数据修改底层约束项配置文件，得到经修改底层约束项配置文件，进而映射处理模块42再将经修改底层约束项配置文件映射到前端页面，从而实现对前端页面的约束功能的修改。需要说明的是，将经修改底层约束项配置文件映射到前端页面的过程，和将底层约束项配置文件映射到前端页面的过程一致，在此不再赘述。

应当明晰的是，基于相关技术中对约束的配置方式，在需要进行约束功能的修改时，也需要前端人员和后端人员的共同配合才能实现，对于人员有着特殊要求，同时还涉及到多方人员的协调配合，十分不便。而基于本申请实施例所提供的约束配置方法，可以直接对底层约束项配置文件进行修改，进而将修改后的底层约束项配置文件(即经修改底层约束项配置文件)映射到前端页面，即可实现对约束功能的修改，修改方式简单易操作，可行性高，同时还不需要前端人员和后端人员的投入，仅通过一个交付人员或者运维人员就可以实现对约束功能的修改工作，真正做到使用人员与开发人员的分离，人力成本低，便利性高，因此本申请实施例所提供的约束配置方案具有很高的实际应用价值。

在本申请实施例中，参见图7所示，约束配置装置4还可以包括：检测模块46和提示模块47；

检测模块46可以对约束条件是否满足进行检测，进而在检测到底层约束项配置文件中的某一约束条件未满足时，提示模块47即发送用于提示该约束条件未被满足的提示信息。这样，通过自动提醒，用户即可知道具体是哪一个约束条件未满足，从而方便用户进行问题定位，进而进行后续的调整。避免在出现问题之后还需要用户手动去筛查具体是什么约束条件未满足的情况的发生，提升了用户体验。需要说明的是，在本申请实施例中提示方式包括但不限于页面弹框提示、音频提示、警报灯提示等。

综上所述，本申请实施例提供一种约束配置装置，通过生成记录有约束条件的底层约束项配置文件，进而将底层约束项配置文件映射到前端页面上，从而使得前端页面与底层约束项配置文件关联。这样前端页面在进行管控时，则会按照底层约束项配置文件中的约束条件进行管控，即前端页面会具有与底层约束项配置文件相应的约束功能。通过上述实现过程，只需要将约束条件写成底层约束项配置文件形式，再将底层约束项配置文件映射到前端页面即可实现对约束条件的配置，整个过程十分简单，同时也不需要前端人员和后端人员的投入，降低了人力成本。此外，本申请实施例所提供得约束配置方法可以直接对底层约束项配置文件进行修改，进而将修改后的底层约束项配置文件映射到前端页面，即可实现对前端页面约束功能的修改。修改方式简单易操作，可行性高，同时还不需要前端人员和后端人员的投入，仅通过一个交付人员或者运维人员就可以实现对约束功能的修改工作，真正做到使用人员与开发人员的分离，人力成本低，便利性高，具有很高的实际应用价值。

实施例四

本实施例提供了一种电子设备，参见图8所示，其包括处理器801、存储器802以及通信总线803。其中：

通信总线803用于实现处理器801和存储器802之间的连接通信。

处理器801用于执行存储器802中存储的一个或多个程序，以实现上述实施例一和/或实施例二中约束配置方法的各步骤。

可以理解，图8所示的结构仅为示意，电子设备还可包括比图8中所示更多或者更少的组件，或者具有与图8所示不同的配置。

本实施例还提供了一种计算机可读存储介质，如软盘、光盘、硬盘、闪存、u盘、cf卡、sd卡、mmc卡等，在该计算机可读存储介质中存储有实现上述各个步骤的一个或者多个程序，这一个或者多个程序可被一个或者多个处理器执行，以实现上述第一实施例和/或第二实施例中云平台切换控制方法的各步骤。在此不再赘述。

在本申请所提供的几个实施例中，应该理解到，所揭露的装置和方法，也可以通过其它的方式实现。以上所描述的装置实施例仅仅是示意性的，例如，附图中的流程图和框图显示了根据本申请的多个实施例的装置、方法和计算机程序产品的可能实现的体系架构、功能和操作。在这点上，流程图或框图中的每个方框可以代表一个模块、程序段或代码的一部分，所述模块、程序段或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意，在有些作为替换的实现方式中，方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如，两个连续的方框实际上可以基本并行地执行，它们有时也可以按相反的顺序执行，这依所涉及的功能而定。也要注意的是，框图和/或流程图中的每个方框、以及框图和/或流程图中的方框的组合，可以用执行规定的功能或动作的专用的基于硬件的系统来实现，或者可以用专用硬件与计算机指令的组合来实现。

另外，在本申请各个实施例中的各功能模块可以集成在一起形成一个独立的部分，也可以是各个模块单独存在，也可以两个或两个以上模块集成形成一个独立的部分。

所述功能如果以软件功能模块的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本申请各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：u盘、移动硬盘、只读存储器(rom，read-onlymemory)、随机存取存储器(ram，randomaccessmemory)、磁碟或者光盘等各种可以存储程序代码的介质。

以上所述仅为本申请的实施例而已，并不用于限制本申请的保护范围，对于本领域的技术人员来说，本申请可以有各种更改和变化。凡在本申请的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本申请的保护范围之内。应注意到：相似的标号和字母在下面的附图中表示类似项，因此，一旦某一项在一个附图中被定义，则在随后的附图中不需要对其进行进一步定义和解释。

以上所述，仅为本申请的具体实施方式，但本申请的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本申请揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本申请的保护范围之内。因此，本申请的保护范围应所述以权利要求的保护范围为准。

需要说明的是，在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。