一种确定系统容量的方法及装置与流程

[0001]
本发明实施例涉及金融科技(fintech)领域，尤其涉及一种确定系统容量的方法及装置。


背景技术：

[0002]
随着计算机技术的发展，越来越多的技术应用在金融领域，传统金融业正在逐步向金融科技转变，但由于金融行业的安全性、实时性要求，也对技术提出的更高的要求。在金融领域中，由于金融业务执行的并发性，银行系统在一段时间内可能会执行大量的金融业务，这就需要银行系统提供较充足的容量来处理这些金融业务。因此，及时地评估出银行系统的容量，对于确保银行系统的正常运行极其重要。
[0003]
现有银行系统的容量评估方法主要是基于运维人员或成本运营规划人员进行人工估算。具体地说，当需要对银行系统的容量进行评估时，运维人员或成本运营规划人员获取银行系统运行过程中的运行状态(比如系统每笔交易的请求处理时长、系统内机器数量、机器负载等)，并对运行状态中的运行数据进行计算，得到银行系统的容量的评估结果。然而，由于这种处理方式主要依赖运维人员或成本运营规划人员进行人工计算，需要耗费较长的精力和时间，且由于评估的银行系统大都是线上运行的系统，评估后的应用存在滞后性。此外，由于前期的评估结果不准确或者人工计算中出现纰漏，导致评估的容量小于实际容量，则系统在上线过程中就有可能因系统负载不足导致交易异常，造成客户资金异常，从而给客户带来严重的损失。也有可能出现评估的容量远大于实际需求的容量，如此会导致服务器资源浪费，从而导致银行运营成本增加。
[0004]
综上，目前亟需一种确定系统容量的方法，用以解决现有技术中存在人工评估系统容量导致评估效率低、准确性低的问题。


技术实现要素：

[0005]
本发明实施例提供了一种确定系统容量的方法及装置，用以解决现有技术中存在人工评估系统容量导致评估效率低、准确性低的问题。
[0006]
第一方面，本发明实施例提供了一种确定系统容量的方法，包括：
[0007]
采集应用系统中各业务子系统的当前运行信息；
[0008]
针对至少一个业务子系统，从所述业务子系统的当前运行信息中确定各容量影响因素的实时信息；
[0009]
根据所述各容量影响因素的实时信息和所述业务子系统的容量计算模型，确定所述业务子系统的系统容量；其中，所述容量计算模型中设置有通过业务子系统的历史运行信息确定的各容量影响因素的权重。
[0010]
上述技术方案中，通过实时获取应用系统中各业务子系统的当前运行信息，并针对至少一个业务子系统，从业务子系统的当前运行信息中确定各容量影响因素的实时信息。再根据各容量影响因素的实时信息和业务子系统的容量计算模型，确定业务子系统的
系统容量。由于结合各容量影响因素的实时信息、各容量影响因素的权重以及容量计算模型对系统容量进行自动化计算，如此可以避免人工过多的介入，有助于减少依靠人工确定系统容量所耗费的时间和人力，并有助于确保系统容量确定的实时性、准确性，从而可以解决现有技术中存在人工评估系统容量导致评估效率低、准确性低的问题。
[0011]
可选地，根据如下方式确定所述各容量影响因素的权重：
[0012]
基于层次分析法，对所述应用系统的历史运行信息进行分析处理，确定作为方案层的各第一影响因素、作为准则层的各第二影响因素及作为目标层的系统容量；各容量影响因素包括所述各第一影响因素和所述各第二影响因素；
[0013]
基于层次分析法，确定所述各第一影响因素的第一权重和所述各第二影响因素的第二权重。
[0014]
上述技术方案中，通过层次分析法对应用系统的历史运行信息进行分析处理，可以快速准确地确定出各第一影响因素的第一权重和各第二影响因素的第二权重，以便后续容量计算模型根据各第一影响因素的第一权重和各第二影响因素的第二权重确定业务子系统的系统容量。
[0015]
可选地，所述各第一影响因素包括单机处理能力和机器数；所述各第二影响因素包括容灾能力、机器负载、存储负载及业务量负载。
[0016]
可选地，根据所述各容量影响因素的实时信息和所述业务子系统的容量计算模型，确定所述业务子系统的系统容量，包括：
[0017]
根据下述公式(1)确定所述业务子系统的最大系统容量；
[0018]
所述公式(1)为：
[0019]
最大系统容量＝最大业务处理能力
÷
(负载状况
×
负载权重)..............(1)
[0020]
根据下述公式(2)确定所述业务子系统的容灾系统容量；
[0021]
所述公式(2)为：
[0022]
容灾系统容量＝容灾能力
×
最大系统容量
×
容灾能力的权重.............(2)
[0023]
其中，负载状况包括机器负载、存储负载和业务量负载，容灾能力为可用机器数占总机器数的占比。
[0024]
上述技术方案中，通过容量计算模型可以高效准确地确定业务子系统的最大系统容量、容灾系统容量，并基于业务子系统的最大系统容量、容灾系统容量可以实时准确地确定出业务子系统的系统容量，而无需依靠人工过多的介入，有助于减少依靠人工确定系统容量所耗费的时间和人力，并有助于确保系统容量确定的实时性、准确性。
[0025]
可选地，所述业务子系统为联机业务子系统；
[0026]
根据下述公式(3)确定所述联机业务子系统的最大业务处理能力；
[0027]
所述公式(3)为：
[0028][0029]
其中，最大tps请求量(transactions per second，事务数/秒)表示单位时间内的最大请求事务数。
[0030]
可选地，所述业务子系统为批量业务子系统；
[0031]
根据下述公式(4)确定所述批量业务子系统的最大业务处理能力；
[0032]
所述公式(4)为：
[0033][0034]
可选地，所述方法还包括：
[0035]
根据所述业务子系统的当前运行信息，确定所述业务子系统的动态系统容量。
[0036]
上述技术方案中，通过实时获取业务子系统的当前运行信息，并基于业务子系统的当前运行信息可以实时准确地确定业务子系统的动态系统容量，以便为后续根据容量计算模型实时准确地确定出业务子系统的系统容量提供支持。
[0037]
第二方面，本发明实施例还提供了一种确定系统容量的装置，包括：
[0038]
采集单元，用于采集应用系统中各业务子系统的当前运行信息；
[0039]
处理单元，用于针对至少一个业务子系统，从所述业务子系统的当前运行信息中确定各容量影响因素的实时信息；根据所述各容量影响因素的实时信息和所述业务子系统的容量计算模型，确定所述业务子系统的系统容量；其中，所述容量计算模型中设置有通过业务子系统的历史运行信息确定的各容量影响因素的权重。
[0040]
可选地，所述处理单元具体用于：
[0041]
根据如下方式确定所述各容量影响因素的权重：
[0042]
基于层次分析法，对所述应用系统的历史运行信息进行分析处理，确定作为方案层的各第一影响因素、作为准则层的各第二影响因素及作为目标层的系统容量；各容量影响因素包括所述各第一影响因素和所述各第二影响因素；
[0043]
基于层次分析法，确定所述各第一影响因素的第一权重和所述各第二影响因素的第二权重。
[0044]
可选地，所述处理单元具体用于：
[0045]
所述各第一影响因素包括单机处理能力和机器数；所述各第二影响因素包括容灾能力、机器负载、存储负载及业务量负载。
[0046]
可选地，所述处理单元具体用于：
[0047]
根据下述公式(1)确定所述业务子系统的最大系统容量；
[0048]
所述公式(1)为：
[0049]
最大系统容量＝最大业务处理能力
÷
(负载状况
×
负载权重)..............(1)
[0050]
根据下述公式(2)确定所述业务子系统的容灾系统容量；
[0051]
所述公式(2)为：
[0052]
容灾系统容量＝容灾能力
×
最大系统容量
×
容灾能力的权重.............(2)
[0053]
其中，负载状况包括机器负载、存储负载和业务量负载，容灾能力为可用机器数占总机器数的占比。
[0054]
可选地，所述业务子系统为联机业务子系统；
[0055]
所述处理单元具体用于：
[0056]
根据下述公式(3)确定所述联机业务子系统的最大业务处理能力；
[0057]
所述公式(3)为：
[0058]
[0059]
其中，最大tps请求量(transactions per second，事务数/秒)表示单位时间内的最大请求事务数。
[0060]
可选地，所述业务子系统为批量业务子系统；
[0061]
所述处理单元具体用于：
[0062]
根据下述公式(4)确定所述批量业务子系统的最大业务处理能力；
[0063]
所述公式(4)为：
[0064][0065]
其中，存储性能系数、网络时延系数均为常数。
[0066]
可选地，所述处理单元还用于：
[0067]
根据所述业务子系统的当前运行信息，确定所述业务子系统的动态系统容量。
[0068]
第三方面，本发明实施例提供一种计算设备，包括：
[0069]
存储器，用于存储计算机程序；
[0070]
处理器，用于调用所述存储器中存储的计算机程序，按照获得的程序执行确定系统容量的方法。
[0071]
第四方面，本发明实施例提供一种计算机可读存储介质，所述计算机可读存储介质存储有计算机可执行程序，所述计算机可执行程序用于使计算机执行确定系统容量的方法。
附图说明
[0072]
为了更清楚地说明本发明实施例中的技术方案，下面将对实施例描述中所需要使用的附图作简要介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域的普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。
[0073]
图1为本发明实施例提供的一种系统架构的示意图；
[0074]
图2为本发明实施例提供的一种确定系统容量的方法的流程示意图；
[0075]
图3为本发明实施例提供的一种层次结构模型的示意图；
[0076]
图4为本发明实施例提供的一种联机子系统容量计算模型中系统容量与请求数的关系示意图；
[0077]
图5为本发明实施例提供的一种联机子系统容量计算模型中系统容量与故障机器数的关系示意图；
[0078]
图6为本发明实施例提供的一种联机子系统的容量计算结果示意图；
[0079]
图7为本发明实施例提供的一种批量任务子系统容量与批量任务运行时长的关系示意图；
[0080]
图8为本发明实施例提供的一种批量任务内涉及账户数与批量任务处理时长的关系示意图；
[0081]
图9为本发明实施例提供的一种批量任务子系统的容量计算结果示意图；
[0082]
图10为本发明实施例提供的一种确定系统容量的装置的结构示意图。
具体实施方式
[0083]
为了使本发明的目的、技术方案和优点更加清楚，下面将结合附图对本发明作进一步地详细描述，显然，所描述的实施例仅仅是本发明的一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其它实施例，都属于本发明保护的范围。
[0084]
下面首先对本发明实施例中涉及的部分用语进行解释说明，以便于本领域技术人员进行理解。
[0085]
(1)it系统：it全称internet technology，it系统即互联网应用系统，本发明实施例中所提到的应用系统可以指代银行存款业务的互联网应用系统，当然也可以指代金融领域的其它交易应用系统，本发明实施例对此并不作限制。
[0086]
(2)容量：应用系统(比如银行it系统等)能够支撑终端服务请求所需要的服务器资源数量。
[0087]
(3)容量平台：用于对应用系统(比如银行it系统等)的容量进行容量计算，并反馈出合理的容量评估结果供运维人员参考。
[0088]
(4)tps：transactions per second，也就是事务数/秒。其中，一个事务是指一个客户端向服务器发送请求然后服务器做出反应的过程。客户端在发送请求时开始计时，收到服务器响应后结束计时，以此来计算使用的时间和完成的事务个数。一个事务即一笔交易。
[0089]
如上介绍了本发明实施例中涉及的部分用语，下面对本发明实施例涉及的技术特征进行介绍。
[0090]
由于现有技术依靠人工对银行系统的容量进行评估，需要耗费较长的精力和时间，且由于评估的银行系统大都是线上运行的系统，评估后的应用存在滞后性。此外，由于人工的评估结果不准确，导致评估的容量小于实际容量或者评估的容量大于实际容量，导致系统因负载不足出现交易异常或者导致服务器资源浪费。因此，本发明实施例通过构建服务器容量平台，替代人工，用以快速准确地评估出系统容量，以便解决现有技术中存在人工评估系统容量导致评估效率低、准确性低的问题。
[0091]
为了便于理解本发明实施例，首先以图1中示出的系统架构为例说明适用于本发明实施例容量计算的系统架构。如图1所示，如图1所示，该系统架构可以包括容量平台和外部系统。由于应用系统(比如银行存款it系统等)一般都包括联机系统和批量任务系统两部分，因此容量平台采集的对象为联机系统和批量任务系统。
[0092]
其中，容量平台可以包括采集模块101和容量计算模块102。该容量计算模块可以包括联机系统计算模块1021和批量任务系统计算模块1022。
[0093]
采集模块101用于对应用系统(比如银行存款it系统等)的运行信息进行采集(比如定时采集，采集频率为每1秒采集一次)。同时对采集到的应用系统的运行信息进行分析归类整合。比如将每秒采集到的联机系统的请求量进行规整(加权平均)，整理为1分钟的数据，并输入给容量计算模块102进行容量计算。其中，采集模块可以设置在服务器中，以便于对应用系统的运行信息进行采集，也可以是人工收集应用系统的运行信息并进行归类整理后再输入到容量计算模块102进行容量计算。
[0094]
容量计算模块102用于将采集模块整理好的数据，输入预先配置好的容量计算模
型进行容量计算(比如联机系统的运行数据输入联机系统计算模块1021进行容量计算，批量任务系统的运行数据输入批量任务系统计算模块1022进行容量计算)，得到容量计算结果，即为应用系统(比如银行it系统等)的实时容量，并将该实时容量反馈给用户(比如运维人员或成本运营规划人员等)，用户可以根据容量计算结果确定是否需要对应用系统进行扩容或缩容。
[0095]
外部系统可以包括应用系统(比如银行存款it系统等)和用户(比如运维人员或成本运营规划人员等)。其中，应用系统用于为容量平台提供应用系统的运行信息(比如联机系统的实际请求量、各联机交易执行耗时，批量任务系统的批量任务数量、批量任务执行耗时、系统内主机cpu负载、内存负载、硬盘i/o负载、存储服务使用情况、机器数量等)；用户用于接收容量平台对应用系统的运行信息进行容量计算得到的容量计算结果，并根据容量计算结果确定是否需要对应用系统进行扩容或缩容。
[0096]
需要说明的是，上述图1所示的结构仅是一种示例，本发明实施例对此不做限定。
[0097]
基于上述描述，图2示例性的示出了本发明实施例提供的一种确定系统容量的方法的流程，该流程可以由确定系统容量的装置执行。
[0098]
如图2所示，该流程具体包括：
[0099]
步骤201，采集应用系统中各业务子系统的当前运行信息。
[0100]
步骤202，针对至少一个业务子系统，从所述业务子系统的当前运行信息中确定各容量影响因素的实时信息。
[0101]
步骤203，根据所述各容量影响因素的实时信息和所述业务子系统的容量计算模型，确定所述业务子系统的系统容量。
[0102]
上述步骤201中，本发明实施例利用采集模块可以实时采集应用系统中各业务子系统的当前运行信息，例如采集模块可以是单个服务器，也可以是服务器集群，利用单个服务器或服务集群采集各业务子系统的当前运行信息。其中，服务器可以是独立的物理服务器，也可以是多个物理服务器构成的服务器集群或者分布式系统，还可以是提供云服务、云计算、云存储、网络服务、人工智能平台等基础云计算服务的云服务器。当然采集模块也可以是人工收集各业务子系统的当前运行信息并进行归类整理。在实际应用场景中，本发明实施例对此并不作限制。在对各业务子系统的当前运行信息进行采集时，比如每1秒钟采集一次或每2秒钟采集一次各业务子系统的当前运行信息等，可以根据实际业务场景的需要进行设置，本发明实施例对此并不作限制。该当前运行信息可以包括各业务子系统的各容量影响因素的实时信息，比如以业务子系统为联机子系统和批量任务子系统为例对采集的当前运行信息进行说明，该当前运行信息可以包括联机系统的实际请求量(tps)、各联机交易执行耗时，批量任务系统的批量任务数量，批量任务执行耗时，系统内主机cpu负载、内存负载、硬盘i/o负载，存储服务使用情况(比如数据库容量、数据库访问次数等)、机器数量等。在对各业务子系统的当前运行信息进行采集后，将采集到的各业务子系统的当前运行信息存储在数据库。
[0103]
上述步骤202和步骤203中，针对至少一个业务子系统，可以基于通过业务子系统的历史运行信息确定的容量计算模型的各容量影响因素以及各容量影响因素的权重，从业务子系统的当前运行信息中确定出各容量影响因素的实时信息，并将各容量影响因素的实时信息输入到业务子系统的容量计算模型中，确定出业务子系统的系统容量。由于结合各
容量影响因素的实时信息和容量计算模型对系统容量进行自动化计算，如此可以避免人工过多的介入，有助于减少依靠人工确定系统容量所耗费的时间和人力，并有助于确保系统容量确定的实时性、准确性，从而可以解决现有技术中存在人工评估系统容量导致评估效率低、准确性低的问题。其中，该各容量影响因素可以包括各第一影响因素和各第二影响因素。可以基于层次分析法和应用系统的历史运行信息确定出各容量影响因素的权重，具体过程为：基于层次分析法，对应用系统的历史运行信息进行分析处理，确定作为方案层的各第一影响因素、作为准则层的各第二影响因素及作为目标层的系统容量；基于层次分析法，确定各第一影响因素的第一权重和各第二影响因素的第二权重。通过层次分析法对应用系统的历史运行信息进行分析处理，可以快速准确地确定出各第一影响因素的第一权重和各第二影响因素的第二权重，以便后续容量计算模型根据各第一影响因素的第一权重和各第二影响因素的第二权重确定业务子系统的系统容量。其中，各第一影响因素可以包括单机处理能力、机器数和线程数；各第二影响因素可以包括容灾能力、机器负载、存储负载及业务量负载。
[0104]
示例性地，本发明实施例以应用系统为银行存款it系统为例，对确定业务子系统的系统容量的过程进行描述。其中，银行存款it系统可以包括联机业务子系统和批量业务子系统。需要说明的是，本发明实施例对应用系统的范围并不作限制，在其它业务应用场景中，其它业务应用场景对应的应用系统也可以采用本发明提供的技术方案实现对系统容量的计算。
[0105]
根据下述公式(1)确定业务子系统的最大系统容量，该公式(1)具体为：
[0106]
最大系统容量＝最大业务处理能力
÷
(负载状况
×
负载权重)..............(1)根据公式(2)确定业务子系统的容灾系统容量，该公式(2)具体为：
[0107]
容灾系统容量＝容灾能力
×
最大系统容量
×
容灾能力的权重.............(2)
[0108]
其中，负载状况包括机器负载、存储负载和业务量负载，容灾能力为可用机器数占总机器数的占比。
[0109]
需要说明的是，若业务子系统为联机业务子系统，则根据下述公式(3)确定联机业务子系统的最大业务处理能力。该公式(3)具体为：
[0110][0111]
其中，最大tps请求量(transactions per second，事务数/秒)表示单位时间内的最大请求事务数。
[0112]
若业务子系统为批量业务子系统，则根据下述公式(4)确定批量业务子系统的最大业务处理能力。该公式(4)具体为：
[0113][0114]
其中，存储性能系数、网络时延系数均为常数。
[0115]
此外，在本发明实施例的具体实施过程中，根据业务子系统的当前运行信息，可以快速准确地确定出业务子系统的动态系统容量。比如通过监控业务子系统的实时请求量或批量任务处理量等可以确定出业务子系统的动态系统容量。
[0116]
示例性地，下面继续以应用系统为银行存款it系统为例，对本发明实施例中涉及
的容量计算模块的具体实施过程进行描述。
[0117]
由于银行存款it系统可以包括联机子系统和批量任务子系统两部分，因此本发明的技术方案涉及的容量计算模型也可以由两部分构成，即联机子系统容量计算模型和批量任务子系统容量计算模型。需要说明的是，本发明的技术方案涉及的容量计算模型所依赖的各项计算因子主要来自于各采集数据，比如机器数量、单实例应用程序可处理的能力、单实例的处理线程等。而这些计算因子分别占有不同的影响权重，会对容量计算模型的输出结果产生不同的影响。因此在执行容量计算模型前，需要结合实际的业务场景得到不同计算因子各自的影响权重，再结合容量计算模型进行计算可以得到银行存款it系统的容量。
[0118]
其中，容量计算模型的构建过程具体为：
[0119]
step1：利用层次分析法(analytic hierarchy process，ahp)对银行存款it系统的影响因子的影响权重进行分析，得到容量计算模型的影响因子及其影响权重。
[0120]
首先介绍层次分析法中的层次结构模型，参考图3，图3为本发明实施例提供的一种层次结构模型的示意图。该层次结构模型包括目的层(系统容量)、准则层(a1容灾能力、a2机器负载、a3数据库负载、a4系统负载)和方案层(b1机器数、b2单机处理能力、b3配置线程数)。
[0121]
下面对利用层次分析法确定影响因子及其影响权重的过程进行介绍。
[0122]
a、确定容量计算模型的影响因子。
[0123]
由于在确定各层次各因素之间的影响权重时，如果只是定性的结果(比如a1容灾能力占比0.3、a2机器负载占比0.2等)，则不容易被用户认可或易导致容量计算模型计算出的结果不准确。因此本发明实施例采用层次分析法中的一致矩阵法，即：不把所有因素放在一起比较，而是两两相互比较；对此时采用相对尺度，以尽可能减少性质不同因素相互比较的困难，以提高准确度。其中，一致矩阵法是表示本层所有因素针对上一层某一个因素(比如准则层或目标层)的相对重要性的比较。如表1所示，一致矩阵法的元素a
ij
表示的是第i个因素相对于第j个因素的比较结果，这个值使用的是santy的1-9标度方法给出的。
[0124]
表1
[0125][0126]
b、通过一致矩阵法的两两相互比较，可以得到，在系统容量计算模型中，关键的几个影响因子为机器数、单机的处理能力，以及单机上部署的应用实例所配置的线程数。在确定了对容量计算公式所造成影响的影响因子后，还需要对这些影响因子各自的权重占比进行分析。其中，本发明实施例将机器数定义为b1，单机处理能力定义为b2，应用实例所配置的线程数定义为b3。
[0127]
c、确定容量计算模型的影响因子的影响权重。
[0128]
对b层的各层因子(机器数b1、单机处理能力b2、配置线程数b3)进行归一化处理，得到归一向量w，即w＝{w1,w2,
…
,w
n
}，且w
i
表示同一层第i个因素对于上一层某因素相对重要性计算各层中各元素(即影响因子)对总目标的合成权重，最后即可得到b层的层次总排序。
[0129]
鉴于此，b层中三个因素对总目标(系统容量)的排序为a1、a2、a3，则b层中的各个因素对a层中因素为a
j
的层次单排序为b
1j
,b
2j
,
…
b
nj
。因此b层的层次总排序为：
[0130][0131]
即b层第i个因素对总目标的影响权重为由于b层中各因素是a层中各因素两两对比获得，因此可以通过b层各因素的影响权重反推出a层各因素的影响权重，即可以得到a层中第i个因素对总目标(系统容量)的影响权重。
[0132]
d、由于在系统实际运行中，也会有其它定性规则控制着a层各因子(比如业务系统高可用规则、负载要求规则等)，因此还需得到a层中各因子的影响权重。本发明实施例采用控制变量法，例如，在计算a1的影响权重时，控制单机处理能力b2、配置线程数b3的值不变。由于b层中各因素是a层中各因素两两对比获得，因此可以通过b层各因素的影响权重反推出a层各因素的影响权重，即可根据b层中第i个因素计算出a1对b1的影响权重(由于b2、b3的值不变，即可认为该影响权重是a1对总目标的影响权重)。其中，b层第i个因素对总目标的影响权重为此外，由于b层中各因素是a层中各因素两两对比获得的，因此计算出a1对b1的影响权重有多个，如此还需要对a1的多个影响权重进行加权平均，得到a1最终的影响权重，即影响因子a1的影响权重占比系数为k1。a层中其余因子的计算方法以此类推。同时可以得到a层中各因素的权值的计算公式，该计算公式为：
[0133]
f1＝a
×
k
i
+(p+q)................................................(6)
[0134]
其中，f1为b层第1个因素对总目标的影响权重，a为表示a层中各因素，k
i
为a层中某一因素的权值，即a层中某一因素的影响权重占比系数，p为单机处理能力b2对应的固定值，是一常数，q为配置线程数b3对应的固定值，是一常数。
[0135]
需要说明的是，在计算a1的影响权重时，也可以控制机器数b1、配置线程数b3的值不变，即可根据b层中第i个因素计算出a1对b2的影响权重(由于b1、b3的值不变，即可认为该影响权重是a1对总目标的影响权重)，如此可以采用上述的计算思路来计算出a1最终的影响权重，即影响因子a1的影响权重占比系数，a层中其余因子的计算方法以此类推。或者在计算a1的影响权重时，也可以控制机器数b1、单机处理能力b2的值不变，即可根据b层中第i个因素计算出a1对b3的影响权重(由于b1、b2的值不变，即可认为该影响权重是a1对总目标的影响权重)，如此可以采用上述的计算思路来计算出a1最终的影响权重，即影响因子a1的影响权重占比系数，a层中其余因子的计算方法以此类推。当然，在确定a2、a3或a4的影响权重时，也可以采用上述提供的本发明实施例的技术方案进行计算，在此不再赘述。
[0136]
step2：构建容量计算模型。
[0137]
在确定出系统容量的影响因子以及各影响因子的影响权重后，就可以对容量计算模型进行构建。
[0138]
(1)构建联机系统容量计算模型。
[0139]
a、各层影响因子的取值来源。
[0140]
由于一套银行存款it系统的单机处理性能主要是由系统程序决定的(即n台服务器在1秒内能处理的交易请求m应该趋近于一个常数)。因而可以认为联机子系统的容量等于系统可以处理的请求量(tps)。经过分析，联机子系统的容量主要是由联机子系统的请求量(tps)、请求处理时延、主机cpu负载、系统容灾策略(容灾能力)确定。示例性地，图4为本发明实施例提供的一种联机子系统容量计算模型中系统容量与请求数的关系示意图。如图4所示，当请求量越大时，联机子系统需要处理的请求也就越多，对应消耗的cpu计算资源也就越多，主机cpu负载也会因此提高。
[0141]
b、各层影响因子及各层影响因子的影响权重代入公式计算。
[0142]
示例性地，图5为本发明实施例提供的一种联机子系统容量计算模型中系统容量与故障机器数的关系示意图。如图5所示，当联机子系统在集群内出现故障时，相对应的集群处理性能也会下降(集群内有n台机器时，故障n台机器时，集群内处理性能损失n/n)，因此机器在出现故障异常时，也会影响联机子系统容量计算模型对系统容量的评估计算，因此系统容灾策略(容灾能力)也是联机子系统容量计算模型需要考虑的一个因素。
[0143]
根据上述层次分析法得到的探索关系，套入各层影响因子的影响权重，即可以推导出联机子系统的容量公式模型近似为：
[0144][0145][0146]
其中，最大tps请求量(transactions per second，事务数/秒)表示单位时间内的最大请求事务数，负载状况可以包括机器负载、存储负载和业务量负载，负载权重为各负载对应的影响权重，α为单机处理能力的影响权重。
[0147]
由于还需要考虑容灾场景，即出现集群内机器故障不可用的场景，则联机子系统的实时容量模型为：
[0148][0149]
其中，k1为容灾场景下容灾能力的影响权重。
[0150]
鉴于此，对于联机子系统容量计算模块，将联机子系统的当前运行信息输入到联机子系统容量计算模块进行容量计算，就可以得到联机子系统的实时动态容量及实时最大容量，并将联机子系统的实时动态容量、实时最大容量以及实时动态容量与实时最大容量的比值反馈给用户，以便用户根据容量平台反馈的结果进行确定是否进行扩容或缩容。参考图6，为本发明实施例提供的一种联机子系统的容量计算结果示意图，根据该示意图，用户可以直观地了解系统容量的实时动态变化，便于用户进行决策。
[0151]
(2)构建批量任务系统容量计算模型。
[0152]
a、各层影响因子的取值来源。
[0153]
由于银行存款系统的批量任务子系统主要是处理批量入账、账务核对、利息计提等，因此批量任务的处理时长与批量任务子系统容量、任务中处理的账户数、批量线程的计算能力、存储服务性能/容量、网络传输耗时等有较大关系。而批量任务子系统容量又与各容量影响因素(可以包括机器负载、数据库负载、容灾能力、机器数、单机处理能力、配置线程数等)以及各容量影响因素的影响权重有关。其中，参考图7，为本发明实施例提供的一种批量任务子系统容量与批量任务运行时长的关系示意图，根据该示意图可知，当批量任务子系统容量越大时，批量任务子系统的运行时长也就越长。参考图8，为本发明实施例提供的一种批量任务内涉及账户数与批量任务处理时长的关系示意图，根据该示意图可知，当批量任务内涉及的账户数逐渐越多时，批量任务的处理时长逐渐增加，之后逐渐趋于稳定。
[0154]
b、各层影响因子及各层影响因子的影响权重代入公式计算。
[0155]
根据上述层次分析法得到的探索关系，套入各层影响因子的影响权重，即可以推导出批量任务子系统的容量公式模型为：
[0156]
最大容量＝单机批量任务处理能力
×
机器数
÷
(负载状况
×
负载权重)......(10)
[0157][0158]
其中，负载状况可以包括机器负载、存储负载和业务量负载，负载权重为各负载状况对应的影响权重，存储性能系数、网络时延系数均为常数。
[0159]
根据上述的系统容量推导，可以得到系统的批量处理能力(如果在系统运行过程中没有变更优化，因此可以认为系统的批量处理能力是一个常数。若有变更优化，容量计算模型也可以根据采集到的运行信息进行计算修正，重新修订该常数值)，如此即可得到批量任务子系统的容量计算模型为：
[0160]
最大容量＝机器数
×
批量处理能力.................................(12)
[0161]
其中，批量处理能力在常态下(即系统运行过程中未进行变更优化)可以被认为是一个常数。
[0162]
由于还需要考虑容灾场景，即出现集群内机器故障不可用的场景，则批量任务子系统的实时容量模型为：
[0163][0164]
其中，k1为容灾场景下容灾能力的影响权重。
[0165]
鉴于此，对于批量任务子系统容量计算模块，在根据采集到的银行存款it系统的当前运行信息后，就可以计算得到银行存款it系统内批量子系统的处理能力，同样可以根据批量任务子系统容量计算模块对批量任务子系统的当前运行信息进行容量计算，能够得到批量任务子系统的实时动态容量及实时最大容量，并将批量任务子系统的实时动态容量、实时最大容量以及实时动态容量与实时最大容量的比值反馈给用户，以便用户根据容量平台反馈的结果进行确定是否进行扩容或缩容。其中，该批量任务子系统的实时动态容量可以通过监控批量任务子系统的当前运行信息(比如批量任务处理量、批量任务执行耗时、批量任务处理能力等)确定出批量任务子系统的动态系统容量。参考图9，为本发明实施例提供的一种批量任务子系统的容量计算结果示意图，根据该示意图，用户可以直观地了解系统容量的实时动态变化，便于用户进行决策。
[0166]
上述实施例表明，通过实时获取应用系统中各业务子系统的当前运行信息，并针对至少一个业务子系统，从业务子系统的当前运行信息中确定各容量影响因素的实时信息。再根据各容量影响因素的实时信息和业务子系统的容量计算模型，确定业务子系统的系统容量。由于结合各容量影响因素的实时信息、各容量影响因素的权重以及容量计算模型对系统容量进行自动化计算，如此可以避免人工过多的介入，有助于减少依靠人工确定系统容量所耗费的时间和人力，并有助于确保系统容量确定的实时性、准确性，从而可以解决现有技术中存在人工评估系统容量导致评估效率低、准确性低的问题。
[0167]
基于相同的技术构思，图10示例性的示出了本发明实施例提供的一种确定系统容量的装置，该装置可以执行确定系统容量的方法的流程。
[0168]
如图10所示，该装置包括：
[0169]
采集单元1001，用于采集应用系统中各业务子系统的当前运行信息；
[0170]
处理单元1002，用于针对至少一个业务子系统，从所述业务子系统的当前运行信息中确定各容量影响因素的实时信息；根据所述各容量影响因素的实时信息和所述业务子系统的容量计算模型，确定所述业务子系统的系统容量；其中，所述容量计算模型中设置有通过业务子系统的历史运行信息确定的各容量影响因素的权重。
[0171]
可选地，所述处理单元1002具体用于：
[0172]
根据如下方式确定所述各容量影响因素的权重：
[0173]
基于层次分析法，对所述应用系统的历史运行信息进行分析处理，确定作为方案层的各第一影响因素、作为准则层的各第二影响因素及作为目标层的系统容量；各容量影响因素包括所述各第一影响因素和所述各第二影响因素；
[0174]
基于层次分析法，确定所述各第一影响因素的第一权重和所述各第二影响因素的第二权重。
[0175]
可选地，所述处理单元1002具体用于：
[0176]
所述各第一影响因素包括单机处理能力和机器数；所述各第二影响因素包括容灾能力、机器负载、存储负载及业务量负载。
[0177]
可选地，所述处理单元1002具体用于：
[0178]
根据下述公式(1)确定所述业务子系统的最大系统容量；
[0179]
所述公式(1)为：
[0180]
最大系统容量＝最大业务处理能力
÷
(负载状况
×
负载权重)..............(1)
[0181]
根据下述公式(2)确定所述业务子系统的容灾系统容量；
[0182]
所述公式(2)为：
[0183]
容灾系统容量＝容灾能力
×
最大系统容量
×
容灾能力的权重.............(2)
[0184]
其中，负载状况包括机器负载、存储负载和业务量负载，容灾能力为可用机器数占总机器数的占比。
[0185]
可选地，所述业务子系统为联机业务子系统；
[0186]
所述处理单元1002具体用于：
[0187]
根据下述公式(3)确定所述联机业务子系统的最大业务处理能力；
[0188]
所述公式(3)为：
[0189][0190]
其中，最大tps请求量(transactions per second，事务数/秒)表示单位时间内的最大请求事务数。
[0191]
可选地，所述业务子系统为批量业务子系统；
[0192]
所述处理单元1002具体用于：
[0193]
根据下述公式(4)确定所述批量业务子系统的最大业务处理能力；
[0194]
所述公式(4)为：
[0195][0196]
其中，存储性能系数、网络时延系数均为常数。
[0197]
可选地，所述处理单元1002还用于：
[0198]
根据所述业务子系统的当前运行信息，确定所述业务子系统的动态系统容量。
[0199]
基于相同的技术构思，本发明实施例提供一种计算设备，包括：
[0200]
存储器，用于存储计算机程序；
[0201]
处理器，用于调用所述存储器中存储的计算机程序，按照获得的程序执行确定系统容量的方法。
[0202]
基于相同的技术构思，本发明实施例提供一种计算机可读存储介质，所述计算机可读存储介质存储有计算机可执行程序，所述计算机可执行程序用于使计算机执行确定系统容量的方法。
[0203]
本领域内的技术人员应明白，本发明的实施例可提供为方法、系统、或计算机程序产品。因此，本发明可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本发明可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、cd-rom、光学存储器等)上实施的计算机程序产品的形式。
[0204]
本发明是参照根据本发明的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。
[0205]
这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。
[0206]
这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。
[0207]
尽管已描述了本发明的优选实施例，但本领域内的技术人员一旦得知了基本创造性概念，则可对这些实施例作出另外的变更和修改。所以，所附权利要求意欲解释为包括优选实施例以及落入本发明范围的所有变更和修改。
[0208]
显然，本领域的技术人员可以对本发明进行各种改动和变型而不脱离本发明的精神和范围。这样，倘若本发明的这些修改和变型属于本申请权利要求及其等同技术的范围之内，则本发明也意图包含这些改动和变型在内。