CN110308925A - 集群容量模型的处理方法及装置 - Google Patents

集群容量模型的处理方法及装置 Download PDF

Info

Publication number
CN110308925A
CN110308925A CN201910495875.6A CN201910495875A CN110308925A CN 110308925 A CN110308925 A CN 110308925A CN 201910495875 A CN201910495875 A CN 201910495875A CN 110308925 A CN110308925 A CN 110308925A
Authority
CN
China
Prior art keywords
capacity
module
cluster
model
online
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
CN201910495875.6A
Other languages
English (en)
Inventor
赵子青
吴峰
郭伟
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Shanghai Yidianshikong Network Co Ltd
Original Assignee
Shanghai Yidianshikong Network Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Shanghai Yidianshikong Network Co Ltd filed Critical Shanghai Yidianshikong Network Co Ltd
Priority to CN201910495875.6A priority Critical patent/CN110308925A/zh
Publication of CN110308925A publication Critical patent/CN110308925A/zh
Withdrawn legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/70—Software maintenance or management

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Abstract

本申请公开了一种集群容量模型的处理方法及装置。该方法包括：判断预设的第一集群容量模型中的模块容量是否有变化；如果是，则确定引起模块容量变化的因素；根据确定的模块容量变化因素，采用模块缩减算法对所述模块执行容量压测操作；迭代执行容量压测操作的结果，得到第二集群容量模型。该装置包括：判断模块、确定模块、执行模块和迭代模块。本申请解决了由于集群容量模型会受产品逻辑改变，开发发布新代码等的影响造成容量为未知变化状况的技术问题。

Description

集群容量模型的处理方法及装置
技术领域
本申请涉及集群容量模型领域，具体而言，涉及一种集群容量模型的处理方法及装置。
背景技术
在集群容量经过真实请求压测，得到分段式精细化管理容量模型，但得到得容量模型只是一个短时间内容量恒定的状态。
在后续产品运营中，产品功能、产品逻辑会定期的发生改变，当产品功能、产品逻辑改变，开发发布新的代码后，代码改变的模块容量会发生改变，此集群容量也发生了改变，模型容量也发生了改变，对应这种情况，集群容量又成了一个未知变化的状况。
针对相关技术中集群容量模型会受产品逻辑改变，开发发布新代码等的影响造成容量为未知变化状况的问题，目前尚未提出有效的解决方案。
发明内容
本申请的主要目的在于提供一种集群容量模型的处理方法及装置，以解决集群容量模型会受产品逻辑改变，开发发布新代码等的影响造成容量为未知变化状况的问题。
为了实现上述目的，根据本申请的一个方面，提供了一种集群容量模型的处理方法。
根据本申请的集群容量模型的处理方法包括：判断预设的第一集群容量模型中的模块容量是否有变化；如果是，则确定引起模块容量变化的因素；根据确定的模块容量变化因素，采用模块缩减算法对所述模块执行容量压测操作；迭代执行容量压测操作的结果，得到第二集群容量模型。
进一步的，判断预设的第一集群容量模型中的模块容量是否有变化包括：
建立第一集群容量模型，其中，所述第一集群容量模型为分段式容量管理模型；
周期性比对第一集群容量模型的模块容量和预设容量是否一致。
进一步的，确定引起模块容量变化的因素包括：
查询所述第一集群容量模型的模块是否接收到在预设时间阈值内的代码发布；
如果是，则将代码发布确定为引起模块容量变化的因素；
将模块容量变化因素在运维端输出。
进一步的，确定引起模块容量变化的因素包括：
查询所述第一集群容量模型的模块是否接收到在预设时间阈值内的代码发布；
如果不是，则将查询结果在运维端输出。
进一步的，采用模块缩减算法对所述模块执行容量压测操作包括：
依照预设缩减规则确定第一模块中设备的待缩减数量；
对缩减后的第一模块执行容量压测操作。
进一步的，迭代执行容量压测操作的结果，得到第二集群容量模型之后还包括：
判断执行容量压测操作的结果；
当判断执行容量压测操作得到的模块容量超出预设上限阈值时，则在运维端输出扩容的提示消息；
当判断执行容量压测操作得到的模块容量超出预设下限阈值时，则在运维端输出缩容的提示消息。
为了实现上述目的，根据本申请的另一方面，提供了一种集群容量模型的处理装置。
根据本申请的集群容量模型的处理装置包括：判断模块，用于判断预设的第一集群容量模型中的模块容量是否有变化；确定模块，用于如果是，则确定引起模块容量变化的因素；执行模块，用于根据确定的模块容量变化因素，采用模块缩减算法对所述模块执行容量压测操作；迭代模块，用于迭代执行容量压测操作的结果，得到第二集群容量模型。
进一步的，所述判断模块包括：建立第一集群容量模型，其中，所述第一集群容量模型为分段式容量管理模型；周期性比对第一集群容量模型的模块容量和预设容量是否一致。
进一步的，所述确定模块包括：查询所述第一集群容量模型的模块是否接收到在预设时间阈值内的代码发布；如果是，则将代码发布确定为引起模块容量变化的因素；将模块容量变化因素在运维端输出。
进一步的，所述确定模块还包括：确定引起模块容量变化的因素包括：查询所述第一集群容量模型的模块是否接收到在预设时间阈值内的代码发布；如果不是，则将查询结果在运维端输出。
在本申请实施例中，采用处理集群容量模型的方式，通过判断预设的第一集群容量模型中的模块容量是否有变化；如果是，则确定引起模块容量变化的因素；根据确定的模块容量变化因素，采用容量调用算法对所述模块执行容量压测操作；迭代执行容量压测操作的结果，得到第二集群容量模型；达到了确定模块容量变化因素，并迭代得到新的集群容量模型的目的，避免集群容量模型受产品逻辑改变，开发发布新代码等影响的情况，从而实现了能够监控容量变化状况的技术效果，进而解决了由于集群容量模型会受产品逻辑改变，开发发布新代码等的影响造成容量为未知变化状况的技术问题。
附图说明
构成本申请的一部分的附图用来提供对本申请的进一步理解，使得本申请的其它特征、目的和优点变得更明显。本申请的示意性实施例附图及其说明用于解释本申请，并不构成对本申请的不当限定。在附图中：
图1是根据本申请第一实施例的集群容量模型的处理方法示意图；
图2是根据本申请第二实施例的集群容量模型的处理方法示意图；
图3是根据本申请第三实施例的集群容量模型的处理方法示意图；
图4是根据本申请第四实施例的集群容量模型的处理方法示意图；
图5是根据本申请第五实施例的集群容量模型的处理方法示意图；
图6是根据本申请第六实施例的集群容量模型的处理方法示意图；
图7是根据本申请第一实施例的集群容量模型的处理装置示意图；
图8是根据本申请一优选实施例的集群容量模型示意图。
具体实施方式
为了使本技术领域的人员更好地理解本申请方案，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分的实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都应当属于本申请保护的范围。
需要说明的是，本申请的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本申请的实施例。此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。
在本申请中，术语“上”、“下”、“左”、“右”、“前”、“后”、“顶”、“底”、“内”、“外”、“中”、“竖直”、“水平”、“横向”、“纵向”等指示的方位或位置关系为基于附图所示的方位或位置关系。这些术语主要是为了更好地描述本发明及其实施例，并非用于限定所指示的装置、元件或组成部分必须具有特定方位，或以特定方位进行构造和操作。
并且，上述部分术语除了可以用于表示方位或位置关系以外，还可能用于表示其他含义，例如术语“上”在某些情况下也可能用于表示某种依附关系或连接关系。对于本领域普通技术人员而言，可以根据具体情况理解这些术语在本发明中的具体含义。
此外，术语“安装”、“设置”、“设有”、“连接”、“相连”、“套接”应做广义理解。例如，可以是固定连接，可拆卸连接，或整体式构造；可以是机械连接，或电连接；可以是直接相连，或者是通过中间媒介间接相连，又或者是两个装置、元件或组成部分之间内部的连通。对于本领域普通技术人员而言，可以根据具体情况理解上述术语在本发明中的具体含义。
需要说明的是，在不冲突的情况下，本申请中的实施例及实施例中的特征可以相互组合。下面将参考附图并结合实施例来详细说明本申请。
根据本发明实施例，提供了一种集群容量模型的处理方法，如图1所示，该方法包括如下的步骤S100至步骤S106：
步骤S100、判断预设的第一集群容量模型中的模块容量是否有变化；
具体的，如图2所示，判断预设的第一集群容量模型中的模块容量是否有变化包括：
步骤S200、建立第一集群容量模型，其中，所述第一集群容量模型为分段式容量管理模型；
步骤S202、周期性比对第一集群容量模型的模块容量和预设容量是否一致。
举个例子，可以建立如图8所示的集群容量模型系统(第一集群容量模型)，该模型系统可以同时支撑40万用户在线或40万用户同时下订单请求；其包含4个业务模块；模型为分段式精细化集群容量管理模型，具体可参照下表：
按照示例，得到以上的第一集群容量模型之后，按照预设的周期比对模块容量(真实容量)和预设容量，从而可以看出真实容量和预设容量之间是否存在变化，为进一步处理提供保障。
比如：预设的周期为每五分钟监控一次真实容量和预设容量是否一致。
步骤S102、如果是，则确定引起模块容量变化的因素；
优选的，如图3所示，确定引起模块容量变化的因素包括：
步骤S300、查询所述第一集群容量模型的模块是否接收到在预设时间阈值内的代码发布；
步骤S302、如果是，则将代码发布确定为引起模块容量变化的因素；
步骤S304、将模块容量变化因素在运维端输出。
如果判断出不一致，则表明容量存在变化，再判断在预设时间阈值内是否发布代码，具体操作为查询第一集群容量模型的模块是否接收到在预设时间阈值内的代码发布，如果接收到，则表明在预设时间阈值内代理发布过代码，将代码发布确定为引起模块容量变化的因素，并且将模块容量变化因素在运维端输出，提醒人员变化因素为代码发布引起，从而人员可以知晓接下来将会进行重新压测并迭代，同时为接下来的压测提供判断基础。
如果判断出一致，则表明容量不存在变化，系统继续正常运行，不执行重新压测并迭代的操作。
在本实施例中，预设时间阈值为3天。
优选的，如图4所示，确定引起模块容量变化的因素包括：
步骤S400、查询所述第一集群容量模型的模块是否接收到在预设时间阈值内的代码发布；
步骤S402、如果不是，则将查询结果在运维端输出。
如果判断出不一致，则表明容量存在变化，再判断在预设时间阈值内是否发布代码，具体操作为查询第一集群容量模型的模块是否接收到在预设时间阈值内的代码发布，如果没接收到，则表明在预设时间阈值内代理没有发布过代码，需要把容量发生变化归为其他情况；有可能是产品功能、逻辑的改变而引起的变化，此类情况，需要通知运维人员人工进行分析确认容量变化的因素。具体而言，如果没接收到，将查询结果发送至运维端，运维人员通过运维端查看查询结果，并且人工判断出引起模块容量变化的因素。
步骤S104、根据确定的模块容量变化因素，采用模块缩减算法对所述模块执行容量压测操作；
当判断在预设时间内接收到代码发布后，确定代码发布为模块容量变化因素，则采用采用模块缩减算法对所述模块执行容量压测操作；实现了重新压测，为集群容量模型提供保障。
具体的，如图5所示，采用模块缩减算法对所述模块执行容量压测操作包括：
步骤S500、依照预设缩减规则确定第一模块中设备的待缩减数量；
步骤S502、对缩减后的第一模块执行容量压测操作。
本实施例中，以模块2发生变化为例：
集群日常用户在线峰值30万，但能支撑最大的峰值时50万，那此时在日常30 万及以下的峰值模块2的分段式精细化容量数据可以直接通过监控记录下来；如10万用户在线时,模块2容量15％，15万用户在线时模块2容量20％，20万用户在线时模块容量35％，25万用户在线时模块2容量43％，30万用户在线时55％；此时因平时的峰值容量不超过30万，那30万后的容量数据无法通过平时的用户在线来获取数据，那就需要通过缩减模块2的设备量，通过提升单机请求量来压测；
(5万在线) 指标容量 (10万在线) 指标容量 (15万在线) 指标容量 (20万在线) 指标容量 (25万在线) 指标容量
模块2 13％ 模块2 20％ 模块2 28％ 模块2 37％ 模块2 40％
根据缩减模块2下的设备量来做压测，那具体缩减多少台设备？这时就需要根据平时峰值来做核算；比如压测最大50万峰值支撑时，模块2下10台设备，那瓶颈每台设备质量为5万次/(秒.台)，依次换算就会得到如下表：
50万在线 45万在线 40万在线 35万在线 30万在线
模块2(10台设备) 5万/(秒.台) 4.5万/(秒.台) 4万/(秒.台) 3.5万/(秒.台) 3万/(秒.台)
那此时只需要让单机达到以上每个档次的支撑量，就可以转换完成原最大支撑量的压测，就可以得到对应得容量数据；那缩减设备量得算法如下：
50万在线，10台设备，单机5万/(秒.台)-->30万在线，x台设备，单机5 万/(秒.台)，那就可以得出这个x＝6台设备；此时模块2应该缩减设备的量就为4台，保留6台设备既可；
然后根据6台设备的基准两，来算出不同档次单机请求量时，用户同时在线的峰值，如下表：
模块2(6台设备) 模块2(10台设备)
原模型单机5万/(秒.台)用户同时在线峰值 5*6＝30万用户在线 5*10＝50万用户在线
原模型单机4.5万/(秒.台)用户同时在线峰值 4.5*6＝27万用户在线 4.5*10＝45万用户在线
原模型单机4万/(秒.台)用户同时在线峰值 4*6＝24万用户在线 4*10＝40万用户在线
原模型单机3.5万/(秒.台)用户同时在线峰值 3.5*6＝21万用户在线 3.5*10＝35万用户在线
原模型单机3万/(秒.台)用户同时在线峰值 3*6＝18万用户在线 3*10＝30万用户在线
经过以上的方法计算后，就可以先缩减设备，在日常最大在线30万用户峰值下启动对模块2进行压测了，通过观察集群用户的在线量，查看模块2的容量数据，记录如下表：
模块2单机请求量 模块2的容量(6台设备)
集群18万用户在线 3万/(秒.台) 50％
集群21万用户在线 3.5万/(秒.台) 57％
集群24万用户在线 4万/(秒.台) 67％
集群27万用户在线 4.5万/(秒.台) 80％
集群30万用户在线 5万/(秒.台) 95％
然后汇总下没有缩减设备前模块2的容量和缩减后模块2的容量，就能得出代码变更后集群模块2新的容量模型数据如下表：
5万在线容量 10万在线容量 15万在线容量 20万在线容量 25万在线容量
模块2(代码变更后) 13％ 20％ 28％ 37％ 40％
30万在线容量 35万在线容量 40万在线容量 45万在线容量 50万在线容量
模块2(代码变更后) 45％ 53％ 63％ 75％ 90％
然后和没变更前模块2的容量数据对比如下表：
5万在线容量 10万在线容量 15万在线容量 20万在线容量 25万在线容量
模块2(代码变更前) 11％ 16％ 23％ 31％ 36％
模块2(代码变更后) 13％ 20％ 28％ 37％ 40％
30万在线容量 35万在线容量 40万在线容量 45万在线容量 50万在线容量
模块2(代码变更前) 45％ 53％ 63％ 75％ 90％
模块2(代码变更后) 50％ 57％ 68％ 82％ 95％
步骤S106、迭代执行容量压测操作的结果，得到第二集群容量模型。
以上述的示例为例，通过迭代，形成新的容量模型数据如下表：
优选的，如图6所示，迭代执行容量压测操作的结果，得到第二集群容量模型之后还包括：
步骤S600、判断执行容量压测操作的结果；
步骤S602、当判断执行容量压测操作得到的模块容量超出预设上限阈值时，则在运维端输出扩容的提示消息；
步骤S604、当判断执行容量压测操作得到的模块容量超出预设下限阈值时，则在运维端输出缩容的提示消息。
如新变化的代码逻辑非常重，单机消耗的硬件资源远比上面这种情况多，导致在压测时，同时用户在线30万时，模块2的容量已接近上限阈值：95％，此时已达到一个非常警戒的一个状态，那此时集群原最大支撑量已完全改变，不能再支撑到最大的50万用户在线，需要对模块2进行扩容，扩容到50万用户在线时，模块2的容量最大也不能超过上限阈值：95％的警戒值；比如模块 2由原来的10台设备，扩容后变成15台设备。
如新变化的代码逻辑变得非常的轻，胆小消耗原低于原来消耗的情况，在 50万用户同时在线时，模块2的容量也才达到下限阈值：65％左右，这时就可以对模块2进行缩容，比如缩2-3台设备，让模块2在50万用户同时在线时的容量上升到95％左右，已达到模块2的最大合理利用率。
从以上的描述中，可以看出，本发明实现了如下技术效果：
在本申请实施例中，采用处理集群容量模型的方式，通过判断预设的第一集群容量模型中的模块容量是否有变化；如果是，则确定引起模块容量变化的因素；根据确定的模块容量变化因素，采用容量调用算法对所述模块执行容量压测操作；迭代执行容量压测操作的结果，得到第二集群容量模型；达到了确定模块容量变化因素，并迭代得到新的集群容量模型的目的，避免集群容量模型受产品逻辑改变，开发发布新代码等影响的情况，从而实现了能够监控容量变化状况的技术效果，进而解决了由于集群容量模型会受产品逻辑改变，开发发布新代码等的影响造成容量为未知变化状况的技术问题。
需要说明的是，在附图的流程图示出的步骤可以在诸如一组计算机可执行指令的计算机系统中执行，并且，虽然在流程图中示出了逻辑顺序，但是在某些情况下，可以以不同于此处的顺序执行所示出或描述的步骤。
根据本发明实施例，还提供了一种用于实施上述集群容量模型的处理方法的装置，如图1所示，该装置包括：
判断模块10，用于判断预设的第一集群容量模型中的模块容量是否有变化；
具体的，判断预设的第一集群容量模型中的模块容量是否有变化包括：
建立第一集群容量模型，其中，所述第一集群容量模型为分段式容量管理模型；
周期性比对第一集群容量模型的模块容量和预设容量是否一致。
举个例子，可以建立如图8所示的集群容量模型系统(第一集群容量模型)，该模型系统可以同时支撑40万用户在线或40万用户同时下订单请求；其包含4个业务模块；模型为分段式精细化集群容量管理模型，具体可参照下表：
按照示例，得到以上的第一集群容量模型之后，按照预设的周期比对模块容量(真实容量)和预设容量，从而可以看出真实容量和预设容量之间是否存在变化，为进一步处理提供保障。
比如：预设的周期为每五分钟监控一次真实容量和预设容量是否一致。
确定模块20，用于如果是，则确定引起模块容量变化的因素；
优选的，确定引起模块容量变化的因素包括：
查询所述第一集群容量模型的模块是否接收到在预设时间阈值内的代码发布；
如果是，则将代码发布确定为引起模块容量变化的因素；
将模块容量变化因素在运维端输出。
如果判断出不一致，则表明容量存在变化，再判断在预设时间阈值内是否发布代码，具体操作为查询第一集群容量模型的模块是否接收到在预设时间阈值内的代码发布，如果接收到，则表明在预设时间阈值内代理发布过代码，将代码发布确定为引起模块容量变化的因素，并且将模块容量变化因素在运维端输出，提醒人员变化因素为代码发布引起，从而人员可以知晓接下来将会进行重新压测并迭代，同时为接下来的压测提供判断基础。
如果判断出一致，则表明容量不存在变化，系统继续正常运行，不执行重新压测并迭代的操作。
在本实施例中，预设时间阈值为3天。
优选的，确定引起模块容量变化的因素包括：
查询所述第一集群容量模型的模块是否接收到在预设时间阈值内的代码发布；
如果不是，则将查询结果在运维端输出。
如果判断出不一致，则表明容量存在变化，再判断在预设时间阈值内是否发布代码，具体操作为查询第一集群容量模型的模块是否接收到在预设时间阈值内的代码发布，如果没接收到，则表明在预设时间阈值内代理没有发布过代码，需要把容量发生变化归为其他情况；有可能是产品功能、逻辑的改变而引起的变化，此类情况，需要通知运维人员人工进行分析确认容量变化的因素。具体而言，如果没接收到，将查询结果发送至运维端，运维人员通过运维端查看查询结果，并且人工判断出引起模块容量变化的因素。
执行模块30，用于根据确定的模块容量变化因素，采用模块缩减算法对所述模块执行容量压测操作；
当判断在预设时间内接收到代码发布后，确定代码发布为模块容量变化因素，则采用采用模块缩减算法对所述模块执行容量压测操作；实现了重新压测，为集群容量模型提供保障。
具体的，采用模块缩减算法对所述模块执行容量压测操作包括：
依照预设缩减规则确定第一模块中设备的待缩减数量；
对缩减后的第一模块执行容量压测操作。
本实施例中，以模块2发生变化为例：
集群日常用户在线峰值30万，但能支撑最大的峰值时50万，那此时在日常30 万及以下的峰值模块2的分段式精细化容量数据可以直接通过监控记录下来；如10万用户在线时,模块2容量15％，15万用户在线时模块2容量20％，20万用户在线时模块容量35％，25万用户在线时模块2容量43％，30万用户在线时55％；此时因平时的峰值容量不超过30万，那30万后的容量数据无法通过平时的用户在线来获取数据，那就需要通过缩减模块2的设备量，通过提升单机请求量来压测；
(5万在线) 指标容量 (10万在线) 指标容量 (15万在线) 指标容量 (20万在线) 指标容量 (25万在线) 指标容量
模块2 13％ 模块2 20％ 模块2 28％ 模块2 37％ 模块2 40％
根据缩减模块2下的设备量来做压测，那具体缩减多少台设备？这时就需要根据平时峰值来做核算；比如压测最大50万峰值支撑时，模块2下10台设备，那瓶颈每台设备质量为5万次/(秒.台)，依次换算就会得到如下表：
50万在线 45万在线 40万在线 35万在线 30万在线
模块2(10台设备) 5万/(秒.台) 4.5万/(秒.台) 4万/(秒.台) 3.5万/(秒.台) 3万/(秒.台)
那此时只需要让单机达到以上每个档次的支撑量，就可以转换完成原最大支撑量的压测，就可以得到对应得容量数据；那缩减设备量得算法如下：
50万在线，10台设备，单机5万/(秒.台)-->30万在线，x台设备，单机5 万/(秒.台)，那就可以得出这个x＝6台设备；此时模块2应该缩减设备的量就为4台，保留6台设备既可；
然后根据6台设备的基准两，来算出不同档次单机请求量时，用户同时在线的峰值，如下表：
模块2(6台设备) 模块2(10台设备)
原模型单机5万/(秒.台)用户同时在线峰值 5*6＝30万用户在线 5*10＝50万用户在线
原模型单机4.5万/(秒.台)用户同时在线峰值 4.5*6＝27万用户在线 4.5*10＝45万用户在线
原模型单机4万/(秒.台)用户同时在线峰值 4*6＝24万用户在线 4*10＝40万用户在线
原模型单机3.5万/(秒.台)用户同时在线峰值 3.5*6＝21万用户在线 3.5*10＝35万用户在线
原模型单机3万/(秒.台)用户同时在线峰值 3*6＝18万用户在线 3*10＝30万用户在线
经过b的方法计算后，就可以先缩减设备，在日常最大在线30万用户峰值下启动对模块2进行压测了，通过观察集群用户的在线量，查看模块2的容量数据，记录如下表：
模块2单机请求量 模块2的容量(6台设备)
集群18万用户在线 3万/(秒.台) 50％
集群21万用户在线 3.5万/(秒.台) 57％
集群24万用户在线 4万/(秒.台) 67％
集群27万用户在线 4.5万/(秒.台) 80％
集群30万用户在线 5万/(秒.台) 95％
然后汇总下没有缩减设备前模块2的容量和缩减后模块2的容量，就能得出代码变更后集群模块2新的容量模型数据如下表：
5万在线容量 10万在线容量 15万在线容量 20万在线容量 25万在线容量
模块2(代码变更后) 13％ 20％ 28％ 37％ 40％
30万在线容量 35万在线容量 40万在线容量 45万在线容量 50万在线容量
模块2(代码变更后) 45％ 53％ 63％ 75％ 90％
然后和没变更前模块2的容量数据对比如下表：
5万在线容量 10万在线容量 15万在线容量 20万在线容量 25万在线容量
模块2(代码变更前) 11％ 16％ 23％ 31％ 36％
模块2(代码变更后) 13％ 20％ 28％ 37％ 40％
30万在线容量 35万在线容量 40万在线容量 45万在线容量 50万在线容量
模块2(代码变更前) 45％ 53％ 63％ 75％ 90％
模块2(代码变更后) 50％ 57％ 68％ 82％ 95％
迭代模块40，用于迭代执行容量压测操作的结果，得到第二集群容量模型。
以上述的示例为例，通过迭代，形成新的容量模型数据如下表：
优选的，迭代执行容量压测操作的结果，得到第二集群容量模型之后还包括：
判断执行容量压测操作的结果；
当判断执行容量压测操作得到的模块容量超出预设上限阈值时，则在运维端输出扩容的提示消息；
当判断执行容量压测操作得到的模块容量超出预设下限阈值时，则在运维端输出缩容的提示消息。
如新变化的代码逻辑非常重，单机消耗的硬件资源远比上面这种情况多，导致在压测时，同时用户在线30万时，模块2的容量已接近上限阈值：95％，此时已达到一个非常警戒的一个状态，那此时集群原最大支撑量已完全改变，不能再支撑到最大的50万用户在线，需要对模块2进行扩容，扩容到50万用户在线时，模块2的容量最大也不能超过上限阈值：95％的警戒值；比如模块 2由原来的10台设备，扩容后变成15台设备。
如新变化的代码逻辑变得非常的轻，胆小消耗原低于原来消耗的情况，在 50万用户同时在线时，模块2的容量也才达到下限阈值：65％左右，这时就可以对模块2进行缩容，比如缩2-3台设备，让模块2在50万用户同时在线时的容量上升到95％左右，已达到模块2的最大合理利用率。
从以上的描述中，可以看出，本发明实现了如下技术效果：
在本申请实施例中，采用处理集群容量模型的方式，通过判断预设的第一集群容量模型中的模块容量是否有变化；如果是，则确定引起模块容量变化的因素；根据确定的模块容量变化因素，采用容量调用算法对所述模块执行容量压测操作；迭代执行容量压测操作的结果，得到第二集群容量模型；达到了确定模块容量变化因素，并迭代得到新的集群容量模型的目的，避免集群容量模型受产品逻辑改变，开发发布新代码等影响的情况，从而实现了能够监控容量变化状况的技术效果，进而解决了由于集群容量模型会受产品逻辑改变，开发发布新代码等的影响造成容量为未知变化状况的技术问题。
显然，本领域的技术人员应该明白，上述的本发明的各模块或各步骤可以用通用的计算装置来实现，它们可以集中在单个的计算装置上，或者分布在多个计算装置所组成的网络上，可选地，它们可以用计算装置可执行的程序代码来实现，从而，可以将它们存储在存储装置中由计算装置来执行，或者将它们分别制作成各个集成电路模块，或者将它们中的多个模块或步骤制作成单个集成电路模块来实现。这样，本发明不限制于任何特定的硬件和软件结合。
以上所述仅为本申请的优选实施例而已，并不用于限制本申请，对于本领域的技术人员来说，本申请可以有各种更改和变化。凡在本申请的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本申请的保护范围之内。

Claims (10)

1.一种集群容量模型的处理方法，其特征在于，包括：
判断预设的第一集群容量模型中的模块容量是否有变化；
如果是，则确定引起模块容量变化的因素；
根据确定的模块容量变化因素，采用模块缩减算法对所述模块执行容量压测操作；
迭代执行容量压测操作的结果，得到第二集群容量模型。
2.根据权利要求1所述的处理方法，其特征在于，判断预设的第一集群容量模型中的模块容量是否有变化包括：
建立第一集群容量模型，其中，所述第一集群容量模型为分段式容量管理模型；
周期性比对第一集群容量模型的模块容量和预设容量是否一致。
3.根据权利要求1所述的处理方法，其特征在于，确定引起模块容量变化的因素包括：
查询所述第一集群容量模型的模块是否接收到在预设时间阈值内的代码发布；
如果是，则将代码发布确定为引起模块容量变化的因素；
将模块容量变化因素在运维端输出。
4.根据权利要求1所述的处理方法，其特征在于，确定引起模块容量变化的因素包括：
查询所述第一集群容量模型的模块是否接收到在预设时间阈值内的代码发布；
如果不是，则将查询结果在运维端输出。
5.根据权利要求1所述的处理方法，其特征在于，采用模块缩减算法对所述模块执行容量压测操作包括：
依照预设缩减规则确定第一模块中设备的待缩减数量；
对缩减后的第一模块执行容量压测操作。
6.根据权利要求1所述的处理方法，其特征在于，迭代执行容量压测操作的结果，得到第二集群容量模型之后还包括：
判断执行容量压测操作的结果；
当判断执行容量压测操作得到的模块容量超出预设上限阈值时，则在运维端输出扩容的提示消息；
当判断执行容量压测操作得到的模块容量超出预设下限阈值时，则在运维端输出缩容的提示消息。
7.一种集群容量模型的处理装置，其特征在于，包括：
判断模块，用于判断预设的第一集群容量模型中的模块容量是否有变化；
确定模块，用于如果是，则确定引起模块容量变化的因素；
执行模块，用于根据确定的模块容量变化因素，采用模块缩减算法对所述模块执行容量压测操作；
迭代模块，用于迭代执行容量压测操作的结果，得到第二集群容量模型。
8.根据权利要求7所述的处理装置，其特征在于，所述判断模块包括：
建立第一集群容量模型，其中，所述第一集群容量模型为分段式容量管理模型；
周期性比对第一集群容量模型的模块容量和预设容量是否一致。
9.根据权利要求7所述的处理装置，其特征在于，所述确定模块包括：
查询所述第一集群容量模型的模块是否接收到在预设时间阈值内的代码发布；
如果是，则将代码发布确定为引起模块容量变化的因素；
将模块容量变化因素在运维端输出。
10.根据权利要求7所述的处理装置，其特征在于，所述确定模块还包括：
确定引起模块容量变化的因素包括：
查询所述第一集群容量模型的模块是否接收到在预设时间阈值内的代码发布；
如果不是，则将查询结果在运维端输出。
CN201910495875.6A 2019-06-05 2019-06-05 集群容量模型的处理方法及装置 Withdrawn CN110308925A (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN201910495875.6A CN110308925A (zh) 2019-06-05 2019-06-05 集群容量模型的处理方法及装置

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN201910495875.6A CN110308925A (zh) 2019-06-05 2019-06-05 集群容量模型的处理方法及装置

Publications (1)

Publication Number Publication Date
CN110308925A true CN110308925A (zh) 2019-10-08

Family

ID=68075916

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201910495875.6A Withdrawn CN110308925A (zh) 2019-06-05 2019-06-05 集群容量模型的处理方法及装置

Country Status (1)

Country Link
CN (1) CN110308925A (zh)

Similar Documents

Publication Publication Date Title
CN102223254A (zh) 监控系统及方法
CN107204894A (zh) 网络业务质量的监控方法及装置
CN101815003A (zh) 全业务融合网络统一资源模型
CN108932217A (zh) 能耗统计的方法及装置
CN103853826A (zh) 一种分布式性能数据处理方法
CN103731870A (zh) 监控任务的管理方法及装置
CN111596924A (zh) 一种微服务划分方法和装置
CN107316451A (zh) 基于无线表计的集群型网络抄表方法及装置
CN100488114C (zh) 一种网元管理方法与系统
CN111460315B (zh) 社群画像构建方法、装置、设备及存储介质
CN101247434A (zh) 一种话务分析方法及系统
CN103685574A (zh) 面向服务的通用物联网资源分配方法
CN104424555A (zh) 用于发布/订阅系统中的控制方法及设备
CN105282045B (zh) 一种基于一致性哈希算法的分布式计算和储存方法
CN105471938A (zh) 服务器负载管理方法及装置
CN110308925A (zh) 集群容量模型的处理方法及装置
CN108650134A (zh) 网络故障定位的方法、装置及电子设备
CN104750834A (zh) 一种规则的存储方法、匹配方法及装置
CN111556090A (zh) 智能物联网的功能聚合自组织系统及方法
CN101605049B (zh) 网管数据统计分析指标的处理方法和装置、数据管理系统
CN110333896A (zh) 集群容量模型的处理方法及装置
CN105868409A (zh) 数据采集系统
CN104239222B (zh) 一种内存访问方法、设备和系统
CN110450189A (zh) 用于机器人的异常处理方法及装置
CN110389876A (zh) 基础资源容量监管方法、装置、设备及存储介质

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
WW01 Invention patent application withdrawn after publication
WW01 Invention patent application withdrawn after publication

Application publication date: 20191008