CN110543366A - 用于业务集群的业务模块容量调优方法以及装置、服务器 - Google Patents

用于业务集群的业务模块容量调优方法以及装置、服务器 Download PDF

Info

Publication number
CN110543366A
CN110543366A CN201910799917.5A CN201910799917A CN110543366A CN 110543366 A CN110543366 A CN 110543366A CN 201910799917 A CN201910799917 A CN 201910799917A CN 110543366 A CN110543366 A CN 110543366A
Authority
CN
China
Prior art keywords
capacity
module
service
servers
server
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.)
Pending
Application number
CN201910799917.5A
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 CN201910799917.5A priority Critical patent/CN110543366A/zh
Publication of CN110543366A publication Critical patent/CN110543366A/zh
Pending legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5005—Allocation of resources, e.g. of the central processing unit [CPU] to service a request
    • G06F9/5027—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals
    • G06F9/505—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals considering the load
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5083—Techniques for rebalancing the load in a distributed system
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2209/00—Indexing scheme relating to G06F9/00
    • G06F2209/50—Indexing scheme relating to G06F9/50
    • G06F2209/5013—Request control
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2209/00—Indexing scheme relating to G06F9/00
    • G06F2209/50—Indexing scheme relating to G06F9/50
    • G06F2209/508—Monitor

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Debugging And Monitoring (AREA)

Abstract

本申请公开了一种用于业务集群的业务模块容量调优方法以及装置、服务器。该方法包括当业务集群中接收到对于同一个业务模块下的服务器调用请求时，判断服务器之间的模块容量是否具有差别；如果模块容量有差别，则调整所述服务器的被调用权重，以均衡所述服务器之间的容量。本申请解决了缺乏对容量不健康的业务模块进行容量调优方的技术问题。通过本申请实现了对不健康业务模块进行调优处理，使得模块下不同性能的服务器利用率都能最大化，并且能均衡服务器之间的容量。

Description

用于业务集群的业务模块容量调优方法以及装置、服务器
技术领域
本申请涉及业务集群处理领域，具体而言，涉及一种用于业务集群的业务模块容量调优方法以及装置、服务器。
背景技术
业务请求发起经负载均衡接入，请求数量会基本均匀落在被调用模块下服务器上，因服务器之间的性能差异，就会导致容量上就会出现差别。
发明人发现，由于缺乏对容量不健康的业务模块进行容量调优方案，从而不利于使得该业务模块容量成为健康的状态。
针对相关技术中缺乏对容量不健康的业务模块进行容量调优方的问题，目前尚未提出有效的解决方案。
发明内容
本申请的主要目的在于提供一种用于业务集群的业务模块容量调优方法以及装置、服务器，以解决缺乏对容量不健康的业务模块进行容量调优方问题。
为了实现上述目的，根据本申请的一个方面，提供了一种用于业务集群的业务模块容量调优方法。
根据本申请的用于业务集群的业务模块容量调优方法包括：当业务集群中接收到对于同一个业务模块下的服务器调用请求时，判断服务器之间的模块容量是否具有差别；如果模块容量有差别，则调整所述服务器的被调用权重，以均衡所述服务器之间的容量。
进一步地，如果模块容量有差别，则调整所述服务器的被调用权重，以均衡所述服务器之间的容量包括：
在业务高峰期判断所述服务器之间的模块容量差别是否达到不健康业务模块的容量差别；
如果在业务高峰期判断所述服务器之间的模块容量差别达到不健康业务模块的容量差别，则调整所述服务器的被调用权重。
进一步地，当业务集群中接收到对于同一个业务模块下的服务器调用请求时，判断服务器之间的模块容量是否具有差别包括：
当业务集群中接收到对于同一个业务模块下的服务器调用请求时，根据业务模块的业务功能选择一个判断指标做为业务模块容量衡量的预设标准；
根据预设标准判断服务器之间的所述判断指标是否具有差别。
进一步地，如果容量有差别，则调整所述服务器的被调用权重，以均衡所述服务器之间的模块容量包括：
确定接收到对于同一个业务模块下的服务器调用请求时被调用量和被调用权重；
在服务器之间的模块容量有差别时，调整所述服务器的被调用权重得到新的权重＝(单台支撑能力*容量基准)/被调用量；
其中所述容量基准为容量最高的安全阈值，所述单台支撑能力是指服务器容量支撑能力。
进一步地，所述模块容量选用CPU使用率。
为了实现上述目的，根据本申请的另一方面，提供了一种用于业务集群的业务模块容量调优装置。
根据本申请的用于业务集群的业务模块容量调优装置包括：判断模块，用于当业务集群中接收到对于同一个业务模块下的服务器调用请求时，判断服务器之间的模块容量是否具有差别；调优模块，用于在模块容量有差别时，调整所述服务器的被调用权重，以均衡所述服务器之间的容量。
进一步地，所述调优模块，用于
在业务高峰期判断所述服务器之间的模块容量差别是否达到不健康业务模块的容量差别；
如果在业务高峰期判断所述服务器之间的模块容量差别达到不健康业务模块的容量差别，则调整所述服务器的被调用权重。
进一步地，所述判断模块，用于
当业务集群中接收到对于同一个业务模块下的服务器调用请求时，根据业务模块的业务功能选择一个判断指标做为业务模块容量衡量的预设标准；
根据预设标准判断服务器之间的所述判断指标是否具有差别。
进一步地，所述判断模块，用于
确定接收到对于同一个业务模块下的服务器调用请求时被调用量和被调用权重；
在服务器之间的模块容量有差别时，调整所述服务器的被调用权重得到新的权重＝(单台支撑能力*容量基准)/被调用量；
其中所述容量基准为容量最高的安全阈值，所述单台支撑能力是指服务器容量支撑能力。
为了实现上述目的，根据本申请的再一个方面，提供了一种服务器，包括：所述的业务模块容量调优装置。
在本申请实施例中用于业务集群的业务模块容量调优方法以及装置、服务器，采用当业务集群中接收到对于同一个业务模块下的服务器调用请求时，通过判断服务器之间的模块容量是否具有差别的方式，达到了如果模块容量有差别，则调整所述服务器的被调用权重，以均衡所述服务器之间的容量的目的，从而实现了对不健康业务模块进行调优处理的技术效果，进而解决了缺乏对容量不健康的业务模块进行容量调优方的技术问题。
附图说明
构成本申请的一部分的附图用来提供对本申请的进一步理解，使得本申请的其它特征、目的和优点变得更明显。本申请的示意性实施例附图及其说明用于解释本申请，并不构成对本申请的不当限定。在附图中：
图1是根据本申请第一实施例的用于业务集群的业务模块容量调优方法流程示意图；
图2是根据本申请第二实施例的用于业务集群的业务模块容量调优方法流程示意图；
图3是根据本申请第三实施例的用于业务集群的业务模块容量调优方法流程示意图；
图4是根据本申请第四实施例的用于业务集群的业务模块容量调优方法流程示意图；
图5是根据本申请实施例的用于业务集群的业务模块容量调优装置结构示意图。
具体实施方式
为了使本技术领域的人员更好地理解本申请方案，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分的实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都应当属于本申请保护的范围。
需要说明的是，本申请的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本申请的实施例。此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、***、产品或设备不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。
在本申请中，术语“上”、“下”、“左”、“右”、“前”、“后”、“顶”、“底”、“内”、“外”、“中”、“竖直”、“水平”、“横向”、“纵向”等指示的方位或位置关系为基于附图所示的方位或位置关系。这些术语主要是为了更好地描述本申请及其实施例，并非用于限定所指示的装置、元件或组成部分必须具有特定方位，或以特定方位进行构造和操作。
并且，上述部分术语除了可以用于表示方位或位置关系以外，还可能用于表示其他含义，例如术语“上”在某些情况下也可能用于表示某种依附关系或连接关系。对于本领域普通技术人员而言，可以根据具体情况理解这些术语在本申请中的具体含义。
此外，术语“安装”、“设置”、“设有”、“连接”、“相连”、“套接”应做广义理解。例如，可以是固定连接，可拆卸连接，或整体式构造；可以是机械连接，或电连接；可以是直接相连，或者是通过中间媒介间接相连，又或者是两个装置、元件或组成部分之间内部的连通。对于本领域普通技术人员而言，可以根据具体情况理解上述术语在本申请中的具体含义。
需要说明的是，在不冲突的情况下，本申请中的实施例及实施例中的特征可以相互组合。下面将参考附图并结合实施例来详细说明本申请。
在本申请中当同一个模块下每台服务器面对同数量被调用请求，服务器之间的容量出现差别较大时，需要对该模块下的服务器被调用权重进行优化调整，通过对服务器权重的调整，让服务器之间的容量尽可能都集中在一个能接受的容量区间内，使该业务模块容量成为容量健康业务模块。
如图1所示，该方法包括如下的步骤S102至步骤S104：
步骤S102，当业务集群中接收到对于同一个业务模块下的服务器调用请求时，判断服务器之间的模块容量是否具有差别；
当业务集群中接收到对于同一个业务模块下的服务器调用请求时需要判断服务器之间的模块容量是否具有差别。比如判断服务器之间的模块容量是否有较大差别，或者，判断服务器之间的模块容量的差别是否超出了阈值。
具体地，所述模块容量是指，根据模块的功能从模块的多个指标维度中选出一个指标做为模块容量衡量的唯一核心标准。
需要注意的是，可以作为指标有：模块中服务器的CPU使用率、内存使用率、I/O使用率、模块程序上业务返回码等等。
比如，接入型服务，一般选CPU的使用率做为本模块支撑性能唯一核心指标，CPU使用率90％了，说明该模块已达到性能最大支撑瓶颈。
又比如，数据存储模块，一般选磁盘I/O读写性能做为唯一核心指标。
步骤S104，如果模块容量有差别，则调整所述服务器的被调用权重，以均衡所述服务器之间的容量。
如果根据判断结果得知模块容量有差别，则调整所述服务器的被调用权重，以均衡所述服务器之间的容量使得模块容量为健康容量模块。
需要注意的是，由于业务请求发起经负载均衡接入，请求数量会基本均匀落在被调用模块下服务器上，因服务器之间的性能差异，就会导致容量上就会出现差别。具体地，有一些模块下服务器之间容量差别不大，在能接受范围内的，定义为容量健康模块。此外，另有一些模块下服务器之间容量差别较大，那定义为容量不健康模块。
还需要注意的是，判断模块容量是否属于健康容量的方法可以采用多种，在本申请的实施例中并不进行具体限定，本领域技术人员可以根据实际使用情况进行选择。
所述业务集群是指，多个业务模块的组成后实现一个完整业务功能或者某各核心功能的集合。
所述业务模块是指，某个业务功能点部署在单个服务器或者一组服务器上的集合。
从以上的描述中，可以看出，本申请实现了如下技术效果：
本申请实施例中，采用当业务集群中接收到对于同一个业务模块下的服务器调用请求时，通过判断服务器之间的模块容量是否具有差别的方式，达到了如果模块容量有差别，则调整所述服务器的被调用权重，以均衡所述服务器之间的容量的目的，从而实现了对不健康业务模块进行调优处理的技术效果，进而解决了缺乏对容量不健康的业务模块进行容量调优方的技术问题。
根据本申请实施例，作为本实施例中的优选，如图2所示，如果模块容量有差别，则调整所述服务器的被调用权重，以均衡所述服务器之间的容量包括：
步骤S202，在业务高峰期判断所述服务器之间的模块容量差别是否达到不健康业务模块的容量差别；
步骤S204，如果在业务高峰期判断所述服务器之间的模块容量差别达到不健康业务模块的容量差别，则调整所述服务器的被调用权重。
优选地，所述模块容量选用CPU使用率。
通过在业务高峰期判断所述服务器之间的模块容量差别是否达到不健康业务模块的容量差别，如果在业务高峰期判断所述服务器之间的模块容量差别达到不健康业务模块的容量差别，则调整所述服务器的被调用权重。
具体地，当同一个模块下每台服务器面对同数量被调用请求，服务器之间的容量出现差别较大时，需要对该模块下的服务器被调用权重进行优化调整，通过对服务器权重的调整，让服务器之间的容量尽可能都集中在一个能接受的容量区间内，使该业务模块容量成为容量健康业务模块。
通过被调用模块下服务器被调用权重的调整，让模块下不同性能的服务器利用率都能最大化，并且能均衡服务器之间的容量，避免某台服务器容量短板而引起连锁奔溃，让业务在运营中更稳定，服务器成本最优。
根据本申请实施例，作为本实施例中的优选，如图3所示，当业务集群中接收到对于同一个业务模块下的服务器调用请求时，判断服务器之间的模块容量是否具有差别包括：
步骤S302，当业务集群中接收到对于同一个业务模块下的服务器调用请求时，根据业务模块的业务功能选择一个判断指标做为业务模块容量衡量的预设标准；
步骤S304，根据预设标准判断服务器之间的所述判断指标是否具有差别。
优选地，所述模块容量选用CPU使用率。
当业务集群中接收到对于同一个业务模块下的服务器调用请求时，根据业务模块的业务功能选择一个判断指标做为业务模块容量衡量的预设标准。根据预设标准判断服务器之间的所述判断指标是否具有差别。
具体地，当同一个模块下每台服务器面对同数量被调用请求，服务器之间的容量出现差别较大时，需要对该模块下的服务器被调用权重进行优化调整，通过对服务器权重的调整，让服务器之间的容量尽可能都集中在一个能接受的容量区间内，使该业务模块容量成为容量健康业务模块。
通过被调用模块下服务器被调用权重的调整，让模块下不同性能的服务器利用率都能最大化，并且能均衡服务器之间的容量，避免某台服务器容量短板而引起连锁奔溃，让业务在运营中更稳定，服务器成本最优。
根据本申请实施例，作为本实施例中的优选，如图4所示，如果容量有差别，则调整所述服务器的被调用权重，以均衡所述服务器之间的模块容量包括：
步骤S402，确定接收到对于同一个业务模块下的服务器调用请求时被调用量和被调用权重；
步骤S404，在服务器之间的模块容量有差别时，调整所述服务器的被调用权重得到新的权重＝(单台支撑能力*容量基准)/被调用量；
通过确定接收到对于同一个业务模块下的服务器调用请求时被调用量和被调用权重，然后在服务器之间的模块容量有差别时，调整所述服务器的被调用权重得到新的权重＝(单台支撑能力*容量基准)/被调用量。
所述容量基准为容量最高的安全阈值，所述单台支撑能力是指服务器容量支撑能力。
上述调优方法，通过被调用模块下服务器被调用权重的调整，让模块下不同性能的服务器利用率都能最大化，并且能均衡服务器之间的容量，避免某台服务器容量短板而引起连锁奔溃，让业务在运营中更稳定，服务器成本最优。
优选地，如果一次调优结果不能够满足需求即达不到容量标准值，则需要进行多次调优。
需要说明的是，在附图的流程图示出的步骤可以在诸如一组计算机可执行指令的计算机***中执行，并且，虽然在流程图中示出了逻辑顺序，但是在某些情况下，可以以不同于此处的顺序执行所示出或描述的步骤。
根据本申请实施例，还提供了一种用于实施上述方法的用于业务集群的业务模块容量调优装置，如图5所示，该装置包括：判断模块10，用于当业务集群中接收到对于同一个业务模块下的服务器调用请求时，判断服务器之间的模块容量是否具有差别；调优模块20，用于在模块容量有差别时，调整所述服务器的被调用权重，以均衡所述服务器之间的容量。
本申请实施例的判断模块10中当业务集群中接收到对于同一个业务模块下的服务器调用请求时需要判断服务器之间的模块容量是否具有差别。比如判断服务器之间的模块容量是否有较大差别，或者，判断服务器之间的模块容量的差别是否超出了阈值。
具体地，所述模块容量是指，根据模块的功能从模块的多个指标维度中选出一个指标做为模块容量衡量的唯一核心标准。
需要注意的是，可以作为指标有：模块中服务器的CPU使用率、内存使用率、I/O使用率、模块程序上业务返回码等等。
比如，接入型服务，一般选CPU的使用率做为本模块支撑性能唯一核心指标，CPU使用率90％了，说明该模块已达到性能最大支撑瓶颈。
又比如，数据存储模块，一般选磁盘I/O读写性能做为唯一核心指标。
本申请实施例的调优模块20中如果根据判断结果得知模块容量有差别，则调整所述服务器的被调用权重，以均衡所述服务器之间的容量使得模块容量为健康容量模块。
需要注意的是，由于业务请求发起经负载均衡接入，请求数量会基本均匀落在被调用模块下服务器上，因服务器之间的性能差异，就会导致容量上就会出现差别。具体地，有一些模块下服务器之间容量差别不大，在能接受范围内的，定义为容量健康模块。此外，另有一些模块下服务器之间容量差别较大，那定义为容量不健康模块。
根据本申请实施例，作为本实施例中的优选，所述调优模块20，用于在业务高峰期判断所述服务器之间的模块容量差别是否达到不健康业务模块的容量差别；如果在业务高峰期判断所述服务器之间的模块容量差别达到不健康业务模块的容量差别，则调整所述服务器的被调用权重。
优选地，所述模块容量选用CPU使用率。
通过在业务高峰期判断所述服务器之间的模块容量差别是否达到不健康业务模块的容量差别，如果在业务高峰期判断所述服务器之间的模块容量差别达到不健康业务模块的容量差别，则调整所述服务器的被调用权重。
具体地，当同一个模块下每台服务器面对同数量被调用请求，服务器之间的容量出现差别较大时，需要对该模块下的服务器被调用权重进行优化调整，通过对服务器权重的调整，让服务器之间的容量尽可能都集中在一个能接受的容量区间内，使该业务模块容量成为容量健康业务模块。
通过被调用模块下服务器被调用权重的调整，让模块下不同性能的服务器利用率都能最大化，并且能均衡服务器之间的容量，避免某台服务器容量短板而引起连锁奔溃，让业务在运营中更稳定，服务器成本最优。
根据本申请实施例，作为本实施例中的优选，所述判断模块10，用于当业务集群中接收到对于同一个业务模块下的服务器调用请求时，根据业务模块的业务功能选择一个判断指标做为业务模块容量衡量的预设标准；根据预设标准判断服务器之间的所述判断指标是否具有差别。
优选地，所述模块容量选用CPU使用率。
当业务集群中接收到对于同一个业务模块下的服务器调用请求时，根据业务模块的业务功能选择一个判断指标做为业务模块容量衡量的预设标准。根据预设标准判断服务器之间的所述判断指标是否具有差别。
具体地，当同一个模块下每台服务器面对同数量被调用请求，服务器之间的容量出现差别较大时，需要对该模块下的服务器被调用权重进行优化调整，通过对服务器权重的调整，让服务器之间的容量尽可能都集中在一个能接受的容量区间内，使该业务模块容量成为容量健康业务模块。
通过被调用模块下服务器被调用权重的调整，让模块下不同性能的服务器利用率都能最大化，并且能均衡服务器之间的容量，避免某台服务器容量短板而引起连锁奔溃，让业务在运营中更稳定，服务器成本最优。
根据本申请实施例，作为本实施例中的优选，所述判断模块10，用于确定接收到对于同一个业务模块下的服务器调用请求时被调用量和被调用权重；在服务器之间的模块容量有差别时，调整所述服务器的被调用权重得到新的权重＝(单台支撑能力*容量基准)/被调用量；
通过确定接收到对于同一个业务模块下的服务器调用请求时被调用量和被调用权重，然后在服务器之间的模块容量有差别时，调整所述服务器的被调用权重得到新的权重＝(单台支撑能力*容量基准)/被调用量。
所述容量基准为容量最高的安全阈值，所述单台支撑能力是指服务器容量支撑能力。
上述调优模块，通过被调用模块下服务器被调用权重的调整，让模块下不同性能的服务器利用率都能最大化，并且能均衡服务器之间的容量，避免某台服务器容量短板而引起连锁奔溃，让业务在运营中更稳定，服务器成本最优。
在本申请的另一实施例中，还提供了一种服务器，包括：所述的业务模块容量调优装置。所述业务模块容量调优装置的实现原理和有益效果如上所述，在此不再进行赘述。
本申请的调优方法的实现原理，可以参考如下方式进行实现：
以下以模块A，容量核心指标CPU使用率，模块下7台服务器，如业务高峰期每台服务器被访问/被调用量N＝2000次/秒，每台服务器被调用权重都是q＝100作为例子进行举例。
步骤一：在业务使用高峰期容量不健康模块记录如下数据：
服务器1 服务器2 服务器3 服务器4 服务器5 服务器6 服务器7
被调用量 2000次/秒 2000次/秒 2000次/秒 2000次/秒 2000次/秒 2000次/秒 2000次/秒
被调用权重 100 100 100 100 100 100 100
CPU使用率(％) 70 60 55 81 72 48 51
步骤二：计算单台服务器容量支撑能力，单台支撑能力＝(被调用量*被调用权重)/CPU，单台支撑能力取整，计算得数据：
(被调用量*被调用权重)＝2000*100＝200000
服务器1 服务器2 服务器3 服务器4 服务器5 服务器6 服务器7
计算过程 ＝20000/70 ＝20000/60 ＝20000/55 ＝20000/81 ＝20000/72 ＝20000/48 ＝20000/51
单台支撑能力 2857 3333 3636 2469 2777 4166 3921
步骤三：制定的容量最高安全值：比如，表中的CPU利用率为85％，寻找该模块下容量最高的服务器，并且确认此最高的容量是否在安全值范文内，如上表中服务器4容量最高，为81，且在最高范围值内。
步骤四：在被调用量不变的情况下，已最高容量81为基准值，对容量没有达到81的模块进行权重提升，让其容量达到81，计算方法如下：
新的权重值＝(单台支撑能力*容量基准)/被调用量；
然后根据其它服务器的容量进行新权重计算，结果取整，数据如下：
步骤五：现网调整权重，然后观察高峰时期模块下各服务器容量的数据并记录。
现网调整权重可具体见下表。由于理论计算值和调优后服务器真实容量值可能存在一定的差异，理论是应该也是一致的。比如，下表中的x1..x7的值都应该是81，但实际可能存在一些偏差，有些服务器因硬件性能不一样。
所以在请求增加时，负载上升的幅度会比预期的高，采用x1...x7作为标识。比如，x1...x7中的值不是81，并且和81相减的绝对值大于5且在调优后服务器1容量真实值x1＝86时，就需要再对该服务器1容量做一次调优。调整后高峰期容量计算理论值：
服务器1 服务器2 服务器3 服务器4 服务器5 服务器6 服务器7
调整后权重 116 135 147 100 112 169 159
权重调整后新容量值 81 81 81 81 81 81 81
调整后高峰期容量真实值：
服务器1 服务器2 服务器3 服务器4 服务器5 服务器6 服务器7
调整后权重 116 135 147 100 112 169 159
权重调整后新容量值 x1 x2 x3 x4 x5 x6 x7
显然，本领域的技术人员应该明白，上述的本申请的各模块或各步骤可以用通用的计算装置来实现，它们可以集中在单个的计算装置上，或者分布在多个计算装置所组成的网络上，可选地，它们可以用计算装置可执行的程序代码来实现，从而，可以将它们存储在存储装置中由计算装置来执行，或者将它们分别制作成各个集成电路模块，或者将它们中的多个模块或步骤制作成单个集成电路模块来实现。这样，本申请不限制于任何特定的硬件和软件结合。
以上所述仅为本申请的优选实施例而已，并不用于限制本申请，对于本领域的技术人员来说，本申请可以有各种更改和变化。凡在本申请的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本申请的保护范围之内。

Claims (10)

1.一种用于业务集群的业务模块容量调优方法，其特征在于，包括：
当业务集群中接收到对于同一个业务模块下的服务器调用请求时，判断服务器之间的模块容量是否具有差别；
如果模块容量有差别，则调整所述服务器的被调用权重，以均衡所述服务器之间的容量。
2.根据权利要求1所述的业务模块容量调优方法，其特征在于，如果模块容量有差别，则调整所述服务器的被调用权重，以均衡所述服务器之间的容量包括：
在业务高峰期判断所述服务器之间的模块容量差别是否达到不健康业务模块的容量差别；
如果在业务高峰期判断所述服务器之间的模块容量差别达到不健康业务模块的容量差别，则调整所述服务器的被调用权重。
3.根据权利要求1所述的业务模块容量调优方法，其特征在于，当业务集群中接收到对于同一个业务模块下的服务器调用请求时，判断服务器之间的模块容量是否具有差别包括：
当业务集群中接收到对于同一个业务模块下的服务器调用请求时，根据业务模块的业务功能选择一个判断指标做为业务模块容量衡量的预设标准；
根据预设标准判断服务器之间的所述判断指标是否具有差别。
4.根据权利要求1所述的业务模块容量调优方法，其特征在于，如果容量有差别，则调整所述服务器的被调用权重，以均衡所述服务器之间的模块容量包括：
确定接收到对于同一个业务模块下的服务器调用请求时被调用量和被调用权重；
在服务器之间的模块容量有差别时，调整所述服务器的被调用权重得到新的权重＝(单台支撑能力*容量基准)/被调用量；
其中所述容量基准为容量最高的安全阈值，所述单台支撑能力是指服务器容量支撑能力。
5.根据权利要求1所述的业务模块容量调优方法，其特征在于，所述模块容量选用CPU使用率。
6.一种用于业务集群的业务模块容量调优装置，其特征在于，包括：
判断模块，用于当业务集群中接收到对于同一个业务模块下的服务器调用请求时，判断服务器之间的模块容量是否具有差别；
调优模块，用于在模块容量有差别时，调整所述服务器的被调用权重，以均衡所述服务器之间的容量。
7.根据权利要求6所述的用于业务集群的业务模块容量调优装置，其特征在于，所述调优模块，用于
在业务高峰期判断所述服务器之间的模块容量差别是否达到不健康业务模块的容量差别；
如果在业务高峰期判断所述服务器之间的模块容量差别达到不健康业务模块的容量差别，则调整所述服务器的被调用权重。
8.根据权利要求6所述的用于业务集群的业务模块容量调优装置，其特征在于，所述判断模块，用于
当业务集群中接收到对于同一个业务模块下的服务器调用请求时，根据业务模块的业务功能选择一个判断指标做为业务模块容量衡量的预设标准；
根据预设标准判断服务器之间的所述判断指标是否具有差别。
9.根据权利要求6所述的用于业务集群的业务模块容量调优装置，其特征在于，所述判断模块，用于
确定接收到对于同一个业务模块下的服务器调用请求时被调用量和被调用权重；
在服务器之间的模块容量有差别时，调整所述服务器的被调用权重得到新的权重＝(单台支撑能力*容量基准)/被调用量；
其中所述容量基准为容量最高的安全阈值，所述单台支撑能力是指服务器容量支撑能力。
10.一种服务器，其特征在于，包括：如权利要求6至9任一项所述的业务模块容量调优装置。
CN201910799917.5A 2019-08-27 2019-08-27 用于业务集群的业务模块容量调优方法以及装置、服务器 Pending CN110543366A (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN201910799917.5A CN110543366A (zh) 2019-08-27 2019-08-27 用于业务集群的业务模块容量调优方法以及装置、服务器

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN201910799917.5A CN110543366A (zh) 2019-08-27 2019-08-27 用于业务集群的业务模块容量调优方法以及装置、服务器

Publications (1)

Publication Number Publication Date
CN110543366A true CN110543366A (zh) 2019-12-06

Family

ID=68712181

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201910799917.5A Pending CN110543366A (zh) 2019-08-27 2019-08-27 用于业务集群的业务模块容量调优方法以及装置、服务器

Country Status (1)

Country Link
CN (1) CN110543366A (zh)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112583922A (zh) * 2020-12-16 2021-03-30 罗普特科技集团股份有限公司 视频监控服务智能调度***

Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20070143460A1 (en) * 2005-12-19 2007-06-21 International Business Machines Corporation Load-balancing metrics for adaptive dispatching of long asynchronous network requests
CN101753444A (zh) * 2009-12-31 2010-06-23 卓望数码技术（深圳）有限公司 一种负载均衡方法和负载均衡装置
CN102611735A (zh) * 2011-12-21 2012-07-25 奇智软件（北京）有限公司 一种应用服务的负载均衡方法及***
CN105049536A (zh) * 2015-09-08 2015-11-11 南京大学 IaaS云环境中的负载均衡***和负载均衡方法
CN107124472A (zh) * 2017-06-26 2017-09-01 杭州迪普科技股份有限公司 负载均衡方法及装置、计算机可读存储介质
CN108572873A (zh) * 2018-04-24 2018-09-25 中国科学院重庆绿色智能技术研究院 一种解决Spark数据倾斜问题的负载均衡方法及装置
CN110134513A (zh) * 2019-04-17 2019-08-16 平安科技（深圳）有限公司 负载均衡方法、装置、计算机设备及存储介质

Patent Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20070143460A1 (en) * 2005-12-19 2007-06-21 International Business Machines Corporation Load-balancing metrics for adaptive dispatching of long asynchronous network requests
CN101753444A (zh) * 2009-12-31 2010-06-23 卓望数码技术（深圳）有限公司 一种负载均衡方法和负载均衡装置
CN102611735A (zh) * 2011-12-21 2012-07-25 奇智软件（北京）有限公司 一种应用服务的负载均衡方法及***
CN105049536A (zh) * 2015-09-08 2015-11-11 南京大学 IaaS云环境中的负载均衡***和负载均衡方法
CN107124472A (zh) * 2017-06-26 2017-09-01 杭州迪普科技股份有限公司 负载均衡方法及装置、计算机可读存储介质
CN108572873A (zh) * 2018-04-24 2018-09-25 中国科学院重庆绿色智能技术研究院 一种解决Spark数据倾斜问题的负载均衡方法及装置
CN110134513A (zh) * 2019-04-17 2019-08-16 平安科技（深圳）有限公司 负载均衡方法、装置、计算机设备及存储介质

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112583922A (zh) * 2020-12-16 2021-03-30 罗普特科技集团股份有限公司 视频监控服务智能调度***
CN112583922B (zh) * 2020-12-16 2022-09-20 罗普特科技集团股份有限公司 视频监控服务智能调度***

Similar Documents

Publication Publication Date Title
CN106453125B (zh) 一种基于实时负载率的远程服务调用负载均衡***
CN111694663B (zh) 服务器集群的负载均衡方法、装置及***
KR102047900B1 (ko) 분산 데이터베이스의 부하를 레벨링하는 방법 및 장치
CN102111813B (zh) 一种载波负荷均衡的方法和设备
CN101699901A (zh) 优化用户设备搜索空间的方法及装置
CN110795203A (zh) 资源调度方法、装置、***和计算设备
CN105516347A (zh) 一种流媒体服务器的负载均衡调配的方法及装置
CN111045808A (zh) 一种分布式网络任务调度方法及装置
CN103746934A (zh) 一种cdn带宽平衡的方法、cdn控制中心及***
CN108055701B (zh) 一种资源调度方法及基站
CN102724105B (zh) 一种负载均衡方法和装置
US20220338061A1 (en) Method for load imbalance optimization under same network coverage, apparatus, device, and storage medium
CN110213351A (zh) 一种面向广域高性能计算环境的动态自适应io负载均衡方法
WO2014194704A1 (en) A grouping processing method and system
CN110784894A (zh) Lte***负载均衡方法和装置
CN110543366A (zh) 用于业务集群的业务模块容量调优方法以及装置、服务器
CN106998340A (zh) 一种板卡资源的负载均衡方法及装置
CN105282045A (zh) 一种基于一致性哈希算法的分布式计算和储存方法
CN109982375A (zh) 一种服务小区的负荷均衡调整方法及装置
CN110554920A (zh) 处理容量不健康模块的方法以及装置
CN104899072B (zh) 基于虚拟化平台的细粒度资源调度***及方法
CN101730147B (zh) 载频分配方法及装置
CN116684098A (zh) 基于区块链的数据处理方法、装置、设备、介质及产品
CN114338683A (zh) 调度请求处理方法、装置、存储介质及电子设备
US9479579B2 (en) Grouping processing method and system

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
RJ01 Rejection of invention patent application after publication

Application publication date: 20191206

RJ01 Rejection of invention patent application after publication