CN119363810A - 业务部署方法、云管理平台和相关装置 - Google Patents

Abstract

本申请公开了一种业务部署方法、云管理平台和相关装置，属于云计算技术领域。所述方法包括：提供配置界面，从配置界面获取业务配置信息，基于该业务配置信息和业务副本数量，确定目标业务的资源部署策略，并按照该资源部署策略，在该多个业务单元上部署目标业务，该资源部署策略指示一个业务单元承载有租户的至少一个用户组，且每Rf个业务单元承载有一个相同的用户组的业务副本，Rf为业务副本数量。对于任意一个用户组中的任意一个用户来说，即使承载该用户的一个业务单元故障，该用户还能够从其他的业务单元获取相应业务，从而有效提高目标业务的容灾能力。

Description

业务部署方法、云管理平台和相关装置

本申请要求于2023年7月24日提交的申请号为202310911636.0、发明名称为“一种架构划分方法、装置及系统”的中国专利申请的优先权，其全部内容通过引用结合在本申请中。

技术领域

本申请涉及云计算技术领域，特别涉及一种业务部署方法、云管理平台和相关装置。

背景技术

随着信息技术的不断发展，尤其是互联网技术的进步，大型政企和金融单位开始逐步构建自身的数据中心来满足其业务对资源的需求。由于单纯依靠增加物理设备来构建数据中心的代价非常昂贵，因此，云计算应运而生。云服务提供商能够通过云计算技术构建云平台，该云平台包括云管理平台和云基础设施，该云管理平台用于管理云基础设施，云基础设施包括至少一个云数据中心，租户能够在该至少一个云数据中心上部署相应业务。

在相关技术中，为了保证业务的可用性，租户需要在至少一个云数据中心上部署多个相互独立、业务功能相同的业务单元，每个业务单元具备完整的业务功能。这样，在接收到某个业务请求之后，按照设定的规则，将该业务请求路由至相应的业务单元来处理。例如，根据该业务所服务的用户与业务单元的对应关系，将某个用户的业务请求路由至相应业务单元进行处理。

但是，一个业务单元可能对应多个用户，若该业务单元由于过载或者分布式拒绝服务(Distributed Denial of Service，DDOS)攻击等原因产生故障，则会导致该业务单元对应的多个用户无法使用该业务，使得该业务的容灾能力较差。

发明内容

本申请提供了一种业务部署方法、云管理平台和相关装置，可以解决相关技术中业务容灾能力差的问题。所述技术方案如下：

第一方面，提供了一种业务部署方法，应用于云管理平台，所述云管理平台用于管理云基础设施，所述云基础设施包括至少一个云数据中心，所述至少一个云数据中心部署有多个业务单元，所述方法包括：

提供配置界面，所述配置界面用于指示租户输入待部署的所述目标业务的业务配置信息，所述业务配置信息用于配置所述目标业务；从所述配置界面获取所述业务配置信息；基于所述业务配置信息和业务副本数量，确定所述目标业务的资源部署策略，并按照所述资源部署策略，在所述多个业务单元上部署所述目标业务，其中，所述资源部署策略指示一个所述业务单元承载有所述租户的至少一个用户组，且每Rf个所述业务单元承载有一个相同的用户组的业务副本，Rf为所述业务副本数量，Rf≥2。

本申请能够根据租户输入的目标业务的业务配置信息和业务副本数量，确定该目标业务的资源部署策略，进而按照该资源部署策略，在多个业务单元上部署该目标业务。由于业务副本数量大于或等于2，该资源部署策略指示该一个业务单元承载有该租户的至少一个用户组，并且每Rf个业务单元承载有一个相同的用户组的业务副本，Rf为业务副本数量。也就是说，业务单元能够为该租户的至少一个用户组提供服务，每个用户组能够由至少两个业务单元进行承载，在这种情况下，对于任意一个用户组中的任意一个用户来说，即使承载该用户的一个业务单元故障，该用户还能够从其他的业务单元获取相应业务，相较于一个业务单元故障，而导致该业务单元所服务的用户都无法正常获取服务的方法来说，本申请所提供的方法能够有效提高目标业务的容灾能力。

云管理平台能够通过提供配置界面来指示租户输入待部署的目标业务的业务配置信息，进而租户能够在该配置界面输入目标业务的业务配置信息。

可选地，该业务配置信息包括微服务的最小启动节点数量、微服务的最小启动规格、最大资源量、业务性能参数、最大爆炸半径、微服务的性能基线中的一者或多者，该最大资源量指示目标业务所能占用的资源上限，该业务性能参数指示目标业务的性能下限，该最大爆炸半径指示目标业务的容灾能力的下限，该性能基线指示微服务的启动规格、启动节点数量与性能参数的对应关系。

可选地，该配置界面还用于指示租户输入业务副本数量，进而租户能够在该配置界面输入业务副本数量，对于租户的任意一个用户组来说，该业务副本数量为租户期望的承载该用户组的业务单元的数量，该业务副本数量大于或者等于2。

在本申请中，业务单元能够为该租户的至少一个用户组提供服务，每个用户组由至少两个业务单元进行承载，在这种情况下，对于任意一个用户组中的任意一个用户来说，即使承载该用户的一个业务单元故障，该用户还能够从其他的业务单元获取相应业务，相较于一个业务单元故障，而导致该业务单元所服务的用户都无法正常获取服务的方法来说，本申请的方法能够有效提高目标业务的容灾能力。

可选地，该资源部署策略指示用户组的Rf个业务副本各自部署在独立的业务单元上，每Rf个业务单元最多承载有一个相同的用户组的业务副本。

上述每Rf个业务单元最多承载有一个相同的用户组的业务副本也可以理解为任意Rf个业务单元上仅部署有一个相同的用户组对应的业务副本。

由于每Rf个业务单元最多承载有一个相同的用户组的业务副本，对于租户的任意一个用户组来说，若承载该用户组的任意一个业务单元故障，则该用户组还能够从其他的业务单元中获取相应的服务，只有承载该用户组的所有业务单元都产生故障才会导致该用户组无法获取服务，从而对目标业务的正常运行产生影响。而由于承载该用户组的业务单元所承载的其他用户组还被其他的业务单元承载，因此，即使承载该用户组的所有业务单元都产生故障，这些其他用户组还能够从其他的业务单元中获取服务。

可选地，资源部署策略包括用于提供目标业务的业务单元的数量和业务单元的部署规格，该用于提供目标业务的各个业务单元的规格和性能相同。在这种情况下，基于业务配置信息和业务副本数量，确定该目标业务的资源部署策略的实现过程包括：基于目标业务的业务配置信息和业务副本数量，按照资源部署约束条件，确定用于提供目标业务的业务单元的数量和业务单元的部署规格。

其中，该资源部署约束条件包括微服务的最小启动节点数量、微服务的最小启动规格、最大资源量、业务性能参数、最大爆炸半径、业务副本数量、微服务的性能基线中的一者或多者，该最大资源量指示目标业务所能占用的资源上限，该业务性能参数指示目标业务的性能下限，该最大爆炸半径指示目标业务的容灾能力的下限，该性能基线指示微服务的启动规格、启动节点数量与性能参数的对应关系。

由于最大资源量指示该目标业务所能占用的资源上限，业务性能参数指示该目标业务的性能下限，最大爆炸半径指示该目标业务的容灾能力的下限，因此，按照资源部署约束条件能够保证目标业务的所占用的资源不超过该最大资源量的同时，保证该目标业务的性能不低于业务性能参数，以及目标业务的容灾能力优于或等于该最大爆炸半径指示的容灾能力。也就是说，本申请在资源部署约束条件的约束下，确定的目标业务的资源部署策略能够兼顾目标业务的业务性能、容灾能力和资源成本，使得目标业务在最大资源量不变的情况下，相比于相关技术能够具有更小的爆炸半径以及更优的性能。

可选地，基于目标业务的业务配置信息和业务副本数量，按照资源部署约束条件，确定多个候选资源部署策略，该候选资源部署策略包括业务单元的候选数量和业务单元的候选部署规格；从该多个候选资源部署策略中选择一个候选资源部署策略，将选择的候选资源部署策略包括的业务单元的候选数量和候选部署规格作为目标业务的资源部署策略包括的业务单元的数量和部署规格。

可选地，该候选部署规格包括业务单元中用于提供目标业务的至少一个微服务分别对应的启动节点数量和启动规格，该资源部署约束条件满足下述的不等式：

其中，在上述不等式中，i是指第i个微服务，minnum_i是指第i个微服务的最小启动节点数量，num_i是指候选部署规格中第i个微服务的启动节点数量，mins_i是指第i个微服务的最小启动规格，s_i是指候选部署规格中第i个微服务的启动规格，S是指最大资源量，n是指业务单元中该至少一个微服务的数量，N是指业务单元的候选数量，mint(j)是指候选部署规格中第j个微服务的启动规格和启动节点数量对应的性能参数最小，T是指业务性能参数，B是指最大爆炸半径，Rf是指业务副本数量，X_i是指第i个微服务的性能基线。

在微服务的启动规格包括计算资源规格、内存资源规格和最大硬盘资源规格，最小启动规格包括最小计算资源规格、最小内存资源规格和最小硬盘资源规格，最大资源量包括最大计算资源量、最大内存资源量和最大硬盘资源量的情况下，上述不等式中mins_i≤s_i是指第i个微服务的最小计算资源规格小于或等于候选部署规格中第i个微服务的计算资源规格、第i个微服务的最小内存资源规格小于或等于候选部署规格中第i个微服务的内存资源规格、并且第i个微服务的最小硬盘资源规格小于或等于候选部署规格中第i个微服务的硬盘资源规格。

同理，上述不等式中s_inum_i≤S是指候选部署规格中第i个微服务的计算资源规格与第i个微服务的启动节点数量之积小于等于最大计算资源量、候选部署规格中第i个微服务的内存资源规格与第i个微服务的启动节点数量之积小于等于最大内存资源量、并且候选部署规格中第i个微服务的硬盘资源规格与第i个微服务的启动节点数量之积小于等于最大硬盘资源量。

对于任意一个候选部署规格来说，该候选部署规格包括业务单元中每个微服务分别对应的启动节点数量和启动规格。由于微服务的启动规格和启动节点数量与性能参数存在对应关系，因此，每个微服务还分别对应相应的性能参数。而对于业务单元来说，该业务单元的性能实际上是由该业务单元中性能参数最小的微服务决定的，因此，若该业务单元中性能参数最小的微服务的性能参数都大于或等于N分之T，则能够保证该N个业务单元的性能之和(即目标业务的性能)不低于该业务性能参数(T)。

需要说明的是，上述业务副本数量不大于业务单元的数量。

可选地，该业务配置信息包括爆炸半径权重和资源权重，在这种情况下，可以基于该爆炸半径权重和资源权重，从多个候选资源部署策略中选择一个候选资源部署策略。

可选地，可以基于该爆炸半径权重和资源权重，从多个候选资源部署策略中选择第q个候选资源部署策略作为目标业务的资源部署策略，该第q个候选资源部署策略满足如下公式(1)-(3)。

min(α₁A_q+α₂R_q)q∈1,…,z(1)

其中，在上述公式(1)-(3)中，min()是指取括号内的最小值，α₁是指资源权重，α₂是指爆炸半径权重，z是指候选资源部署策略的数量，q是指多个候选资源部署策略中第q个候选资源部署策略。f()是指对括号内的数进行归一化，qN是指该第q个候选资源部署策略中业务单元的候选数量，s_qi是指第q个候选资源部署策略中第i个微服务的启动规格，num_qi是指第q个候选资源部署策略中第i个微服务的启动节点数量，n是指业务单元中该至少一个微服务的数量，Rf是指业务副本数量。

在实际应用中，基于目标业务的业务配置信息和业务副本数量，确定目标业务的资源部署策略之后，云管理平台还能够显示业务部署建议界面，该业务部署建议界面用于显示该目标业务的资源部署策略。

可选地，该业务部署建议界面还用于显示资源消耗情况和实际爆炸半径中的至少一个，该资源消耗情况指示目标业务的资源部署策略所占用的资源量，该实际爆炸半径指示基于该目标业务的资源部署策略所部署的目标业务的容灾能力。

可选地，该业务部署建议界面还用于指示租户触发业务部署请求，在按照该资源部署策略，在多个业务单元上部署目标业务之前，云管理平台还能够接收该业务部署请求，该业务部署请求用于指示云管理平台按照该业务部署建议界面显示的资源部署策略部署目标业务。

也就是说，在显示该目标业务的资源部署策略之后，租户还能够在该业务部署建议界面触发业务部署请求，该云管理平台还能够接收该租户触发的业务部署请求，从而按照该资源部署策略，在多个业务单元上部署目标业务。

在实际应用中，该业务配置信息还包括用户特征信息，在这种情况下，云管理平台还能够获取用户特征信息，该用户特征信息为租户的用户组中的多个用户的特征信息，该特征信息包括风险特征信息，该风险特征信息是指易导致业务出现故障的特征，基于该多个用户的风险特征信息，从该多个用户中确定至少一个风险用户，对该至少一个风险用户进行分组，得到该至少一个风险用户分别所属的风险用户组，基于该多个用户中常规用户的特征信息，对常规用户进行分组，得到该常规用户分别所属的常规用户组，该常规用户为多个用户中除风险用户之外的用户。

由于该风险特征信息是指易导致业务出现故障的特征，因此，根据该多个用户的风险特征信息能够准确地从多个用户中确定出容易导致业务出现问题的用户，即风险用户，进而对该风险用户和常规用户分别确定所属的用户组，这样，能够将风险用户和常规用户划分至不同的用户组，从而最大程度上避免风险用户对常规用户的影响，有效提升目标业务对常规用户的服务质量。

可选地，该特征信息包括用户风险特征标签。该用户风险特征标签包括历史故障子标签和异常流量子标签中的至少一个子标签。其中，历史故障表征用户的流量导致目标业务产生故障的次数，或者，为表征用户无法获取目标业务的次数。异常流量子标签表征用户的异常流量产生的次数。

可选地，该风险特征信息包括至少一个风险子标签，以及每个风险子标签对应的风险子标签权重。在特征信息包括用户风险特征标签的情况下，该至少一个风险子标签为上述用户风险特征标签中历史故障子标签和异常流量子标签中的至少一个。

基于该多个用户的风险特征信息，从该多个用户中确定至少一个风险用户的实现过程包括：基于该多个用户的风险特征信息，确定该多个用户分别对应的风险特征分数，按照从高到底的顺序对多个用户的风险特征分数进行排序，将排序结果的前百分之p的风险特征分数对应的用户作为该至少一个风险用户。

可选地，该资源部署策略包括业务单元的数量，云管理平台能够基于业务单元的数量和业务副本数量，确定用户分组数量。在这种情况下，基于该多个用户中常规用户的特征信息，对常规用户进行分组的实现方式包括：基于风险用户组的数量、用户分组数量和常规用户的特征信息，对该常规用户进行分组。

可选地，基于目标业务的业务单元的数量和业务副本数量，按照如下公式(4)，确定用户分组数量。

其中，在上述公式(4)中，T是指用户分组数量，N是指业务单元的数量，Rf是指业务副本数量。

可选地，基于常规用户的特征信息，确定常规用户的特征向量，基于常规用户的特征向量，对常规用户进行聚类，得到多个常规用户簇，基于该多个常规用户簇和常规组数量，确定该常规用户分别所属的常规用户组，该常规组数量为用户分组数量与风险用户组的数量的差值。

可选地，该特征信息还包括用户价值特征标签、用户需求特征标签和用户流量特征标签中的至少一个特征标签，以及每个特征标签对应的特征标签权重。该常规用户的特征向量包括至少一个元素，该至少一个元素与该特征信息包括的特征标签一一对应。对于任意一个常规用户来说，基于该常规用户的目标特征标签，确定该常规用户的特征向量中该目标特征标签对应的元素的值，该目标特征标签为该至少一个特征标签中的任意一个。按照相同的方式对每个常规用户都进行处理，能够得到每个常规用户的特征向量。

基于多个常规用户簇和常规组数量，确定该常规用户分别所属的常规用户组的实现过程包括：将每个常规用户簇的常规用户随机划分为K组，以得到每个常规用户簇分别包括的K个子簇，K等于该常规组数量，基于该每个常规用户簇分别包括的K个子簇，确定常规用户分别所属的常规用户组。

基于该每个常规用户簇分别包括的K个子簇，确定常规用户分别所属的常规用户组的实现过程包括：令g＝1，从多个常规用户簇包括的子簇中分别随机选择一个子簇，以得到多个子簇，将该多个子簇中的常规用户作为第g个常规用户组中的用户，从该多个常规用户簇中删除该多个子簇，若g小于常规用户组数量，则令g＝g+1，并返回上述从多个常规用户簇包括的子簇中分别随机选择一个子簇，以得到多个子簇的步骤。

对于任意一个常规用户组来说，通过上述方法能够保证该常规用户组中的用户包括每个常规用户簇中的一部分用户。由于常规用户簇中用户的特征是相近的，而不同常规用户簇的用户具有不同的特征，因此，这样能够保证最终确定常规用户组中包括不同的特征用户，从而实现对常规用户的均匀分组。

在实际应用中，也可以无需确定风险用户，直接基于该用户分组数量和该租户的多个用户的特征信息，对该多个用户进行分组来得到该多个用户分别所属的用户组。

可选的，基于该多个用户的特征信息，分别确定该多个用户的特征向量，进而基于该多个用户的特征向量，对该多个用户进行聚类，得到多个用户簇，基于用户分组数量和该多个用户簇，确定该多个用户分别所属的用户组。

第二方面，提供了一种业务部署装置，所述业务部署装置具有实现上述第一方面中业务部署方法行为的功能。所述业务部署装置包括至少一个模块，该至少一个模块用于实现上述第一方面所提供的业务部署方法。

第三方面，提供了一种计算设备集群，所述计算设备集群包括至少一个计算设备，每个计算设备包括处理器和存储器，所述至少一个计算设备的处理器用于执行所述至少一个计算设备的存储器中存储的指令，以使得所述计算设备集群执行第一方面所述的业务部署方法。

可选地，每个计算设备还可以包括通信总线，该通信总线用于每个计算设备的处理器与存储器之间建立连接。

第四方面，提供了一种计算机可读存储介质，所述存储介质包括计算机程序指令，当所述计算机程序指令由计算设备集群执行时，使得计算设备集群执行上述第一方面所述的业务部署方法的步骤。

第五方面，提供了一种包含指令的计算机程序产品，当所述指令被计算设备集群运行时，使得所述计算设备集群执行上述第一方面所述的业务部署方法的步骤。

上述第二方面、第三方面、第四方面和第五方面所获得的技术效果与第一方面中对应的技术手段获得的技术效果近似，在这里不再赘述。

附图说明

图1是本申请实施例提供的一种业务单元的示意图；

图2是本申请实施例提供的一种实施环境的示意图；

图3是本申请实施例提供的一种云管理平台的示意图；

图4是本申请实施例提供的一种业务部署方法的流程图；

图5是本申请实施例提供的一种配置界面的示意图；

图6是本申请实施例提供的一种目标业务的部署方式的示意图；

图7是本申请实施例提供的一种部署建议界面的示意图；

图8是本申请实施例提供的另一种目标业务的部署方式的示意图；

图9是本申请实施例提供的一种业务部署装置的结构示意图；

图10是本申请实施例提供的一种计算机设备的结构示意图；

图11是本申请实施例提供的一种计算设备集群的架构图；

图12是本申请实施例提供的一种计算设备之间的连接示意图。

具体实施方式

为使本申请实施例的目的、技术方案和优点更加清楚，下面将结合附图对本申请实施方式作进一步地详细描述。

为了便于理解，在对本申请实施例提供的业务部署方法进行详细地解释说明之前，先对本申请实施例涉及的应用场景以及实施环境进行介绍。

首先对本申请实施例涉及的应用场景进行介绍。

随着信息技术的不断发展，尤其是互联网技术的进步，大型政企和金融单位开始逐步构建自身的数据中心来满足其业务对资源的需求。由于单纯依靠增加物理设备来构建数据中心的代价非常昂贵，因此，云计算应运而生。云服务提供商能够通过云计算技术构建云平台，该云平台包括云管理平台和云基础设施，该云管理平台用于管理云基础设施，云基础设施包括至少一个云数据中心，租户能够在该至少一个云数据中心上部署相应业务。

在相关技术中，为了保证业务的可用性，租户需要在至少一个云数据中心上部署多个相互独立、业务功能相同的业务单元，每个业务单元具备完整的业务功能。这样，在接收到某个业务请求之后，按照设定的规则，将该业务请求路由至相应的业务单元来处理。例如，设置该业务所服务的用户与业务单元的对应关系，进而根据发送业务请求的用户确定对应的业务单元，将该业务请求路由至相应业务单元进行处理。示例地，请参考图1，某个业务所服务的用户分别为用户1至用户12，业务单元的数量为4个，分别为业务单元1至业务单元4，其中，业务单元1对应用户1至用户3，业务单元2对应用户4至用户6，业务单元3对应用户7至用户9，业务单元4对应用户10至用户12。在这种情况下，若接收到用户1发送的业务请求之后，能够将该业务请求发送给该用户1对应的业务单元1进行处理。

但是，在上述方法中，一个业务单元可能对应多个用户，若该业务单元由于过载或者DDOS攻击等原因产生故障，则会导致该业务单元对应的多个用户无法使用该业务，使得该业务的容灾能力较差。以上述业务单元1为例，该业务单元1对应用户1至用户3，若该业务单元1产生故障，则该业务单元1服务的用户1、用户2和用户3都无法使用该业务。

为了便于描述，后续以爆炸半径(也称为故障半径)来表征该业务的容灾能力，爆炸半径越大表示该业务的容灾能力越差，爆炸半径越小表示该业务的容灾能力越强。

在流量均匀的场景下，也即是，在各个用户发送的业务请求的数量和速度均相同且稳定的情况下，若一个业务单元故障，采用上述方式会导致该业务单元所服务的用户都无法正常获取服务，因此，该方法的爆炸半径是以业务单元为粒度的，该方法的爆炸半径为N分之一，N为业务单元的数量，也即是，一个业务单元故障会对N分之一的业务产生影响。

基于此，本申请实施例提出了一种业务部署方法，能够根据租户输入的目标业务的业务配置信息和业务副本数量，确定该目标业务的资源部署策略，进而按照该资源部署策略，在多个业务单元上部署该目标业务。由于业务副本数量大于或等于2，该资源部署策略指示该一个业务单元承载有该租户的至少一个用户组，并且每Rf个业务单元承载有一个相同的用户组的业务副本，Rf为业务副本数量。也就是说，业务单元能够为该租户的至少一个用户组提供服务，每个用户组能够由至少两个业务单元进行承载，在这种情况下，对于任意一个用户组中的任意一个用户来说，即使承载该用户的一个业务单元故障，该用户还能够从其他的业务单元获取相应业务，相较于一个业务单元故障，而导致该业务单元所服务的用户都无法正常获取服务的方法来说，本申请实施例所提供的方法能够有效提高目标业务的容灾能力。

接下来对本申请实施例涉及的实施环境进行介绍。

请参考图2，图2是本申请实施例提供的一种实施环境的示意图。该实施环境包括租户侧01和服务侧(即云平台)02，该云平台包括云管理平台21和云基础设施22，该云管理平台用于管理云基础设施，该云基础设施包括至少一个云数据中心，该至少一个云数据中心部署有多个业务单元。

云管理平台21能够提供配置界面，并显示给租户侧01，该配置界面用于指示租户输入待部署的目标业务的业务配置信息，云管理平台21能够从该配置界面获取目标业务的业务配置信息，进而基于该业务配置信息和业务副本数量，确定该目标业务的资源部署策略，并且按照该资源部署策略在该多个业务单元上部署该目标业务，该资源部署策略指示一个业务单元承载有租户的至少一个用户组，且每Rf个业务单元承载有一个相同的用户组的业务副本。

请参考图3，图3是本申请实施例提供的一种云管理平台的示意图，该云管理平台包括资源规划单元301、部署单元302和业务单元303。

其中，资源规划单元301能够从配置界面获取租户输入的待部署的目标业务的业务配置信息，并且基于目标业务的业务配置信息和业务副本数量，确定该目标业务的资源部署策略。部署单元302能够基于该目标业务的资源部署策略，在多个业务单元上部署该目标业务。在将该目标业务部署完成之后，能够通过业务单元303为租户的用户提供服务。

可选地，该云管理平台还包括监测单元304，该监测单元304用于在业务单元303为租户的用户提供服务的过程中，对用户流量数据以及目标业务的运行性能进行监测。在一些实施例中，该监测单元304将目标业务的运行性能反馈给租户，租户能够根据该目标业务的运行性能重新对该业务配置信息进行设置。

在一种可能的实现方式中，该云管理平台还包括用户组划分单元305，该用户组划分单元305能够获取用户特征信息，该用户特征信息为租户的用户组中的多个用户的特征信息，该特征信息包括风险特征信息，该风险特征信息是指易导致业务出现故障的特征，进而基于该多个用户的风险特征信息，从多个用户中确定至少一个风险用户，对该至少一个风险用户进行分组，得到该至少一个风险用户分别所属的风险用户组，基于该多个用户中常规用户的特征信息，对该常规用户进行分组，得到该常规用户分别所属的常规用户组，该常规用户为该多个用户中除风险用户之外的用户，最终得到租户的用户组的分组情况。为了便于描述，后续将该用户分组情况称作用户分组策略。在这种情况下，该部署单元302能够基于该目标业务的资源部署策略以及该用户分组策略，在多个业务单元上部署该目标业务。

在一些实施例中，该云管理平台还包括业务部署建议单元306，该业务部署建议单元306能够显示业务部署建议界面，该业务部署建议界面用于显示目标业务的资源部署策略。可选地，该业务部署建议界面还能够显示用户分组策略。

在一些实施例中，该业务部署建议界面还用于指示租户触发业务部署请求。在这种情况下，该业务部署建议单元306能够接收该业务部署请求，进而按照该业务部署建议界面显示的资源部署策略部署目标业务。

可选地，在云管理平台还包括用户组划分单元305的情况下，该监测单元304还能够基于监测到的用户流量数据，对上述用户特征信息进行更新。

本申请实施例提供的业务部署方法的执行主体为云平台包括的云管理平台，该云平台可以是由多台物理服务器组成的服务器集群或者分布式系统等，还可以是提供云服务、云数据库、云计算、云函数、云存储、网络服务、云通信、中间件服务、域名服务、安全服务、内容分发网络(content delivery network，CDN)、以及大数据和人工智能平台等基础云计算服务的云服务器，或者是一个云计算服务中心。

本领域技术人员应能理解上述云平台、云管理平台和云基础设施仅为举例，其他现有的或今后可能出现的云平台、云管理平台和云基础设施如可适用于本申请实施例，也应包含在本申请实施例保护范围以内，并在此以引用方式包含于此。

需要说明的是，本申请实施例描述的应用场景以及实施环境是为了更加清楚的说明本申请实施例的技术方案，并不构成对于本申请实施例提供的技术方案的限定，本领域普通技术人员可知，随着技术的演变和新应用场景的出现，本申请实施例提供的技术方案对于类似的技术问题，同样适用。

图4是本申请实施例提供的一种业务部署方法的流程图，该方法应用于云管理平台，该云管理平台用于管理云基础设施，该云基础设施包括至少一个云数据中心，该至少一个云数据中心部署有多个业务单元。请参考图4，该方法包括如下步骤。

步骤401：提供配置界面，该配置界面用于指示租户输入待部署的目标业务的业务配置信息，该业务配置信息用于配置目标业务。

云管理平台能够通过提供配置界面来指示租户输入待部署的目标业务的业务配置信息，进而租户能够在该配置界面输入目标业务的业务配置信息。

在一些实施例中，该业务配置信息包括微服务的最小启动节点数量、微服务的最小启动规格、最大资源量、业务性能参数、最大爆炸半径、微服务的性能基线中的一者或多者，该最大资源量指示目标业务所能占用的资源上限，该业务性能参数指示目标业务的性能下限，该最大爆炸半径指示目标业务的容灾能力的下限，该性能基线指示微服务的启动规格、启动节点数量与性能参数的对应关系。

需要说明的是，本申请实施例中的业务单元包括至少一个节点，每个节点可以由一个物理服务器的部分或全部构成，本申请实施例对此不做限定。

在实际应用中，根据不同的业务需求，该目标业务的微服务可能为分布式微服务，也可能为集中式微服务。对于任意一个业务单元来说，该分布式微服务是指微服务分布在该业务单元上的多个节点上，集中式微服务是指微服务分布在该业务单元的一个节点上。上述最小启动节点数量是指微服务在该业务单元上最少需要分布的节点的数量。

示例地，若用于提供目标业务的微服务包括数据库(Data Base，DB)微服务，该DB微服务为分布式微服务，在这种情况下，该DB微服务能够通过分布式存储技术，将数据中心中的多个物理服务器上分散的存储资源构成一个虚拟的存储设备，共同对外提供数据存储功能。若该DB微服务最小启动节点数量为2，则说明该DB微服务最少需要分布在业务单元的2个节点上。

可选地，该微服务的最小启动规格是指微服务在目标节点上的最小规格，该目标节点为微服务所分布的至少一个节点中的任意一个节点。该最小启动规格包括最小计算资源规格、最小内存资源规格和最小硬盘资源规格。

示例地，若用于提供目标业务的微服务包括应用程序编程接口(applicationprogramming interface，API)微服务和DB微服务。该API微服务的最小启动规格为4U8G50G，也即是，该API微服务在目标节点上的最小计算资源规格为4个中央处理器(central processing unit，CPU)核心，最小内存资源规格为8吉字节(gigabyte，GB)，最小硬盘资源规格为50G。该DB微服务的最小启动规格为32U128G1000G，也即是，该API微服务在目标节点上的最小计算资源规格为32个CPU核心，最小内存资源规格为128GB，最小硬盘资源规格为1000G。

可选地，最大资源量包括最大计算资源量、最大内存资源量和最大硬盘资源量。

示例地，该最大资源量可以为800U3200G100T，也即是，该最大计算资源量为800个CPU核心，最大内存资源量为3200G，最大硬盘资源量为100太字节(terabyte，TB)。

在一些实施例中，业务性能参数包括每秒查询数(queries per second，QPS)、每秒事务数(transactions per second，TPS)、并发数中的至少一个。其中，QPS是指目标业务每秒钟能够处理的查询数量，TPS是指目标业务每秒钟能够处理的事务数量，并发数是指目标业务能同时处理的请求数量。当然，在实际应用中，该业务性能参数还可以包括其他能够表征目标业务性能的参数，本申请实施例对此不做限定。

示例地，该业务性能参数可以为5000QPS，在这种情况下，表示该目标业务每秒钟能够处理的查询数量的下限为5000。

在实际应用中，对于目标业务的任意一个业务单元中的任意一个微服务来说，不同启动规格、不同启动节点数量的微服务在该业务单元中的性能不同。在一些实施例中，业务配置信息包括微服务的性能基线，该性能基线指示微服务的启动规格、启动节点数量与性能参数的对应关系。该性能参数指示该微服务在该业务单元中，具有相应启动规格和启动节点数量情况下的性能。

可选地，该微服务的启动规格包括计算资源规格、内存资源规格和最大硬盘资源规格。该微服务的性能参数包括QPS、TPS、并发数中的至少一个，其中，QPS是指在任意一个业务单元中相应微服务每秒钟能够处理的查询数量，TPS是指任意一个业务单元中相应微服务每秒钟能够处理的事务数量，并发数是指任意一个业务单元中相应微服务能同时处理的请求数量。

例如，API微服务的性能基线如下述表1所示。API微服务在启动规格为4U8G50G(即计算资源规格为4个CPU核心，内存资源规格为8GB，硬盘资源规格为50G)、启动节点数量为1个的情况下，该API微服务在任意一个业务单元中每秒钟能够处理的查询数量为100。在启动规格为4U8G50G、启动节点数量为5个的情况下，该API微服务在任意一个业务单元中每秒钟能够处理的查询数量为600。在启动规格为4U8G50G、启动节点数量为10个的情况下，该API微服务在任意一个业务单元中每秒钟能够处理的查询数量为1600。在启动规格为4U8G50G、启动节点数量为20个的情况下，该API微服务在任意一个业务单元中每秒钟能够处理的查询数量为2800。在启动规格为8U16G100G(即计算资源规格为8个CPU核心，内存资源规格为16GB，硬盘资源规格为100G)、启动节点数量为1个的情况下，该API微服务在任意一个业务单元中每秒钟能够处理的查询数量为500。在启动规格为8U16G100G、启动节点数量为5个的情况下，该API微服务在任意一个业务单元中每秒钟能够处理的查询数量为1800。在启动规格为8U16G100G、启动节点数量为10个的情况下，该API微服务在任意一个业务单元中每秒钟能够处理的查询数量为5000。在启动规格为8U16G100G、启动节点数量为20个的情况下，该API微服务在任意一个业务单元中每秒钟能够处理的查询数量为6800。

表1

启动规格	启动节点数量	性能参数
			4U8G50G	1	100QPS
4U8G50G	5	600QPS
			4U8G50G	10	1600QPS
4U8G50G	20	2800QPS
			8U16G100G	1	500QPS
8U16G100G	5	1800QPS
			8U16G100G	10	5000QPS
8U16G100G	20	6800QPS

需要说明的是，该微服务的性能参数与上述业务性能参数是一一对应的，即，在业务性能参数包括QPS的情况下，该微服务的性能参数也包括QPS，在业务性能参数包括TPS的情况下，该微服务的性能参数也包括TPS。在业务性能参数包括并发数的情况下，该微服务的性能参数也包括并发数。

在一些实施例中，该业务配置信息还包括爆炸半径权重和资源权重。该爆炸半径权重和资源权重指示租户对于目标业务的容灾能力和目标业务的资源占用情况的权衡比重。若爆炸半径权重大于资源权重，则表示租户更为看重目标业务的容灾能力，期望目标业务的容灾能力更好。若爆炸半径权重小于资源权重，则表示租户更为看重目标业务的目标业务的资源使用情况，期望目标业务的占用的资源更少。

示例地，该爆炸半径权重可以为90，资源权重可以为10，该爆炸半径权重大于资源权重，表示相比于目标业务的资源使用情况，租户更为看重目标业务的容灾能力，期望目标业务的容灾能力更好。

例如，云管理平台提供如图5所示的配置界面，进而租户能够在该配置界面输入目标业务的业务配置信息。其中，用于提供目标业务的微服务包括微服务1和微服务2，微服务1为API微服务，微服务2为DB微服务。该API微服务的最小启动规格为4U8G50G，最小启动节点数为1，性能基线为图5中示出的性能基线表(即API.excel)，该DB微服务的最小启动规格为16U64G500G，最小启动节点数为2，性能基线为DB.excel(图5中未示出)。最大资源量为800U3200G100T、业务性能参数为5000QPS、最大爆炸半径为0.1、爆炸半径权重为90和资源权重为10。

可选地，该配置界面还用于指示租户输入业务副本数量，进而租户能够在该配置界面输入业务副本数量，对于租户的任意一个用户组来说，该业务副本数量为租户期望的承载该用户组的业务单元的数量，该业务副本数量大于或者等于2。当然，在实际应用中，该业务副本数量还可以是事先配置的，本申请实施例对此不做限定。

步骤402：从该配置界面获取目标业务的业务配置信息。

步骤403：基于目标业务的业务配置信息和业务副本数量，确定目标业务的资源部署策略，并按照该资源部署策略，在多个业务单元上部署目标业务，该资源部署策略指示一个业务单元承载有租户的至少一个用户组，且每Rf个业务单元承载有一个相同的用户组的业务副本，Rf为业务副本数量，Rf≥2。

也就是说，业务单元能够为该租户的至少一个用户组提供服务，每个用户组由至少两个业务单元进行承载，在这种情况下，对于任意一个用户组中的任意一个用户来说，即使承载该用户的一个业务单元故障，该用户还能够从其他的业务单元获取相应业务，相较于一个业务单元故障，而导致该业务单元所服务的用户都无法正常获取服务的方法来说，本申请实施例所提供的方法能够有效提高目标业务的容灾能力。

可选地，该资源部署策略指示用户组的Rf个业务副本各自部署在独立的业务单元上，每Rf个业务单元最多承载有一个相同的用户组的业务副本。

上述每Rf个业务单元最多承载有一个相同的用户组的业务副本也可以理解为任意Rf个业务单元上仅部署有一个相同的用户组对应的业务副本。

由于每Rf个业务单元最多承载有一个相同的用户组的业务副本，对于租户的任意一个用户组来说，若承载该用户组的任意一个业务单元故障，则该用户组还能够从其他的业务单元中获取相应的服务，只有承载该用户组的所有业务单元都产生故障才会导致该用户组无法获取服务，从而对目标业务的正常运行产生影响。而由于承载该用户组的业务单元所承载的其他用户组还被其他的业务单元承载，因此，即使承载该用户组的所有业务单元都产生故障，这些其他用户组还能够从其他的业务单元中获取服务。

换句话说，在本申请实施例中，租户的任意一个用户组无法获取服务才会对目标业务的运行产生影响，因此，本申请实施中的爆炸半径是以用户组为粒度的，爆炸半径为T分之一，T为租户的用户组的数量，也即是，一个用户组无法获取服务会对T分之一的目标业务的产生影响。

示例地，若目标业务的业务单元的数量为4，分别为业务单元0、业务单元1、业务单元2和业务单元3。租户的用户组的数量为6，分别为用户组A、用户组B、用户组C、用户组D、用户组E和用户组F，业务副本数量为2。在这种情况下，每个用户组有两个业务副本，对于任意一个用户组来说，资源部署策略指示该用户组的2个业务副本各自部署在独立的业务单元上，目标业务的业务单元中的每2个业务单元最多承载有一个相同的用户组的业务副本。请参考图6，图6为本申请实施例提供的一种目标业务的部署方式，其中，业务单元0承载有用户组A、用户组B和用户组C，业务单元1承载有用户组A、用户组D和用户组E，业务单元2承载有用户组B、用户组D和用户组F，业务单元3承载有用户组C、用户组E和用户组F。以用户组A为例，用户组A的2个业务副本各自部署在独立的业务单元上(即为业务单元0和业务单元1)。以目标业务的业务单元中的任意2个业务单元(业务单元1和业务单元2)为例，该业务单元1上承载有用户组A、用户组D和用户组E，业务单元2承载有用户组B、用户组D和用户组F，该业务单元1和业务单元2仅部署有一个相同的用户组(业务单元D)对应的业务副本。

对于用户组A来说，若承载该用户组A的业务单元0和业务单元1都产生故障会导致该用户组A无法获取服务，从而对目标业务的正常运行产生影响。业务单元0和业务单元1所承载的其他用户组为用户组B、用户组C、用户组D和用户组E。以用户组B为例来说，该用户组B还被业务单元2承载，因此，即使业务单元0和业务单元1都产生故障，该用户组B还能够从业务单元2获取服务。

在一些实施例中，资源部署策略包括用于提供目标业务的业务单元的数量和业务单元的部署规格，该用于提供目标业务的各个业务单元的规格和性能相同。在这种情况下，基于业务配置信息和业务副本数量，确定该目标业务的资源部署策略的实现过程包括：基于目标业务的业务配置信息和业务副本数量，按照资源部署约束条件，确定用于提供目标业务的业务单元的数量和业务单元的部署规格。

其中，该资源部署约束条件包括微服务的最小启动节点数量、微服务的最小启动规格、最大资源量、业务性能参数、最大爆炸半径、业务副本数量、微服务的性能基线中的一者或多者，该最大资源量指示目标业务所能占用的资源上限，该业务性能参数指示目标业务的性能下限，该最大爆炸半径指示目标业务的容灾能力的下限，该性能基线指示微服务的启动规格、启动节点数量与性能参数的对应关系。

由于最大资源量指示该目标业务所能占用的资源上限，业务性能参数指示该目标业务的性能下限，最大爆炸半径指示该目标业务的容灾能力的下限，因此，按照资源部署约束条件能够保证目标业务的所占用的资源不超过该最大资源量的同时，保证该目标业务的性能不低于业务性能参数，以及目标业务的容灾能力优于或等于该最大爆炸半径指示的容灾能力。也就是说，本申请实施例在资源部署约束条件的约束下，确定的目标业务的资源部署策略能够兼顾目标业务的业务性能、容灾能力和资源成本，使得目标业务在最大资源量不变的情况下，相比于相关技术能够具有更小的爆炸半径以及更优的性能。

在一些实施例中，基于目标业务的业务配置信息和业务副本数量，按照资源部署约束条件，确定多个候选资源部署策略，该候选资源部署策略包括业务单元的候选数量和业务单元的候选部署规格；从该多个候选资源部署策略中选择一个候选资源部署策略，将选择的候选资源部署策略包括的业务单元的候选数量和候选部署规格作为目标业务的资源部署策略包括的业务单元的数量和部署规格。

可选地，该候选部署规格包括业务单元中用于提供目标业务的至少一个微服务分别对应的启动节点数量和启动规格，该资源部署约束条件满足下述的不等式：

其中，在上述不等式中，i是指第i个微服务，minnum_i是指第i个微服务的最小启动节点数量，num_i是指候选部署规格中第i个微服务的启动节点数量，mins_i是指第i个微服务的最小启动规格，s_i是指候选部署规格中第i个微服务的启动规格，S是指最大资源量，n是指业务单元中该至少一个微服务的数量，N是指业务单元的候选数量，mint(j)是指候选部署规格中第j个微服务的启动规格和启动节点数量对应的性能参数最小，T是指业务性能参数，B是指最大爆炸半径，Rf是指业务副本数量，X_i是指第i个微服务的性能基线。

在微服务的启动规格包括计算资源规格、内存资源规格和最大硬盘资源规格，最小启动规格包括最小计算资源规格、最小内存资源规格和最小硬盘资源规格，最大资源量包括最大计算资源量、最大内存资源量和最大硬盘资源量的情况下，上述不等式中mins_i≤s_i是指第i个微服务的最小计算资源规格小于或等于候选部署规格中第i个微服务的计算资源规格、第i个微服务的最小内存资源规格小于或等于候选部署规格中第i个微服务的内存资源规格、并且第i个微服务的最小硬盘资源规格小于或等于候选部署规格中第i个微服务的硬盘资源规格。

同理，上述不等式中s_inum_i≤S是指候选部署规格中第i个微服务的计算资源规格与第i个微服务的启动节点数量之积小于等于最大计算资源量、候选部署规格中第i个微服务的内存资源规格与第i个微服务的启动节点数量之积小于等于最大内存资源量、并且候选部署规格中第i个微服务的硬盘资源规格与第i个微服务的启动节点数量之积小于等于最大硬盘资源量。

对于任意一个候选部署规格来说，该候选部署规格包括业务单元中每个微服务分别对应的启动节点数量和启动规格。由于微服务的启动规格和启动节点数量与性能参数存在对应关系，因此，每个微服务还分别对应相应的性能参数。而对于业务单元来说，该业务单元的性能实际上是由该业务单元中性能参数最小的微服务决定的，因此，若该业务单元中性能参数最小的微服务的性能参数都大于或等于N分之T，则能够保证该N个业务单元的性能之和(即目标业务的性能)不低于该业务性能参数(T)。

需要说明的是，上述业务副本数量不大于业务单元的数量。

在一些实施例中，该业务配置信息包括爆炸半径权重和资源权重，在这种情况下，可以基于该爆炸半径权重和资源权重，从多个候选资源部署策略中选择一个候选资源部署策略。

可选地，可以基于该爆炸半径权重和资源权重，从多个候选资源部署策略中选择第q个候选资源部署策略作为目标业务的资源部署策略，该第q个候选资源部署策略满足如下公式(1)-(3)。

min(α₁A_q+α₂R_q)q∈1,…,z(1)

其中，在上述公式(1)-(3)中，min()是指取括号内的最小值，α₁是指资源权重，α₂是指爆炸半径权重，z是指候选资源部署策略的数量，q是指多个候选资源部署策略中第q个候选资源部署策略。f()是指对括号内的数进行归一化，qN是指该第q个候选资源部署策略中业务单元的候选数量，s_qi是指第q个候选资源部署策略中第i个微服务的启动规格，num_qi是指第q个候选资源部署策略中第i个微服务的启动节点数量，n是指业务单元中该至少一个微服务的数量，Rf是指业务副本数量。

需要说明的是，上述能够表征该第q个候选资源部署策略所占用的资源量，对该第q个候选资源部署策略所占用的资源量进行归一化的实现过程可以是：将该第q个候选资源部署策略所占用的资源量除以最大资源量之后的值作为该第q个候选资源部署策略所占用的资源量进行归一化后的值。

可选地，该第q个候选资源部署策略所占用的资源量包括计算资源量、内存资源量和硬盘资源量，该最大资源量包括最大计算资源量、最大内存资源量和最大硬盘资源量，在这种情况下，可以对该第q个候选资源部署策略所占用的计算资源量、内存资源量和硬盘资源量分别进行归一化，以得到归一化后的计算资源量、归一化后的内存资源量和归一化后的硬盘资源量，将该归一化后的计算资源量、归一化后的内存资源量和归一化后的硬盘资源量之和，作为该第q个候选资源部署策略所占用的资源量进行归一化后的值。

将第q个候选资源部署策略所占用的计算资源量除以最大计算资源量之后的值，作为归一化后的计算资源量，将第q个候选资源部署策略所占用的内存资源量除以最大内存资源量之后的值，作为归一化后的内存资源量，将第q个候选资源部署策略所占用的硬盘资源量除以最大硬盘资源量之后的值，作为归一化后的硬盘资源量。

当然，上述仅仅是一种对该第q个候选资源部署策略所占用的资源量进行归一化的方式，在实际应用中，还可以通过其他的方式对该第q个候选资源部署策略所占用的资源量进行归一化，本申请实施例对此不做限定。

在实际应用中，为了加快求解的速度，还可以基于该资源部署约束条件满足的不等式，以及上述公式(1)-(3)，按照粒子群算法，从多个候选资源部署策略中选择第q个候选资源部署策略作为目标业务的资源部署策略，本申请实施例对此不做限定。

在一些实施例中，除了根据爆炸半径权重和资源权重，从该多个候选资源部署策略中选择一个候选资源部署策略之外，也可以将多个候选资源部署策略中任意一个候选资源部署策略，本申请实施例对此不做限定。

需要说明的是，本申请实施例中目标业务的业务单元均位于同一个区域(region)中，若该region包括多个可用区(availability zone，AZ)，则对于目标业务的资源部署策略中启动节点数量为多个的微服务来说，该微服务分布的节点可以位于同一个AZ，也可以位于不同的AZ，本申请实施例对此不做限定。由于AZ内故障不会波及到其他AZ和Region，因此，若该微服务分布的节点位于不同的AZ，则能够进一步提升目标业务的容灾性能。

在实际应用中，基于目标业务的业务配置信息和业务副本数量，确定目标业务的资源部署策略之后，云管理平台还能够显示业务部署建议界面，该业务部署建议界面用于显示该目标业务的资源部署策略。

可选地，该业务部署建议界面还用于显示资源消耗情况和实际爆炸半径中的至少一个，该资源消耗情况指示目标业务的资源部署策略所占用的资源量，该实际爆炸半径指示基于该目标业务的资源部署策略所部署的目标业务的容灾能力。

示例地，若目标业务的微服务包括API微服务和DB微服务，请参考图7，如图7中示出的业务部署建议界面中，该目标业务的资源部署策略中用于提供目标业务的业务单元的数量为5个，对于任意一个业务单元来说，该业务单元中API微服务的启动节点数量为2个，启动规格为8U16G100G。DB微服务的启动节点数量为4个，启动规格为32U128G1000。其中，API微服务两个的节点位于两个AZ中，分别为AZ1和AZ2，DB微服务的4个节点中也位于两个AZ中，分别为AZ1和AZ2，并且该DB微服务的4个节点中的2个节点位于同一个AZ中。该目标业务的资源部署策略对应的资源消耗情况为720U2720G21T，实际爆炸半径为0.1。

在一种可能的实现方式中，该业务部署建议界面还用于指示租户触发业务部署请求，在按照该资源部署策略，在多个业务单元上部署目标业务之前，云管理平台还能够接收该业务部署请求，该业务部署请求用于指示云管理平台按照该业务部署建议界面显示的资源部署策略部署目标业务。

也就是说，在显示该目标业务的资源部署策略之后，租户还能够在该业务部署建议界面触发业务部署请求，该云管理平台还能够接收该租户触发的业务部署请求，从而按照该资源部署策略，在多个业务单元上部署目标业务。

在实际应用中，该业务配置信息还包括用户特征信息，在这种情况下，云管理平台还能够获取用户特征信息，该用户特征信息为租户的用户组中的多个用户的特征信息，该特征信息包括风险特征信息，该风险特征信息是指易导致业务出现故障的特征，基于该多个用户的风险特征信息，从该多个用户中确定至少一个风险用户，对该至少一个风险用户进行分组，得到该至少一个风险用户分别所属的风险用户组，基于该多个用户中常规用户的特征信息，对常规用户进行分组，得到该常规用户分别所属的常规用户组，该常规用户为多个用户中除风险用户之外的用户。

由于该风险特征信息是指易导致业务出现故障的特征，因此，根据该多个用户的风险特征信息能够准确地从多个用户中确定出容易导致业务出现问题的用户，即风险用户，进而对该风险用户和常规用户分别确定所属的用户组，这样，能够将风险用户和常规用户划分至不同的用户组，从而最大程度上避免风险用户对常规用户的影响，有效提升目标业务对常规用户的服务质量。

在一些实施例中，该特征信息包括用户风险特征标签。该用户风险特征标签包括历史故障子标签和异常流量子标签中的至少一个子标签。其中，历史故障表征用户的流量导致目标业务产生故障的次数，或者，为表征用户无法获取目标业务的次数。异常流量子标签表征用户的异常流量产生的次数。

可选地，该风险特征信息包括至少一个风险子标签，以及每个风险子标签对应的风险子标签权重。在特征信息包括用户风险特征标签的情况下，该至少一个风险子标签为上述用户风险特征标签中历史故障子标签和异常流量子标签中的至少一个。

基于该多个用户的风险特征信息，从该多个用户中确定至少一个风险用户的实现过程包括：基于该多个用户的风险特征信息，确定该多个用户分别对应的风险特征分数，按照从高到底的顺序对多个用户的风险特征分数进行排序，将排序结果的前百分之p的风险特征分数对应的用户作为该至少一个风险用户。

在一些实施例中，对于该多个用户中任意一个用户来说，对该用户的风险特征信息中至少一个风险子标签进行归一化，以得到至少一个归一化后的风险子标签，基于该至少一个归一化后的风险子标签和每个风险子标签对应的风险子标签权重，确定该用户对应的风险特征分数。按照相同的方式对该多个用户中每个用户都进行处理，能够确定该多个用户分别对应的风险特征分数。

在一些实施例中，对于任意一个风险子标签来说，将用户的风险子标签除以该多个用户中该风险子标签的最大值，以得到归一化后的风险子标签。按照相同的方式对至少一个风险子标签中每个风险子标签都进行处理，得到至少一个归一化后的风险子标签。

可选地，将每个归一化后的风险子标签分别乘以该风险子标签对应的风险子标签权重，以得到至少一个第一子标签，将该至少一个第一子标签之和作为该用户对应的风险特征分数。

示例地，可以将该至少一个风险用户划分至同一个用户组，以得到至少一个风险用户所属的风险用户组。当然，在实际应用中，若风险用户数量较多，也可以将该多个风险用户随机划分为至少两个用户组，以得到该多个风险用户分别所属的风险用户组，本申请实施例对此不做限定。

在一些实施例中，该资源部署策略包括业务单元的数量，云管理平台能够基于业务单元的数量和业务副本数量，确定用户分组数量。在这种情况下，基于该多个用户中常规用户的特征信息，对常规用户进行分组的实现方式包括：基于风险用户组的数量、用户分组数量和常规用户的特征信息，对该常规用户进行分组。

可选地，基于目标业务的业务单元的数量和业务副本数量，按照如下公式(4)，确定用户分组数量。

其中，在上述公式(4)中，T是指用户分组数量，N是指业务单元的数量，Rf是指业务副本数量。

示例地，在N等于4，Rf等于2的情况下，该也即是，用户分组数量为6。

在实际应用中，在确定该用户分组数量之后，上述业务部署建议界面还可以显示该用户分组数量。

在一些实施例中，基于常规用户的特征信息，确定常规用户的特征向量，基于常规用户的特征向量，对常规用户进行聚类，得到多个常规用户簇，基于该多个常规用户簇和常规组数量，确定该常规用户分别所属的常规用户组，该常规组数量为用户分组数量与风险用户组的数量的差值。

在一些实施例中，该特征信息还包括用户价值特征标签、用户需求特征标签和用户流量特征标签中的至少一个特征标签，以及每个特征标签对应的特征标签权重。该常规用户的特征向量包括至少一个元素，该至少一个元素与该特征信息包括的特征标签一一对应。对于任意一个常规用户来说，基于该常规用户的目标特征标签，确定该常规用户的特征向量中该目标特征标签对应的元素的值，该目标特征标签为该至少一个特征标签中的任意一个。按照相同的方式对每个常规用户都进行处理，能够得到每个常规用户的特征向量。

可选地，该用户风险特征标签还包括每个子标签对应的子标签权重。

可选地，该用户价值特征标签包括用户等级子标签、用户类别子标签和用户类型子标签中的至少一个子标签，以及每个子签对应的子标签权重。其中，用户等级子标签表征用户在租户的目标业务中的等级。用户类别子标签表征用户为内部用户或外部用户，或者，表征用户的年龄层次，或者，表征用户的职业属性，或者，表征用户的性别。用户类型子标签表征用户是否为贵宾(very important person，VIP)用户。

可选地，用户需求特征标签包括可用性需求子标签和业务类型子标签中的至少一个子标签，以及每个子标签对应的子标签权重。其中，可用性需求子标签表征用户对目标业务所提供的服务的质量要求，业务类型子标签表征用户需要目标业务提供的业务类型。

在一些实施例中，用户对目标业务所提供的服务的质量要求可以通过服务水平协议(service level agreement，SLA)确定，也可以通过其他方式确定，本申请实施例对此不做限定。

示例地，若目标业务能够提供的业务类型包括业务A、业务B和业务C。在这种情况下，对于租户的任意一个用户来说，可以基于该用户对目标业务的历史访问的业务类型，将该历史访问的业务类型中访问次数最多的业务类型，或者，将最近一次访问的业务类型，作为该用户的业务类型子标签。当然，在实际应用中还可以通过其他的方式确定该用户的业务类型子标签，本申请实施例对此不做限定。

可选地，用户流量特征标签包括流量子标签和过载子标签中的至少一个子标签，以及每个子标签对应的子标签权重。其中，流量子标签表征用户在历史时间段所产生的流量大小，过载子标签表征在历史时间段用户导致目标业务出现过载的次数。

其中，该历史时间段是事先设置的，例如，该历史时间段可以设置为近3个月，在这种情况下，若当前时间为2000年1月1日，则该历史时间段为1999年10月1日至1999年12月31日。而且在不同的情况下，还可以根据不同的需求进行修改。

示例地，如下表2所示，该特征信息包括用户价值特征标签、用户风险特征标签和用户流量特征标签，用户价值特征标签的特征标签权重为0.5，用户风险特征标签的特征标签权重为0.2，用户流量特征标签的特征标签权重为0.3。其中，用户价值特征标签包括用户等级子标签、用户类别子标签和用户类型子标签，该用户等级子标签的取值范围为大于0且不大于9的正整数，该用户等级子标签对应的子标签权重为0.8，该用户类别子标签的取值范围为0或者1，该用户类别子标签对应的子标签权重为0.1，该用户类型子标签的取值范围为0或者1，该户类型子标签对应的子标签权重为0.1。用户风险特征标签包括历史故障子标签和异常流量子标签，该历史故障子标签的取值范围为大于0且不大于100的正整数，该历史故障子标签对应的子标签权重为0.8，该异常流量子标签为大于0且不大于100的正整数，该异常流量子标签对应的子标签权重为0.2。用户流量特征标签包括流量子标签，该流量子标签的取值范围为实数，该流量子标签对应的子标签权重为1。

表2

在一些实施例中，基于该常规用户的目标特征标签，确定该常规用户的特征向量中该目标特征标签对应的元素的值的实现过程包括：对该常规用户的目标特征标签中的至少一个子标签进行归一化，以得到至少一个归一化后的子标签，基于该至少一个归一化后的子标签、每个子标签对应的权重，以及目标特征标签对应的特征标签权重，确定该目标特征标签对应的元素的值。

对于该至少一个子标签中的任意一个子标签来说，将该常规用户的该子标签除以该多个常规用户中相应子标签的最大值，以得到归一化后的子标签。按照相同的方式对至少一个子标签中每个子标签都进行处理，得到至少一个归一化后的子标签。

将每个归一化后的子标签分别乘以该子标签对应的子标签权重，以得到至少一个第二子标签，该至少一个第二子标签的和乘以该目标特征标签对应的特征标签权重，以得到该目标特征标签对应的元素的值。

在一些实施例中，基于常规用户的特征向量，按照相关聚类算法，对该常规用户进行聚类，得到多个常规用户簇。

可选地，该聚类算法可以为K-means算法、k-means++算法等等，本申请实施例对此不做限定。

基于多个常规用户簇和常规组数量，确定该常规用户分别所属的常规用户组的实现过程包括：将每个常规用户簇的常规用户随机划分为K组，以得到每个常规用户簇分别包括的K个子簇，K等于该常规组数量，基于该每个常规用户簇分别包括的K个子簇，确定常规用户分别所属的常规用户组。

基于该每个常规用户簇分别包括的K个子簇，确定常规用户分别所属的常规用户组的实现过程包括：令g＝1，从多个常规用户簇包括的子簇中分别随机选择一个子簇，以得到多个子簇，将该多个子簇中的常规用户作为第g个常规用户组中的用户，从该多个常规用户簇中删除该多个子簇，若g小于常规用户组数量，则令g＝g+1，并返回上述从多个常规用户簇包括的子簇中分别随机选择一个子簇，以得到多个子簇的步骤。

对于任意一个常规用户组来说，通过上述方法能够保证该常规用户组中的用户包括每个常规用户簇中的一部分用户。由于常规用户簇中用户的特征是相近的，而不同常规用户簇的用户具有不同的特征，因此，这样能够保证最终确定常规用户组中包括不同的特征用户，从而实现对常规用户的均匀分组。

接下来通过举例来介绍对租户的用户进行分组的实现过程。

示例地，请参考表3，云管理平台能够获取如下表3所示的用户特征信息，该租户的用户组中包括8个用户，该8个用户分别用户A至用户H，用户A至用户H的特征信息均包括用户价值特征标签、用户风险特征标签、用户需求特征标签和用户流量特征标签，以及每个特征标签对应的特征标签权重(表3中未示出)。用户风险特征标签包括历史故障子标签和异常流量子标签，以及每个子标签对应的子标签权重(表3中未示出)，用户价值特征标签包括用户等级子标签、用户类别子标签和用户类型子标签，以及每个子签对应的子标签权重(表3中未示出)，用户流量特征标签包括流量子标签以及流量子标签对应的子标签权重(表3中未示出)。用户A的特征信息中用户等级子标签为9、用户类别子标签为1、用户类型子标签为1、历史故障子标签为2、异常流量子标签为2、流量子标签为5吉字节(gigabyte，G)。用户B至用户H的特征信息与用户A的特征信息类似，此次不再展开说明。

表3

用户的风险特征信息包括至少一个风险子标签，该至少一个风险子标签为用户风险特征标签中历史故障子标签和异常流量子标签，每个风险子标签对应的风险子标签权重均为0.5。基于8个用户的风险特征信息，确定该8个用户分别对应的风险特征分数，按照从高到底的顺序对多个用户的风险特征分数进行排序，该排序结果的前百分之10的风险特征分数对应的用户为用户C和用户D，进而将该用户C和用户D作为该风险用户，并将该用户C和用户D划分至同一个风险用户组(风险用户组1)中。进而基于常规用户(用户A、用户B、用户E-用户H)的特征信息，确定常规用户的特征向量，基于该常规用户的特征向量，对常规用户进行聚类，得到多个常规用户簇，该常规用户的特征向量以及对应的常规用户簇如下表4所示。

表4

请参考表5，基于该多个常规用户簇和常规组数量，确定该常规用户分别所属的常规用户组，以及风险用户所属的风险用户组如下表5所示。

表5

基于上文描述，本申请实施例能够先对风险用户分组，进而再对常规用户进行分组，从而实现对风险用户和常规用户的隔离，从而最大程度上避免风险用户对常规用户的影响，有效提升目标业务对常规用户的服务质量。然而，在实际应用中，也可以无需确定风险用户，直接基于该用户分组数量和该租户的多个用户的特征信息，对该多个用户进行分组来得到该多个用户分别所属的用户组。

在一些实施例中，可以基于该多个用户的特征信息，分别确定该多个用户的特征向量，进而基于该多个用户的特征向量，对该多个用户进行聚类，得到多个用户簇，基于用户分组数量和该多个用户簇，确定该多个用户分别所属的用户组。

其中，基于多个用户的特征信息，分别确定该多个用户的特征向量的实现方式，与上文中基于常规用户的特征信息，确定常规用户的特征向量的实现方式类似；基于该多个用户的特征向量，对多个用户进行聚类，得到多个用户簇的实现方式，与上文中基于常规用户的特征向量，对常规用户进行聚类，得到多个常规用户簇的实现方式类似；基于用户分组数量和多个用户簇，确定该多个用户分别所属的用户组的实现方式，与上文中基于该多个常规用户簇和常规组数量，确定该常规用户分别所属的常规用户组的实现方式类似，详细内容请参考上文中的相关内容，此处不再赘述。

接下来将结合图8对本申请实施例提供的业务部署方法进行再次介绍。

示例地，请参考图8，若业务副本数量为2，用于提供目标业务的微服务包括微服务1和微服务2，在这种情况下，基于目标业务的业务配置信息和业务副本数量，确定目标业务的资源部署策略，按照该资源部署策略，在多个业务单元上部署目标业务。在该资源部署策略中，目标业务的业务单元的数量为4，分别为业务单元0、业务单元1、业务单元2和业务单元3。租户的用户为用户1至用户12，该租户的用户组的数量为6，分别为用户组A、用户组B、用户组C、用户组D、用户组E和用户组F，其中，用户组A包括用户1和用户5，用户组B包括用户2和用户4，用户组C包括用户3和用户6，用户组D包括用户7和用户12，用户组E包括用户8和用户9，用户组F包括用户10和用户11。该资源部署策略指示用户组的2个业务副本各自部署在独立的业务单元上，每2个业务单元最多承载有一个相同的用户组的业务副本。其中，业务单元0承载有用户组A、用户组B和用户组C，业务单元1承载有用户组A、用户组D和用户组E，业务单元2承载有用户组B、用户组D和用户组F，业务单元3承载有用户组C、用户组E和用户组F。以用户组A为例，用户组A的2个业务副本各自部署在独立的业务单元上(即为业务单元0和业务单元1)。以目标业务的业务单元中的任意2个业务单元(业务单元1和业务单元2)为例，该业务单元1上承载有用户组A、用户组D和用户组E，业务单元2承载有用户组B、用户组D和用户组F，该业务单元1和业务单元2仅部署有一个相同的用户组(业务单元D)对应的业务副本。

本申请实施例能够根据租户输入的目标业务的业务配置信息和业务副本数量，确定该目标业务的资源部署策略，进而按照该资源部署策略，在多个业务单元上部署该目标业务。由于业务副本数量大于或等于2，该资源部署策略指示该一个业务单元承载有该租户的至少一个用户组，并且每Rf个业务单元承载有一个相同的用户组的业务副本，Rf为业务副本数量。也就是说，业务单元能够为该租户的至少一个用户组提供服务，每个用户组能够由至少两个业务单元进行承载，在这种情况下，对于任意一个用户组中的任意一个用户来说，即使承载该用户的一个业务单元故障，该用户还能够从其他的业务单元获取相应业务，相较于一个业务单元故障，而导致该业务单元所服务的用户都无法正常获取服务的方法来说，本申请实施例所提供的方法能够有效提高目标业务的容灾能力。

在资源部署策略指示用户组的Rf个业务副本各自部署在独立的业务单元上，每Rf个业务单元最多承载有一个相同的用户组的业务副本的情况下，由于每Rf个业务单元最多承载有一个相同的用户组的业务副本，对于租户的任意一个用户组来说，若承载该用户组的任意一个业务单元故障，则该用户组还能够从其他的业务单元中获取相应的服务，只有承载该用户组的所有业务单元都产生故障才会导致该用户组无法获取服务，从而对目标业务的正常运行产生影响。而由于承载该用户组的业务单元所承载的其他用户组还被其他的业务单元承载，因此，即使承载该用户组的所有业务单元都产生故障，这些其他用户组还能够从其他的业务单元中获取服务。由于最大资源量指示该目标业务所能占用的资源上限，业务性能参数指示该目标业务的性能下限，最大爆炸半径指示该目标业务的容灾能力的下限，因此，按照资源部署约束条件能够保证目标业务的所占用的资源不超过该最大资源量的同时，保证该目标业务的性能不低于业务性能参数，以及目标业务的容灾能力优于或等于该最大爆炸半径指示的容灾能力。也就是说，本申请实施例在资源部署约束条件的约束下，确定的目标业务的资源部署策略能够兼顾目标业务的业务性能、容灾能力和资源成本，使得目标业务在最大资源量不变的情况下，相比于相关技术能够具有更小的爆炸半径以及更优的性能。由于风险特征信息是指易导致业务出现故障的特征，因此，根据该多个用户的风险特征信息能够准确地从多个用户中确定出容易导致业务出现问题的用户，即风险用户，进而对该风险用户和常规用户分别确定所属的用户组，这样，能够将风险用户和常规用户划分至不同的用户组，从而最大程度上避免风险用户对常规用户的影响，有效提升目标业务对常规用户的服务质量。

图9是本申请实施例提供的一种业务部署装置的结构示意图，该业务部署装置包含于云管理平台，即该业务部署装置可以由软件、硬件或者两者的结合实现成为上述云管理平台的部分或者全部。参见图9，该装置包括：提供模块901、第一获取模块902和第一确定模块903。

提供模块901，用于提供配置界面，该配置界面用于指示租户输入待部署的目标业务的业务配置信息，该业务配置信息用于配置目标业务。详细实现过程参考上述各个实施例中对应的内容，此处不再赘述。

第一获取模块902，用于从配置界面获取业务配置信息。详细实现过程参考上述各个实施例中对应的内容，此处不再赘述。

第一确定模块903，用于基于业务配置信息和业务副本数量，确定目标业务的资源部署策略，并按照资源部署策略，在多个业务单元上部署目标业务，其中，该资源部署策略指示一个业务单元承载有租户的至少一个用户组，且每Rf个业务单元承载有一个相同的用户组的业务副本，Rf为业务副本数量，Rf≥2。详细实现过程参考上述各个实施例中对应的内容，此处不再赘述。

可选地，该资源部署策略指示用户组的Rf个业务副本各自部署在独立的业务单元上，每Rf个业务单元最多承载有一个相同的用户组的业务副本。

可选地，该资源部署策略包括业务单元的数量和部署规格，第一确定模块903具体用于：

基于业务配置信息和业务副本数量，按照资源部署约束条件，确定业务单元的数量和部署规格，其中，该资源部署约束条件包括微服务的最小启动节点数量、微服务的最小启动规格、最大资源量、业务性能参数、最大爆炸半径、业务副本数量、微服务的性能基线中的一者或多者，该最大资源量指示目标业务所能占用的资源上限，该业务性能参数指示目标业务的性能下限，该最大爆炸半径指示目标业务的容灾能力的下限，该性能基线指示微服务的启动规格、启动节点数量与性能参数的对应关系。

可选地，第一确定模块903具体用于：

基于业务配置信息和业务副本数量，按照资源部署约束条件，确定多个候选资源部署策略，该候选资源部署策略包括业务单元的候选数量和候选部署规格；

从多个候选资源部署策略中选择一个候选资源部署策略，将选择的候选资源部署策略包括的业务单元的候选数量和候选部署规格作为目标业务的资源部署策略包括的业务单元的数量和部署规格。

可选地，候选部署规格包括用于提供目标业务的至少一个微服务分别对应的启动节点数量和启动规格；资源部署约束条件满足下述的不等式：

其中，i是指第i个微服务，minnum_i是指第i个微服务的最小启动节点数量，num_i是指候选部署规格中第i个微服务的启动节点数量，mins_i是指第i个微服务的最小启动规格，s_i是指候选部署规格中第i个微服务的启动规格，S是指最大资源量，n是指至少一个微服务的数量，N是指候选数量，mint(j)是指候选部署规格中第j个微服务的启动规格和启动节点数量对应的性能参数最小，T是指业务性能参数，B是指最大爆炸半径，Rf是指业务副本数量，X_i是指第i个微服务的性能基线。

可选地，业务配置信息包括爆炸半径权重和资源权重；

第一确定模块903具体用于：

基于爆炸半径权重和资源权重，从多个候选资源部署策略中选择一个候选资源部署策略。

可选地，装置还包括：

第二获取模块，用于获取用户特征信息，该用户特征信息为租户的用户组中的多个用户的特征信息，特征信息包括风险特征信息，该风险特征信息是指易导致业务出现故障的特征；

第二确定模块，用于基于多个用户的风险特征信息，从多个用户中确定至少一个风险用户；

第一分组模块，用于对至少一个风险用户进行分组，得到至少一个风险用户分别所属的风险用户组；

第二分组模块，用于基于多个用户中常规用户的特征信息，对常规用户进行分组，得到常规用户分别所属的常规用户组，该常规用户为多个用户中除风险用户之外的用户。

可选地，其特征在于，资源部署策略包括业务单元的数量；

装置还包括：

第三确定模块，用于基于业务单元的数量和业务副本数量，确定用户分组数量；

第二分组模块具体用于：

基于风险用户组的数量、用户分组数量和常规用户的特征信息，对常规用户进行分组。

可选地，第二分组模块具体用于：

基于常规用户的特征信息，确定常规用户的特征向量；

基于常规用户的特征向量，对常规用户进行聚类，得到多个常规用户簇；

基于多个常规用户簇和常规组数量，确定常规用户分别所属的常规用户组，该常规组数量为用户分组数量与风险用户组的数量的差值。

可选地，业务副本数量为租户在配置界面输入的。

可选地，装置还包括：

显示模块，用于显示业务部署建议界面，该业务部署建议界面用于显示目标业务的资源部署策略。

可选地，业务部署建议界面还用于显示资源消耗情况和实际爆炸半径中的至少一个，该资源消耗情况指示资源部署策略所占用的资源量，该实际爆炸半径指示基于资源部署策略所部署的目标业务的容灾能力。

可选地，业务部署建议界面还用于指示租户触发业务部署请求，装置还包括：

接收模块，用于接收业务部署请求，该业务部署请求用于指示云管理平台按照业务部署建议界面显示的资源部署策略部署目标业务。

本申请实施例能够根据租户输入的目标业务的业务配置信息和业务副本数量，确定该目标业务的资源部署策略，进而按照该资源部署策略，在多个业务单元上部署该目标业务。由于业务副本数量大于或等于2，该资源部署策略指示该一个业务单元承载有该租户的至少一个用户组，并且每Rf个业务单元承载有一个相同的用户组的业务副本，Rf为业务副本数量。也就是说，业务单元能够为该租户的至少一个用户组提供服务，每个用户组能够由至少两个业务单元进行承载，在这种情况下，对于任意一个用户组中的任意一个用户来说，即使承载该用户的一个业务单元故障，该用户还能够从其他的业务单元获取相应业务，相较于一个业务单元故障，而导致该业务单元所服务的用户都无法正常获取服务的方法来说，本申请实施例所提供的方法能够有效提高目标业务的容灾能力。

在资源部署策略指示用户组的Rf个业务副本各自部署在独立的业务单元上，每Rf个业务单元最多承载有一个相同的用户组的业务副本的情况下，由于每Rf个业务单元最多承载有一个相同的用户组的业务副本，对于租户的任意一个用户组来说，若承载该用户组的任意一个业务单元故障，则该用户组还能够从其他的业务单元中获取相应的服务，只有承载该用户组的所有业务单元都产生故障才会导致该用户组无法获取服务，从而对目标业务的正常运行产生影响。而由于承载该用户组的业务单元所承载的其他用户组还被其他的业务单元承载，因此，即使承载该用户组的所有业务单元都产生故障，这些其他用户组还能够从其他的业务单元中获取服务。由于最大资源量指示该目标业务所能占用的资源上限，业务性能参数指示该目标业务的性能下限，最大爆炸半径指示该目标业务的容灾能力的下限，因此，按照资源部署约束条件能够保证目标业务的所占用的资源不超过该最大资源量的同时，保证该目标业务的性能不低于业务性能参数，以及目标业务的容灾能力优于或等于该最大爆炸半径指示的容灾能力。也就是说，本申请实施例在资源部署约束条件的约束下，确定的目标业务的资源部署策略能够兼顾目标业务的业务性能、容灾能力和资源成本，使得目标业务在最大资源量不变的情况下，相比于相关技术能够具有更小的爆炸半径以及更优的性能。由于风险特征信息是指易导致业务出现故障的特征，因此，根据该多个用户的风险特征信息能够准确地从多个用户中确定出容易导致业务出现问题的用户，即风险用户，进而对该风险用户和常规用户分别确定所属的用户组，这样，能够将风险用户和常规用户划分至不同的用户组，从而最大程度上避免风险用户对常规用户的影响，有效提升目标业务对常规用户的服务质量。

需要说明的是：上述实施例提供的业务部署装置在进行业务部署时，仅以上述各功能模块的划分进行举例说明，实际应用中，可以根据需要而将上述功能分配由不同的功能模块完成，即将装置的内部结构划分成不同的功能模块，以完成以上描述的全部或者部分功能。另外，上述实施例提供的业务部署装置与业务部署方法实施例属于同一构思，其具体实现过程详见方法实施例，这里不再赘述。

图9所示的业务部署装置中的提供模块、第一获取模块和第一确定模块均可以通过软件实现，或者可以通过硬件实现，或者通过软硬结合的方式实现。接下来以业务部署装置中的提供模块为例，介绍该提供模块的实现方式。类似的，上述其他模块的实现方式可以参考该提供模块的实现方式。

模块作为软件功能单元的一种举例，提供模块可以包括运行在计算实例上的代码。其中，计算实例可以包括物理主机、虚拟机、容器中的至少一种。进一步地，上述计算实例可以是一台或者多台。例如，提供模块可以包括运行在多个主机/虚拟机/容器上的代码。需要说明的是，用于运行该代码的多个主机/虚拟机/容器可以分布在相同的区域(region)中，也可以分布在不同的region中。进一步地，用于运行该代码的多个主机/虚拟机/容器可以分布在相同的可用区(availability zone，AZ)中，也可以分布在不同的AZ中，每个AZ包括一个数据中心或多个地理位置相近的数据中心。其中，通常一个region可以包括多个AZ。

同样，用于运行该代码的多个主机/虚拟机/容器可以分布在同一个VPC中，也可以分布在多个虚拟私有云(virtual private cloud，VPC)中。其中，通常一个VPC设置在一个region内，同一region内两个VPC之间，以及不同region的VPC之间跨区通信需在每个VPC内设置通信网关，经通信网关实现VPC之间的互连。

模块作为硬件功能单元的一种举例，提供模块可以包括至少一个计算设备，如服务器等。或者，提供模块也可以是利用专用集成电路(application-specific integratedcircuit，ASIC)实现、或可编程逻辑器件(programmable logic device，PLD)实现的设备等。其中，上述PLD可以是复杂程序逻辑器件(complex programmable logical device，CPLD)、现场可编程门阵列(field-programmable gate array，FPGA)、通用阵列逻辑(generic array logic，GAL)或其任意组合实现。

提供模块包括的多个计算设备可以分布在相同的region中，也可以分布在不同的region中。提供模块包括的多个计算设备可以分布在相同的AZ中，也可以分布在不同的AZ中。同样，提供模块包括的多个计算设备可以分布在同一个VPC中，也可以分布在多个VPC中。其中，所述多个计算设备可以是服务器、ASIC、PLD、CPLD、FPGA和GAL等计算设备的任意组合。

在其他实施例中，业务部署装置中的提供模块可以用于执行上述业务部署方法中的任意步骤，业务部署装置中的第一获取模块可以用于执行上述业务部署方法中的任意步骤，业务部署装置中的第一确定模块可以用于执行上述业务部署方法中的任意步骤，业务部署装置中的提供模块、第一获取模块和第一确定模块负责实现的步骤可根据需要指定，通过业务部署装置中的提供模块、第一获取模块和第一确定模块分别实现上述业务部署的方法中不同的步骤，从而实现提供业务部署装置的全部功能。

本申请实施例还提供一种计算设备100。如图10所示，计算设备100包括：总线102、处理器104、存储器106和通信接口108。处理器104、存储器106和通信接口108之间通过总线102通信。计算设备100可以是服务器或终端设备。应理解，本申请不限定计算设备100中的处理器、存储器的个数。

总线102可以是外设部件互连标准(peripheral component interconnect，PCI)总线或扩展工业标准结构(extended industry standard architecture，EISA)总线等。总线可以分为地址总线、数据总线、控制总线等。为便于表示，图10中仅用一条线表示，但并不表示仅有一根总线或一种类型的总线。总线102可包括在计算设备100各个部件(例如，存储器106、处理器104、通信接口108)之间传送信息的通路。

处理器104可以包括中央处理器(central processing unit，CPU)、图形处理器(graphics processing unit，GPU)、微处理器(micro processor，MP)、数字信号处理器(digital signal processor，DSP)、集成电路等处理器中的任意一种或多种。集成电路如ASIC、PLD或其组合。可选地，上述PLD为CPLD、FPGA、GAL或其任意组合。

存储器106可以包括易失性存储器(volatile memory)，例如随机存取存储器(random access memory，RAM)。存储器106还可以包括非易失性存储器(non-volatilememory)，例如只读存储器(read-only memory，ROM)，快闪存储器，机械硬盘(hard diskdrive，HDD)或固态硬盘(solid state drive，SSD)，或者是能够用于携带或存储具有指令或数据结构形式的期望的程序代码并能够由计算机存取的任何其它介质，但不限于此。存储器106独立存在，并通过总线102与处理器104相连接，或者，存储器106与处理器104集成在一起。

存储器106中存储有可执行的程序代码，处理器104执行该可执行的程序代码以实现前述业务部署方法。也即，存储器106上存有用于执行业务部署方法的指令。

例如，存储器106中存储有可执行的代码，处理器104执行该可执行的代码以实现如上文图9所示提供模块、第一获取模块和第一确定模块的功能。也即，存储器106上存有用于执行本申请实施例提供的业务部署方法的指令。

通信接口108使用例如但不限于网络接口卡、收发器一类的收发模块，来实现计算设备100与其他设备或通信网络之间的通信。网络接口包括有线通信接口，或者还包括无线通信接口。其中，有线通信接口例如以太网接口等。以太网接口为光接口、电接口或其组合。无线通信接口为无线局域网(wireless local area networks，WLAN)接口、蜂窝网络通信接口或其组合等。

本申请实施例还提供了一种计算设备集群。该计算设备集群包括多个计算设备。计算设备可以是服务器，例如是中心服务器、边缘服务器，或者是本地数据中心中的本地服务器。在一些实施例中，计算设备也可以是台式机、笔记本电脑或者智能手机等终端设备。

如图11所示，该计算设备集群包括多个计算设备100。计算设备集群中的多个计算设备100中的存储器106中可以存有相同的用于执行上述业务部署方法的指令。

在一些可能的实现方式中，该计算设备集群中的多个计算设备100的存储器106中也可以分别存有用于执行上述业务部署方法的部分指令。换言之，该多个计算设备100的组合可以共同执行用于执行上述业务部署方法的全部指令。

需要说明的是，计算设备集群中不同的计算设备100中的存储器106可以存储不同的指令，用于执行上述业务部署方法的部分功能。也即，不同的计算设备100中的存储器106存储的指令可以实现上文中业务部署装置所包括的部分模块或全部模块的功能。

在一些可能的实现方式中，计算设备集群中的一个或多个计算设备可以通过网络连接。其中，该网络可以是广域网或局域网等等。图12示出了一种可能的实现方式，如图12所示，两个计算设备100A和100B之间通过网络进行连接。具体地，通过各个计算设备中的通信接口与该网络进行连接。在这一类可能的实现方式中，计算设备100A中的存储器106中存有执行上文中业务部署装置所包括的一部分模块的功能的指令。同时，计算设备100B中的存储器106中存有执行上文中业务部署装置所包括的另一部分模块的功能的指令。

应理解，图12中示出的计算设备100A的功能也可以由多个计算设备100完成。同样，计算设备100B的功能也可以由多个计算设备100完成。

本申请实施例还提供了另一种计算设备集群。该计算设备集群中各计算设备之间的连接关系可以类似的参考图11和图12所述计算设备集群的连接方式。不同的是，该计算设备集群中的一个或多个计算设备100中的存储器106中可以存有相同的用于执行业务部署方法的指令。

在一些可能的实现方式中，该计算设备集群中的一个或多个计算设备100的存储器106中也可以分别存有用于执行业务部署方法的部分指令。换言之，一个或多个计算设备100的组合可以共同执行用于执行业务部署方法的指令。

本申请实施例还提供了一种计算机可读存储介质，所述存储介质内存储有指令，当所述指令在计算机设备集群上运行时，使得计算机执行上述实施例所述的业务部署方法的步骤。

本申请实施例还提供了一种包含指令的计算机程序产品，当所述指令在计算机设备集群上运行时，使得计算机设备集群执行上述实施例所述的业务部署方法的步骤。或者说，提供了一种计算机程序，当所述计算机程序在计算机设备集群上运行时，使得计算机设备集群执行上述实施例所述的业务部署方法的步骤。

在上述实施例中，可以全部或部分地通过软件、硬件、固件或者其任意结合来实现。当使用软件实现时，可以全部或部分地以计算机程序产品的形式实现。所述计算机程序产品包括一个或多个计算机指令。在计算机上加载和执行所述计算机指令时，全部或部分地产生按照本申请实施例所述的流程或功能。所述计算机可以是通用计算机、专用计算机、计算机网络或其他可编程装置。所述计算机指令可以存储在计算机可读存储介质中，或者从一个计算机可读存储介质向另一个计算机可读存储介质传输，例如，所述计算机指令可以从一个网站站点、计算机、服务器或数据中心通过有线(例如：同轴电缆、光纤、数据用户线(digital subscriber line，DSL))或无线(例如：红外、无线、微波等)方式向另一个网站站点、计算机、服务器或数据中心进行传输。所述计算机可读存储介质可以是计算机能够存取的任何可用介质，或者是包含一个或多个可用介质集成的服务器、数据中心等数据存储设备。所述可用介质可以是磁性介质(例如：软盘、硬盘、磁带)、光介质(例如：数字通用光盘(digital versatiledisc，DVD))或半导体介质(例如：固态硬盘(solid state disk，SSD))等。值得注意的是，本申请实施例提到的计算机可读存储介质可以为非易失性存储介质，换句话说，可以是非瞬时性存储介质。

应当理解的是，本文提及的“多个”是指两个或两个以上。在本申请实施例的描述中，除非另有说明，“/”表示或的意思，例如，A/B可以表示A或B；本文中的“和/或”仅仅是一种描述关联对象的关联关系，表示可以存在三种关系，例如，A和/或B，可以表示：单独存在A，同时存在A和B，单独存在B这三种情况。另外，为了便于清楚描述本申请实施例的技术方案，在本申请实施例中，采用了“第一”、“第二”等字样对功能和作用基本相同的相同项或相似项进行区分。本领域技术人员可以理解“第一”、“第二”等字样并不对数量和执行次序进行限定，并且“第一”、“第二”等字样也并不限定一定不同。

需要说明的是，本申请实施例所涉及的信息(包括但不限于用户设备信息、用户个人信息等)、数据(包括但不限于用于分析的数据、存储的数据、展示的数据等)以及信号，均为经用户授权或者经过各方充分授权的，且相关数据的收集、使用和处理需要遵守相关国家和地区的相关法律法规和标准。例如，本申请实施例中涉及到的目标业务的业务配置信息都是在充分授权的情况下获取的。

以上所述为本申请提供的实施例，并不用以限制本申请，凡在本申请的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本申请的保护范围之内。

Claims (22)

1.一种业务部署方法，其特征在于，应用于云管理平台，所述云管理平台用于管理云基础设施，所述云基础设施包括至少一个云数据中心，所述至少一个云数据中心部署有多个业务单元，所述方法包括：

提供配置界面，所述配置界面用于指示租户输入待部署的所述目标业务的业务配置信息，所述业务配置信息用于配置所述目标业务；

从所述配置界面获取所述业务配置信息；

基于所述业务配置信息和业务副本数量，确定所述目标业务的资源部署策略，并按照所述资源部署策略，在所述多个业务单元上部署所述目标业务，其中，所述资源部署策略指示一个所述业务单元承载有所述租户的至少一个用户组，且每Rf个所述业务单元承载有一个相同的用户组的业务副本，Rf为所述业务副本数量，Rf≥2。

2.如权利要求1所述的方法，其特征在于，所述资源部署策略指示所述用户组的Rf个业务副本各自部署在独立的所述业务单元上，每Rf个所述业务单元最多承载有一个相同的用户组的业务副本。

3.如权利要求1或2所述的方法，其特征在于，所述资源部署策略包括所述业务单元的数量和部署规格，所述基于所述业务配置信息和业务副本数量，确定所述目标业务的资源部署策略，包括：

基于所述业务配置信息和所述业务副本数量，按照资源部署约束条件，确定所述业务单元的数量和部署规格，其中，所述资源部署约束条件包括微服务的最小启动节点数量、微服务的最小启动规格、最大资源量、业务性能参数、最大爆炸半径、业务副本数量、微服务的性能基线中的一者或多者，所述最大资源量指示所述目标业务所能占用的资源上限，所述业务性能参数指示所述目标业务的性能下限，所述最大爆炸半径指示所述目标业务的容灾能力的下限，所述性能基线指示微服务的启动规格、启动节点数量与性能参数的对应关系。

4.如权利要求3所述的方法，其特征在于，所述基于所述业务配置信息和所述业务副本数量，按照资源部署约束条件，确定所述业务单元的数量和部署规格，包括：

基于所述业务配置信息和所述业务副本数量，按照所述资源部署约束条件，确定多个候选资源部署策略，所述候选资源部署策略包括所述业务单元的候选数量和候选部署规格；

从所述多个候选资源部署策略中选择一个候选资源部署策略，将选择的候选资源部署策略包括的所述业务单元的候选数量和候选部署规格作为所述目标业务的资源部署策略包括的所述业务单元的数量和部署规格。

5.如权利要求4所述的方法，其特征在于，所述候选部署规格包括用于提供所述目标业务的至少一个所述微服务分别对应的启动节点数量和启动规格；所述资源部署约束条件满足下述的不等式：

其中，i是指第i个微服务，minnum_i是指所述第i个微服务的最小启动节点数量，num_i是指所述候选部署规格中所述第i个微服务的启动节点数量，mins_i是指所述第i个微服务的最小启动规格，s_i是指所述候选部署规格中所述第i个微服务的启动规格，S是指所述最大资源量，n是指所述至少一个微服务的数量，N是指所述候选数量，mint(j)是指所述候选部署规格中第j个微服务的启动规格和启动节点数量对应的性能参数最小，T是指所述业务性能参数，B是指所述最大爆炸半径，Rf是指所述业务副本数量，X_i是指所述第i个微服务的性能基线。

6.如权利要求4所述的方法，其特征在于，所述业务配置信息包括爆炸半径权重和资源权重；

所述从多个所述候选资源部署策略中选择一个候选资源部署策略，包括：

基于所述爆炸半径权重和所述资源权重，从所述多个候选资源部署策略中选择一个候选资源部署策略。

7.如权利要求1至6任一项所述的方法，其特征在于，所述方法还包括：

获取用户特征信息，所述用户特征信息为所述租户的用户组中的多个用户的特征信息，所述特征信息包括风险特征信息，所述风险特征信息是指易导致业务出现故障的特征；

基于所述多个用户的风险特征信息，从所述多个用户中确定至少一个风险用户；

对所述至少一个风险用户进行分组，得到所述至少一个风险用户分别所属的风险用户组；

基于所述多个用户中常规用户的特征信息，对所述常规用户进行分组，得到所述常规用户分别所属的常规用户组，所述常规用户为所述多个用户中除所述风险用户之外的用户。

8.如权利要求7所述的方法，其特征在于，所述资源部署策略包括所述业务单元的数量；

所述方法还包括：

基于所述业务单元的数量和所述业务副本数量，确定用户分组数量；

所述基于所述多个用户中常规用户的特征信息，对所述常规用户进行分组，包括：

基于所述风险用户组的数量、所述用户分组数量和所述常规用户的特征信息，对所述常规用户进行分组。

9.如权利要求8所述的方法，其特征在于，所述基于所述风险用户组的数量、所述用户分组数量和所述常规用户的特征信息，对所述常规用户进行分组，包括：

基于所述常规用户的特征信息，确定所述常规用户的特征向量；

基于所述常规用户的特征向量，对所述常规用户进行聚类，得到多个常规用户簇；

基于所述多个常规用户簇和常规组数量，确定所述常规用户分别所属的常规用户组，所述常规组数量为所述用户分组数量与所述风险用户组的数量的差值。

10.如权利要求1至9任一项所述的方法，其特征在于，所述业务副本数量为所述租户在所述配置界面输入的。

11.如权利要求1至10任一项所述的方法，其特征在于，所述基于所述业务配置信息和所述业务副本数量，确定所述目标业务的资源部署策略之后，所述方法还包括：

显示业务部署建议界面，所述业务部署建议界面用于显示所述目标业务的资源部署策略。

12.如权利要求11所述的方法，其特征在于，所述业务部署建议界面还用于显示资源消耗情况和实际爆炸半径中的至少一个，所述资源消耗情况指示所述资源部署策略所占用的资源量，所述实际爆炸半径指示基于所述资源部署策略所部署的所述目标业务的容灾能力。

13.如权利要求11或12所述的方法，其特征在于，所述业务部署建议界面还用于指示所述租户触发业务部署请求，在按照所述资源部署策略，在所述多个业务单元上部署所述目标业务之前，所述方法还包括：

接收所述业务部署请求，所述业务部署请求用于指示所述云管理平台按照所述业务部署建议界面显示的所述资源部署策略部署所述目标业务。

14.一种业务部署装置，其特征在于，所述业务部署装置包含于云管理平台，所述云管理平台用于管理云基础设施，所述云基础设施包括至少一个云数据中心，所述至少一个云数据中心部署有多个业务单元，所述装置包括：

提供模块，用于提供配置界面，所述配置界面用于指示租户输入待部署的所述目标业务的业务配置信息，所述业务配置信息用于配置所述目标业务；

第一获取模块，用于从所述配置界面获取所述业务配置信息；

第一确定模块，用于基于所述业务配置信息和业务副本数量，确定所述目标业务的资源部署策略，并按照所述资源部署策略，在所述多个业务单元上部署所述目标业务，其中，所述资源部署策略指示一个所述业务单元承载有所述租户的至少一个用户组，且每Rf个所述业务单元承载有一个相同的用户组的业务副本，Rf为所述业务副本数量，Rf≥2。

15.如权利要求14所述的装置，其特征在于，所述资源部署策略指示所述用户组的Rf个业务副本各自部署在独立的所述业务单元上，每Rf个所述业务单元最多承载有一个相同的用户组的业务副本。

16.如权利要求14或15所述的装置，其特征在于，所述装置还包括：

第二获取模块，用于获取用户特征信息，所述用户特征信息为所述租户的用户组中的多个用户的特征信息，所述特征信息包括风险特征信息，所述风险特征信息是指易导致业务出现故障的特征；

第二确定模块，用于基于所述多个用户的风险特征信息，从所述多个用户中确定至少一个风险用户；

第一分组模块，用于对所述至少一个风险用户进行分组，得到所述至少一个风险用户分别所属的风险用户组；

第二分组模块，用于基于所述多个用户中常规用户的特征信息，对所述常规用户进行分组，得到所述常规用户分别所属的常规用户组，所述常规用户为所述多个用户中除所述风险用户之外的用户。

17.如权利要求16所述的装置，其特征在于，所述资源部署策略包括所述业务单元的数量；

所述装置还包括：

第三确定模块，用于基于所述业务单元的数量和所述业务副本数量，确定用户分组数量；

所述第二分组模块具体用于：

基于所述风险用户组的数量、所述用户分组数量和所述常规用户的特征信息，对所述常规用户进行分组。

18.如权利要求14至17任一项所述的装置，其特征在于，所述业务副本数量为所述租户在所述配置界面输入的。

19.如权利要求14至18任一项所述的装置，其特征在于，所述装置还包括：

显示模块，用于显示业务部署建议界面，所述业务部署建议界面用于显示所述目标业务的资源部署策略。

20.一种计算设备集群，其特征在于，所述计算设备集群包括至少一个计算设备，每个计算设备包括处理器和存储器；

所述至少一个计算设备的处理器用于执行所述至少一个计算设备的存储器中存储的指令，以使得所述计算设备集群执行如权利要求1-13任一所述的方法。

21.一种计算机可读存储介质，其特征在于，所述存储介质包括计算机程序指令，当所述计算机程序指令由计算设备集群执行时，所述计算设备集群执行如权利要求1-13任一所述的方法。

22.一种包含指令的计算机程序产品，其特征在于，当所述指令被计算设备集群运行时，使得所述计算设备集群执行如权利要求1-13任一所述的方法。