一种消息处理方法及装置与流程

[0001]
本申请涉及网络技术领域，尤其涉及一种消息处理方法及装置。


背景技术：

[0002]
在业务系统的消息产生后，需要执行设备执行该消息对应的命令，以根据执行结果进行后续系统运维。例如，数据库发生主备切换产生切换通知消息，需要执行设备执行该切换通知消息对应的核查切换结果命令等，确认是否切换成功。又例如，网络设备、服务器等产生的告警消息，需要执行设备执行该告警消息对应的命令，如图1所示，在该示例中，现有技术方案通过消息生成中心、消息调度中心、ansible集群组成的架构完成上述系统运维。其中，消息调度中心设置有round robin(轮询调度，一种消息调度算法，用于将消息分配给服务器集群。特点是有固定分配次序，全部服务器都会均等分配到消息)，使得ansible容器实例获得数量均等的告警消息；消息生成中心依据告警生成告警消息，然后消息调度中心基于轮询调度，将告警消息逐个分配给ansible集群里对应的ansible容器实例处理。该架构可以保证ansible集群里每个ansible容器实例处理的告警消息的数量均等，但由于告警消息的消息类型不尽相同，ansible容器实例处理每种类型的告警消息所耗时间不同，甚至不同类型消息的执行耗时跨度从毫秒级到秒级，很容易导致ansible集群里中出现ansible容器实例最长耗时和最短耗时的两极分化，导致ansible容器实例资源的分配不均，浪费资源。
[0003]
因此，现在亟需一种消息处理方法及装置，能够灵活分配消息处理任务，均匀各服务容器实例中的待处理消息的处理耗时，提升消息处理性能。


技术实现要素：

[0004]
本发明实施例提供一种消息处理方法及装置，能够灵活分配消息处理任务，均匀各服务容器实例中的待处理消息的处理耗时，提升消息处理性能。
[0005]
第一方面，本发明实施例提供一种消息处理方法，该方法包括：
[0006]
调度中心接收各待分配消息；针对任一待分配消息，所述调度中心确定所述待分配消息的处理耗时估值；所述调度中心获取消息服务中心中各消息队列的第一总耗时估值；根据各待分配消息的处理耗时估值和所述各消息队列的第一总耗时估值，按照效率匹配原则，分别确定各待分配消息对应的各消息队列；其中，每个消息队列对应有容器服务中心上的服务容器实例；所述服务容器实例用于处理对应消息队列中的消息；所述效率匹配原则为第一总耗时估值低的消息队列对应处理耗时估值高的待分配消息。
[0007]
上述方法中，调度中心为每个待分配消息确定处理耗时估值，并根据各待分配消息的处理耗时估值和各消息队列的第一总耗时估值，按照效率匹配原则，分别确定各待分配消息对应的各消息队列。也就是说，使得第一总耗时估值低的消息队列对应处理耗时估值高的待分配消息。进一步，使得从消息队列里获取消息并进行处理的各服务容器实例，均匀分配处理消息所耗费的时间。相比于现有技术中，在各服务容器实例间均匀分配消息数
量来说，本申请可以保证各服务容器实例处理待处理消息的总耗时相同，实现均匀分配消息处理资源，加快消息的处理速度。
[0008]
可选的，所述调度中心确定所述待分配消息的处理耗时估值，包括：
[0009]
所述调度中心根据耗时估值记录确定所述待分配消息的处理耗时估值，所述耗时估值记录中包含各类型消息的处理耗时估值，所述处理耗时估值是根据各服务容器实例处理各类型消息所耗时间得到的。
[0010]
上述方法中，耗时估值记录为根据各服务容器实例处理各类型消息所耗时间得到的，则保证耗时估值记录中的各类型消息的处理耗时估值是根据真实消息处理所耗用的时间得到，提高消息处理资源分配的均匀性，节约消息处理资源。
[0011]
可选的，所述耗时估值记录是通过如下方式获得的，包括：估算中心周期性从各服务容器实例获取各消息的执行结果，并统计该时段内的所述各消息的执行结果，得到在生产环境下各类型消息的第一处理耗时估值；所述执行结果中包含处理耗时和消息类型；所述估算中心周期性从测试中心获取各消息的执行结果，并统计该时段内的所述各消息的执行结果，得到在测试环境下各类型消息的第二处理耗时估值；所述估算中心根据所述第一处理耗时估值和所述第二处理耗时估值更新所述耗时估值记录。
[0012]
上述方法中，估算中心周期性从各服务容器实例获取各消息的执行结果统计获取的各消息的执行结果，得到在生产环境下各类型消息的第一处理耗时估值，根据第一处理耗时估值更新耗时估值记录。如此，使得耗时估值记录中的各类型消息的处理耗时估值紧跟生产环境的各类型消息处理耗时，保证耗时估值记录中的各类型消息的处理耗时估值的时效性和准确性。估算中心周期性从各测试中心获取各消息的执行结果统计获取的各消息的执行结果，得到在测试环境下各类型消息的第二处理耗时估值，根据第二处理耗时估值更新耗时估值记录。如此，防止出现某种类型消息可能因为处理次数少，导致处理耗时估值准确性低。甚至可能出现某种消息因为从未被处理过，导致处理耗时估值仍然是初始值0的情况。以提高耗时估值记录中处理耗时估值的准确性。
[0013]
可选的，所述耗时估值记录通过如下方式更新，包括：m
a’＝(m
a
*n
a
+t
a
)/n
a’；n
a’＝n
a
+n
a
；其中，m
a’：更新后的所述耗时估值记录中对应类型消息的耗时估值；m
a
：更新前的所述耗时估值记录中所述对应类型消息的耗时估值；n
a’：更新后所述耗时估值记录中所述对应类型消息的总执行次数；n
a
：更新前所述耗时估值记录中所述对应类型消息的总执行次数；n
a
：所述执行结果中对应类型消息的执行次数；t
a
：所述执行结果中执行所述对应类型消息的所耗时间。
[0014]
上述方法中，通过m
a’＝(m
a
*n
a
+t
a
)/n
a’；n
a’＝n
a
+n
a
；使得耗时估计记录中的处理估计值为测试环境和生产环境下历史各类型消息处理所耗时间的均值，保证耗时估计记录中的处理估计值的准确性。
[0015]
可选的，所述调度中心根据所述待分配消息的耗时估值将所述待分配消息发送至所述消息队列之前，还包括：所述调度中心获取第二总耗时估值，所述第二总耗时估值为所述调度中心中所有待分配消息的处理耗时估值的总值；所述调度中心获取第三总耗时估值，所述第三总耗时估值为所述消息服务中心中各消息队列的所有待处理消息的处理耗时估值的总值；所述调度中心根据所述第二总耗时估值和所述第三总耗时估值，确定是否对消息队列集群和服务容器实例集群进行扩容或缩容。
[0016]
上述方法中，相比于现有技术中：服务实例预先部署在服务器上，服务实例数量固定；当某个调度周期出现大量告警时，容易超过现有处理能力，延长告警消息处理时间。本方法根据第二总耗时估值和第三总耗时估值，确定是否对消息队列集群和服务容器实例集群进行扩容或缩容。可以准确确定扩容或缩容方案，进一步动态调整消息队列集群和服务容器实例集群中的消息队列和服务容器实例数量，加快待处理消息的处理速度。
[0017]
可选的，确定对所述消息队列集群和所述服务容器实例集群进行的扩容或缩容，包括：所述调度中心将扩容需求或缩容需求发送至容器管理中心，以使所述容器管理中心根据所述扩容需求或缩容需求对所述消息队列集群和所述服务容器实例集群进行扩容或缩容。
[0018]
上述方法中，通过容器管理中心根据调度中心发送的扩容需求或缩容需求，动态调整消息队列集群和服务容器实例集群中的执行容器实例数量，不仅加快待处理消息的处理速度，同时提高了消息处理的资源利用率。
[0019]
可选的，所述调度中心根据所述第二总耗时估值和所述第三总耗时估值，确定是否对所述消息队列集群和所述服务容器实例集群进行的扩容或缩容，包括：所述调度中心根据所述第一总耗时估值的上限与所述消息队列的数量确定所述第三总耗时估值的上限；所述调度中心根据所述第三总耗时估值的上限和所述第三总耗时估值确定所述消息队列集群的缓存资源信息；所述调度中心根据所述缓存资源信息、所述第二总耗时估值和所述第一总耗时估值的上限，确定所述消息队列集群和所述服务容器实例集群进行的扩容需求或缩容需求。
[0020]
上述方法中，调度中心根据第三总耗时估值的上限和第三总耗时估值确定消息队列集群的缓存资源信息。进而根据该缓存资源信息、第二总耗时估值和第一总耗时估值的上限确定，也就是，根据消息队列集群中当前缓存资源信息、调度中心中所有待分配消息的处理耗时估值的总值，以及消息队列的第一总耗时估值的上限确定，若将调度中心中所有待分配消息分配到消息队列集群后，消息队列集群是否会出现缓存资源不足或缓存资源过多，而相应导致的消息处理过慢，降低消息处理的时效性；或缓存资源没有充足利用，增加消息处理成本。由此，通过消息队列集群不足的缓存资源或多余的缓存资源与消息队列的第一总耗时估值的上限，确定需要扩容或缩容的消息队列数量以及服务容器实例数量，进而对消息队列集群或服务容器实例集群进行相应的扩容或缩容，以提升消息处理的时效性和降低消息处理成本。
[0021]
可选的，所述消息队列与所述服务容器实例一一对应，所述调度中心所述缓存资源信息、所述第二总耗时估值和所述第一总耗时估值的上限，确定所述消息队列集群和所述服务容器实例集群进行的扩容需求或缩容需求，包括：n
change
＝(t
allocate-(t
target
*n
exist-t
queuetotal
))/t
target
；如果n
change
>0，则n
expansion
＝init(n
change
)+1；如果n
change
<＝0，则n
shrinkage
＝init(n
change
)；其中，n
change
：为扩容或缩容所述消息队列和所述服务容器实例的数量，t
allocate
：所述第二总耗时估值，t
target
：所述第一总耗时估值的上限，n
exist
：消息队列的数量，t
queue total
：所述第三总耗时估值，n
expansion
：消息队列和服务容器实例的扩容数量，n
shrinkage
：消息队列和服务容器实例的缩容数量，init(n
change
)：对扩容数量或缩容数量的取整函数。
[0022]
上述方法中，若消息队列与服务容器实例一一对应，获得第三总耗时估值的上限
和第三总耗时估值的差值，得到消息队列集群剩余缓存资源。则进一步，通过第二总耗时估值与该剩余缓存资源的差值，得到若将调度中心中所有待分配消息分配到消息队列集群后，消息队列集群的剩余缓存资源。再进一步，根据该所有待分配消息分配后获得的剩余缓存资源与第一总耗时估值的比值，确定扩容需求和缩容需求。考虑消息队列和服务容器实例为整数个，以及资源可用性；若该比值为大于零时，为扩容需求，取整且加1；若该比值为小于零时，为缩容需求，取整且减1。
[0023]
第二方面，本发明实施例提供一种消息处理装置，所述消息处理系统包括：
[0024]
调度中心、估算中心、测试中心、服务容器中心，以及至少一个消息队列和至少一个服务容器实例；所述调度中心，用于执行如上文调度中心执行的所述的方法；所述估算中心，用于执行如上文估算中心执行的所述的方法；所述测试中心，用于在测试环境下对各类型消息进行循环处理，获取所述各类型消息的执行结果；所述服务容器中心，用于接收所述调度中心发送的扩容需求或缩容需求，并根据所述扩容需求或缩容需求对消息队列集群和服务容器实例集群进行扩容或缩容。
[0025]
第三方面，本发明实施例提供一种消息处理装置，该装置包括：
[0026]
收发模块，用于接收各待分配消息；
[0027]
确定模块，用于针对任一待分配消息，确定所述待分配消息的处理耗时估值；
[0028]
处理模块，用于获取消息服务中心中各消息队列的第一总耗时估值；根据各待分配消息的处理耗时估值和所述各消息队列的第一总耗时估值，按照效率匹配原则，分别确定各待分配消息对应的各消息队列；其中，每个消息队列对应有容器服务中心上的服务容器实例；所述服务容器实例用于处理对应消息队列中的消息；所述效率匹配原则为第一总耗时估值低的消息队列对应处理耗时估值高的待分配消息。
[0029]
第四方面，本申请实施例还提供一种计算设备，包括：存储器，用于存储程序；处理器，用于调用所述存储器中存储的程序，按照获得的程序执行如第一方面的各种可能的设计中所述的方法。
[0030]
第五方面，本申请实施例还提供一种计算机可读非易失性存储介质，包括计算机可读程序，当计算机读取并执行所述计算机可读程序时，使得计算机执行如第一方面的各种可能的设计中所述的方法。
[0031]
本申请的这些实现方式或其他实现方式在以下实施例的描述中会更加简明易懂。
附图说明
[0032]
为了更清楚地说明本发明实施例中的技术方案，下面将对实施例描述中所需要使用的附图作简要介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域的普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。
[0033]
图1为本发明实施例提供的现有技术中的一种消息处理的架构示意图；
[0034]
图2为本发明实施例提供的一种消息处理的架构示意图；
[0035]
图3为本发明实施例提供的一种消息处理方法的流程示意图；
[0036]
图4为本发明实施例提供的一种消息处理方法的流程示意图；
[0037]
图5为本发明实施例提供的一种消息处理装置示意图。
具体实施方式
[0038]
为了使本发明的目的、技术方案和优点更加清楚，下面将结合附图对本发明作进一步地详细描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其它实施例，都属于本发明保护的范围。
[0039]
本发明实施例提供的一种消息处理的系统架构，如图2所示，该系统结构中包括：生成中心、调度中心、估算中心、测试中心、容器管理中心、包含至少一个消息队列和包含至少一个结果队列的队列集群(队列集群中包含消息队列集群和结果队列集群)、包含至少一个服务容器实例的服务容器实例集群。
[0040]
生成中心：用于根据对接的业务系统等生成待分配消息；
[0041]
调度中心：用于根据本地的耗时估值记录为待分配消息确定处理耗时估值，并根据待分配消息的处理耗时估值对待分配消息进行分配消息队列，以及生成消息队列集群和服务容器实例集群的扩容缩容方案；
[0042]
估算中心：用于根据生产环境和测试环境下的消息的执行结果更新耗时估值记录；
[0043]
测试中心：用于模拟真实生产环境，对全量类型消息进行循环处理，获取全量类型消息的执行结果；
[0044]
容器管理中心：用于根据扩容或缩容方案对消息队列集群和服务容器实例集群进行扩容或缩容；
[0045]
队列集群：用于在消息队列集群中的各消息队列中缓存待处理消息，在各结果队列中缓存消息的执行结果；
[0046]
服务容器实例集群：用于该集群中的各服务容器实例获取对应消息队列中缓存的待处理消息进行处理，生成消息的执行结果。
[0047]
生成中心产生待分配消息后，推送至调度中心。调度中心根据耗时估值记录确定各待分配消息的处理耗时估值，并根据消息队列集群中的各消息队列中的第一总耗时估值，将调度中心中的各待分配消息分别发生至对应的消息队列，完成待分配消息的分配。服务容器实例集群中的各服务容器实例从对应的消息队列中获取消息并进行处理，生成消息的执行结果，将执行结果发送至结果队列。估算中心获取结果队列中消息的执行结果，根据该执行结果中的处理耗时和消息类型更新耗时估值记录。调度中心从估算中心获取更新后的耗时估值记录。其中，估算中心还获取测试中心对全量类型消息，或者部分类型消息进行循环处理得到的执行结果，并根据执行结果中的处理耗时和消息类型更新耗时估值记录，这里对测试中心循环测试处理的消息类型与数量不做限定，可根据具体需求灵活设定。调度中心还根据第二总耗时估值(调度中心当前所有待分配消息的处理耗时估值的总值)和第三总耗时估值(消息队列集群中所有消息的处理耗时估值的总值)，确定对消息队列集群和服务容器实例集群进行的扩容或缩容方案，并将该扩容或缩容方案发送至容器管理中心。使得容器管理中心根据该扩容或缩容方案对队列集群和服务容器实例集群进行扩容或缩容。这里需要说明的是，上述队列集群中的各消息队列及结果队列运行在消息服务中心；上述服务容器实例集群中的各服务容器实例运行在容器服务中心；其中，消息服务中心可以以一个服务器集群为物理层运行基础设备，容器服务中心可以以一个服务器集群为物理
层运行基础设备，调度中心、生产中心、测试中心、估算中心可以分别以一个服务器集群为物理层运行基础设备；或者，消息服务中心、容器服务中心、调度中心、生产中心、测试中心、估算中心可以都运行在一个服务器集群中，这里对消息服务中心、容器服务中心、调度中心、生产中心、测试中心、估算中心的物理层运行基础设备具体不做限定，可以依据具体需要配置。
[0048]
基于此，本申请实施例提供了一种消息处理方法流程，如图3所示，包括：
[0049]
步骤301、调度中心接收各待分配消息；
[0050]
此处，待分配消息可以是业务系统或者任意系统中的需要处理的消息，例如，业务系统中产生的告警消息、软件部署过程中的部署进度消息、服务器的配置消息等等。
[0051]
步骤302、针对任一待分配消息，所述调度中心确定所述待分配消息的处理耗时估值；
[0052]
步骤303、所述调度中心获取消息服务中心中各消息队列的第一总耗时估值；根据各待分配消息的处理耗时估值和所述各消息队列的第一总耗时估值，按照效率匹配原则，分别确定各待分配消息对应的各消息队列；其中，每个消息队列对应有容器服务中心上的服务容器实例；所述服务容器实例用于处理对应消息队列中的消息；所述效率匹配原则为第一总耗时估值低的消息队列对应处理耗时估值高的待分配消息。
[0053]
此处，服务容器实例可以是ansible(一种python语言实现的自动化运维工具，集成了安全登录、复杂命令执行及结果返回等功能，适合代为执行处理大量重复性it运维工作)、puppet(一个it基础设施自动化管理工具，它能够帮助系统管理员管理基础设施的整个生命周期)等自动化运维工具。
[0054]
上述方法中，调度中心为每个待分配消息确定处理耗时估值，并根据各待分配消息的处理耗时估值和各消息队列的第一总耗时估值，按照效率匹配原则，分别确定各待分配消息对应的各消息队列。也就是说，使得第一总耗时估值低的消息队列对应处理耗时估值高的待分配消息。进一步，使得从消息队列里获取消息并进行处理的各服务容器实例，均匀分配处理消息所耗费的时间。相比于现有技术中，在各服务容器实例间均匀分配消息数量来说，本申请可以保证各服务容器实例处理待处理消息的总耗时相同，实现均匀分配消息处理资源，加快消息的处理速度。
[0055]
本申请实施例提供了一种调度中心确定待分配消息的处理耗时估值的方法，包括：所述调度中心根据耗时估值记录确定所述待分配消息的处理耗时估值，所述耗时估值记录中包含各类型消息的处理耗时估值，所述处理耗时估值是根据各服务容器实例处理各类型消息所耗时间得到的。也就是说，调度中心中包含耗时估值记录，每当接收到生产中心推送的待分配消息，则根据待分配消息的消息类型为该待分配消息分配相应的处理耗时估值，使得到分配消息中包含消息类型、消息对象、处理耗时估值。
[0056]
本申请实施例提供了一种获得耗时估值记录方法，包括：估算中心周期性从各服务容器实例获取各消息的执行结果，并统计该时段内的所述各消息的执行结果，得到在生产环境下各类型消息的第一处理耗时估值；所述执行结果中包含处理耗时和消息类型；所述估算中心周期性从测试中心获取各消息的执行结果，并统计该时段内的所述各消息的执行结果，得到在测试环境下各类型消息的第二处理耗时估值；所述估算中心根据所述第一处理耗时估值和所述第二处理耗时估值更新所述耗时估值记录。也就是说，服务容器实例
集群中各服务容器实例，对在生产环境下的消息进行处理获得执行结果；估算中心根据生产环境下消息的执行结果确定第一处理耗时估值。例如：在周期时间内的生产环境下，针对a类消息的执行结果包括：实际执行次数为z
a1
、z
a1
次总的实际处理耗时为t
a1
；则第一耗时估值为可以以第一耗时估值为a类消息的处理耗时估值。测试中心在测试环境下的周期时间内，对全量类型消息，或生产环境中较少处理到的各类型消息进行循环处理获得执行结果；估算中心根据测试环境下消息的执行结果确定第二处理耗时估值。例如：在周期时间内的生产环境下针对a类消息的执行结果包括：实际执行次数为z
a2
、z
a2
次总的实际处理耗时为t
a2
；则第二耗时估值为可以以第二耗时估值为a类消息的处理耗时估值。或者，估算中心可以根据第一耗时估值和第二耗时估值确定处理耗时估值，例如，在上述示例中，估算中心可以以为a类消息的处理耗时估值。其中，估算中心获取服务容器实例的执行结果的周期与获取测试中心的执行结果的周期可以相同也可以不同，可以根据各类型消息的生产周期、生产数量、业务需要设定，具体不做限制。
[0057]
又或者，估算中心根据获取的执行结果更新耗时估值记录。例如，耗时估值记录如下表1：
[0058]
消息类型处理耗时估值总执行次数am
a
n
a
bm
b
n
b
………
xm
x
n
x
[0059]
表1
[0060]
该耗时估值记录中的所有处理耗时估值和总执行次数的初始值都可以设置为0，或者根据经验设置为经验值。为了提升耗时估值记录中的各类型消息的处理耗时估值的准确性，估算中心周期性的从结果队列中和测试中心获取执行结果，并会定期或不定期根据获取的执行结果更新耗时估值记录。执行结果可以包括消息来源、消息类型、执行对象、处理耗时、结果属性和超时状态这六个关键信息，举例如下：
[0061]
消息来源：测试中心；消息类型：a；执行对象：o1；处理耗时：t1；结果属性：r1；超时状态：否；
[0062]
消息来源：服务容器实例；消息类型：a；执行对象：o2；处理耗时：t2；结果属性：r2；超时状态：否；
[0063]
消息来源：服务容器实例；消息类型：a；执行对象：o3；处理耗时：t3；结果属性：r3；超时状态：是；
[0064]
消息来源：测试中心；消息类型：b；执行对象：o4；处理耗时：t4；结果属性：r4；超时状态：否；
[0065]
消息来源：服务容器实例；消息类型：b；执行对象：o5；处理耗时：t5；结果属性：r5；超时状态：否；
[0066]
估算中心收到上述执行结果后，若消息处理为超时状态，则表示该执行结果为异
常执行结果，因此，导致处理耗时出现极值，若根据该执行结果更新耗时估值记录会严重影响后续估值计算，因此，首先剔除超时的执行结果。
[0067]
则根据如下公式更新耗时估值记录中的各类型消息的处理耗时估值：m
a’＝(m
a
*n
a
+t
a
)/n
a’；n
a’＝n
a
+n
a
；其中，m
a’：更新后的所述耗时估值记录中对应类型消息的耗时估值；m
a
：更新前的所述耗时估值记录中所述对应类型消息的耗时估值；n
a’：更新后所述耗时估值记录中所述对应类型消息的总执行次数；n
a
：更新前所述耗时估值记录中所述对应类型消息的总执行次数；n
a
：所述执行结果中对应类型消息的执行次数；t
a
：所述执行结果中执行所述对应类型消息的所耗时间。在上述示例中，n
a
＝2、n
b
＝2；t
a
＝t1+t2、t
b
＝t4+t5；则：m
a’＝(m
a
*n
a
+(t1+t2))/(n
a
+2)、m
b’＝(m
b
*n
b
+(t4+t5))/(n
b
+2)。
[0068]
更新的耗时估值记录如下：
[0069]
消息类型处理耗时估值总执行次数am
a’n
a’bm
b’n
b
’………
xm
x
n
x
[0070]
表2
[0071]
由此，估算中心将表2提供给调度中心，或者估算中心在调度中心获取耗时估值记录时，将更新后的耗时估值记录发送至调度中心。其中，耗时估值记录可以以表的形式，键值对的形式记录，上述示例只是一种耗时估值记录实现可能，具体存在方式不做限定。
[0072]
本申请实施例提供了一种扩容或缩容方法，所述调度中心根据所述待分配消息的耗时估值将所述待分配消息发送至所述消息队列之前，还包括：所述调度中心获取第二总耗时估值，所述第二总耗时估值为所述调度中心中所有待分配消息的处理耗时估值的总值；所述调度中心获取第三总耗时估值，所述第三总耗时估值为所述消息服务中心中各消息队列的所有待处理消息的处理耗时估值的总值；所述调度中心根据所述第二总耗时估值和所述第三总耗时估值，确定是否对消息队列集群和服务容器实例集群进行扩容或缩容。也就是说，调度中心在将待分配消息分配至各消息队列之前，还会获取各消息队列中的所有待处理消息的处理耗时估值的总值，即，第三总耗时估值；以及调度中心中所有待分配消息的处理耗时估值的总值，即，第二总耗时估值。如此，若各消息队列中包含原有的消息以及刚分配的消息，这种情况下，各消息队列中的消息处理耗时估值的总值为第二总耗时估值与第三总耗时估值的和，判断是否超过服务容器实例集群的处理能力上限，若超过，则需要对消息队列和服务容器实例进行扩容，若没有超过，且低于处理能力下限，则需要对消息队列和服务容器实例进行缩容。如此，保证处理消息资源的利用率。其中，服务容器实例集群的处理能力上限与处理能力下限可以根据历史经验设定，具体不做限制。
[0073]
本申请实施例提供了一种扩容或缩容方法，确定对所述消息队列集群和所述服务容器实例集群进行的扩容或缩容，包括：所述调度中心将扩容需求或缩容需求发送至容器管理中心，以使所述容器管理中心根据所述扩容需求或缩容需求对所述消息队列集群和所述服务容器实例集群进行扩容或缩容。也就是说，调度中心获得扩容或缩容需求后，将该扩容或缩容需求发送至容器管理中心。容器管理中心可以包含服务容器实例和消息队列的镜像文件，如此，可以根据扩容或缩容需求在服务容器实例对应的服务器集群中安装并运行
服务容器实例的镜像文件，在消息队列对应的服务器集群中安装并运行消息队列的镜像文件完成扩容或缩容。在一种示例中，容器管理中心可以应用k8s系统(kubernetes，开源容器编排平台，通过对象式api实现对容器集群的批量调度与编排，从而确保应用服务的高可用，提供自动扩容/缩容等重要特性。其中调度与编排的对象通过yaml文件进行定义)、服务容器实例为ansible容器实例，则可以更新k8s里描述ansible容器实例yaml文件，将replicas参数改为扩容或缩容后的消息队列数量，执行kubectl apply-f ansible.yaml,触发ansible容器实例扩容或缩容。
[0074]
本申请实施例提供了一种扩容或缩容方法，所述调度中心根据所述第二总耗时估值和所述第三总耗时估值，确定是否对所述消息队列集群和所述服务容器实例集群进行的扩容或缩容，包括：所述调度中心根据所述第一总耗时估值的上限与所述消息队列的数量确定所述第三总耗时估值的上限；所述调度中心根据所述第三总耗时估值的上限和所述第三总耗时估值确定所述消息队列集群的缓存资源信息；所述调度中心根据所述缓存资源信息、所述第二总耗时估值和所述第一总耗时估值的上限，确定所述消息队列集群和所述服务容器实例集群进行的扩容需求或缩容需求。也就是说，调度中心可以根据分配待分配消息之前消息队列集群中的剩余缓存资源，和分配所有待分配消息之后消息队列集群中的剩余缓存资源，以及消息队列中各缓存消息的处理耗时估值总值的最大值，判断消息队列集群和服务容器实例集群是否需要扩容或缩容，使得在调度中心分配待分配消息之前即对消息队列集群和服务容器实例集群进行调整，保证消息队列集群和服务容器实例集群的消息处理速度以及资源利用率。其中，第一总耗时估值的上限可以为根据服务容器实例处理消息的能力确定，以使得服务容器实例处理完消息队列中的第一总耗时估值的上限对应的所有消息后，不影响所获得的执行结果的应用。也就是说，根据消息处理的时效性确定消息队列中第一总耗时估值的上限。
[0075]
本申请实施例提供了一种扩容或缩容方法，所述消息队列与所述服务容器实例一一对应，所述调度中心所述缓存资源信息、所述第二总耗时估值和所述第一总耗时估值的上限，确定所述消息队列集群和所述服务容器实例集群进行的扩容需求或缩容需求，包括：n
change
＝(t
allocate-(t
target
*n
exist-t
queue total
))/t
target
；如果n
change
>0，则n
expansion
＝init(n
change
)+1；如果n
change
<＝0，则n
shrinkage
＝init(n
change
)；其中，n
change
：扩容或缩容所述消息队列和所述服务容器实例的数量，t
allocate
：所述第二总耗时估值，t
target
：所述第一总耗时估值的上限，n
exist
：消息队列的数量，t
queue total
：所述第三总耗时估值，n
expansion
：消息队列和服务容器实例的扩容数量，n
shrinkage
：消息队列和服务容器实例的缩容数量，init(n
change
)：对扩容数量或缩容数量的取整函数。也就是说，如果n
change
>0，容器管理中心接收n
expansion
后，触发消息队列扩容，增加n
expansion
条空消息队列和服务容器实例。在一种实现方式中，消息队列序号在现有消息队列序号的最大序号上增加，如此，各消息队列的序号从小到大编写标记，便于后续缩容等操作。例如，调度中心将待分配消息按处理耗时估值由小到大排序并按顺序存入堆栈，即栈底是处理耗时估值最小的待分配消息，栈顶是处理耗时估值最大的待分配消息，进行消息分配时，依照效率匹配原则将处理耗时估值低的待分配消息分配至第一总耗时估值高的消息队列，将处理耗时估值高的待分配消息分配至第一总耗时估值低的消息队列。但当第一总耗时估值低的消息队列不止一个，则将处理耗时估值高待分配消息分配给序号低的消息队列，以保证最大序号的消息队列中的第一总耗时估值相对较
小；当进行缩容时，则可以将序号大的消息队列中的消息重新分配至其他消息队列，将该消息队列取消，加快缩容速度。如果n
change
<0，容器管理中心接收，则n
shrinkage
后，触发消息队列缩容，减少n
expansion
条消息队列和服务容器实例，其中，对消息队列执行缩容之前，需先将待缩容的消息队列里的消息全部转移到调度中心重新分配。缩容顺序是依照队列序号倒序缩容，即从序号大的消息队列开始进行缩容。如果n
change
＝0，表示无需扩容缩容，直接进入待分配消息的分配。
[0076]
基于上述方法流程，本申请实施例提供了一种消息处理流程，如图4所示，包括：
[0077]
步骤401、估算中心获取测试中心中的执行结果。
[0078]
步骤402、估算中心获取结果队列中的执行结果。
[0079]
步骤403、估算中心根据获取的执行结果更新耗时估值记录。
[0080]
步骤404、估算中心将更新后的耗时估值记录发送至调度中心。
[0081]
步骤405、生成中心生成待分配消息。
[0082]
步骤406、生成中心将待分配消息推送至调度中心。
[0083]
步骤407、调度中心根据耗时估值记录为各待分配消息确定处理耗时估值。
[0084]
步骤408、调度中心获取各消息队列的第一总耗时估值。
[0085]
步骤409、调度中心获取第二总耗时估值和第三总耗时估值。
[0086]
步骤410、调度中心根据第二总耗时估值和第三总耗时估值确定扩容或缩容需求。
[0087]
步骤411、调度中心将扩容或缩容需求发送至容器管理中心。
[0088]
步骤412、容器管理中心更改配置。
[0089]
步骤413、容器管理中心对消息队列集群和服务容器实例集群进行相应的扩容或缩容。
[0090]
步骤414、调度中心根据待分配消息的处理耗时估值大小，将待分配消息压入堆栈，使得由栈底至栈顶的待分配消息的处理耗时估值的大小依次增大。
[0091]
步骤415、调度中心根据效率匹配原则读取栈顶的待分配消息，并确定当前第一总耗时估值最小的消息队列，若第一总耗时估值最小的消息队列数量大于1，则将该待分配消息分配给序号小的消息队列。
[0092]
步骤416、服务容器实例获取消息队列中的消息进行处理，并得到执行结果。
[0093]
步骤417、服务容器实例将执行结果发送至结果队列。
[0094]
步骤418、估算中心获取结果队列中的执行结果。
[0095]
这里需要说明的是，上述流程并不唯一，如，步骤401、步骤402、步骤403、步骤404可以发生在步骤405至步骤417中的任何一个流程步骤前或流程步骤后，步骤402可以在步骤401之前执行。步骤410中确定无需扩容或缩容，则无需执行步骤411-步骤413。步骤416可以在图4中的整个流程中任意时刻进行。
[0096]
基于同样的思想，本申请实施例提供了一种消息处理装置，如图5所示，该装置包括：
[0097]
收发模块501，用于接收各待分配消息；
[0098]
确定模块502，用于针对任一待分配消息，确定所述待分配消息的处理耗时估值；
[0099]
处理模块503，用于获取消息服务中心中各消息队列的第一总耗时估值；根据各待分配消息的处理耗时估值和所述各消息队列的第一总耗时估值，按照效率匹配原则，分别
确定各待分配消息对应的各消息队列；其中，每个消息队列对应有容器服务中心上的服务容器实例；所述服务容器实例用于处理对应消息队列中的消息；所述效率匹配原则为第一总耗时估值低的消息队列对应处理耗时估值高的待分配消息。
[0100]
可选的，所述确定模块502还用于，根据耗时估值记录确定所述待分配消息的处理耗时估值，所述耗时估值记录中包含各类型消息的处理耗时估值，所述处理耗时估值是根据各服务容器实例处理各类型消息所耗时间得到的。
[0101]
可选的，所述处理模块503还用于，周期性从各服务容器实例获取各消息的执行结果，并统计该时段内的所述各消息的执行结果，得到在生产环境下各类型消息的第一处理耗时估值；所述执行结果中包含处理耗时和消息类型；所述处理模块503还用于，周期性从测试中心获取各消息的执行结果，并统计该时段内的所述各消息的执行结果，得到在测试环境下各类型消息的第二处理耗时估值；所述处理模块503还用于，根据所述第一处理耗时估值和所述第二处理耗时估值更新所述耗时估值记录。
[0102]
可选的，更新所述耗时估值记录，包括：m
a’＝(m
a
*n
a
+t
a
)/n
a’；n
a’＝n
a
+n
a
；其中，m
a’：更新后的所述耗时估值记录中对应类型消息的耗时估值；m
a
：更新前的所述耗时估值记录中所述对应类型消息的耗时估值；n
a’：更新后所述耗时估值记录中所述对应类型消息的总执行次数；n
a
：更新前所述耗时估值记录中所述对应类型消息的总执行次数；n
a
：所述执行结果中对应类型消息的执行次数；t
a
：所述执行结果中执行所述对应类型消息的所耗时间。
[0103]
可选的，所述处理模块503还用于，获取第二总耗时估值，所述第二总耗时估值为所述调度中心中所有待分配消息的处理耗时估值的总值；所述处理模块503还用于，获取第三总耗时估值，所述第三总耗时估值为所述消息服务中心中各消息队列的所有待处理消息的处理耗时估值的总值；所述处理模块503还用于，根据所述第二总耗时估值和所述第三总耗时估值，确定是否对消息队列集群和服务容器实例集群进行扩容或缩容。
[0104]
可选的，所述处理模块503还用于，将扩容需求或缩容需求发送至容器管理中心，以使所述容器管理中心根据所述扩容需求或缩容需求对所述消息队列集群和所述服务容器实例集群进行扩容或缩容。
[0105]
可选的，所述处理模块503还用于，根据所述第一总耗时估值的上限与所述消息队列的数量确定所述第三总耗时估值的上限；所述调度中心根据所述第三总耗时估值的上限和所述第三总耗时估值确定所述消息队列集群的缓存资源信息；所述调度中心根据所述缓存资源信息、所述第二总耗时估值确定和所述第一总耗时估值的上限，所述消息队列集群和所述服务容器实例集群进行的扩容需求或缩容需求。
[0106]
可选的，所述消息队列与所述服务容器实例一一对应，所述调度中心所述缓存资源信息、所述第二总耗时估值和所述第一总耗时估值的上限，确定所述消息队列集群和所述服务容器实例集群进行的扩容需求或缩容需求，包括：n
change
＝(t
allocate-(t
target
*n
exist-t
queue total
))/t
target
；如果n
change
>0，则n
expansion
＝init(n
change
)+1；如果n
change
<＝0，则n
shrinkage
＝init(n
change
)；其中，n
change
：扩容或缩容所述消息队列和所述服务容器实例的数量，t
allocate
：所述第二总耗时估值，t
target
：所述第一总耗时估值的上限，n
exist
：消息队列的数量，t
queuetotal
：所述第三总耗时估值，n
expansion
：消息队列和服务容器实例的扩容数量，n
shrinkage
：消息队列和服务容器实例的缩容数量，init(n
change
)：对扩容数量或缩容数量的取整函数。
[0107]
本领域内的技术人员应明白，本申请的实施例可提供为方法、系统、或计算机程序产品。因此，本申请可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、cd-rom、光学存储器等)上实施的计算机程序产品的形式。
[0108]
本申请是参照根据本申请的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。
[0109]
这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。
[0110]
这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。
[0111]
显然，本领域的技术人员可以对本申请进行各种改动和变型而不脱离本申请的精神和范围。这样，倘若本申请的这些修改和变型属于本申请权利要求及其等同技术的范围之内，则本申请也意图包含这些改动和变型在内。