CN108268363A - 用于业务容量管理的方法和设备 - Google Patents

Abstract

本发明提供了一种用于业务容量管理的方法和设备。该方法包括：确定第一业务系统在第一业务环境中的资源开销；确定第二业务系统在第二业务环境中的业务计划以及第二业务环境与第一业务环境之间的环境差异；根据第一业务系统的资源开销、第二业务系统的业务计划以及环境差异，预测第二业务系统的资源开销；根据预测的第二业务系统的资源开销，确定第二业务系统的业务容量。这样，通过测试第一业务系统的真实数据确定得到第一业务系统的资源开销，进而确定得到第二业务系统的业务容量，相对于根据人为经验确定得到第二业务系统的业务容量。本申请实施例可以实现对业务系统的业务容量的更准确评估。

Description

用于业务容量管理的方法和设备

技术领域

本申请涉及业务支撑领域，尤其涉及一种用于业务容量管理的方法和设备。

背景技术

业务系统在进行业务容量管理的过程中需要对其进行业务处理时使用的数据库服务器和应用服务器的业务容量进行评估。当前，一般采用由事务处理性能委员会(Transaction Processing Performance Council，简称为TPC)发布的TPC-C基准测试方案或者标准性能评估机构(SPEC)评估体系中的SPECjAppServer2004基准测试方案来对业务系统的业务容量进行评估。

然而，这两种基准测试方案在进行业务容量评估时存在以下问题：(1)针对TPC-C方案，无法准确估计业务系统相对于TPC测试环境的复杂系数；(2)针对SPECjAppServer2004方案，无法准确估计业务的复杂系数。因此，为了预防可能存在的容量瓶颈风险，在使用上述两种方法对业务系统的业务容量进行评估时，通常根据人为经验将无法准确估计的参数值相应的扩大，这样，使得实际评估出的业务容量大于业务系统实际所需的业务容量，导致在实际应用场景中存在容量冗余的问题。

发明内容

本发明实施例提供了新颖的用于业务容量管理的方法和设备。

根据本发明实施例的用于业务容量管理的方法可包括：确定第一业务系统在第一业务环境中的资源开销；确定第二业务系统在第二业务环境中的业务计划以及第二业务环境与第一业务环境之间的环境差异；根据第一业务系统的资源开销、第二业务系统的业务计划以及环境差异，预测第二业务系统的资源开销；以及根据预测的第二业务系统的资源开销，确定第二业务系统的业务容量。

根据本发明实施例的用于业务容量管理的设备可包括：第一确定单元，用于确定第一业务系统在第一业务环境中的资源开销；第二确定单元，用于确定第二业务系统在第二业务环境中的业务计划以及第二业务环境与第一业务环境之间的环境差异；计算单元，用于根据第一业务系统的资源开销、第二业务系统的业务计划以及环境差异，预测第二业务系统的资源开销；以及业务容量确定单元，用于根据计算单元预测的第二业务系统的资源开销，确定第二业务系统的业务容量。

根据本发明实施例的用于业务容量管理的方法和设备，通过测试第一业务系统的真实数据确定得到第一业务系统的资源开销，进而确定得到第二业务系统的业务容量，相对于根据人为经验确定得到第二业务系统的业务容量。本申请实施例可以实现对业务系统的业务容量的更准确评估。

附图说明

通过阅读以下参照附图对非限制性实施例所作的详细描述，本发明的其它特征、目的和优点将会变得更明显，其中，相同或相似的附图标记表示相同或相似的特征。

图1是示出根据本发明实施例的用于业务容量管理的方法的流程示意图；

图2是示出根据本发明实施例的示例业务容量分析预测模型的示意图；

图3(a)和图3(b)是示出根据本发明实施例的一种示例业务容量联动矩阵应对策略的示意图；

图4是示出根据本发明实施例的标准语音话单处理时长与CPU使用率之间的关系的示意图；

图5是示出根据本发明实施例的用于业务容量管理的设备的结构示意图；以及

图6是示出能够实现根据本发明实施例的用于业务容量管理的方法及其设备的计算设备的示例性硬件架构的结构图。

具体实施方式

现在将参考附图更全面地描述示例实施方式。然而，示例实施方式能够以多种形式实施，且不应被理解为限于在此阐述的实施方式；相反，提供这些实施方式使得本发明更全面和完整，并将示例实施方式的构思全面地传达给本领域的技术人员。在图中，为了清晰，可能夸大了区域和层的厚度。在图中相同的附图标记表示相同或类似的结构，因而将省略它们的详细描述。

本申请实施例提供了一种用于业务容量管理的方法和设备。该方法包括：确定第一业务系统在第一业务环境中的资源开销；确定第二业务系统在第二业务环境中的业务计划以及第二业务环境与第一业务环境之间的环境差异；根据第一业务系统的资源开销、第二业务系统的业务计划以及环境差异，确定第二业务系统的资源开销；根据第二业务系统的资源开销，确定第二业务系统的业务容量。

这样，通过采集第一业务系统的真实数据并且通过分析处理得到第一业务系统的资源开销，进而确定第二业务系统的业务容量，相对于根据人为经验估算得到第二业务系统的业务容量，本申请实施例可以实现对业务系统的业务容量的更准确评估。

在本申请实施例中，第一业务系统可以是测试环境(即第一业务环境)下的业务系统，第二业务系统可以是在不同业务环境(即第二业务环境，例如生产环境)下新上线的新业务系统。

下面结合本申请具体实施例及相应的附图对本申请技术方案进行清楚、完整地描述。显然，所描述的实施例仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

以下结合附图，详细说明本申请各实施例提供的技术方案。

图1是示出根据本发明实施例的用于业务容量管理的方法100的流程示意图。如图1所示，方法100包括以下步骤：步骤101，确定第一业务系统在第一业务环境中的资源开销；步骤102，确定第二业务系统在第二业务环境中的业务计划以及第二业务环境与第一业务环境之间的环境差异；步骤103，根据第一业务系统的资源开销、第二业务系统的业务计划以及环境差异，预测第二业务系统的资源开销；以及步骤104，根据预测的第二业务系统的资源开销，确定第二业务系统的业务容量。

在一个实施例中，在步骤101中，在需要根据第一业务系统确定第二业务系统的系统容量时，可以首先确定得到第一业务系统在第一业务环境中的资源开销。在一个示例中，可以通过以下方式确定得到第一业务系统的资源开销，包括：在第一业务环境下，采集第一业务系统的业务特征信息，以及第一业务系统在进行业务交易时所使用的服务器的资源开销，业务特征信息中包含第一业务系统的业务交易量以及第一业务系统在进行业务交易时的特征数据；根据业务特征信息以及第一业务系统在进行业务交易时所使用的服务器的资源开销，确定第一业务系统在第一业务环境中的资源开销。

在一个实施例中，可以按照设定频率采集得到第一业务系统的业务特征信息，该频率可以被设定为1次/每小时，也可以是1次/半小时，这里不做具体限定。

业务特征信息可以包含第一业务系统的业务交易量以及第一业务系统在进行业务交易时的特征数据，特征数据可以是第一业务系统在进行交易时与交易相关的指标信息的数据。

第一业务系统在进行业务交易时所使用的服务器的个数可以是一个，也可以是多个，这里不做具体限定。服务器的资源开销，可以是所有服务器中每一个服务器的资源开销，也可以是其中一个或几个服务器的资源开销，这里也不做具体限定。服务器的资源开销例如可以包括与服务器相关的以下各项中的一项或多项：服务器的CPU利用率、内存利用率、磁盘I/O、网络流量指标等。

需要说明的是，在本申请实施例中，对于业务特征信息的采集频率可以被设置为与对于服务器的资源开销的采集频率相同。

在确定业务特征信息以及服务器的资源开销后，可以进一步确定第一业务系统在第一业务环境中的资源开销。

在实际应用中，为了保证确定的第一业务系统在第一业务环境中的资源开销的准确性，在确定业务特征信息后，还可以对业务特征信息进行预处理。对业务特征信息进行预处理包括但不限于：(1)针对性能数据进行数据质量检查；(2)筛选法定节假日等特殊时段；(3)处理性能与业务指标数据的采集周期，使其保持一致；(4)进行业务与CPU使用率的相关性分析；(5)筛选出业务交易量每天的最大值以及对应的性能数据，用于容量预测。

在对业务特征信息进行预处理后，确定第一业务系统在第一业务环境中的资源开销的处理还可以包括：根据业务特征信息，确定第一业务系统中包含的业务类型的种类；根据服务器的资源开销，确定服务器针对每一种业务类型的数据流；根据服务器针对每一种业务类型的数据流，确定每一种业务类型的资源开销；根据每一种业务类型的资源开销，确定所有业务类型的资源开销，并将所有业务类型的资源开销作为第一业务系统在第一业务环境中的资源开销。

在一个实施例中，确定的第一业务系统中包含的业务类型的种类，可以仅包括第一业务系统中包含的关键业务的种类。确定每一种业务类型的数据流的处理可以通过为每一种业务类型在服务器上发起的请求数以及发起请求名称的统计确定得到。

在得到每一种业务类型的数据流后，每一种业务类型的资源开销可以通过以下步骤确定得到：(1)利用系统容量的历史采样数据建立容量分析预测的新模型；(2)进行系统容量分析；(3)统计指标处理；以及(4)预测模型参数估计。

图2是示出根据本发明实施例的建立业务容量分析预测模型的示例方法的示意图。如图2所示，该容量分析预测模型的建立方法可以利用CPU利用率以及内存利用率两部分数据进行。针对CPU利用率，首先，对CPU利用率数据修匀，其次，对CPU利用率再次数据修匀，再次，对CPU利用率一次和二次指数容量修匀，最后计算CPU利用率的截距与斜率，并对CPU利用率调整修匀。针对内存利用率，首先，计算环比修匀，其次，计算一次、二次指数容量修匀，再次计算历史参数变量值，最后，计算预测的斜率与截距。

在一个实施例中，系统容量分析可以利用容量分析法来进行。容量分析法的基本原理是采用时间序列分析预测，通过计算指数容量修匀，结合一定的时间序列形成预测模型从而对未来的情况进行预测。在一个示例中，其公式为：S_t＝ay_t+(1-a)S_t-1，即每一时间周期的指数容量修匀都是本周期实际观察值与前一周期指数容量修匀的加权平均的值。

在一个实施例中，在进行容量分析时，可以利用上述公式确定平滑初始值。根据公式，当t取1时有：S₁＝ay₁+(1-a)S₀，此时开始收集数据，因此无y₀，定义S₁为初始值，S₁的定义方法为：S₁＝(y₁+y₂+y₃+…+y_n)/n，即待积累若干数据后，取S₁等于前面若干数据的简单算术平均数。

在另一实施例中，可以根据确定的平滑初始值进行数据修匀确定处理。指数数据修匀的取值可以采用历史值进行推算，公式如下：

F(a)＝min(∑S_t-y_t)

数据修匀的意义是决定平滑水平以及对预测值与实际结果之间差异的响应速度.故数据修匀a越接近于1，实际值对本次容量修匀的下降越快；平滑常数a越接近于0，实际值对本次容量修匀影响程度的下降越慢。采用穷举的方法，从0开始，以0.01为步长，代入公式中，以此得到拟合值和实际值偏差最小的取值，确定数据修匀值。

在一个实施例中，统计指标处理可包括以下两个步骤：(1)指数平滑处理；以及(2)指数平滑计算。

指数平滑处理的计算公式可以是：其中，为数据修匀，χ为历史值中每月CPU小时均值中最大值与最小增长率，即：χ＝C_M/C_m-1，其中，C_M和C_m每月CPU小时均值的最大值和最小值，通过历史记录查找可以得到。当t＝1，即第一期时，采用前三期的平均值作为初始值。

指数平滑计算可以涉及以下计算公式：

一次指数平滑计算公式：

二次指数平滑计算公式(1)：以及

二次指数平滑计算公式(2)：其中，n为预测天数，截距2S′_t-S_t，斜率

在一个实施例中，在预测模型参数估计的处理过程中，根据计算可以得到预测为一次函数，同样资源利用率也为一次函数，计算资源利用的截距和斜率：

一次指数平滑计算公式：其中，P_t为第t期的CPU使用量一次指数容量修匀；C_c为第n期的CPU使用量的真实值；P_t-1为第n-1期一次指数容量修匀。

二次指数平滑计算公式：其中，Q_t为表示t期的二次指数容量修匀；Q_t-1为第n-1期的二次指数容量修匀。

计算截距的过程如下：首先，计算各期拟合值的截距，s_t为截距参数变量因子：s_t＝2P_t-Q_t；其次，计算预测的模型截距：其中，为预测模型的截距；s_l为最后一期拟合值的截距；γ为预测模型的截距的调整修匀。

计算斜率的过程如下：首先，根据公式计算各期拟合值的斜率，其中为斜率参数变量修匀；其次，根据公式计算预测模型的斜率，其中：为预测模型的截距；η为预测模型的截距的调整修匀；f_l为最后一期拟合值的斜率。

在通过上述记载的方法确定得到每一种业务类型的资源开销之后，可以进一步确定得到所有业务类型的资源开销。在一个实施例中，所有业务类型的资源开销可以根据以下公式来确定：

其中，a_ii为不同业务类型下的单业务配比比例，C_name0i为服务器上的资源开销，N_ii为所有业务类型下的服务器吞吐量，n为单业务的种类数，C_mnameni为所有业务类型下计算出的一定配比的单业务数中服务器的CPU利用率。

在一些实施例中，可以在确定第一业务系统的资源开销后，在步骤102中确定第二业务系统在第二业务环境中的业务计划以及第二业务环境与第一业务环境之间的环境差异。

在一个实施例中，步骤102中确定第二业务系统在第二业务环境中的业务计划可包括确定以下各项中的一项或多项：第二业务系统的业务类型的种类、第二业务系统的场景配比、以及第二业务系统中每一种业务类型的数据流的数据特征。

这里描述的确定第二业务系统的业务计划的处理可以是对第二业务系统的发展规模进行估量，预估在未来特定时间段内新业务可能的业务成交量。

在另一实施例中，步骤102中确定第二业务环境与第一业务环境之间的环境差异的处理可包括确定素数第一业务环境和第二业务环境中服务器的CPU的个数，核数，主频的区别，以及内存及IO硬盘大小的区别。

在一些实施例中，在确定第二业务系统的业务计划以及环境差异后，可以在步骤103中结合步骤101中确定的第一业务系统的资源开销，预测第二业务系统的资源开销。

在一个实施例中，预测第二业务系统的资源开销的处理可以包括：根据第一业务系统中每一种业务类型的资源开销，以及第二业务系统中每一种业务类型的数据流的数据特征，确定第二业务系统中每一种业务类型的资源开销；根据第二业务系统中每一种业务类型的资源开销、第二业务系统的业务计划、环境差异、以及第二业务系统中每一种业务类型的数据流的数据特征，确定第二业务系统的资源开销。

需要说明的是，在预测第二业务系统的资源开销之前，首先可以确定第二业务系统所包含的业务类型。第二业务系统包含的业务类型例如可包括以下三种类型：第一种业务类型仅在原有系统上新增某项功能，某种服务，面对的是前台人员或是内部员工；第二种业务类型为增加新系统、新平台，与原有系统没有交互，面对的是最终用户；第三种业务类型为增加新功能、新服务项目，与原有的系统(例如，CRM或是BOSS系统)存在交互。

这样，在确定第二业务系统包含的业务类型后，可以预测第二业务类型的资源开销。在一个实施例中，预测第二业务系统的资源开销可以包括以下步骤：确定第二业务系统的业务交易量；计算累计计算值之间的系数调整；根据第二业务系统的业务交易量以及系数调整，计算第二业务系统所需的资源开销。

在一个示例中，可以根据公式来计算累计计算值之间的系数调整，其中C_mnamei为第二业务系统中包含的所有业务类型累计计算服务器的资源开销，Z_tnamei为第二业务系统中包含的所有业务类型压力测试服务器的资源开销。

在另一示例中，可以根据公式来计算第二业务系统所需的资源开销，其中，M_i为单业务的配比数，C_fnameni为服务器的资源开销的预测值。

在另一些实施例中，在确定得到第二业务系统的资源开销后，可以在步骤104中进一步确定得到第二业务系统的业务容量。例如，可以根据以下公式来确定第二业务系统的业务容量：C_pnameni＝C_fnameni*T_adjust，其中，T_adjust为不同机器性能之间的调整系数。

在另一实施例中，在确定第二业务系统的业务容量后，该方法还可以包括：根据第二业务系统的业务容量，确定联动策略，联动策略可包含不同的资源占用度与资源占用度下的应对策略，资源占用度可包含CPU资源使用率以及内存使用率；根据联动策略，对第二业务系统处理的业务进行控制。

图3(a)和3(b)是示出根据本发明实施例的一种示例业务容量联动矩阵应对策略的示意图。图3(a)和3(b)中所示的图形在本申请中可以被称为联动矩阵，如图3所示，图3(a)的联动矩阵可包括CPU使用率与应对策略之间的关系，并且图3(b)的联动矩阵可包括内存使用率与应对策略之间的关系。

如图3(a)所示，针对CPU使用率而言，在CPU使用率为80％-85％之间时，应对策略为将三分之一业务切换至备用机；在CPU使用率为85％-90％之间时，应对策略为将三分之二业务切换至备用机；在CPU使用率为90％-95％之间时，应对策略为将全部业务切换至备用机；在CPU使用率为95％-98％之间时，应对策略为将全部业务切换至备用机，并停止非关键业务；在CPU使用率为98％-100％之间时，应对策略为将全部业务切换至备用机，并停止非关键业务，除此之外，重启被管机到诊断模式。

如图3(b)所示，针对内存使用率而言，在内存使用率为90％-95％之间时，应对策略为将二分之一业务切换到备用机；在内存使用率为95％-98％之间时，应对策略为将全部业务切换到备用机，并停止关键业务；在内存使用率为98％-100％之间时，应对策略为将全部业务切换到备用机，并停止关键业务，除此之外，重启被管机到诊断模式。

本申请实施例中，联动策略存储于应对策略规则库。根据系统资源占用度不同，应对策略规则库向监控系统提供合适的应对策略，比如当计算机系统资源占用度介于85％到90％之间时，监控系统向负责分发业务的负载均衡交换机或采集前置机发送指令，将2/3业务量分流到备用机上；当计算机系统CPU使用率超过98％时，必须采取全部业务切换到备用机，停非关键业务，重启计算机到诊断模式的应对步骤。因为这种情况极有可能是计算机感染了计算机病毒或者被植入了异常程序所致，必须重启到诊断模式下保护硬件继而排查故障源。

需要说明的是，联动策略中的切换阀值，是在处理能力远小于实际生产计算机的测试计算机上实测得到的。以计费测试系统为例，衡量业务性能的标准语音话单处理时长和CPU使用率之间的实测关系如图4所示。

图4为本申请实施例提供的一种标准语音话单处理时长与CPU使用率之间的关系的示意图。图4中的横坐标代表CPU的使用率，纵坐标代表标准语音话单处理时长，图4中，在CPU使用率为85％、90％、95％和98％时存在跳变的现象。因此，可以将跳变处的点选取出来作为切换阀值。生产计算机的处理能力虽然远大于测试计算机，但只是并行处理能力更强而已，CPU使用率和业务性能之间的关系是基本不变的。其他系统资源使用率和其他业务性能的关联关系测定方法与此相同。

这样，通过系统容量的历史采样数据建立容量分析预测的模型，结合系统资源开销值，推导出业务或者功能的联动矩阵，得出业务量与资源消耗的关系，得出新业务或者新功能的系统容量需求，这种算法既结合了系统当前业务运行容量值，又结合了新功能在测试环境中的测试值，比原有的单一的主机容量估算或者单一业务压力测试结果提高了精确度，并且避免了许多需要经验确定的相关计算参数值，减轻了容量估计的不确定的影响。

本申请实施例提供的技术方案，在确定第二业务系统的业务容量时，可以确定第一业务系统在第一业务环境中的资源开销，根据第二业务系统在第二业务环境中的业务计划以及第二业务环境与第一业务环境之间的环境差异，预测第二业务系统的资源开销，并根据预测的第二业务系统的资源开销，最终确定第二业务系统的业务容量。这样，通过测试第一业务系统的真实数据确定得到第一业务系统的资源开销，进而确定得到第二业务系统的业务容量，相对于根据人为经验确定得到第二业务系统的业务容量，本申请实施例可以实现对业务系统的业务容量的准确评估。

图5是示出根据本发明实施例的用于业务容量管理的设备的结构示意图。如图5所示，用于业务容量管理的设备500可包括：第一确定单元51、第二确定单元52、计算单元53以及业务容量确定单元54，其中：第一确定单元51用于确定第一业务系统在第一业务环境中的资源开销；第二确定单元52用于确定第二业务系统在第二业务环境中的业务计划以及第二业务环境与第一业务环境之间的环境差异；计算单元53用于根据第一业务系统的资源开销、第二业务系统的业务计划以及环境差异，预测第二业务系统的资源开销；并且业务容量确定单元54用于根据计算单元53预测的第二业务系统的资源开销，确定第二业务系统的业务容量。

在一个实施例中，资源开销确定单元51还可用于进行以下操作：在第一业务环境下，采集第一业务系统的业务特征信息，以及第一业务系统在进行业务交易时所使用的服务器的资源开销，业务特征信息中包含第一业务系统的业务交易量以及第一业务系统在进行业务交易时的特征数据；以及根据业务特征信息以及第一业务系统在进行业务交易时所使用的服务器的资源开销，确定第一业务系统在第一业务环境中的资源开销。

在一个示例中，根据业务特征信息以及第一业务系统在进行业务交易时所使用的服务器的资源开销确定第一业务系统在第一业务环境中的资源开销的处理可包括：根据业务特征信息，确定第一业务系统中包含的业务类型的种类；根据服务器的资源开销，确定服务器针对每一种业务类型的数据流；根据服务器针对每一种业务类型的数据流，确定每一种业务类型的资源开销；以及根据每一种业务类型的资源开销，确定所有业务类型的资源开销，并将所有业务类型的资源开销作为第一业务系统在第一业务环境中的资源开销。

在本申请提供的另一实施例中，用于业务容量管理的设备500还可包括控制单元55，该控制单元55用于在确定第二业务系统的业务容量后，根据第二业务系统的业务容量，确定联动策略，联动策略包含不同的资源占用度与资源占用度下的应对策略，资源占用度包含CPU资源使用率以及内存使用率；根据联动策略，对第二业务系统处理的业务进行控制。

根据本发明实施例的用于业务容量管理的设备的其他细节与以上结合图1至图4描述的相应方法相同，这里不再赘述。

根据本发明实施例的用于业务容量管理的设备通过采集第一业务系统的真实数据并且通过分析处理得到第一业务系统的资源开销，进而确定第二业务系统的业务容量，因此相对于根据人为经验估算得到第二业务系统的业务容量，能够实现对业务系统的业务容量的更准确评估。

需要说明的是，本申请实施例提供的用于业务容量管理的设备可以通过硬件方式实现，也可以通过软件方式实现，这里不做限定。

结合图1至图5描述的用于业务容量管理的方法及其设备的至少一部分可以由计算设备实现。图6示出能够实现根据本发明实施例的用于业务容量管理的方法及设备的计算设备的示例性硬件架构的结构图。如图6所示，计算设备600包括输入设备601、输入接口602、中央处理器603、存储器604、输出接口605、以及输出设备606。其中，输入接口602、中央处理器603、存储器604、以及输出接口605通过总线610相互连接，输入设备601和输出设备606分别通过输入接口602和输出接口605与总线610连接，进而与计算设备600的其他组件连接。具体地，输入设备601接收来自外部的输入信息，并通过输入接口602将输入信息传送到中央处理器603；中央处理器603基于存储器604中存储的计算机可执行指令对输入信息进行处理以生成输出信息，将输出信息临时或者永久地存储在存储器604中，然后通过输出接口605将输出信息传送到输出设备606；输出设备606将输出信息输出到计算设备600的外部供用户使用。

也就是说，图5所示的设备也可以被实现为包括：存储有计算机可执行指令的存储器；以及处理器，该处理器在执行计算机可执行指令时可以实现结合图1至图4描述的用于业务容量管理的方法。这里，处理器可以基于输入信息执行计算机可执行指令，从而实现结合图1至图5描述的用于业务容量管理的方法及设备。

需要明确的是，本发明并不局限于上文所描述并在图中示出的特定配置和处理。为了简明起见，这里省略了对已知方法的详细描述。在上述实施例中，描述和示出了若干具体的步骤作为示例。但是，本发明的方法过程并不限于所描述和示出的具体步骤，本领域的技术人员可以在领会本发明的精神后，作出各种改变、修改和添加，或者改变步骤之间的顺序。

以上所述的结构框图中所示的功能块可以实现为硬件、软件、固件或者它们的组合。当以硬件方式实现时，其可以例如是电子电路、专用集成电路(ASIC)、适当的固件、插件、功能卡等等。当以软件方式实现时，本发明的元素是被用于执行所需任务的程序或者代码段。程序或者代码段可以存储在机器可读介质中，或者通过载波中携带的数据信号在传输介质或者通信链路上传送。

本发明可以以其他的具体形式实现，而不脱离其精神和本质特征。例如，特定实施例中所描述的算法可以被修改，而系统体系结构并不脱离本发明的基本精神。因此，当前的实施例在所有方面都被看作是示例性的而非限定性的，本发明的范围由所附权利要求而非上述描述定义，并且，落入权利要求的含义和等同物的范围内的全部改变从而都被包括在本发明的范围之中。

Claims (16)

1.一种用于业务容量管理的方法，其特征在于，所述方法包括：

确定第一业务系统在第一业务环境中的资源开销；

确定第二业务系统在第二业务环境中的业务计划以及所述第二业务环境与所述第一业务环境之间的环境差异；

根据所述第一业务系统的资源开销、所述第二业务系统的业务计划以及所述环境差异，预测所述第二业务系统的资源开销；以及

根据预测的所述第二业务系统的资源开销，确定所述第二业务系统的业务容量。

2.如权利要求1所述的方法，其中，所述确定第一业务系统在第一业务环境中的资源开销的处理包括：

在所述第一业务环境下，采集所述第一业务系统的业务特征信息，以及所述第一业务系统在进行业务交易时所使用的服务器的资源开销，所述业务特征信息中包含所述第一业务系统的业务交易量以及所述第一业务系统在进行业务交易时的特征数据；以及

根据所述业务特征信息以及所述第一业务系统在进行业务交易时所使用的服务器的资源开销，确定所述第一业务系统在所述第一业务环境中的资源开销。

3.如权利要求2所述的方法，其中，所述根据所述业务特征信息以及所述第一业务系统在进行业务交易时所使用的服务器的资源开销确定所述第一业务系统在所述第一业务环境中的资源开销的处理包括：

根据所述业务特征信息，确定所述第一业务系统中包含的业务类型的种类；

根据所述服务器的资源开销，确定所述服务器针对每一种业务类型的数据流；

根据所述服务器针对每一种业务类型的数据流，确定每一种业务类型的资源开销；以及

根据每一种业务类型的资源开销，确定所有业务类型的资源开销，并将所述所有业务类型的资源开销作为所述第一业务系统在所述第一业务环境中的资源开销。

4.如权利要求3所述的方法，其中，所有业务类型的资源开销是根据以下公式确定的：

其中，a_ii为不同业务类型下单业务配比比例，C_name0i为所述服务器上的资源开销，N_ii为所有业务类型下所述服务器的吞吐量，n为单业务的种类数，C_mnameni为所有业务类型下计算出的一定配比的单业务数中所述服务器的CPU利用率。

5.如权利要求1所述的方法，其中，确定第二业务系统在第二业务环境中的业务计划的处理包括：确定第二业务系统的业务类型的种类、所述第二业务系统的场景配比以及所述第二业务系统中每一种业务类型的数据流的数据特征。

6.如权利要求1所述的方法，其中，所述预测所述第二业务系统的资源开销的处理包括：

根据所述第一业务系统中每一种业务类型的资源开销，以及所述第二业务系统中每一种业务类型的数据流的数据特征，确定所述第二业务系统中每一种业务类型的资源开销；

根据所述第二业务系统中每一种业务类型的资源开销、所述第二业务系统的业务计划、所述环境差异、以及所述第二业务系统中每一种业务类型的数据流的数据特征，确定所述第二业务系统的资源开销。

7.如权利要求6所述的方法，其中，预测所述第二业务系统的资源开销，包括：

确定所述第二业务系统的业务交易量；

计算累计计算值之间的系数调整；以及

根据所述第二业务系统的业务交易量以及所述系数调整，计算所述第二业务系统所需的资源开销。

8.如权利要求1所述的方法，在确定所述第二业务系统的业务容量后，所述方法还包括：

根据所述第二业务系统的业务容量，确定联动策略，所述联动策略包含不同的资源占用度与所述资源占用度下的应对策略，所述资源占用度包含CPU资源使用率以及内存使用率；以及

根据所述联动策略，对所述第二业务系统处理的业务进行控制。

9.一种用于业务容量管理的设备，其特征在于，所述设备包括：

第一确定单元，用于确定第一业务系统在第一业务环境中的资源开销；

第二确定单元，用于确定第二业务系统在第二业务环境中的业务计划以及所述第二业务环境与所述第一业务环境之间的环境差异；

计算单元，用于根据所述第一业务系统的资源开销、所述第二业务系统的业务计划以及所述环境差异，预测所述第二业务系统的资源开销；

业务容量确定单元，用于根据所述计算单元预测的所述第二业务系统的资源开销，确定所述第二业务系统的业务容量。

10.如权利要求9所述的设备，其中，所述第一确定单元还用于：

在所述第一业务环境下，采集所述第一业务系统的业务特征信息，以及所述第一业务系统在进行业务交易时所使用的服务器的资源开销，所述业务特征信息中包含所述第一业务系统的业务交易量以及所述第一业务系统在进行业务交易时的特征数据；以及

根据所述业务特征信息以及所述第一业务系统在进行业务交易时所使用的服务器的资源开销，确定所述第一业务系统在所述第一业务环境中的资源开销。

11.如权利要求10所述的设备，其中，所述根据所述业务特征信息以及所述第一业务系统在进行业务交易时所使用的服务器的资源开销确定所述第一业务系统在所述第一业务环境中的资源开销的处理包括：

根据所述业务特征信息，确定所述第一业务系统中包含的业务类型的种类；

根据所述服务器的资源开销，确定所述服务器针对每一种业务类型的数据流；

根据所述服务器针对每一种业务类型的数据流，确定每一种业务类型的资源开销；以及

根据每一种业务类型的资源开销，确定所有业务类型的资源开销，并将所述所有业务类型的资源开销作为所述第一业务系统在所述第一业务环境中的资源开销。

12.如权利要求11所述的设备，其中，所有业务类型的资源开销是根据以下公式确定的：

其中，a_ii为不同业务类型下单业务配比比例，C_name0i为所述服务器上的资源开销，N_ii为所有业务类型下所述服务器的吞吐量，n为单业务的种类数，C_mnameni为所有业务类型下计算出的一定配比的单业务数中所述服务器的CPU利用率。

13.如权利要求9所述的设备，其中，所述第二确定单元还用于：确定第二业务系统的业务类型的种类、所述第二业务系统的场景配比以及所述第二业务系统中每一种业务类型的数据流的数据特征。

14.如权利要求9所述的设备，其中，所述计算单元还用于：

根据所述第一业务系统中每一种业务类型的资源开销，以及所述第二业务系统中每一种业务类型的数据流的数据特征，确定所述第二业务系统中每一种业务类型的资源开销；以及

根据所述第二业务系统中每一种业务类型的资源开销、所述第二业务系统的业务计划、所述环境差异、以及所述第二业务系统中每一种业务类型的数据流的数据特征，确定所述第二业务系统的资源开销。

15.如权利要求14所述的设备，其中，所述计算单元还用于：

确定所述第二业务系统的业务交易量；

计算累计计算值之间的系数调整；以及

根据所述第二业务系统的业务交易量以及所述系数调整，计算所述第二业务系统所需的资源开销。

16.如权利要求9所述的设备，还包括确定单元，该确定单元用于：

根据所述第二业务系统的业务容量，确定联动策略，所述联动策略包含不同的资源占用度与所述资源占用度下的应对策略，所述资源占用度包含CPU资源使用率以及内存使用率；以及

根据所述联动策略，对所述第二业务系统处理的业务进行控制。