CN110489225A - 一种基于消息队列的服务扩容方法、装置及设备 - Google Patents
一种基于消息队列的服务扩容方法、装置及设备 Download PDFInfo
- Publication number
- CN110489225A CN110489225A CN201810462140.9A CN201810462140A CN110489225A CN 110489225 A CN110489225 A CN 110489225A CN 201810462140 A CN201810462140 A CN 201810462140A CN 110489225 A CN110489225 A CN 110489225A
- Authority
- CN
- China
- Prior art keywords
- queue
- micro services
- dilatation
- message
- message queue
- 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
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
-
- 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/54—Interprogram communication
- G06F9/546—Message passing systems or structures, e.g. queues
Landscapes
- Engineering & Computer Science (AREA)
- Software Systems (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Telephonic Communication Services (AREA)
Abstract
本发明实施例提供一种基于消息队列的服务扩容方法、装置及设备。所述方法包括:基于微服务架构的消息队列,根据影响因子获取扩容调整策略,所述影响因子至少包各微服务的CPU占用率和所述消息队列的每分钟出队数;根据所述扩容调整策略对微服务和/或所述消息队列进行动态扩容。本发明实施例基于微服务架构的消息队列,将各微服务的CPU占用率和消息队列的每分钟出队数作为影响因子获取扩容调整策略,根据扩容调整策略对微服务和/或消息队列进行动态扩容,针对单点服务故障、海量消息等异常场景都能有效提供自动化的应急手段,实现系统快速恢复和动态分配系统资源。
Description
技术领域
本发明实施例涉及移动通信的业务支撑领域,尤其涉及一种基于消息队列的服务扩容方法、装置及设备。
背景技术
随着信息系统功能越来越强大,随之而来的是功能模块越来越复杂,随着业务量增加单实例已无法满足要求,逐步形成分布式系统,同时模块之间调用形成网状结构。近年来,随着云计算、SOA、微服务等技术不断成熟,大型信息系统开始进行模块解耦,消息队列得到广泛使用。
消息队列(MQ)是一种应用程序对应用程序的通信方法。应用程序通过写和检索出入列队的针对应用程序的消息来通信,而无需专用连接来链接它们。消息传递指的是程序之间通过在消息中发送数据进行通信,而不是通过直接调用彼此来通信,直接调用通常是用于诸如远程过程调用的技术。排队指的是应用程序通过队列来通信。队列的使用除去了接收和发送应用程序同时执行的要求。
引入消息队列的好处在于实现了系统解耦,避免两个系统直接交互,甚至只要消息格式不变,即使接收者的接口、位置、或者配置改变,也不会给发送者带来任何改变。而且消息发送者无需知道消息接收者是谁,使得系统设计更清晰。同时主流的消息队列服务都具备很强的扩展性、可靠性,会随着访问量的增减而自动增减逻辑处理服务器。
但针对有序消息的场景,消息队列多数不是天然支持,按照CAP理论,要同时满足一致性、可用性、可靠性几乎不可能,互联网多数场景通过牺牲一致性换取高可用,系统往往满足最终一致性。如果非得保证消息顺序做到强一致性,可以通过部署调整实现,主要有以下两种部署方式,即图1所示的单一生产者-队列-消费者模式和图2所示的多生产者-队列-消费者模式。
对于单一的生产者-队列-消费者模式,即生产者、队列、消费者都是一对一的关系,队列使用先进先出(FIFO)模式,这样就能保证消息按照次序执行,但这种方式无法支撑大业务量的场景。
对于多生产者-队列-消费者模式,仍保持队列的先进先出模式,生产者采用一对多模式,先按照高可用组(X)取模再按照队列数(Y)取模,消费者共配置Y个,每个都只连接指定的队列,以此保证消息的时序处理。这种方式部署困难,后续的调整也比较复杂,或者为满足前台海量请求预留大量冗余资源。
上述两种部署方式中,图2所示的多生产者-队列-消费者模式优于图1所示的单一生产者-队列-消费者模式,然而,多产者-队列-消费者模式仍然存在一些问题,比如单点故障恢复困难,不具备自动分配计算资源的能力等。
发明内容
针对现有技术存在的问题,本发明实施例提供一种基于消息队列的服务扩容方法、装置及设备,有效解决了单点故障恢复困难,实现了自动分配计算资源。
第一方面,本发明实施例提供一种基于消息队列的服务扩容方法,包括:
基于微服务架构的消息队列,根据影响因子获取扩容调整策略,所述影响因子至少包各微服务的CPU占用率和所述消息队列的每分钟出队数;
根据所述扩容调整策略对微服务和/或所述消息队列进行动态扩容。
第二方面,本发明实施例提供一种基于消息队列的服务扩容装置,包括:
扩容策略模块,用于基于微服务架构的消息队列,根据影响因子获取扩容调整策略,所述影响因子至少包各微服务的CPU占用率和所述消息队列的每分钟出队数;
动态扩容模块,用于根据所述扩容调整策略对微服务和/或所述消息队列进行动态扩容。
第三方面,本发明实施例提供了一种基于消息队列的服务扩容设备,包括:
至少一个处理器;以及
与所述处理器通信连接的至少一个存储器,其中:
所述存储器存储有可被所述处理器执行的程序指令,所述处理器调用所述程序指令能够执行本发明实施例第一方面所述基于消息队列的服务扩容方法及其任一可选实施例所述的方法。
第四方面,提供一种非暂态计算机可读存储介质,所述非暂态计算机可读存储介质存储计算机指令,所述计算机指令执行本发明实施例第一方面所述基于消息队列的服务扩容方法及其任一可选实施例的方法。
本发明实施例提供的一种基于消息队列的服务扩容方法,基于微服务架构的消息队列,将各微服务的CPU占用率和消息队列的每分钟出队数作为影响因子获取扩容调整策略,根据扩容调整策略对微服务和/或消息队列进行动态扩容,针对单点服务故障、海量消息等异常场景都能有效提供自动化的应急手段,实现系统快速恢复和动态分配计算资源。
附图说明
为了更清楚地说明本发明实施例或现有技术中的技术方案,下面将对实施例或现有技术描述中所需要使用的附图作一简单地介绍,显而易见地,下面描述中的附图是本发明的一些实施例,对于本领域普通技术人员来讲,在不付出创造性劳动的前提下,还可以根据这些附图获得其他的附图。
图1为本发明实施例单一生产者-队列-消费者模式示意图;
图2为本发明实施例多生产者-队列-消费者模式示意图;
图3为本发明实施例基于消息队列的服务扩容方法示意图;
图4为本发明实施例基于消息队列的服务扩容系统架构示意图;
图5为本发明实施例基于消息队列的服务扩容装置示意图;
图6为本发明实施例基于消息队列的服务扩容设备的框架示意图。
具体实施方式
为使本发明实施例的目的、技术方案和优点更加清楚,下面将结合本发明实施例中的附图,对本发明实施例中的技术方案进行清楚地描述,显然,所描述的实施例是本发明一部分实施例,而不是全部的实施例。基于本发明中的实施例,本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例,都属于本发明保护的范围。
基于现有技术中的两种消息队列的部署方式,即图1所示的单一生产者-队列-消费者模式和图2所示的多生产者-队列-消费者模式,存在各自不足。图2所示的多生产者-队列-消费者模式可满足复杂的应用需求,然而却存在如下问题:
1)单点故障恢复困难,由于消费者必须指定队列消费,无法发挥原有分布式系统扩展能力,消费者单点故障不能通过队列重新分配恢复,必须拉起指定的消费者,否则会造成时序错乱,失去消息一致性保障。
2)不具备自动分配计算资源的能力,也是由于这种必须指定的配置方式,导致部署调整复杂,扩缩容一般需通过手工方式解决,不具备自动扩缩容能力,不能有效的面对前端海量请求的场景,或者为了满足最大需求预留大量的冗余处理能力,导致平时系统空闲时浪费资源。
引入微服务架构后,单点的故障时有发生,同时在大型活动营销活动期间,前端经常会出现海量请求,如果不能很好的进行扩缩容,要么会造成大量消息长时间得不到处理,要么需预留大量的系统资源,无法有效的利用系统资源。为解决上述问题本发明实施例提供一种基于消息队列的服务扩容方法、装置及设备。
图3为本发明实施例基于消息队列的服务扩容方法示意图,如图3所示的基于消息队列的服务扩容方法,其执行主体为执行该方法的计算机设备,包括:
101,基于微服务架构的消息队列,根据影响因子获取扩容调整策略,所述影响因子至少包各微服务的CPU占用率和所述消息队列的每分钟出队数;
微服务是一种在云中部署应用和服务的新技术,其基本思想在于考虑围绕着业务领域组件来创建应用,每个应用称为一个微服务,这样每个应用就可独立地进行开发、管理和加速。微服务架构是指部署和管理各分散的微服务的系统架构,通过微服务架构进行应用系统开发有利于应用系统的横向扩展和纵向扩展。
本发明实施例所述微服务架构的消息队列请参考图2,其中微服务包括图2中的生产者和消费者,每个生产者或消费者就是一个微服务,所有微服务以消息队列为中心,生产者为消息队列提供消息,消费者消费消息队列中的消息。
本发明实施例的扩容调整策略与各个微服务有关,也与消息队列有关。优选的,需要根据各微服务的CPU占用率和所述消息队列的每分钟出队数来确定扩容调整策略。具体的,对于某个微服务,当它的CPU占用率越高,则需要扩容的可能性越大;消息队列的每分钟出队数越低,则说明消息处理能力可能不足,需要扩容的可能性越大。
102,根据所述扩容调整策略对微服务和/或所述消息队列进行动态扩容。
本发明实施例的扩容调整策略,可以是对微服务进行扩容,也可以是对消息队列进行扩容,也可以同时对微服务和消息队列进行扩容。
本发明实施例的扩容是动态扩容,在根据扩容调整策略进行扩容时并不影响当前消息处理的正常流程。
本发明实施例提供的一种基于消息队列的服务扩容方法,基于微服务架构的消息队列,将各微服务的CPU占用率和消息队列的每分钟出队数作为影响因子获取扩容调整策略,根据扩容调整策略对微服务和/或消息队列进行动态扩容,针对单点服务故障、海量消息等异常场景都能有效提供自动化的应急手段,实现系统快速恢复和动态分配计算资源。
基于上述实施例,所述基于微服务架构的消息队列,根据影响因子获取扩容调整策略,之前还包括:
获取各微服务的性能和/或日志,以及获取所述消息队列的性能和/或积压消息数;其中微服务的性能包括CPU占用率和/或每分钟内存消耗;微服务的日志包括启动失败日志和/或数据异常日志;所述消息队列的性能包括每分钟入队数和/或每分钟出队数;
相应的,所述影响因子还包括各微服务的每分钟内存消耗、启动失败日志和/或数据异常日志,还包括所述消息队列每分钟入队数和/或积压消息数。
具体的,所述每分钟入队数,是指每分钟进入消息队列的消息数;所述每分钟出队数,是指消息队列中每分钟出队的消息数。
本发明实施例在基于微服务架构的消息队列,根据影响因子获取扩容调整策略之前,需要采集日志、性能、积压消息数等数据,其中可以采集微服务的性能和日志数据,例如CPU占用率、每分钟内存消耗、启动失败日志和数据异常日志中的一种或多种;可以采集消息队列的每分钟入队数、每分钟出队数和积压消息数中的一种或多种。
本发明实施例中数据采集的频率为分钟,每分钟采集一次上述数据,所有的日志、性能、积压消息数等数据都是在一个采集周期即一分钟得到数据。当然,也可以采用不同的数据采集的频率,本发明实施例对此不作限定。
需要说明的是,本发明实施例可以通过监控器采集日志、性能、积压消息数等数据。所述监控器开可以在执行主体计算机设备中实现,可以在其他的实体设备中实现,本发明实施例对此不作具体限定。
相应的,可以将微服务和消息队列的采集数据中的一种或多种作为影响因子进行分析,获取扩容调整策略。具体的,可以以微服务的采集数据中的一种或多种作为影响因子进行分析,也可以以消息队列的采集数据中的一种或多种作为影响因子进行分析,也可以同时以微服务和消息队列的采集数据中的多种作为影响因子进行分析。当选取不同的数据作为影响因子时,得到的扩容调整策略可能相同,也可能不相同。
本发明实施例通过将微服务和消息队列的采集数据中的一种或多种作为影响因子进行分析,获取扩容调整策略,可以根据不同的需求实现灵活的分析,得到对应的扩容调整策略。
基于上述实施例,步骤101,所述基于微服务架构的消息队列,根据影响因子获取扩容调整策略,具体包括:
101.1,根据影响因子中的一种或多种,通过扩容场景测试,获取1个或多个候选扩容调整策略;
通过上述分析可知,影响因子包括CPU占用率、每分钟内存消耗、启动失败日志、数据异常日志、每分钟出队数、每分钟入队数以及积压消息数等,本发明实施例可以根据影响因子中的一种或多种通过扩容场景测试而获取候选扩容调整策略。其中扩容场景是以实际系统为基础,根据经验进行调整后的系统,可以满足扩容测试的要求。若多次选择不同的影响因子进行扩容场景测试,则可以得到多个候选扩容调整策略。
例如,采用微服务的CPU占用率和消息队列的每分钟出队数作为影响因子,可用通过计算公式y=f(x)+a,使得入队速率足够大、内存保持足够大,其中x为CPU占用率,y为每分钟出队数,a为常量。例如,根据公式y=f(x)+a,若100=0.1x+a,220=0.2x+a,则a=-20,可以认为,CPU占有率为10%时可处理100条数据,CPU占有率为20%时可处理220条数据,若CPU的处理能力低于这个水平则可能需要扩容。但在具体实施时,还可以综合考虑CPU占用,若CPU占有率低于一定百分比,即使性能稍有下降,仍然在能接受的范围,则可以不进行扩容,本发明实施例对此不作具体限定。
101.2,分别将每个候选扩容调整策略的预期容量指标与所述微服务架构的消息队列的当前容量指标进行对比,根据对比结果选取最优的候选扩容调整策略作为扩容调整策略。
每一个候选扩容调整策略,对应一个预期容量指标。对于步骤101.1得到的1个或多个候选扩容调整策略,本发明实施例进一步根据每个候选扩容调整策略的预期容量指标与所述微服务架构的消息队列的当前容量指标的对比结果,从中选取一个最优的候选扩容调整策略作为扩容调整策略。
需要说明的是,本发明实施例可以通过分析器实现扩容调整策略的获取和分析,即上述步骤101.1和101.2。所述分析器开可以在执行主体计算机设备中实现,可以在其他的实体设备中实现,本发明实施例对此不作具体限定。
基于上述实施例,所述扩容调整策略包括:启动新的微服务以替换原不可用微服务,新增队列和/或新增微服务;
本发明实施例所述扩容调整策略包括两类,一类是替换,即启动新的微服务以替换原不可用微服务,一类是新增即新增队列和新增微服务。所述扩容调整策略可以是任意一类,可以同时包括两类;新增可以新增微服务,也可以新增队列,也可以同时新增微服务和队列。
相应的,步骤102,所述根据所述扩容调整策略对微服务和/或所述消息队列进行动态扩容,具体包括:
若扩容调整策略包括启动新的微服务以替换原不可用微服务,则确认原不可用微服务当前不可用后,根据扩容调整策略启动新的微服务并发布微服务;
若扩容调整策略包括新增微服务,则启动新微服务,并注册所述新微服务,以使所述新微服务根据所述消息队列的消息时序提供服务;
若扩容调整策略包括新增队列,则新增队列并进行均衡扩容,以使得消息在新增的队列和原有队列中均匀分布。
与上述扩容调整策略相对应的,步骤102所述根据所述扩容调整策略对微服务和/或所述消息队列进行动态扩容,也可以是启动新的微服务以替换原不可用微服务,新增队列和新增微服务中的一种或多种。
对于每一种扩容调整策略,都有各自对应的调整方式。
例如,若扩容调整策略包括启动新的微服务以替换原不可用微服务,在实施之前需要再次检测原不可用微服务的当前状态,如果当前状态较原状态发生改变,已经是可用的,则不做调整,避免重复消费等异常;若当前状态仍然是不可用,则根据扩容调整策略启动新的微服务并发布微服务。
若现有微服务的CPU占有率过高或内存消耗过大,扩容调整策略包括新增1个或多个微服务,则启动1个或多个新微服务,新微服务需要注册后才能使用,对1个或多个新微服务进行注册,以使所述新微服务根据所述消息队列的消息时序提供服务;
若消息队列的出队数过低或积压消息数过多,扩容调整策略包括新增1个或多个队列,则新增1个或多个队列并进行均衡扩容,均衡扩容是指使得消息在新增的队列和原有队列中均匀分布。例如,原有3个队列,新增1个队列,则消息将在4个队列中均衡分布。
需要说明的是,本发明实施例可以通过控制器实现微服务替换、微服务新增和消息队列新增的服务注册、服务发布和状态监控同步等。所述控制器开可以在执行主体计算机设备中实现,可以在其他的实体设备中实现,本发明实施例对此不作具体限定。
基于上述实施例,所述进行均衡扩容,具体包括:
若检测到新消息,则基于新增的队列和原有队列,根据所述新消息对应的用户ID取模,对取模后的结果进行平衡HASH计算及取模,获得所述新消息对应的目标队列;
将所述新消息存入所述目标队列。
具体的,为确保动态扩容前后的消息队列能够保证消息落到唯一指定的队列中,同时满足均衡分布的要求,本发明实施例通过用户ID先取模再通过一种平衡HASH计算再次取模得到。
以2个高可用组3个队列为例,UID(用户ID)的指向队列为HASH(UID mod 2)mod 3。假设由3个队列扩展到4个队列,则指向HASH(UID mod 2)mod 4。可知,根据消息对应的用户ID进行上述计算,可以可使消息落到唯一指定的队列中,且在所有队列中均衡分布。
需要说明的是,如果简单的启动一个新的队列或者为服务必然会打破原有的消息时序,特别是在消息队列已积压需要扩容的场景下,时序错乱的可能性极大。为解决该问题,基于上述实施例,步骤102,所述根据所述扩容调整策略对微服务和/或所述消息队列进行动态扩容,还包括:
虚拟队列设置:若扩容调整策略包括新增队列,则根据新增的队列和原有队列的总数量设置相同数量的虚拟队列,通过所述虚拟队列存储新消息;
动态启停控制:若检测到原有队列中的积压消息处理完毕,则利用所述虚拟队列替换原有队列,以实现消息服务。具体的,检测原有队列中的积压消息是否处理完毕;若处理完毕,则通过虚拟队列为原有队列和新增的队列对应的微服务提供消息服务,同时回收原有队列,以回收系统资源。
本发明实施例通过虚拟队列设置和动态启停控制来确保消息的时序,使不发生错乱,使得扩容后消息消费顺序保持一致性。
具体的,对于虚拟队列设置,以3个队列扩容到4个队列为例,在有序消息的场景下,扩展出的新的队列由于无消息积压,原队列存在消息积压,无积压的消费更快,仍会打破消息顺序,因此引入了虚拟队列设置的概念,也即:预先设置多组虚拟队列模板,建设扩容前的队列为Qone1、Qone2、Qone3,扩容后使用另外一组模板生成队列,新的队列为Qtwo1、Qtwo2、Qtwo3、Qtwo4。
本发明实施例在扩容发生时首先生成新的队列,实时刷新生产者缓存更新发送机制,新消息全部进入新的队列组中。由于虚拟队列的数目从原有队列的3个变为4个,采用前述实施例的方法使新消息在4个队列中入队,即根据新消息对应的用户ID取模,对取模后的结果进行平衡HASH计算及取模,这样确保动态扩容前后的消息队列能够保证消息落到唯一指定的队列中,同时满足均衡分布的要求。虽然新的队列中的数据也实现了均衡一致分布,但此时仍不能拉起对应的消费者。
具体的,对于动态启停控制,本发明实施例动态监控Qone1、Qone2、Qone3的队列积压情况,待积压的消息全部消费完毕,全部拉起新的Qtwo1、Qtwo2、Qtwo3、Qtwo4对应的消费者,回收Qone1、Qone2、Qone3对应的消费者以便回收系统资源。
至此就完成了消息队列应急扩容过程,随着微服务化以及容器等推广使用,上述一次扩容可以在几秒钟内完成,完全能够满足生产要求,同时针对单点服务故障、海量消息等异常场景都能有效提供自动化的应急手段,实现系统快速恢复,避免有序消息条件下消息消费问题。
图4为本发明实施例基于消息队列的服务扩容系统架构示意图,如前所述,本发明实施例可以通过监控器采集日志、性能、积压消息数等数据,可以通过分析器实现扩容调整策略的获取和分析,可以通过控制器实现微服务替换、微服务新增和消息队列新增的服务注册、服务发布和状态监控同步等。
请参考图4,在图4的架构下,本发明实施例可以通过监控器进行性能、积压、日志等信息采集;微服务(即生产者、消费者)需注册到控制器,由控制器进行服务发布;根据分析器的策略配置进行策略分析并输出调整后的策略,通知控制器进行服务调整和发布,其中策略分析模块还包括上述消息时序分析控制,服务发布时可以增加服务状态检测、服务暂停等操作,从而实现了有序消息服务应急扩容。
图5为本发明实施例基于消息队列的服务扩容装置示意图,如图5所示,本发明实施例还提供一种基于消息队列的服务扩容装置,包括:
扩容策略模块501,用于基于微服务架构的消息队列,根据影响因子获取扩容调整策略,所述影响因子至少包各微服务的CPU占用率和所述消息队列的每分钟出队数;
动态扩容模块502,用于根据所述扩容调整策略对微服务和/或所述消息队列进行动态扩容。
本发明实施例的装置,可用于执行图3所示的基于消息队列的服务扩容方法实施例的技术方案,其实现原理和技术效果类似,此处不再赘述。
作为一个可选的实施例,所述基于微服务架构的消息队列,根据影响因子获取扩容调整策略,之前还包括:
获取各微服务的性能和/或日志,以及获取所述消息队列的性能和/或积压消息数;其中微服务的性能包括CPU占用率和/或每分钟内存消耗;微服务的日志包括启动失败日志和/或数据异常日志;所述消息队列的性能包括每分钟入队数和/或每分钟出队数;
相应的,所述影响因子还包括各微服务的每分钟内存消耗、启动失败日志和/或数据异常日志,还包括所述消息队列每分钟入队数和/或积压消息数。
作为一个可选的实施例,所述扩容策略模块501,具体包括:
根据影响因子中的一种或多种,通过扩容场景测试,获取1个或多个候选扩容调整策略;
分别将每个候选扩容调整策略的预期容量指标与所述微服务架构的消息队列的当前容量指标进行对比,根据对比结果选取最优的候选扩容调整策略作为扩容调整策略。
作为一个可选的实施例,所述扩容调整策略包括:启动新的微服务以替换原不可用微服务,新增队列和/或新增微服务;
相应的,所述动态扩容模块502,具体包括:
若扩容调整策略包括启动新的微服务以替换原不可用微服务,则确认原不可用微服务当前不可用后,根据扩容调整策略启动新的微服务并发布微服务;
若扩容调整策略包括新增微服务,则启动新微服务,并注册所述新微服务,以使所述新微服务根据所述消息队列的消息时序提供服务;
若扩容调整策略包括新增队列,则新增队列并进行均衡扩容,以使得消息在新增的队列和原有队列中均匀分布。
作为一个可选的实施例,所述进行均衡扩容,具体包括:
若检测到新消息,则基于新增的队列和原有队列,根据所述新消息对应的用户ID取模,对取模后的结果进行平衡HASH计算及取模,获得所述新消息对应的目标队列;
将所述新消息存入所述目标队列。
作为一个可选的实施例,所述动态扩容模块502,还包括:
若扩容调整策略包括新增队列,则根据新增的队列和原有队列的总数量设置相同数量的虚拟队列,通过所述虚拟队列存储新消息;
若检测到原有队列中的积压消息处理完毕,则利用所述虚拟队列替换原有队列,以实现消息服务。
图6为本发明实施例基于消息队列的服务扩容设备的框架示意图。请参考图6,本发明实施例提供一种基于消息队列的服务扩容设备,包括:处理器(processor)610、通信接口(Communications Interface)620、存储器(memory)630和总线640,其中,处理器610,通信接口620,存储器630通过总线640完成相互间的通信。处理器610可以调用存储器630中的逻辑指令,以执行如下方法,包括:基于微服务架构的消息队列,根据影响因子获取扩容调整策略,所述影响因子至少包各微服务的CPU占用率和所述消息队列的每分钟出队数;根据所述扩容调整策略对微服务和/或所述消息队列进行动态扩容。
本发明实施例公开一种计算机程序产品,所述计算机程序产品包括存储在非暂态计算机可读存储介质上的计算机程序,所述计算机程序包括程序指令,当所述程序指令被计算机执行时,计算机能够执行上述各方法实施例所提供的方法,例如包括:基于微服务架构的消息队列,根据影响因子获取扩容调整策略,所述影响因子至少包各微服务的CPU占用率和所述消息队列的每分钟出队数;根据所述扩容调整策略对微服务和/或所述消息队列进行动态扩容。
本发明实施例提供一种非暂态计算机可读存储介质,所述非暂态计算机可读存储介质存储计算机指令,所述计算机指令使所述计算机执行上述各方法实施例所提供的方法,例如包括:基于微服务架构的消息队列,根据影响因子获取扩容调整策略,所述影响因子至少包各微服务的CPU占用率和所述消息队列的每分钟出队数;根据所述扩容调整策略对微服务和/或所述消息队列进行动态扩容。
本领域普通技术人员可以理解:实现上述设备实施例或方法实施例仅仅是示意性的,其中所述处理器和所述存储器可以是物理上分离的部件也可以不是物理上分离的,即可以位于一个地方,或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。本领域普通技术人员在不付出创造性的劳动的情况下,即可以理解并实施。
通过以上的实施方式的描述,本领域的技术人员可以清楚地了解到各实施方式可借助软件加必需的通用硬件平台的方式来实现,当然也可以通过硬件。基于这样的理解,上述技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来,该计算机软件产品可以存储在计算机可读存储介质中,如U盘、移动硬盘、ROM/RAM、磁碟、光盘等,包括若干指令用以使得一台计算机设备(可以是个人计算机,服务器,或者网络设备等)执行各个实施例或者实施例的某些部分所述的方法。
最后应说明的是:以上实施例仅用以说明本发明的技术方案,而非对其限制;尽管参照前述实施例对本发明进行了详细的说明,本领域的普通技术人员应当理解:其依然可以对前述各实施例所记载的技术方案进行修改,或者对其中部分技术特征进行等同替换;而这些修改或者替换,并不使相应技术方案的本质脱离本发明各实施例技术方案的精神和范围。
Claims (10)
1.一种基于消息队列的服务扩容方法,其特征在于,包括:
基于微服务架构的消息队列,根据影响因子获取扩容调整策略,所述影响因子至少包各微服务的CPU占用率和所述消息队列的每分钟出队数;
根据所述扩容调整策略对微服务和/或所述消息队列进行动态扩容。
2.根据权利要求1所述的方法,其特征在于,所述基于微服务架构的消息队列,根据影响因子获取扩容调整策略,之前还包括:
获取各微服务的性能和/或日志,以及获取所述消息队列的性能和/或积压消息数;其中微服务的性能包括CPU占用率和/或每分钟内存消耗;微服务的日志包括启动失败日志和/或数据异常日志;所述消息队列的性能包括每分钟入队数和/或每分钟出队数;
相应的,所述影响因子还包括各微服务的每分钟内存消耗、启动失败日志和/或数据异常日志,还包括所述消息队列每分钟入队数和/或积压消息数。
3.根据权利要求2所述的方法,其特征在于,所述基于微服务架构的消息队列,根据影响因子获取扩容调整策略,具体包括:
根据影响因子中的一种或多种,通过扩容场景测试,获取1个或多个候选扩容调整策略;
分别将每个候选扩容调整策略的预期容量指标与所述微服务架构的消息队列的当前容量指标进行对比,根据对比结果选取最优的候选扩容调整策略作为扩容调整策略。
4.根据权利要求1所述的方法,其特征在于,所述扩容调整策略包括:启动新的微服务以替换原不可用微服务,新增队列和/或新增微服务;
相应的,所述根据所述扩容调整策略对微服务和/或所述消息队列进行动态扩容,具体包括:
若扩容调整策略包括启动新的微服务以替换原不可用微服务,则确认原不可用微服务当前不可用后,根据扩容调整策略启动新的微服务并发布微服务;
若扩容调整策略包括新增微服务,则启动新微服务,并注册所述新微服务,以使所述新微服务根据所述消息队列的消息时序提供服务;
若扩容调整策略包括新增队列,则新增队列并进行均衡扩容,以使得消息在新增的队列和原有队列中均匀分布。
5.根据权利要求4所述的方法,其特征在于,所述进行均衡扩容,具体包括:
若检测到新消息,则基于新增的队列和原有队列,根据所述新消息对应的用户ID取模,对取模后的结果进行平衡HASH计算及取模,获得所述新消息对应的目标队列;
将所述新消息存入所述目标队列。
6.根据权利要求4或5所述的方法,其特征在于,所述根据所述扩容调整策略对微服务和/或所述消息队列进行动态扩容,还包括:
若扩容调整策略包括新增队列,则根据新增的队列和原有队列的总数量设置相同数量的虚拟队列,通过所述虚拟队列存储新消息;
若检测到原有队列中的积压消息处理完毕,则利用所述虚拟队列替换原有队列,以实现消息服务。
7.根据权利要求1所述的方法,其特征在于,所述若检测到原有队列中的积压消息处理完毕,则利用所述虚拟队列替换原有队列,以实现消息服务,具体包括:
检测原有队列中的积压消息是否处理完毕;
若处理完毕,则通过虚拟队列为原有队列和新增的队列对应的微服务提供消息服务,同时回收原有队列,以回收系统资源。
8.一种基于消息队列的服务扩容装置,其特征在于,包括:
扩容策略模块,用于基于微服务架构的消息队列,根据影响因子获取扩容调整策略,所述影响因子至少包各微服务的CPU占用率和所述消息队列的每分钟出队数;
动态扩容模块,用于根据所述扩容调整策略对微服务和/或所述消息队列进行动态扩容。
9.一种基于消息队列的服务扩容设备,其特征在于,包括:
至少一个处理器;以及
与所述处理器通信连接的至少一个存储器,其中:
所述存储器存储有可被所述处理器执行的程序指令,所述处理器调用所述程序指令能够执行如权利要求1至7任一所述的方法。
10.一种非暂态计算机可读存储介质,其特征在于,所述非暂态计算机可读存储介质存储计算机指令,所述计算机指令使所述计算机执行如权利要求1至7任一所述的方法。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201810462140.9A CN110489225A (zh) | 2018-05-15 | 2018-05-15 | 一种基于消息队列的服务扩容方法、装置及设备 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201810462140.9A CN110489225A (zh) | 2018-05-15 | 2018-05-15 | 一种基于消息队列的服务扩容方法、装置及设备 |
Publications (1)
Publication Number | Publication Date |
---|---|
CN110489225A true CN110489225A (zh) | 2019-11-22 |
Family
ID=68545265
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN201810462140.9A Pending CN110489225A (zh) | 2018-05-15 | 2018-05-15 | 一种基于消息队列的服务扩容方法、装置及设备 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN110489225A (zh) |
Cited By (7)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN111245900A (zh) * | 2019-12-31 | 2020-06-05 | 北京健康之家科技有限公司 | 一种分布式消息发送的处理系统及其处理方法 |
CN111309476A (zh) * | 2020-01-22 | 2020-06-19 | 福建天泉教育科技有限公司 | 推送系统自动调整资源的方法、存储介质 |
CN113065785A (zh) * | 2021-04-13 | 2021-07-02 | 国网江苏省电力有限公司信息通信分公司 | 一种电力物联管理平台动态资源扩展方法 |
CN113138860A (zh) * | 2020-01-17 | 2021-07-20 | 中国移动通信集团浙江有限公司 | 消息队列的管理方法及装置 |
CN113609071A (zh) * | 2021-07-28 | 2021-11-05 | 北京金山云网络技术有限公司 | 一种用于消息队列的自动扩容方法及装置 |
CN113806102A (zh) * | 2020-06-15 | 2021-12-17 | 中国移动通信集团浙江有限公司 | 消息队列处理方法、装置及计算设备 |
CN114666201A (zh) * | 2022-03-02 | 2022-06-24 | 国动物联网有限公司 | 一种高可用的分布式微服务架构 |
Citations (9)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN105786909A (zh) * | 2014-12-25 | 2016-07-20 | 北京东方通科技股份有限公司 | 一种自适应消息队列积压负载的应用触发方法和系统 |
CN106227605A (zh) * | 2016-07-26 | 2016-12-14 | 北京北森云计算股份有限公司 | 一种多语言云编译的动态微服务扩容方法及装置 |
CN106453564A (zh) * | 2016-10-18 | 2017-02-22 | 北京京东尚科信息技术有限公司 | 弹性云分布式海量请求处理的方法、装置及系统 |
CN106487594A (zh) * | 2016-10-31 | 2017-03-08 | 中国人民解放军91655部队 | 基于微服务组件的网络流量采集和分析系统 |
US20170155729A1 (en) * | 2013-07-11 | 2017-06-01 | Apollo Education Group, Inc. | Message Consumer Orchestration Framework |
CN106888129A (zh) * | 2017-04-20 | 2017-06-23 | 国家电网公司 | 一种可弹性伸缩的分布式服务管理系统及其方法 |
US9781122B1 (en) * | 2016-05-11 | 2017-10-03 | Oracle International Corporation | Multi-tenant identity and data security management cloud service |
CN107920136A (zh) * | 2017-12-29 | 2018-04-17 | 广东欧珀移动通信有限公司 | 数据同步控制方法、装置以及服务器 |
CN108259522A (zh) * | 2016-12-28 | 2018-07-06 | 中兴通讯股份有限公司 | 一种PaaS平台容器化应用的弹缩方法及装置 |
-
2018
- 2018-05-15 CN CN201810462140.9A patent/CN110489225A/zh active Pending
Patent Citations (9)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20170155729A1 (en) * | 2013-07-11 | 2017-06-01 | Apollo Education Group, Inc. | Message Consumer Orchestration Framework |
CN105786909A (zh) * | 2014-12-25 | 2016-07-20 | 北京东方通科技股份有限公司 | 一种自适应消息队列积压负载的应用触发方法和系统 |
US9781122B1 (en) * | 2016-05-11 | 2017-10-03 | Oracle International Corporation | Multi-tenant identity and data security management cloud service |
CN106227605A (zh) * | 2016-07-26 | 2016-12-14 | 北京北森云计算股份有限公司 | 一种多语言云编译的动态微服务扩容方法及装置 |
CN106453564A (zh) * | 2016-10-18 | 2017-02-22 | 北京京东尚科信息技术有限公司 | 弹性云分布式海量请求处理的方法、装置及系统 |
CN106487594A (zh) * | 2016-10-31 | 2017-03-08 | 中国人民解放军91655部队 | 基于微服务组件的网络流量采集和分析系统 |
CN108259522A (zh) * | 2016-12-28 | 2018-07-06 | 中兴通讯股份有限公司 | 一种PaaS平台容器化应用的弹缩方法及装置 |
CN106888129A (zh) * | 2017-04-20 | 2017-06-23 | 国家电网公司 | 一种可弹性伸缩的分布式服务管理系统及其方法 |
CN107920136A (zh) * | 2017-12-29 | 2018-04-17 | 广东欧珀移动通信有限公司 | 数据同步控制方法、装置以及服务器 |
Non-Patent Citations (1)
Title |
---|
开金宇: "面向可靠性的微服务系统自适应调整技术研究", 《中国优秀博硕士学位论文全文数据库(博士) 信息科技辑》 * |
Cited By (13)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN111245900B (zh) * | 2019-12-31 | 2021-09-14 | 北京健康之家科技有限公司 | 一种分布式消息发送的处理系统及其处理方法 |
CN111245900A (zh) * | 2019-12-31 | 2020-06-05 | 北京健康之家科技有限公司 | 一种分布式消息发送的处理系统及其处理方法 |
CN113138860B (zh) * | 2020-01-17 | 2023-11-03 | 中国移动通信集团浙江有限公司 | 消息队列的管理方法及装置 |
CN113138860A (zh) * | 2020-01-17 | 2021-07-20 | 中国移动通信集团浙江有限公司 | 消息队列的管理方法及装置 |
CN111309476B (zh) * | 2020-01-22 | 2023-11-03 | 福建天泉教育科技有限公司 | 推送系统自动调整资源的方法、存储介质 |
CN111309476A (zh) * | 2020-01-22 | 2020-06-19 | 福建天泉教育科技有限公司 | 推送系统自动调整资源的方法、存储介质 |
CN113806102A (zh) * | 2020-06-15 | 2021-12-17 | 中国移动通信集团浙江有限公司 | 消息队列处理方法、装置及计算设备 |
CN113806102B (zh) * | 2020-06-15 | 2023-11-21 | 中国移动通信集团浙江有限公司 | 消息队列处理方法、装置及计算设备 |
CN113065785A (zh) * | 2021-04-13 | 2021-07-02 | 国网江苏省电力有限公司信息通信分公司 | 一种电力物联管理平台动态资源扩展方法 |
CN113065785B (zh) * | 2021-04-13 | 2024-02-20 | 国网江苏省电力有限公司信息通信分公司 | 一种电力物联管理平台动态资源扩展方法 |
CN113609071A (zh) * | 2021-07-28 | 2021-11-05 | 北京金山云网络技术有限公司 | 一种用于消息队列的自动扩容方法及装置 |
CN114666201A (zh) * | 2022-03-02 | 2022-06-24 | 国动物联网有限公司 | 一种高可用的分布式微服务架构 |
CN114666201B (zh) * | 2022-03-02 | 2024-01-30 | 国动物联网有限公司 | 一种高可用的分布式微服务架构 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN110489225A (zh) | 一种基于消息队列的服务扩容方法、装置及设备 | |
CN107092522B (zh) | 实时数据的计算方法及装置 | |
CN111338774A (zh) | 分布式定时任务调度系统及计算装置 | |
CN103631873B (zh) | 一种数据压缩方法及存储系统 | |
CN105827678B (zh) | 一种基于高可用架构下的通信方法和节点 | |
CN105516292A (zh) | 一种智能变电站云平台的热备方法 | |
CN110099084A (zh) | 一种保证存储服务可用性的方法、系统及计算机可读介质 | |
CN109660421A (zh) | 弹性调度资源的方法、装置、服务器及存储介质 | |
WO2021143590A1 (zh) | 一种分布式容器镜像构建调度系统及方法 | |
CN109245926A (zh) | 智能网卡、智能网卡系统及控制方法 | |
CN106385330B (zh) | 一种网络功能虚拟化编排器的实现方法及装置 | |
CN107729515A (zh) | 一种数据同步的方法、装置及存储介质 | |
CN103810038B (zh) | 一种ha集群中虚拟机存储文件迁移方法及其装置 | |
CN111324667A (zh) | 一种数据同步方法、装置、电子设备及存储介质 | |
CN103561089B (zh) | 虚拟机桌面登录方法、装置及系统 | |
CN108733808A (zh) | 大数据软件系统切换方法、系统、终端设备及存储介质 | |
CN105430028A (zh) | 服务调用方法、提供方法及节点 | |
CN116737560B (zh) | 基于智能导控的智慧训练系统 | |
CN105162837B (zh) | 海量数据存储环境下提升i/o吞吐率的方法及系统 | |
CN116304390A (zh) | 时序数据处理方法、装置、存储介质及电子设备 | |
CN111836221A (zh) | 计费管理方法、设备及系统 | |
CN115665263A (zh) | 一种流量调拨方法、装置、服务器及存储介质 | |
US11983644B2 (en) | Insight allotment to edged locations | |
CN105323320B (zh) | 一种内容分发的方法及装置 | |
CN110018782A (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 | ||
RJ01 | Rejection of invention patent application after publication | ||
RJ01 | Rejection of invention patent application after publication |
Application publication date: 20191122 |