CN114745278A - 一种业务系统扩缩容的方法、装置、电子设备和存储介质 - Google Patents

一种业务系统扩缩容的方法、装置、电子设备和存储介质 Download PDF

Info

Publication number
CN114745278A
CN114745278A CN202210377725.7A CN202210377725A CN114745278A CN 114745278 A CN114745278 A CN 114745278A CN 202210377725 A CN202210377725 A CN 202210377725A CN 114745278 A CN114745278 A CN 114745278A
Authority
CN
China
Prior art keywords
servers
server
service
capacity
reduction
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.)
Granted
Application number
CN202210377725.7A
Other languages
English (en)
Other versions
CN114745278B (zh
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.)
Cd Finance Project Management Co ltd
Original Assignee
Cd Finance Project Management 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 Cd Finance Project Management Co ltd filed Critical Cd Finance Project Management Co ltd
Priority to CN202210377725.7A priority Critical patent/CN114745278B/zh
Publication of CN114745278A publication Critical patent/CN114745278A/zh
Application granted granted Critical
Publication of CN114745278B publication Critical patent/CN114745278B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/08Configuration management of networks or network elements
    • H04L41/0896Bandwidth or capacity management, i.e. automatically increasing or decreasing capacities
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/50Network service management, e.g. ensuring proper service fulfilment according to agreements
    • H04L41/5041Network service management, e.g. ensuring proper service fulfilment according to agreements characterised by the time relationship between creation and deployment of a service
    • H04L41/5051Service on demand, e.g. definition and deployment of services in real time
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/01Protocols
    • H04L67/10Protocols in which an application is distributed across nodes in the network
    • H04L67/1001Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers
    • H04L67/1029Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers using data related to the state of servers by a load balancer
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/01Protocols
    • H04L67/10Protocols in which an application is distributed across nodes in the network
    • H04L67/1001Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers
    • H04L67/1031Controlling of the operation of servers by a load balancer, e.g. adding or removing servers that serve requests

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer And Data Communications (AREA)
  • Information Transfer Between Computers (AREA)

Abstract

本申请提供了一种业务系统扩缩容的方法、装置、电子设备和存储介质,该方法包括:接收第一业务请求,解析第一业务请求的域名并确定第一业务;获取第一业务关联的M个进程,M个进程对应M个服务节点和N个服务器;确定每一个服务节点的运行指标和每一个服务器的资源指标,根据每一个服务节点的运行指标和每一个服务器的资源指标确定针对第一业务的扩缩容策略;根据扩缩容策略生成并发送第一业务的扩缩容指令,控制M个服务节点和/或N个服务器根据扩缩容指令进行扩缩容。该方法能够在对业务系统扩缩容的过程中,同时兼顾服务节点的运行指标和服务器的资源指标,提高了业务系统整体的资源利用率,避免了业务系统资源的浪费。

Description

一种业务系统扩缩容的方法、装置、电子设备和存储介质
技术领域
本申请涉及计算机技术领域,并且更具体地,涉及计算机技术领域中一种业务系统扩缩容的方法、装置、电子设备和存储介质。
背景技术
随着互联网技术的不断创新和发展,互联网技术在各类行业中的应用越来越广泛,例如,对于业务服务行业,可以利用基于互联网技术的大规模云服务器集群或混合运行态下业务集群的业务系统,对外提供服务以满足用户的不同业务请求。业务系统在提供服务的过程中,在某一时段可能会接受大量用户的业务请求,业务系统的访问流量出现急剧增长。为了满足访问流量高峰期的业务请求,及时响应用户的业务请求,保证业务系统的服务质量,业务系统可能需要扩容以解决当前大流量的业务请求。在访问流量高峰期之后,业务系统的业务请求数量逐渐恢复至正常,此时为了避免业务系统整体的资源浪费,需要及时根据当前的业务系统整体的运行状况和资源情况,对业务系统实现缩容管理,该过程称为“对业务系统实现扩缩容过程”。
现有技术在对业务系统实现扩缩容的过程中,主要有以下两种实现方式:第一种方式是对业务系统的服务器资源扩缩容,具体是通过获取服务器的资源指标(例如中央处理单元(Central Processing Unit,CPU)的利用率、内存利用率、存储和网络),根据服务器的资源指标的数据,确定合理的服务器的扩缩容方案,单独对服务器的资源实现扩缩容。在单独对业务系统的服务器资源进行扩缩容的过程中,主要是基于获取的服务器的资源指标来进行扩缩容的判断,但是会存在服务器的资源变化与业务服务的服务节点的运行不对称。例如,用Java技术开发偏内存型的业务服务,当服务器运行过程中可能会出现内存泄漏的情况,内存泄漏主要表现为服务器的内存利用率升高,CPU的利用率增加,此时为了避免服务器的运行压力,业务系统可能会对服务器进行扩容,但是其实业务服务的运行状况一直未发生改变,也就是说,服务器的资源指标的变化并不能完全代表业务服务的运行指标的变化。
第二种方式是通过对业务服务的服务扩缩容,具体是基于采集的业务服务的多个服务节点的运行指标,做业务服务运行资源的粒度处理,通过调整指标的阈值来实现对业务服务的服务节点的扩缩容。在单独对业务服务的服务节点进行扩缩容过程中,只会根据业务服务的运行指标来考虑,也就是说,该扩缩容是假设服务器的资源足够充分为前提,通常会按照倍数级别提供充足的服务器资源,此时可能会出现服务器资源出现剩余,导致服务器资源的浪费。
发明内容
本申请提供了一种业务系统扩缩容的方法、装置、电子设备和存储介质,该方法能够在对业务服务的服务节点进行扩缩容的过程中,同时兼顾业务系统中服务器的资源指标,生成合理的服务节点扩缩容指令,同时对扩容之后的服务节点实行再部署策略,保证了服务节点扩容之后在服务器上的合理分配,避免了业务服务的服务节点和服务器的资源指标的不对称的问题。此外,还可以根据服务器的资源指标确定服务器在扩缩容过程中的扩缩容频率,进一步对服务器的资源指标进行扩缩容,提高了业务系统整体的资源利用率,避免了服务器资源的浪费。
第一方面,提供了一种业务系统扩缩容的方法,其特征在于,该方法包括:接收第一业务请求,解析该第一业务请求的域名并确定第一业务;获取该第一业务关联的M个进程,该M个进程对应M个服务节点和N个服务器,M和N均为大于或等于1的整数;确定该M个服务节点中每一个服务节点的运行指标和该N个服务器中每一个服务器的资源指标,根据该每一个服务节点的运行指标和该每一个服务器的资源指标确定针对该第一业务的扩缩容策略,该运行指标包括响应时间、每秒查询率、吞吐量中的一种或多种,该资源指标包括中央处理器CPU的利用率、内存利用率中的一种或多种;根据该扩缩容策略生成并发送该第一业务的扩缩容指令,控制该M个服务节点和/或该N个服务器根据该扩缩容指令进行扩缩容。
上述技术方案中,在实现业务系统扩缩容的过程中,提出了一种可以根据业务系统的服务节点的运行指标和服务器的资源指标,动态准确的对业务系统进行扩缩容的方法,通过获取业务系统中的服务节点的运行指标和服务器的资源指标,同时考虑这两种指标参数,确定业务系统的服务节点和/或服务器的扩缩容策略,避免了服务节点与服务器资源的变化不同步的问题,避免了服务器资源的浪费,提高了业务系统的利用率,有效提高了用户的体验。
结合第一方面,在某些可能的实现方式中,根据该每一个服务节点的运行指标和该每一个服务器的资源指标确定针对该第一业务的扩缩容策略,包括:当该M个服务节点的运行指标满足第一条件时,根据该M个服务节点的运行指标和该每一个服务器的资源指标,确定该M个服务节点的扩容阈值;根据该M个服务节点的扩容阈值、该M个服务节点的运行指标和该每一个服务器的资源指标,确定该M个服务节点的扩容策略;或,当该M个服务节点的运行指标满足第二条件时,根据该M个服务节点的运行指标和该每一个服务器的资源指标,确定该M个服务节点的缩容阈值;根据该M个服务节点的缩容阈值、该M个服务节点的运行指标和该每一个服务器的资源指标,确定该M个服务节点的缩容策略。
上述技术方案中,在对业务的服务节点实现扩缩容的过程中,结合业务的服务节点的运行指标和服务器的资源指标,确定出业务服务节点的扩缩容阈值,进一步根据服务节点的扩缩容阈值、服务节点的运行指标和服务器的资源指标,确定服务节点的扩缩容策略。在对服务节点扩缩容的过程中,兼顾了当前服务器的资源指标情况,相比较现有技术,避免了在服务节点扩缩容的过程中,提供过多的服务器而导致服务器资源的浪费,有效地提高了服务器的资源指标和服务节点的运行指标之间的匹配关系,提高了业务系统整体的利用率。
结合第一方面和上述实现方式,在某些可能的实现方式中,根据该每一个服务节点的运行指标和该每一个服务器的资源指标确定该第一业务的扩缩容策略,还包括:根据该每一个服务器的资源指标,获取该N个服务器的资源指标的平均值;当该N个服务器的资源指标的平均值大于或等于第一阈值时,根据该每一个服务器的资源指标和该第一阈值,确定该N个服务器的扩容阈值和该N个服务器的扩容频率;根据该每一个服务器的资源指标、该N个服务器的扩容阈值和该N个服务器的扩容频率,确定该N个服务器的扩容策略;或,当该N个服务器的资源指标的平均值小于该第一阈值时,根据该每一个服务器的资源指标和该第一阈值,确定该N个服务器的缩容阈值和该N个服务器的缩容频率;根据该每一个服务器的资源指标、该N个服务器的缩容阈值和该N个服务器的缩容频率,确定该N个服务器的缩容策略。
上述技术方案中,在对服务器进行扩缩容的过程中,考虑了服务器的扩缩容频率和扩缩容阈值,确定扩缩容频率目的是为了控制服务器在扩缩容过程中的速率,避免由于一次性扩缩容的数量太多引起的服务器运行异常,避免业务系统服务出现故障和中断,服务器的扩缩容阈值有效保证了业务系统的正常运转,高效准确地实现了服务器的扩缩容过程。
结合第一方面和上述实现方式,在某些可能的实现方式中,该M个服务节点的扩容策略为增加该M个服务节点的数量,该M个服务节点的缩容策略为减少该M个服务节点的数量,该N个服务器的扩容策略为增加该N个服务器的数量,该N个服务器的缩容策略为减少该N个服务器的数量。
结合第一方面和上述实现方式,在某些可能的实现方式中,根据该N个服务器的资源指标、该N个服务器的扩容阈值和该N个服务器的扩容频率,确定该N个服务器的扩容策略,包括:根据该每一个服务器的资源指标和该N个服务器的资源指标的平均值,从该N个服务器中确定出第一服务器,该第一服务器的资源指标小于该第一阈值;确定该第一服务器的数量,当该第一服务器的数量小于或等于该N个服务器的扩容频率的数值时,根据该N个服务器的扩容频率和该N个服务器的扩容阈值,确定该N个服务器需要增加的服务器的总数和每次增加的服务器的数量;以及,根据该每一个服务器的资源指标、该N个服务器的缩容阈值和该N个服务器的缩容频率,确定该N个服务器的缩容策略,包括:根据该每一个服务器的资源指标和该N个服务器的资源指标的平均值,从该N个服务器中确定出第二服务器,该第二服务器的资源指标大于或等于该第一阈值;确定该第二服务器的数量,当该第二服务器的数量小于或等于该N个服务器的缩容频率的数值时,根据该N个服务器的缩容频率和该N个服务器的缩容阈值,确定该N个服务器中需要减小的服务器的总数和每次减少的服务器的数量。
上述技术方案中,在确定出扩容频率的基础上,通过将服务器的资源指标与第一阈值相比,确定出小于第一阈值的服务器,并将小于第一阈值的服务器的数量与扩容频率的数值相比较,只有当小于第一阈值的服务器的数量小于或等于扩容频率的数值时,才进行服务器的扩容,换句话说,当小于第一阈值的服务器的数量大于扩容频率的数值时,表明服务器只是整体的资源指标大于平均值,但是仍有多个服务器的资源指标数值比较低,此时服务器可以先不扩容,避免服务器资源的浪费。同理,在缩容的过程中,当服务器的平均值小于第一阈值时,需要对服务器进行缩容,但是若存在多个服务器的资源指标数值比较高时,可以先不缩容,避免了由于某个服务器的资源指标数据过高引起的服务器运行故障或异常的问题。
结合第一方面和上述实现方式,在某些可能的实现方式中,控制该M个服务节点和/或该N个服务器根据该扩缩容指令进行扩缩容,包括:根据该每一个服务器的资源指标,获取该N个服务器的资源指标的排序结果;根据该N个服务器的资源指标的排序结果,将资源指标最小的服务器确定为第三服务器;根据该M个服务节点的扩容阈值,将该M个服务节点的数量增加至该M个服务节点的扩容阈值,并控制该第三服务器运行增加的服务节点。
上述技术方案中,在对业务的服务节点进行扩容之后,需要进一步部署扩容的服务节点的运行规则,通过确定资源指标数据最小的服务器,控制该服务器运行扩容的服务节点,有效避免了将扩容之后的服务节点运行在资源指标数据较高的服务器而引起的服务器的运行压力,提高了服务器资源指标的利用率。
结合第一方面和上述实现方式,在某些可能的实现方式中,控制该M个服务节点和/或该N个服务器根据该扩缩容指令进行扩缩容,还包括:当该第二服务器的数量小于或等于该N个服务器的缩容频率的数值时,根据该每一个服务器的资源指标,将该N个服务器中资源指标小于第二阈值的服务器确定为待缩容服务器;当该待缩容服务器中运行该第一业务的服务节点,获取该N个服务器中除该待缩容服务器之外的服务器的资源指标的排序结果;根据该N个服务器中除该待缩容服务器之外的服务器的资源指标的排序结果,按顺序确定x个服务器,将该待缩容服务器运行的该第一业务的服务节点添加至该x个服务器,根据该N个服务器的缩容频率删除该待缩容服务器;当该待缩容服务器中未运行该第一业务对应的服务节点,直接根据该N个服务器的缩容频率删除该待缩容服务器。
上述过程中,在服务器缩容的过程中,当第二服务器数量小于或等于服务器的缩容频率的数值时,需要对服务器进行缩容处理,在缩容之前,首先需要确定待缩容服务器上是否有服务节点运行,若待缩容服务器上有服务节点运行,则不能直接删除该待缩容服务器,必须先将待缩容服务器上的服务节点运行在其他服务器上之后再删除该待缩容服务器,避免了在待缩容服务器上运行有服务节点时直接删除待缩容服务器而引起的业务服务受影响的问题。
综上,在实现业务系统扩缩容的过程中,本申请提出了一种可以根据业务系统的服务节点的运行指标和服务器的资源指标,动态准确的对业务系统实现扩缩容的方法,通过获取业务系统中的服务节点的运行指标和服务器的资源指标,同时考虑这两种指标参数,确定业务系统的服务节点和/或服务器的扩缩容指令,避免了服务节点与服务器资源的变化不同步的问题,避免了服务器资源的浪费,提高了业务系统的利用率,有效提高了用户的体验。
具体地,在对业务的服务节点实现扩缩容的过程中,结合业务的服务节点的运行指标和服务器的资源指标,确定出业务服务节点的扩缩容阈值,进一步根据服务节点的扩缩容阈值、服务节点的运行指标和服务器的资源指标,确定服务节点的扩缩容策略。
此外,在对服务节点扩缩容的过程中,兼顾了当前服务器的资源指标情况,相比较现有技术,避免了在服务节点扩缩容的过程中,提供过多的服务器而导致服务器资源的浪费,有效地提高了服务器的资源指标和服务节点的运行指标之间的匹配关系,提高了业务系统整体的利用率。在对服务器进行扩缩容的过程中,考虑了服务器的扩缩容频率和扩缩容阈值,确定扩缩容频率目的是为了控制服务器在扩缩容过程中的速率,避免由于一次性扩缩容的数量太多引起的服务器运行异常,避免业务系统服务出现故障和中断,服务器的扩缩容阈值有效保证了业务系统的正常运转,高效准确地实现了服务器的扩缩容过程。
在确定出扩容频率的基础上,通过将服务器的资源指标与第一阈值相比,确定出小于第一阈值的服务器,并将小于第一阈值的服务器的数量与扩容频率的数值相比较,只有当小于第一阈值的服务器的数量小于或等于扩容频率的数值时,才进行服务器的扩容,换句话说,当小于第一阈值的服务器的数量大于扩容频率的数值时,表明服务器只是整体的资源指标大于平均值,但是仍有多个服务器的资源指标数值比较低,此时服务器可以先不扩容,避免服务器资源的浪费,同理,在缩容的过程中,当服务器的平均值小于第一阈值时,需要对服务器进行缩容,但是若存在多个服务器的资源指标数值比较高时,可以先不缩容,避免了由于某个服务器的资源指标数据过高引起的服务器运行故障或异常的问题。
最后,在对业务的服务节点进行扩容之后,需要进一步部署扩容的服务节点的运行规则,通过确定资源指标数据最小的服务器,控制该服务器运行扩容的节点,有效避免了将扩容之后的服务节点运行在资源指标数据较高的服务器而引起的服务器的运行压力,提高了服务器资源指标的利用率。在服务器缩容的过程中,当待缩容服务器数量小于或等于服务器的缩容频率的数值时,需要对服务器进行缩容处理,在缩容之前,首先需要确定待缩容服务器上是否有服务节点运行,若待缩容服务器上有服务节点运行,则不能直接删除该待缩容服务器,必须先将待缩容服务器上的服务节点运行在其他服务器上之后再删除该待缩容服务器,避免了在待缩容服务器上运行有服务节点时删除待缩容服务器而引起的业务服务受影响的问题。
第二方面,提供了一种业务系统扩缩容的装置,其特征在于,该装置包括:第一处理模块,用于接收第一业务请求,解析该第一业务请求的域名并确定第一业务;获取模块,用于获取该第一业务关联的M个进程,该M个进程对应M个服务节点和N个服务器,M和N均为大于或等于1的整数;确定模块,用于确定该M个服务节点中每一个服务节点的运行指标和该N个服务器中每一个服务器的资源指标,根据该每一个服务节点的运行指标和该每一个服务器的资源指标确定针对该第一业务的扩缩容策略,该运行指标包括响应时间、每秒查询率、吞吐量中的一种或多种,该资源指标包括中央处理器CPU的利用率、内存利用率中的一种或多种;第二处理模块,用于根据该扩缩容策略生成并发送该第一业务的扩缩容指令,控制该M个服务节点和/或该N个服务器根据该扩缩容指令进行扩缩容。
结合第二方面,在某些可能的实现方式中,该确定模块具体用于:当该M个服务节点的运行指标满足第一条件时,根据该M个服务节点的运行指标和该每一个服务器的资源指标,确定该M个服务节点的扩容阈值;根据该M个服务节点的扩容阈值、该M个服务节点的运行指标和该每一个服务器的资源指标,确定该M个服务节点的扩容策略;或,当该M个服务节点的运行指标满足第二条件时,根据该M个服务节点的运行指标和该每一个服务器的资源指标,确定该M个服务节点的缩容阈值;根据该M个服务节点的缩容阈值、该M个服务节点的运行指标和该每一个服务器的资源指标,确定该M个服务节点的缩容策略。
结合第二方面和上述实现方式,在某些可能的实现方式中,该确定模块具体用于:根据该每一个服务器的资源指标,获取该N个服务器的资源指标的平均值;当该N个服务器的资源指标的平均值大于或等于第一阈值时,根据该每一个服务器的资源指标和该第一阈值,确定该N个服务器的扩容阈值和该N个服务器的扩容频率;根据该每一个服务器的资源指标、该N个服务器的扩容阈值和该N个服务器的扩容频率,确定该N个服务器的扩容策略;或,当该N个服务器的资源指标的平均值小于该第一阈值时,根据该每一个服务器的资源指标和该第一阈值,确定该N个服务器的缩容阈值和该N个服务器的缩容频率;根据该每一个服务器的资源指标、该N个服务器的缩容阈值和该N个服务器的缩容频率,确定该N个服务器的缩容策略。
结合第二方面和上述实现方式,在某些可能的实现方式中,该M个服务节点的扩容策略为增加该M个服务节点的数量,该M个服务节点的缩容策略为减少该M个服务节点的数量,该N个服务器的扩容策略为增加该N个服务器的数量,该N个服务器的缩容策略为减少该N个服务器的数量。
结合第二方面和上述实现方式,在某些可能的实现方式中,该确定模块还用于:根据该每一个服务器的资源指标和该N个服务器的资源指标的平均值,从该N个服务器中确定出第一服务器,该第一服务器的资源指标小于该第一阈值;确定该第一服务器的数量,当该第一服务器的数量小于或等于该N个服务器的扩容频率的数值时,根据该N个服务器的扩容频率和该N个服务器的扩容阈值,确定该N个服务器需要增加的服务器的总数和每次增加的服务器的数量;以及,根据该每一个服务器的资源指标和该N个服务器的资源指标的平均值,从该N个服务器中确定出第二服务器,该第二服务器的资源指标大于或等于该第一阈值;确定该第二服务器的数量,当该第二服务器的数量小于或等于该N个服务器的缩容频率的数值时,根据该N个服务器的缩容频率和该N个服务器的缩容阈值,确定该N个服务器中需要减小的服务器的总数和每次减少的服务器的数量。
结合第二方面和上述实现方式,在某些可能的实现方式中,该第二处理模块具体用于:根据该每一个服务器的资源指标,获取该N个服务器的资源指标的排序结果;根据该N个服务器的资源指标的排序结果,将资源指标最小的服务器确定为第三服务器;根据该M个服务节点的扩容阈值,将该M个服务节点的数量增加至该M个服务节点的扩容阈值,并控制该第三服务器运行增加的服务节点。
结合第二方面和上述实现方式,在某些可能的实现方式中,该第二处理模块具体用于:当该第二服务器的数量小于或等于该N个服务器的缩容频率的数值时,根据该每一个服务器的资源指标,将该N个服务器中资源指标小于第二阈值的服务器确定为待缩容服务器;当该待缩容服务器中运行该第一业务的服务节点,获取该N个服务器中除该待缩容服务器之外的服务器的资源指标的排序结果;根据该N个服务器中除该待缩容服务器之外的服务器的资源指标的排序结果,按顺序确定x个服务器,将该待缩容服务器运行的该第一业务的服务节点添加至该x个服务器,根据该N个服务器的缩容频率删除该待缩容服务器;当该待缩容服务器中未运行该第一业务对应的服务节点,直接根据该N个服务器的缩容频率删除该待缩容服务器。
第三方面,提供一种电子设备,包括存储器和处理器。该存储器用于存储计算机程序,该处理器用于从存储器中调用并运行该计算机程序,使得该电子设备执行上述第一方面或第一方面任意一种可能的实现方式中的方法。
第四方面,提供了一种计算机程序产品,该计算机程序产品包括:计算机程序代码,当该计算机程序代码在计算机上运行时,使得该计算机执行上述第一方面或第一方面任意一种可能的实现方式中的方法。
第五方面,提供了一种计算机可读介质,该计算机可读介质存储有程序代码,当该计算机程序代码在计算机上运行时,使得该计算机执行上述第一方面或第一方面任意一种可能的实现方式中的方法。
附图说明
图1是本申请实施例的一种业务系统扩缩容的方法的应用场景示意图;
图2是本申请实施例提供的一种业务系统扩缩容的方法的示意性流程图;
图3是本申请实施例提供的一种业务系统扩缩容的装置的结构示意图;
图4是本申请实施例提供的一种电子设备的结构示意图。
具体实施方式
下面将结合附图,对本申请中的技术方案进行清楚、详尽地描述。其中,在本申请实施例的描述中,除非另有说明,“/”表示或的意思,例如,A/B可以表示A或B:文本中的“和/或”仅仅是一种描述关联对象的关联关系,表示可以存在三种关系,例如A和/或B,可以表示:单独存在A,同时存在A和B,单独存在B这三种情况,另外,在本申请实施例的描述中,“多个”是指两个或多于两个。
以下,术语“第一”、“第二”仅用于描述目的,而不能理解为暗示或暗示相对重要性或隐含指明所指示的技术特征的数量。由此,限定有“第一”、“第二”的特征可以明示或者隐含地包括一个或者多个该特征。
图1是本申请实施例提供的一种业务系统扩缩容的方法的应用场景示意图。
示例性的,如图1所示,该应用场景可以为基础设置即服务(Infrastructure-as-a-Service,IaaS)、平台即服务(Platform-as-a-Service,PaaS)、软件即服务(Software-as-a-Service,SaaS)中的任意一种。
其中,网关101用于接收前端(例如客户端)发送的业务请求,并进一步将该业务请求发送至与网关101绑定的域名系统(Domain Name System,DNS),完成该业务请求的域名解析,在域名解析之后,网关101将该业务请求转发至后端(服务端)的业务集群管理装置102,业务集群管理装置102根据该业务请求,确定出第一业务103。示例性的,第一业务103包含有服务节点1031、服务节点1032和服务节点1032,每一个服务节点都对应一个运行指标。业务集群管理装置102可以根据服务节点1031的运行指标、服务节点1032的运行指标和服务节点1033的运行指标对第一业务103实现扩缩容管理。同时,服务节点1031在服务器上105运行,服务节点1032在服务器上106上运行,服务节点1033在服务器107上运行,服务器105、服务器106和服务器107均对应一个资源指标。
资源集群管理装置104可以根据服务器105、服务器106和服务器107的资源指标,实现对服务器的扩缩容管理。
指标收集装置108负责收集服务节点1031、服务节点1032和服务节点1032的运行指标以及服务器105、服务器106和服务器107的资源指标,并将收集得到的运行指标和资源指标发送至决策调度装置109。
策略决策调度装置109根据运行指标和资源指标,确定第一业务103的扩缩容策略,并进一步根据该扩缩容策略生成第一业务的扩缩容指令,进一步策略决策调度装置109将该扩缩容指令发送至业务集群管理装置102和/或资源集群管理装置104,业务集群管理装置102和/或资源集群管理装置104根据扩缩容指令完成扩缩容操作。
图2是本申请实施例提供的一种业务系统扩缩容的方法的示意性流程图。应理解,该方法可以应用于图1所示的应用场景中,该方法可以由IaaS云平台、PaaS云平台、SaaS云平台中的任意一种执行。
示例性的,如图2所示,该方法200包括:
201,接收第一业务请求,解析第一业务请求的域名并确定第一业务。
应理解,通常在业务系统进行扩缩容的过程中,需要先接收业务请求,进一步可以通过解析业务请求的域名确定出需要进行扩缩容处理的第一业务,域名解析主要是为了保证业务系统统一对外提供服务。
示例性的,如图1所示,网关101可以接收来自客户端发送的第一业务请求,网关101可以将该第一业务请求发送至与网关101绑定的DNS,通过DNS解析该第一业务请求的域名。随后,网关101将第一业务请求发送至服务端的业务集群管理装置102,业务集群管理装置102根据该第一业务请求从多个业务中确定出与第一业务请求相对应的第一业务103。
202,获取第一业务关联的M个进程,M个进程对应M个服务节点和N个服务器,M和N均为大于或等于1的整数。
应理解,每一个业务在运行过程中,对应多个该业务的服务节点和运行该多个服务节点的一个或多个服务器。
示例性的,如图1所示,业务集群管理装置102可以根据第一业务103确定出第一业务相关联的服务节点1031、服务节点1032和服务节点1033以及服务器105、服务器106、服务器107。
203,确定M个服务节点中每一个服务节点的运行指标和N个服务器中每一个服务器的资源指标,根据每一个服务节点的运行指标和每一个服务器的资源指标确定针对第一业务的扩缩容策略,运行指标包括响应时间、每秒查询率、吞吐量中的一种或多种,资源指标包括中央处理器CPU的利用率、内存利用率中的一种或多种。
应理解,M个服务节点中每一个服务节点在运行过程中,都对应有该服务节点的运行指标。因此在每一个服务节点运行过程中,可以获取每一个服务节点的运行指标。同理,N个服务器在运行M个服务节点的过程中,可以获取N个服务器中每一个服务器的资源指标。
可选的,每一个服务节点的运行指标包括通用化运行指标和个性化运行指标,其中,通用性运行指标包括每秒查询率(Query Per Second,QPS)、响应时间(Reaction Time,RT)、吞吐量中的一种或多种,个性化运行指标包括特定接口调用量、特定接口响应时间中的一种或多种。
应理解,一般情况下,对于业务的服务节点的运行状况的判断,通常是根据服务节点的通用化运行指标来进行后续扩缩容处理,当业务为核心业务时,可以适当的给该核心业务的服务节点添加个性化指标,增加该核心业务的运行指标的精确程度。
可选的,服务器的资源指标包括服务器的CPU利用率、内存利用率等。
通过对第一业务对应的M个服务节点的运行指标以及N个服务器中每个服务器资源指标的收集,可以根据收集的服务节点的运行指标和服务器的资源指标,与各自对应的预设规则或者预设条件进行比较,当运行指标和/或资源指标满足其对应的预设条件或预设规则时,可以基于第一业务下的运行指标和资源指标,生成第一业务的扩缩容策略。
应理解,第一业务的M个进程包含M个服务节点和N个服务器,因此在对第一业务进行扩缩容的过程中,第一业务的扩缩容策略既需要考虑M个服务节点的扩缩容策略,还需要考虑N个服务器的扩缩容策略。
具体的,M个服务节点的扩容策略为增加M个服务节点的数量,M个服务节点的缩容策略为减少M个服务节点的数量,N个服务器的扩容策略为增加N个服务器的数量,N个服务器的缩容策略为减少N个服务器的数量。
本申请实施例提供的一种业务系统扩缩容的方法,在对服务节点进行扩缩容的过程中,可以根据服务节点的运行指标,同时兼顾到服务器的资源指标,根据两者可以确定出业务系统的服务节点在扩缩容过程中可以进行扩缩容的上限值或者下限值,在实际业务系统的服务节点扩缩容的过程中,需要保证服务节点的扩缩容的范围不超过上限值或者下限值。
一种可能的实现方式中,根据M个服务节点的运行指标,确定M个服务节点的扩容策略包括:
(1)当M个服务节点的运行指标满足第一条件时,根据M个服务节点的运行指标和每一个服务器的资源指标,确定M个服务节点的扩容阈值;
(2)根据M个服务节点的扩容阈值、M个服务节点的运行指标和每一个服务器的资源指标,确定M个服务节点的扩容策略。
另一种可能的实现方式中,根据M个服务节点的运行指标,确定M个服务节点的缩容策略包括:
(1)当M个服务节点的运行指标满足第二条件时,根据M个服务节点的运行指标和每一个服务器的资源指标,确定M个服务节点的缩容阈值;
(2)根据M个服务节点的缩容阈值、M个服务节点的运行指标和每一个服务器的资源指标,确定M个服务节点的缩容策略。
应理解,对于服务节点的扩缩容来说,关注的是服务节点的运行指标的平均使用情况,以及M个服务节点是否处于存活状态。如果M个服务节点,突然存在不存活节点,需要及时进行服务节点的扩容处理;如果M个服务节点的平均运行指标突然徒增,也需要及时扩容;但是如果某个服务节点的运行指标徒增,对于服务节点的扩容来说,可以先不进行扩容,等到该服务节点的运行指标开始影响运行指标的平均值时,才需要对服务节点进行扩容。
一种可能的实现方式中,在对M个服务节点的运行指标判断扩缩容的过程中,通过采集M个服务节点的运行指标,根据M个服务节点的运行指标的判断规则,组合得到M个服务节点的逻辑判断结果或者与阈值的比较结果,例如:或、且、大于、小于等。
示例性的,如图1所示,服务节点1031、服务节点1032、服务节点1033中,每一个服务节点均对应一组运行指标,那么一共可以采集到3组运行指标(例如吞吐量、每秒查询率等),基于运行指标的参数的不同,每一种参数可能都对应一个预设的条件(例如吞吐量对应阈值A,每秒查询率对应阈值B),将运行指标的不同的参数分别与对应的预设阈值相比较,例如将服务节点1031、服务节点1032、服务节点1033的运行指标中的吞吐量求平均值,并将吞吐量的平均值与阈值A进行比较,得到3个服务节点的吞吐量的判断结果;将服务节点1031、服务节点1032、服务节点1033的运行指标中的每秒查询率求平均值,并将每秒查询率的平均值与阈值B进行比较,得到3个服务节点的每秒查询率的判断结果。假设第一条件为:对吞吐量和每秒查询率的判断结果取逻辑规则“且”,同时3个服务器的吞吐量最大值与最小值的差值以及每秒查询率的最大值与最小值的差值均在预设阈值范围内,那么当3个服务节点的吞吐量的平均值大于或等于阈值A,且3个服务节点的每秒查询率的平均值大于或等于阈值B,同时,3个服务器的吞吐量以及每秒查询率的数值分布均衡时,则认为3个服务节点满足第一条件,需要对服务节点进行扩容处理。同理,业务节点的缩容处理也类似,此处不再重复说明。
可选地,在设置服务节点的第一条件的过程中,可以实时根据服务节点的运行指标,对服务节点的第一条件进行调整。
应理解,根据服务器的资源指标对服务器资源进行扩缩容的过程中,重点是关注服务器资源指标的平均分配情况,即服务器的资源指标的平均值若大于或等于预设的阈值,表明此时服务器整体的运行压力比较大,需要及时进行扩容处理;若小于预设的阈值,则表明服务器整体的运行压力比较小,可以适当的进行缩容处理。
一种可能的实现方式中,在进行服务器的扩容判断时,主要有以下步骤:
(1)根据每一个服务器的资源指标,获取N个服务器的资源指标的平均值;
(2)当N个服务器的资源指标的平均值大于或等于第一阈值时,根据每一个服务器的资源指标和第一阈值,确定N个服务器的扩容阈值和N个服务器的扩容频率;
(3)根据每一个服务器的资源指标、N个服务器的扩容阈值和N个服务器的扩容频率,确定N个服务器的扩容策略。
应理解,上述在将N个服务器的资源指标的平均值与第一阈值进行比较的过程中,资源指标包括CPU利用率和/或内存利用率,具体是关注CPU利用率还是内存利用率,或者是两个资源指标都需要关注是根据第一业务的特性决定的。例如,当第一业务是侧重于内存型的业务时,此时在进行服务器扩缩容决策的时候,就需要重点关注内存的利用率;当第一业务是侧重于计算型的业务,就需要重点关注CPU的利用率;如果第一业务是内存和CPU均衡的业务,此时CPU的利用率和内存利用率需要同时关注。
还应理解,扩容阈值和扩容频率是为了保证业务系统整体的稳定性以及业务系统中服务器资源的利用率,在对服务器进行扩容的过程中,需要根据每一个服务器的资源指标、服务器的扩容阈值和服务器的扩容频率,确定服务器的扩容策略。具体包括:
(1)根据每一个服务器的资源指标和N个服务器的资源指标的平均值,从N个服务器中确定出第一服务器,第一服务器的资源指标小于第一阈值;
(2)确定第一服务器的数量,当第一服务器的数量小于或等于N个服务器的扩容频率的数值时,根据N个服务器的扩容频率和N个服务器的扩容阈值,确定N个服务器需要增加的服务器的总数和每次增加的服务器的数量。
应理解,在具体扩容过程中,服务器的资源指标的平均值代表了服务器的资源指标整体的利用率。在服务器的资源值指标的平均值大于第一阈值情况下,对于每一个服务器而言,有可能会存在某些服务器的资源指标小于第一阈值,虽然服务器整体的资源指标高于第一阈值,但是当资源指标小于第一阈值的服务器的数量比较多时,为了保证服务器的整体利用率,可以先不进行扩容处理,先给利用率较低的服务器分配节点,保证在服务器整体资源指标高于第一阈值的情况下,每一个服务器的资源指标都能够均衡分配。
示例性的,如图1所示,在进行服务器的扩容处理时,业务系统中存在3台服务器,即服务器105、服务器106和服务器107,3台服务器的整体的资源指标大于第一阈值,且根据第一阈值和每一个服务器的资源指标,确定出3台服务器的扩容频率为2台/次。此时,在3台服务器中,如果有1台服务器的利用率低于第一阈值,那么这3台服务器在进行扩容处理的过程中,扩容频率就会按照实际的利用率低的服务器的数量进行调整,即服务器扩容处理时,实际的扩容频率为1台/次;如果有两台或者两台以上的服务器的利用率都低于第一阈值,此时利用率低的服务器的数量超过了扩容频率的数值,此时即使服务器整体的资源指标利用率比较高,可以对服务器不进行扩容处理,优先选择给利用率低的服务器分配任务,提高这些服务器的利用率,之后再决定是否进行扩容处理;若3台服务器的利用率都很均衡,不存在利用率相差较大的情况,则按照扩容频率2台/次对服务器进行扩容处理。
同理,在进行服务器的缩容判断时,主要有以下步骤:
(1)当N个服务器的资源指标的平均值小于第一阈值时,根据每一个服务器的资源指标和第一阈值,确定N个服务器的缩容阈值和N个服务器的缩容频率;
(2)根据每一个服务器的资源指标、N个服务器的缩容阈值和N个服务器的缩容频率,确定N个服务器的缩容策略。
具体的,根据每一个服务器的资源指标、N个服务器的缩容阈值和N个服务器的缩容频率,确定N个服务器的缩容策略。包括:
(1)根据每一个服务器的资源指标和N个服务器的资源指标的平均值,从N个服务器中确定出第二服务器,第二服务器的资源指标大于或等于第一阈值;
(2)确定第二服务器的数量,当第二服务器的数量小于或等于N个服务器的缩容频率的数值时,根据N个服务器的缩容频率和N个服务器的缩容阈值,确定N个服务器中需要减小的服务器的总数和每次减少的服务器的数量。
服务器在缩容处理的过程中,判断和处理的思路与扩容的过程基本相同,此处不再重复说明。
可选地,对于服务器的资源指标的扩缩容判断时,扩容和缩容的阈值设定为同一个阈值,也可以设置不同的阈值。例如,也可以预先设置服务器的扩容的判断阈值为阈值1,缩容的判断阈值为阈值2,且阈值2小于阈值1,当服务器的资源指标的平均值大于阈值1时,表明服务器当前的资源指标的利用率较高,服务器运行压力较大,需要对服务器进行扩容处理;当服务器的资源指标的平均值小于阈值2时,表示服务器当前的资源指标利用率较低,需要对服务器进行缩容处理;当服务器的资源指标介于阈值1和阈值2之间时,表示服务器当前的资源指标处于稳定运行的状态,此时服务器既不需要进行扩容处理,也不需要进行缩容处理。
应理解,服务节点的扩缩容处理中虽然也考虑了服务器的资源指标,但是在服务节点中针对于服务器的资源指标主要考虑的是哪些服务器的资源指标较低或者哪些服务器的资源指标较高,而不考虑服务器整体的资源指标;而服务器的扩缩容主要针对的是服务器整体的资源指标的均衡情况,重在提高或者降低服务器整体的资源指标,使整体的资源指标处于平均值上下的水平,两者在扩缩容判断和处理的过程中,考虑的因素是有差异的。此外,服务节点的扩缩容和服务器的扩缩容之间没有必然联系,也就是说,服务节点进行扩容或者缩容的时候,服务器可以不扩容不缩容,也可以进行扩容或者缩容。
示例性的,如图1所示,第一业务103包括三个服务节点,分别为服务节点1031、服务节点1032和服务节点1033,每一个服务节点对对应一组运行指标,其中,服务器105用来运行服务节点1031,服务器106用来运行服务节点1032,服务器107用来运行服务节点1033,每一个服务器在运行过程中对应一组资源指标。指标收集装置108可以将服务节点1031、服务节点1032和服务节点1033的运行指标以及服务器105、服务器106和服务器107的资源指标全部收集,之后发送至策略决策调度装置109。策略决策调度装置109通过组合服务节点1031、服务节点1032和服务节点1033的运行指标,并且将组合之后的运行指标的结果与预设的运行指标判断条件进行比较,判断服务节点是否需要进行扩缩容处理,若需要进行扩容或者缩容处理;策略决策调度装置109根据3个服务节点的运行指标和每一个服务器的资源指标,确定3个服务节点的扩容阈值或者缩容阈值;根据3个服务节点的扩容阈值、3个服务节点的运行指标和每一个服务器的资源指标,确定3个服务节点在进行扩容或者缩容处理时需要增加/减少的服务节点的数量。
同时,策略决策调度装置109还可以根据服务器105、服务器106和服务器107的资源指标,计算出三个服务器的资源指标的平均值,通过将该平均值与资源指标的预设阈值进行比较,判断服务器是否需要进行扩缩容处理。当服务器需要进行扩缩容处理时,策略决策调度装置109可以根据服务器105、服务器106和服务器107的资源指标和预设阈值,计算出服务器需要扩容的上限值或者需要缩容的下限值,以及服务器的扩容频率或者缩容频率,进一步根据服务器的扩容上限值和扩容频率,确定服务器的扩容策略,以及,根据服务器的缩容下限值和缩容频率,确定服务器的缩容策略。
上述技术方案中,在对业务的服务节点实现扩缩容的过程中,结合业务的服务节点的运行指标和服务器的资源指标,确定出业务服务节点的扩缩容阈值,进一步根据服务节点的扩缩容阈值、服务节点的运行指标和服务器的资源指标,确定服务节点的扩缩容策略。
此外,在对服务节点扩缩容的过程中,兼顾了当前服务器的资源指标情况,相比较现有技术,避免了在服务节点扩缩容的过程中,提供过多的服务器而导致服务器资源的浪费,有效地提高了服务器的资源指标和服务节点的运行指标之间的匹配关系,提高了业务系统整体的利用率。在对服务器进行扩缩容的过程中,考虑了服务器的扩缩容频率和扩缩容阈值,确定扩缩容频率目的是为了控制服务器在扩缩容过程中的速率,避免由于一次性扩缩容的数量太多引起的服务器运行异常,避免业务系统服务出现故障和中断,服务器的扩缩容阈值有效保证了业务系统的正常运转,高效准确地实现了服务器的扩缩容过程。
在确定出扩容频率的基础上,通过将服务器的资源指标与第一阈值相比,确定出小于第一阈值的服务器,并将小于第一阈值的服务器的数量与扩容频率的数值相比较,只有当小于第一阈值的服务器的数量小于或等于扩容频率的数值时,才进行服务器的扩容,换句话说,当小于第一阈值的服务器的数量大于扩容频率的数值时,表明服务器只是整体的资源指标大于平均值,但是仍有多个服务器的资源指标数值比较低,此时服务器可以先不扩容,避免服务器资源的浪费,同理,在缩容的过程中,当服务器的平均值小于第一阈值时,需要对服务器进行缩容,但是若存在多个服务器的资源指标数值比较高时,可以先不缩容,避免了由于某个服务器的资源指标数据过高引起的服务器运行故障或异常的问题。
204,根据扩缩容策略生成并发送第一业务的扩缩容指令,控制M个服务节点和/或N个服务器根据扩缩容指令进行扩缩容。
示例性的,如图1所述,策略决策调度装置109在确定出服务节点的扩缩容策略和/或服务器的扩缩容策略之后,进一步地,策略决策调度装置109根据对应的扩缩容策略生成扩缩容指令,并将扩缩容指令发送至业务集群管理装置102或资源集群管理装置104。业务集群管理装置102可以根据服务节点的扩缩容指令进行第一业务103的服务节点1031、服务节点1032和服务节点1033的扩缩容处理,即增加或者减少服务节点的数量;资源集群管理装置104可以根据服务器的扩缩容指令进行服务器105、服务器106和服务器107的扩缩容处理,即增加或者减少服务器的数量。
应理解,服务节点在进行扩容处理之后,服务节点的数量有所增加,此时,需要将增加之后的服务节点进行合理的分配,即优先选择将增加后的服务节点运行在资源指标较低的服务器上,具体包括:
(1)根据每一个服务器的资源指标,获取N个服务器的资源指标的排序结果;
(2)根据N个服务器的资源指标的排序结果,将资源指标最小的服务器确定为第三服务器;
(3)根据M个服务节点的扩容阈值,将M个服务节点的数量增加至M个服务节点的扩容阈值,并控制第三服务器运行增加的服务节点。
应理解,服务节点和服务器的扩缩容是独立进行的,服务节点进行扩容处理之后,假设服务器也需要进行扩容处理时,就会出现扩容之后的服务器可能处于闲置的状态,此时闲置的服务器即为所有服务器中资源指标最低的服务器,在下一次服务节点扩容时,会优先将将扩容之后的服务节点运行在该闲置的服务器上。
上述技术方案中,在对业务的服务节点进行扩容之后,需要进一步部署扩容的服务节点的运行规则,通过确定资源指标数据最小的服务器,控制该服务器运行扩容的节点,有效避免了将扩容之后的服务节点运行在资源指标数据较高的服务器而引起的服务器的运行压力,提高了服务器资源指标的利用率。
应理解,在服务器缩容的过程中,可以将资源指标小于特定阈值的服务器确定为待缩容服务器,待缩容服务器为资源指标较低的服务器,在服务器进行缩容之前,需要先判断待缩容服务器上是否运行了第一业务的服务节点,若待缩容服务器处于空闲状态,则直接删除该待缩容服务器即可,若待缩容服务器上运行有第一业务的服务节点,需要先将待缩容服务器上的服务节点分配至其他服务器上之后,保证待缩容服务器处于闲置状态后,才可进行缩容处理。具体包括:
(1)当该第二服务器的数量小于或等于该N个服务器的缩容频率的数值时,根据该每一个服务器的资源指标,将该N个服务器中资源指标小于第二阈值的服务器确定为待缩容服务器;
(2)当该待缩容服务器中运行该第一业务的服务节点,获取该N个服务器中除该待缩容服务器之外的服务器的资源指标的排序结果;
(3)根据该N个服务器中除该待缩容服务器之外的服务器的资源指标的排序结果,按顺序确定x个服务器,将该待缩容服务器运行的该第一业务的服务节点添加至该x个服务器,根据该N个服务器的缩容频率删除该待缩容服务器;
(4)当该待缩容服务器中未运行该第一业务对应的服务节点,直接根据该N个服务器的缩容频率删除该待缩容服务器。
上述过程中,在服务器缩容的过程中,当待缩容服务器数量小于或等于服务器的缩容频率的数值时,需要对服务器进行缩容处理,在缩容之前,首先需要确定待缩容服务器上是否有服务节点运行,若待缩容服务器上有服务节点运行,则不能直接删除该待缩容服务器,必须先将待缩容服务器上的服务节点运行在其他服务器上之后再删除该待缩容服务器,避免了在服务器上运行有服务节点时删除服务器而引起的业务服务受影响的问题。
综上,在实现业务系统扩缩容的过程中,本申请提出了一种可以根据业务系统的服务节点的运行指标和服务器的资源指标,动态准确的对业务系统实现扩缩容的方法,通过获取业务系统中的服务节点的运行指标和服务器的资源指标,同时考虑这两种指标参数,确定业务系统的服务节点和/或服务器的扩缩容指令,避免了服务节点与服务器资源的变化不同步的问题,避免了服务器资源的浪费,提高了业务系统的利用率,有效提高了用户的体验。
具体地,在对业务的服务节点实现扩缩容的过程中,结合业务的服务节点的运行指标和服务器的资源指标,确定出业务服务节点的扩缩容阈值,进一步根据服务节点的扩缩容阈值、服务节点的运行指标和服务器的资源指标,确定服务节点的扩缩容策略。
此外,在对服务节点扩缩容的过程中,兼顾了当前服务器的资源指标情况,相比较现有技术,避免了在服务节点扩缩容的过程中,提供过多的服务器而导致服务器资源的浪费,有效地提高了服务器的资源指标和服务节点的运行指标之间的匹配关系,提高了业务系统整体的利用率。在对服务器进行扩缩容的过程中,考虑了服务器的扩缩容频率和扩缩容阈值,确定扩缩容频率目的是为了控制服务器在扩缩容过程中的速率,避免由于一次性扩缩容的数量太多引起的服务器运行异常,避免业务系统服务出现故障和中断,服务器的扩缩容阈值有效保证了业务系统的正常运转,高效准确地实现了服务器的扩缩容过程。
在确定出扩容频率的基础上,通过将服务器的资源指标与第一阈值相比,确定出小于第一阈值的服务器,并将小于第一阈值的服务器的数量与扩容频率的数值相比较,只有当小于第一阈值的服务器的数量小于或等于扩容频率的数值时,才进行服务器的扩容,换句话说,当小于第一阈值的服务器的数量大于扩容频率的数值时,表明服务器只是整体的资源指标大于平均值,但是仍有多个服务器的资源指标数值比较低,此时服务器可以先不扩容,避免服务器资源的浪费,同理,在缩容的过程中,当服务器的平均值小于第一阈值时,需要对服务器进行缩容,但是若存在多个服务器的资源指标数值比较高时,可以先不缩容,避免了由于某个服务器的资源指标数据过高引起的服务器运行故障或异常的问题。
最后,在对业务的服务节点进行扩容之后,需要进一步部署扩容的服务节点的运行规则,通过确定资源指标数据最小的服务器,控制该服务器运行扩容的节点,有效避免了将扩容之后的服务节点运行在资源指标数据较高的服务器而引起的服务器的运行压力,提高了服务器资源指标的利用率。在服务器缩容的过程中,当待缩容服务器数量小于或等于服务器的缩容频率的数值时,需要对服务器进行缩容处理,在缩容之前,首先需要确定待缩容服务器上是否有服务节点运行,若待缩容服务器上有服务节点运行,则不能直接删除该待缩容服务器,必须先将待缩容服务器上的服务节点运行在其他服务器上之后再删除该待缩容服务器,避免了在待缩容服务器上运行有服务节点时删除待缩容服务器而引起的业务服务受影响的问题。
图3是本申请实施例提供的一种业务系统扩缩容的装置的结构示意图。
示例性的,如图3所示,该装置300包括:
第一处理模块301,用于接收第一业务请求,解析该第一业务请求的域名并确定第一业务;处理模块301相当于图1中的网关101和业务集群管理装置102;
获取模块302,用于获取该第一业务关联的M个进程,该M个进程对应M个服务节点和N个服务器,M和N均为大于或等于1的整数;获取模块302相当于图1中的业务集群管理装置102。
确定模块303,用于确定该M个服务节点中每一个服务节点的运行指标和该N个服务器中每一个服务器的资源指标,根据该每一个服务节点的运行指标和该每一个服务器的资源指标确定针对该第一业务的扩缩容策略,该运行指标包括响应时间、每秒查询率、吞吐量中的一种或多种,该资源指标包括中央处理器CPU的利用率、内存利用率中的一种或多种;确定模块303相当于图1中的指标收集装置108和策略决策调度装置109。
第二处理模块304,用于根据该扩缩容策略生成并发送该第一业务的扩缩容指令,控制该M个服务节点和/或该N个服务器根据该扩缩容指令进行扩缩容;第二处理模块304相当于图1中的策略决策调度装置109、业务集群管理装置102、资源集群管理装置104。
在一种可能的实现方式中,该确定模块303具体用于:当该M个服务节点的运行指标满足第一条件时,根据该M个服务节点的运行指标和该每一个服务器的资源指标,确定该M个服务节点的扩容阈值;根据该M个服务节点的扩容阈值、该M个服务节点的运行指标和该每一个服务器的资源指标,确定该M个服务节点的扩容指令;或,当该M个服务节点的运行指标满足第二条件时,根据该M个服务节点的运行指标和该每一个服务器的资源指标,确定该M个服务节点的缩容阈值;根据该M个服务节点的缩容阈值、该M个服务节点的运行指标和该每一个服务器的资源指标,确定该M个服务节点的缩容指令。
在一种可能的实现方式中,该确定模块303具体用于:根据该每一个服务器的资源指标,获取该N个服务器的资源指标的平均值;当该N个服务器的资源指标的平均值大于或等于第一阈值时,根据该每一个服务器的资源指标和该第一阈值,确定该N个服务器的扩容阈值和该N个服务器的扩容频率;根据该每一个服务器的资源指标、该N个服务器的扩容阈值和该N个服务器的扩容频率,确定该N个服务器的扩容指令;或,当该N个服务器的资源指标的平均值小于该第一阈值时,根据该每一个服务器的资源指标和该第一阈值,确定该N个服务器的缩容阈值和该N个服务器的缩容频率;根据该每一个服务器的资源指标、该N个服务器的缩容阈值和该N个服务器的缩容频率,确定该N个服务器的缩容指令。
在一种可能的实现方式中,该M个服务节点的扩容指令为增加该M个服务节点的数量,该M个服务节点的缩容指令为减少该M个服务节点的数量,该N个服务器的扩容指令为增加该N个服务器的数量,该N个服务器的缩容指令为减少该N个服务器的数量。
在一种可能的实现方式中,该确定模块303还用于:根据该每一个服务器的资源指标和该N个服务器的资源指标的平均值,从该N个服务器中确定出第一服务器,该第一服务器的资源指标小于该第一阈值;确定该第一服务器的数量,当该第一服务器的数量小于或等于该N个服务器的扩容频率的数值时,根据该N个服务器的扩容频率和该N个服务器的扩容阈值,确定该N个服务器需要增加的服务器的总数和每次增加的服务器的数量;以及,根据该每一个服务器的资源指标和该N个服务器的资源指标的平均值,从该N个服务器中确定出第二服务器,该第二服务器的资源指标大于或等于该第一阈值;确定该第二服务器的数量,当该第二服务器的数量小于或等于该N个服务器的缩容频率的数值时,根据该N个服务器的缩容频率和该N个服务器的缩容阈值,确定该N个服务器中需要减小的服务器的总数和每次减少的服务器的数量。
在一种可能的实现方式中,该第二处理模块304具体用于:根据该每一个服务器的资源指标,获取该N个服务器的资源指标的排序结果;根据该N个服务器的资源指标的排序结果,将资源指标最小的服务器确定为第三服务器;根据该M个服务节点的扩容阈值,将该M个服务节点的数量增加至该M个服务节点的扩容阈值,并控制该第三服务器运行增加的服务节点。
在一种可能的实现方式中,该第二处理模块304具体用于:当该第二服务器的数量小于或等于该N个服务器的缩容频率的数值时,将该N个服务器中资源指标小于第二阈值的服务器确定为待缩容服务器;当该待缩容服务器中运行该第一业务的服务节点,获取该N个服务器中除该待缩容服务器之外的服务器的资源指标的排序结果;根据该N个服务器中除该待缩容服务器之外的服务器的资源指标的排序结果,按顺序确定x个服务器,将该待缩容服务器运行的该第一业务的服务节点添加至该x个服务器,根据该N个服务器的缩容频率删除该待缩容服务器;当该待缩容服务器中未运行该第一业务对应的服务节点,直接根据该N个服务器的缩容频率删除该待缩容服务器。
图4是本申请实施例提供的一种电子设备的结构示意图。
示例性的,如图4所示,该电子设备400包括:存储器401和处理器402。
一种可能的实现方式中,存储器401用于存储计算机程序4011;处理器402用于从该存储器401中调用并运行该计算机程序4011实现一种业务系统扩缩容的方法,例如图2中的201至204。
本实施例可以根据上述方法示例对电子设备进行功能模块的划分,例如,可以对应各个功能模块,也可以将两个或两个以上的功能集成在一个处理模块中,上述集成的模块可以采用硬件的形式实现。需要说明的是,本实施例中对模块的划分是示意性的,仅仅为一种逻辑功能划分,实际实现时可以有另外的划分方式。
在采用对应各个功能划分各个功能模块的情况下,该电子设备可以包括:第一处理模块、获取模块、确定模块、第二处理模块等。需要说明的是,上述方法实施例涉及的各个步骤的所有相关内容的可以援引到对应功能模块的功能描述,在此不再赘述。
本实施例提供的电子设备,用于执行上述一种业务系统扩缩容的方法,因此可以达到与上述实现方法相同的效果。
在采用集成的单元的情况下,电子设备可以包括处理模块、存储模块。其中,处理模块可以用于对电子设备的动作进行控制管理。存储模块可以用于支持电子设备执行相互程序代码和数据等。
其中,处理模块可以是处理器或控制器,其可以实现或执行结合本申请公开内容所藐视的各种示例性的逻辑方框,模块和电路。处理器也可以是实现计算功能的组合,例如包括一个或多个微处理器组合,数字信号处理(digital signal processing,DSP)和微处理器的组合等等,存储模块可以是存储器。
本实施例还提供一种计算机可读存储介质,该计算机可读存储介质中存储有计算机程序代码,当该计算机程序代码在计算机上运行时,使得计算机执行上述相关方法步骤实现上述实施例中的一种业务系统扩缩容的方法。
本实施例还提供了一种计算机程序产品,当该计算机程序产品在计算机上运行时,使得计算机执行上述相关步骤,以实现上述实施例中的一种业务系统扩缩容的方法。
另外,本申请的实施例还提供一种装置,该装置具体可以是芯片,组件或模块,该装置可包括相连的处理器和存储器;其中,存储器用于存储指令,当装置运行时,处理器可调用并执行指令,以使芯片执行上述实施例中的一种业务系统扩缩容的方法。
其中,本实施例提供的装置、计算机可读存储介质、计算机程序产品或芯片均用于执行上文所提供的对应的方法,因此,其所能达到的有益效果可参考上文所提供的对应的方法中的有益效果,此处不再赘述。
通过以上实施方式的描述,所属领域的技术人员可以了解到,为描述的方便和简洁,仅以上述各功能模块的划分进行举例说明,实际应用中,可以根据需要而将上述功能分配由不同的功能模块完成,即将装置的内部结构划分成不同的功能模块,以完成以上描述的全部或者部分功能。
在本申请所提供的实施例中,应该理解到,所揭露的装置和方法,可以通过其它的方式实现。例如,以上所描述的装置实施例仅仅是示意性的,例如,模块或单元的划分,仅仅为一种逻辑功能划分,实际实现时可以有另外的划分方式,例如多个单元或组件可以结合或者可以集成到另一个装置,或一些特征可以忽略,或不执行。另一点,所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口,装置或单元的间接耦合或通信连接,可以是电性,机械或其它的形式。
以上内容,仅为本申请的具体实施方式,但本申请的保护范围并不局限于此,任何熟悉本技术领域的技术人员在本申请揭露的技术范围内,可轻易想到变化或替换,都应涵盖在本申请的保护范围之内。因此,本申请的保护范围应以权利要求的保护范围为准。

Claims (10)

1.一种业务系统扩缩容的方法,其特征在于,所述方法包括:
接收第一业务请求,解析所述第一业务请求的域名并确定第一业务;
获取所述第一业务关联的M个进程,所述M个进程对应M个服务节点和N个服务器,M和N均为大于或等于1的整数;
确定所述M个服务节点中每一个服务节点的运行指标和所述N个服务器中每一个服务器的资源指标,根据所述每一个服务节点的运行指标和所述每一个服务器的资源指标确定针对所述第一业务的扩缩容策略,所述运行指标包括响应时间、每秒查询率、吞吐量中的一种或多种,所述资源指标包括中央处理器CPU的利用率、内存利用率中的一种或多种;
根据所述扩缩容策略生成并发送所述第一业务的扩缩容指令,控制所述M个服务节点和/或所述N个服务器根据所述扩缩容指令进行扩缩容。
2.根据权利要求1所述的方法,其特征在于,所述根据所述每一个服务节点的运行指标和所述每一个服务器的资源指标确定针对所述第一业务的扩缩容策略,包括:
当所述M个服务节点的运行指标满足第一条件时,根据所述M个服务节点的运行指标和所述每一个服务器的资源指标,确定所述M个服务节点的扩容阈值;
根据所述M个服务节点的扩容阈值、所述M个服务节点的运行指标和所述每一个服务器的资源指标,确定所述M个服务节点的扩容策略;或,
当所述M个服务节点的运行指标满足第二条件时,根据所述M个服务节点的运行指标和所述每一个服务器的资源指标,确定所述M个服务节点的缩容阈值;
根据所述M个服务节点的缩容阈值、所述M个服务节点的运行指标和所述每一个服务器的资源指标,确定所述M个服务节点的缩容策略。
3.根据权利要求1所述的方法,其特征在于,所述根据所述每一个服务节点的运行指标和所述每一个服务器的资源指标确定所述第一业务的扩缩容策略,还包括:
根据所述每一个服务器的资源指标,获取所述N个服务器的资源指标的平均值;
当所述N个服务器的资源指标的平均值大于或等于第一阈值时,根据所述每一个服务器的资源指标和所述第一阈值,确定所述N个服务器的扩容阈值和所述N个服务器的扩容频率;
根据所述每一个服务器的资源指标、所述N个服务器的扩容阈值和所述N个服务器的扩容频率,确定所述N个服务器的扩容策略;或,
当所述N个服务器的资源指标的平均值小于所述第一阈值时,根据所述每一个服务器的资源指标和所述第一阈值,确定所述N个服务器的缩容阈值和所述N个服务器的缩容频率;
根据所述每一个服务器的资源指标、所述N个服务器的缩容阈值和所述N个服务器的缩容频率,确定所述N个服务器的缩容策略。
4.根据权利要求3所述的方法,其特征在于,所述M个服务节点的扩容策略为增加所述M个服务节点的数量,所述M个服务节点的缩容策略为减少所述M个服务节点的数量,所述N个服务器的扩容策略为增加所述N个服务器的数量,所述N个服务器的缩容策略为减少所述N个服务器的数量。
5.根据权利要求3所述的方法,其特征在于,所述根据所述N个服务器的资源指标、所述N个服务器的扩容阈值和所述N个服务器的扩容频率,确定所述N个服务器的扩容策略,包括:
根据所述每一个服务器的资源指标和所述N个服务器的资源指标的平均值,从所述N个服务器中确定出第一服务器,所述第一服务器的资源指标小于所述第一阈值;
确定所述第一服务器的数量,当所述第一服务器的数量小于或等于所述N个服务器的扩容频率的数值时,根据所述N个服务器的扩容频率和所述N个服务器的扩容阈值,确定所述N个服务器需要增加的服务器的总数和每次增加的服务器的数量;以及,
根据所述每一个服务器的资源指标、所述N个服务器的缩容阈值和所述N个服务器的缩容频率,确定所述N个服务器的缩容策略,包括:
根据所述每一个服务器的资源指标和所述N个服务器的资源指标的平均值,从所述N个服务器中确定出第二服务器,所述第二服务器的资源指标大于或等于所述第一阈值;
确定所述第二服务器的数量,当所述第二服务器的数量小于或等于所述N个服务器的缩容频率的数值时,根据所述N个服务器的缩容频率和所述N个服务器的缩容阈值,确定所述N个服务器中需要减小的服务器的总数和每次减少的服务器的数量。
6.根据权利要求5所述的方法,其特征在于,所述控制所述M个服务节点和/或所述N个服务器根据所述扩缩容指令进行扩缩容,包括:
根据所述每一个服务器的资源指标,获取所述N个服务器的资源指标的排序结果;
根据所述N个服务器的资源指标的排序结果,将资源指标最小的服务器确定为第三服务器;
根据所述M个服务节点的扩容阈值,将所述M个服务节点的数量增加至所述M个服务节点的扩容阈值,并控制所述第三服务器运行增加的服务节点。
7.根据权利要求5所述的方法,其特征在于,所述控制所述M个服务节点和/或所述N个服务器根据所述扩缩容指令进行扩缩容,还包括:
当所述第二服务器的数量小于或等于所述N个服务器的缩容频率的数值时,根据所述每一个服务器的资源指标,将所述N个服务器中资源指标小于第二阈值的服务器确定为待缩容服务器;
当所述待缩容服务器中运行所述第一业务的服务节点,获取所述N个服务器中除所述待缩容服务器之外的服务器的资源指标的排序结果;
根据所述N个服务器中除所述待缩容服务器之外的服务器的资源指标的排序结果,按顺序确定x个服务器,将所述待缩容服务器运行的所述第一业务的服务节点添加至所述x个服务器,根据所述N个服务器的缩容频率删除所述待缩容服务器;
当所述待缩容服务器中未运行所述第一业务对应的服务节点,直接根据所述N个服务器的缩容频率删除所述待缩容服务器。
8.一种业务扩缩容的装置,其特征在于,所述装置包括:
第一处理模块,用于接收第一业务请求,解析所述第一业务请求的域名并确定第一业务;
获取模块,用于获取所述第一业务关联的M个进程,所述M个进程对应M个服务节点和N个服务器,M和N均为大于或等于1的整数;
确定模块,用于确定所述M个服务节点中每一个服务节点的运行指标和所述N个服务器中每一个服务器的资源指标,根据所述每一个服务节点的运行指标和所述每一个服务器的资源指标确定针对所述第一业务的扩缩容策略,所述运行指标包括响应时间、每秒查询率、吞吐量、中的一种或多种,所述资源指标包括中央处理器CPU的利用率、内存利用率中的一种或多种;
第二处理模块,用于根据所述扩缩容策略生成并发送所述第一业务的扩缩容指令,控制所述M个服务节点和/或所述N个服务器根据所述扩缩容指令进行扩缩容。
9.一种电子设备,其特征在于,所述电子设备包括:
存储器,用于存储计算机程序;
处理器,用于从所述存储器中调用并运行所述计算机程序,使得所述电子设备执行如权利要求1至7中任意一项所述的方法。
10.一种计算机可读存储介质,其特征在于,所述计算机可读存储介质存储有计算机程序,当所述计算机程序被执行时,实现如权利要求1至7中任意一项所述的方法。
CN202210377725.7A 2022-04-11 2022-04-11 一种业务系统扩缩容的方法、装置、电子设备和存储介质 Active CN114745278B (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202210377725.7A CN114745278B (zh) 2022-04-11 2022-04-11 一种业务系统扩缩容的方法、装置、电子设备和存储介质

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202210377725.7A CN114745278B (zh) 2022-04-11 2022-04-11 一种业务系统扩缩容的方法、装置、电子设备和存储介质

Publications (2)

Publication Number Publication Date
CN114745278A true CN114745278A (zh) 2022-07-12
CN114745278B CN114745278B (zh) 2024-05-24

Family

ID=82282181

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202210377725.7A Active CN114745278B (zh) 2022-04-11 2022-04-11 一种业务系统扩缩容的方法、装置、电子设备和存储介质

Country Status (1)

Country Link
CN (1) CN114745278B (zh)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN115242648A (zh) * 2022-07-19 2022-10-25 北京百度网讯科技有限公司 扩缩容判别模型训练方法和算子扩缩容方法

Citations (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8024736B1 (en) * 2005-01-28 2011-09-20 Hewlett-Packard Development Company, L.P. System for controlling a distribution of unutilized computer resources
CN107733676A (zh) * 2016-08-12 2018-02-23 中国移动通信集团浙江有限公司 一种弹性调度资源的方法及系统
KR20180096310A (ko) * 2017-02-21 2018-08-29 에스케이텔레콤 주식회사 성능 제어 방법 및 이를 위한 장치
CN109240822A (zh) * 2018-08-07 2019-01-18 东软集团股份有限公司 应用程序弹性伸缩的方法、装置和存储介质以及电子设备
CN109766182A (zh) * 2018-12-18 2019-05-17 平安科技(深圳)有限公司 系统资源动态扩缩容方法、装置、计算机设备及存储介质
CN110175068A (zh) * 2019-04-16 2019-08-27 平安科技(深圳)有限公司 分布式系统中主机数量弹性伸缩方法、装置和计算机设备
CN110677459A (zh) * 2019-09-02 2020-01-10 金蝶软件(中国)有限公司 资源调整方法、装置、计算机设备和计算机存储介质
CN112506444A (zh) * 2020-12-28 2021-03-16 南方电网深圳数字电网研究院有限公司 基于Kubernetes集群的扩缩容控制方法和装置、电子设备
US20210158248A1 (en) * 2019-11-26 2021-05-27 Hitachi, Ltd. Computer system and resource management method
CN112925607A (zh) * 2021-02-22 2021-06-08 深圳前海微众银行股份有限公司 一种系统扩缩容方法及装置、电子设备

Patent Citations (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8024736B1 (en) * 2005-01-28 2011-09-20 Hewlett-Packard Development Company, L.P. System for controlling a distribution of unutilized computer resources
CN107733676A (zh) * 2016-08-12 2018-02-23 中国移动通信集团浙江有限公司 一种弹性调度资源的方法及系统
KR20180096310A (ko) * 2017-02-21 2018-08-29 에스케이텔레콤 주식회사 성능 제어 방법 및 이를 위한 장치
CN109240822A (zh) * 2018-08-07 2019-01-18 东软集团股份有限公司 应用程序弹性伸缩的方法、装置和存储介质以及电子设备
CN109766182A (zh) * 2018-12-18 2019-05-17 平安科技(深圳)有限公司 系统资源动态扩缩容方法、装置、计算机设备及存储介质
CN110175068A (zh) * 2019-04-16 2019-08-27 平安科技(深圳)有限公司 分布式系统中主机数量弹性伸缩方法、装置和计算机设备
CN110677459A (zh) * 2019-09-02 2020-01-10 金蝶软件(中国)有限公司 资源调整方法、装置、计算机设备和计算机存储介质
US20210158248A1 (en) * 2019-11-26 2021-05-27 Hitachi, Ltd. Computer system and resource management method
CN112506444A (zh) * 2020-12-28 2021-03-16 南方电网深圳数字电网研究院有限公司 基于Kubernetes集群的扩缩容控制方法和装置、电子设备
CN112925607A (zh) * 2021-02-22 2021-06-08 深圳前海微众银行股份有限公司 一种系统扩缩容方法及装置、电子设备

Non-Patent Citations (3)

* Cited by examiner, † Cited by third party
Title
D. YOUNG等: "Autonomous hidden node determination using dynamic expansion and contraction approach", IEEE *
XIAOFENG GONG等: "Variable Universe Adaptive Fuzzy Control on the Triple Inverted Pendulum and Choosing Contraction-Expansion Factor", IEEE, 12 January 2010 (2010-01-12) *
尚小东;张煜;郭成昊;: "基于作战任务优先级的容器云弹性伸缩系统", 指挥信息系统与技术, no. 03 *

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN115242648A (zh) * 2022-07-19 2022-10-25 北京百度网讯科技有限公司 扩缩容判别模型训练方法和算子扩缩容方法
CN115242648B (zh) * 2022-07-19 2024-05-28 北京百度网讯科技有限公司 扩缩容判别模型训练方法和算子扩缩容方法

Also Published As

Publication number Publication date
CN114745278B (zh) 2024-05-24

Similar Documents

Publication Publication Date Title
US7552171B2 (en) Incremental run-time session balancing in a multi-node system
JP6559670B2 (ja) ネットワーク機能仮想化情報コンセントレータのための方法、システム、およびコンピュータ読取可能媒体
CN105940377B (zh) 用于基于云的虚拟化编排器的方法、系统和计算机可读介质
US7437460B2 (en) Service placement for enforcing performance and availability levels in a multi-node system
CN109274782B (zh) 一种采集网站数据的方法及装置
JP6881575B2 (ja) 資源割当システム、管理装置、方法およびプログラム
US20060200469A1 (en) Global session identifiers in a multi-node system
CN104572302B (zh) 一种实现资源分配的方法及装置
US11438271B2 (en) Method, electronic device and computer program product of load balancing
CN112711479A (zh) 服务器集群的负载均衡系统、方法、装置和存储介质
CN112698952A (zh) 计算资源统一管理方法、装置、计算机设备及存储介质
CN112416594A (zh) 一种微服务分配方法、电子设备和计算机存储介质
CN106375102A (zh) 一种服务注册方法、使用方法及相关装置
CN114745278B (zh) 一种业务系统扩缩容的方法、装置、电子设备和存储介质
CN114490078A (zh) 一种微服务的动态缩扩容方法、装置及设备
CN112073329B (zh) 分布式限流方法、装置、电子设备和存储介质
CN112751926A (zh) 一种集群中工作节点的管理方法、系统及相关装置
CN115168017B (zh) 一种任务调度云平台及其任务调度方法
CN108366102A (zh) 一种基于Consul的服务发现方法、装置及电子设备
CN109526032B (zh) 修改网络切片实例的方法及装置
CN113377866B (zh) 一种虚拟化数据库代理服务的负载均衡方法及装置
CN112148496B (zh) 超融合虚拟机的计算存储资源的能效管理方法、装置及电子设备
US12058001B2 (en) Control device, control method, control program and control system
CN108600354B (zh) 系统响应时间波动抑制方法和系统
CN114143263A (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
CB02 Change of applicant information
CB02 Change of applicant information

Address after: 100000 Room 302, South third floor, 113 Kaikai Road, Huairou District, Beijing

Applicant after: Zhonghe Nongxin Agricultural Group Co.,Ltd.

Address before: 100000 Room 302, South third floor, 113 Kaikai Road, Huairou District, Beijing

Applicant before: Zhonghe Nongxin Holdings Co.,Ltd.

Address after: 100000 Room 302, South third floor, 113 Kaikai Road, Huairou District, Beijing

Applicant after: Zhonghe Nongxin Holdings Co.,Ltd.

Address before: 100000 Room 302, South third floor, 113 Kaikai Road, Huairou District, Beijing

Applicant before: CD FINANCE PROJECT MANAGEMENT Co.,Ltd.

GR01 Patent grant
GR01 Patent grant