CN111240860A - 消息处理方法及服务系统 - Google Patents

Abstract

本申请提出一种消息处理方法及服务系统，涉及信息技术领域，通过在服务系统中运行事件任务、事件服务、消息队列集群以及事件消费服务，使得事件任务可以向事件服务发送事件消息；然后事件服务可以将接收的事件消息存储至消息队列集群中对应的消息队列；而事件消费服务则可以从消息队列集群中的消息队列获取事件消息进行消费，相比于现有技术，利用事件服务和消息队列集群将事件任务与事件消费服务进行解耦合，从而可以灵活的配置服务系统中事件服务和事件消费服务的数量，进而灵活的调整服务系统处理事件消息的能力。

Description

消息处理方法及服务系统

技术领域

本申请涉及信息技术领域，具体而言，涉及一种消息处理方法及服务系统。

背景技术

在例如网络直播等应用场景中，存在大量的消息事件需要进行处理，比如弹幕消息、消费消息、虚拟礼物消息、互动消息等等。为使这些消息事件能够及时被处理，可以基于微服务构建集群系统，由微服务对消息进行消费处理。

在例如网络直播等场景中，单位时间内产生的消息的数量存在波动，比如当关注度较高的主播开播时，在短时间内可能会产生大量的消息需要被消费；而当关注度较少的主播开播时，在短时间内需要被消费的消息可能会较少；这使得需要动态配置微服务的数量，以应对存在大量需要消费的消息等场景。

然而，目前利用微服务进行消息消费等场景中，需要将消息按照微服务所需的数据结构进行耦合封装，操作不够灵活。

发明内容

本申请的目的在于提供一种消息处理方法及服务系统，能够灵活的调整服务系统处理事件消息的能力。

为了实现上述目的，本申请实施例采用的技术方案如下：

第一方面，本申请实施例提供一种消息处理方法，应用于服务系统，所述服务系统运行有事件任务、事件服务、消息队列集群以及事件消费服务；所述方法包括：

所述事件任务向所述事件服务发送事件消息；

所述事件服务将接收的事件消息存储至所述消息队列集群中对应的消息队列；

所述事件消费服务从所述消息队列集群中的消息队列获取事件消息进行消费。

第二方面，本申请实施例提供一种服务系统，所述服务系统运行有事件任务、事件服务、消息队列集群以及事件消费服务；

所述事件任务用于，向所述事件服务发送事件消息；

所述事件服务用于，将接收的事件消息存储至所述消息队列集群中对应的消息队列；

所述事件消费服务用于，从所述消息队列集群中的消息队列获取事件消息进行消费。

本申请实施例提供的一种消息处理方法及服务系统，通过在服务系统中运行事件任务、事件服务、消息队列集群以及事件消费服务，使得事件任务可以向事件服务发送事件消息；然后事件服务可以将接收的事件消息存储至消息队列集群中对应的消息队列；而事件消费服务则可以从消息队列集群中的消息队列获取事件消息进行消费，相比于现有技术，利用事件服务和消息队列集群将事件任务与事件消费服务进行解耦合，从而可以灵活的配置服务系统中事件服务和事件消费服务的数量，进而灵活的调整服务系统处理事件消息的能力。

为使本申请的上述目的、特征和优点能更明显易懂，下文特举较佳实施例，并配合所附附图，作详细说明如下。

附图说明

为了更清楚地说明本申请实施例的技术方案，下面将对实施例中所需要使用的附图作简单地介绍，应当理解，以下附图仅示出了本申请的某些实施例，因此不应被看作是对范围的限定，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其它相关的附图。

图1示出本申请实施例提供的服务系统的一种示意图；

图2示出本申请实施例提供的消息处理方法的一种示意性流程图；

图3示出本申请实施例提供的消息处理方法在扩容时的一种示意性流程图；

图4示出本申请实施例提供的消息处理方法在扩容时的另一种示意性流程图；

图5示出本申请实施例提供的消息处理方法在缩容时的一种示意性流程图；

图6示出图5中步骤117的子步骤的一种示意性流程图；

图7示出本申请实施例提供的消息处理方法在缩容时的另一种示意性流程图；

图8示出图7中步骤122的子步骤的一种示意性流程图；

图9示出本申请实施例提供的消息处理方法的另一种示意性流程图；

图10示出本申请实施例提供的消息处理方法的再一种示意性流程图。

具体实施方式

为使本申请实施例的目的、技术方案和优点更加清楚，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本申请一部分实施例，而不是全部的实施例。通常在此处附图中描述和示出的本申请实施例的组件可以以各种不同的配置来布置和设计。

因此，以下对在附图中提供的本申请的实施例的详细描述并非旨在限制要求保护的本申请的范围，而是仅仅表示本申请的选定实施例。基于本申请中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

应注意到：相似的标号和字母在下面的附图中表示类似项，因此，一旦某一项在一个附图中被定义，则在随后的附图中不需要对其进行进一步定义和解释。同时，在本申请的描述中，术语“第一”、“第二”等仅用于区分描述，而不能理解为指示或暗示相对重要性。

需要说明的是，在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。

在上述例如网络直播等场景中，在利用微服务对消息进行消费处理时，一般是由中心化的中间服务对各种消息进行集中处理。

比如，可以由中间服务与多个事件任务建立服务连接，由事件任务生产消息，例如开播事件产生的开播消息、送礼事件产生的礼物消息、充值事件产生的充值消息等等；并事件任务将生成的消息按照中间服务所需的数据结构对消息进行耦合封装，然后将消息发送给中间服务，使得中间服务可以统一对所有的事件任务发送的消息进行消费，从而完成各个事件任务处理。

在例如网络直播等场景中，存在单位时间内产生的消息的数量存在波动，比如当关注度较高的主播开播时，在短时间内可能会产生大量的消息需要被消费；这使得当中间服务的数量不足以处理大量的消息时，需要配置更多的中间服务的数量，以应对存在大量需要消费的消息等情况；而当短时间内产生的消息大幅减少时，可以停用部分的中间服务，由剩余的中间服务负责继续处理事件任务生产的消息。

然而，在例如上述的消息处理方案中，由于中间服务属于有状态服务，需要长期保持中间服务与事件任务之间的连接，而且事件任务需要将消息进行耦合封装后才能发送给中间服务进行消息，导致在例如对中间服务的数量等进行扩展时，需要人为的参与配置，并暂时断开中间服务与事件任务之间的连接，操作不够灵活。

为此，基于上述缺陷，本申请实施例提供的一种可能的实现方式为：在服务系统中运行事件任务、事件服务、消息队列集群以及事件消费服务，使得事件任务可以向事件服务发送事件消息；然后事件服务可以将接收的事件消息存储至消息队列集群中对应的消息队列；而事件消费服务则可以从消息队列集群中的消息队列获取事件消息进行消费，利用事件服务和消息队列集群将事件任务与事件消费服务进行解耦合，从而可以灵活的配置服务系统中事件服务和事件消费服务的数量，进而灵活的调整服务系统处理事件消息的能力。

下面结合附图，对本申请的一些实施方式作详细说明。在不冲突的情况下，下述的实施例及实施例中的特征可以相互组合。

请参阅图1，图1示出本申请实施例提供的服务系统的一种示意图，该服务系统可以为由多台服务器构成的服务集群，通过在服务系统中配置多个微服务，使得当不同的微服务之间进行信令交互时，执行本申请实施例提供的消息处理方法。

示例性地，如图1所示，服务系统中可以运行有事件任务、事件服务、消息队列集群以及事件消费服务。

如此，基于如图1所示的服务系统，请参阅图2，图2示出本申请实施例提供的消息处理方法的一种示意性流程图，可以包括以下步骤：

步骤101，事件任务向事件服务发送事件消息；

步骤102，事件服务将接收的事件消息存储至消息队列集群中对应的消息队列；

步骤103，事件消费服务从消息队列集群中的消息队列获取事件消息进行消费。

作为一种可能的实现方式，事件任务可以是互动直播事件、开播事件、送礼事件、消费事件、充值事件等等中的至少之一；事件任务可以用于产生事件消息并发送给事件服务，比如产生互动直播消息、开播消息等等，然后调用事件服务的RPC(Remote ProcedureCall，远程过程调用)接口将消息发送给事件服务，即：在该服务系统中，事件任务可以作为该服务系统中的消息生产者。

事件服务可以为无状态服务，即：事件服务无需跟事件任务或者是消息队列保持连接；当事件服务接收到事件消息时，事件服务可以按照事件消息的主题(topic)或者是标签(tag)，将该事件服务进行分布式投递，即：事件服务可以将事件消息存储至消息队列集群中与事件消息对应的消息队列；比如，事件服务可以将携带有topic为“充值”的事件消息存入消息队列集群中对应主题为“充值”的消息队列；如此，当由于事件任务产生事件消息的速度发生波动，比如事件消息的产生速度大幅增加或者是大幅减少，而需要调整对事件消息的处理能力时，可以灵活的配置事件服务的数量，以调整事件消息被存储至消息队列的速度，而无需人为参数配置各项参数或者断开有状态服务的连接等。

消息队列集群可以包括有多个消息队列，每一消息队列均可以对应至少一个topic，使得每一消息队列可以用于存储对应topic的事件消息。

事件消费服务也可以为无状态服务，即：事件消费服务无需跟消息队列保持连接；事件消费服务可以从消息队列获得事件消息进行消费，比如接收消息队列推流的事件消息或者是从指定的消息队列中拉取事件消息进行消费，从而完成各个事件任务处理；即：事件消费服务可以作为该服务系统中的消息消费者；如此，当消息队列接收事件服务发送的事件消息的速度产生波动，使得消息队列存储事件消息的速度产生波动时，比如消息队列存储事件消息的速度增加或者是减少，而需要调整对事件消息的消费能力时，可以灵活的配置事件消费服务的数量，以调整事件消息被消费的速度，而无需人为参数配置各项参数或者断开有状态服务的连接等。

其中，事件消费服务在拉取事件消息进行消费时，可以基于规则引擎配置的处理逻辑，对事件消息进行分类处理；比如对于携带有topic为“充值”的充值消息，可以根据每一充值消息的充值渠道进行不同的统计处理，以统一来自于不同充值渠道的累计充值额。

可见，基于上述设计，本申请实施例提供的消息处理方法，通过在服务系统中运行事件任务、事件服务、消息队列集群以及事件消费服务，使得事件任务可以向事件服务发送事件消息；然后事件服务可以将接收的事件消息存储至消息队列集群中对应的消息队列；而事件消费服务则可以从消息队列集群中的消息队列获取事件消息进行消费，相比于现有技术，利用事件服务和消息队列集群将事件任务与事件消费服务进行解耦合，从而可以灵活的配置服务系统中事件服务和事件消费服务的数量，进而灵活的调整服务系统处理事件消息的能力。

可以理解的是，图1所示的服务系统仅为示意，服务系统中还可以运行有比图1中所示更多或者更少的微服务，本申请实施例对于服务系统中运行的各个微服务数量以及类型不进行具体的限制。

如上所述，当事件任务产生事件消息的速度增加时，可以调整事件服务的数量，从而调整服务系统处理事件消息的能力。

为此，作为一种可能的实现方式，该服务系统中还可以运行有管理服务，该管理服务可以用于调整服务系统中事件服务的数量，从而调整服务系统处理事件消息的能力。

因此，请参阅图3，图3示出本申请实施例提供的消息处理方法在扩容时的一种示意性流程图，可以包括以下步骤：

步骤106，管理服务监听服务系统中运行事件服务的第一节点的负载状态；

步骤107，当第一节点的负载状态达到第一阈值时，管理服务在服务系统中除第一节点以外的节点启用新的事件服务；

步骤108，新的事件服务接收事件消息，并将接收的事件消息存储至消息队列集群中对应的消息队列。

在本申请实施例中，管理服务可以将服务系统中运行事件服务的服务器作为第一节点，然后监听第一节点的负载状态；当第一节点的负载状态达到第一阈值时，表征运行在第一节点中的事件服务当前消耗了较多的物理资源处理事件消息，即反映了事件任务生成的事件消息增多；此时管理服务可以在服务系统中除第一节点以外的节点启用新的事件服务。

如此，事件任务可以按照设定的策略，比如每30秒刷新一次事件服务列表，从而实时获得当前正在启用的所有事件服务，并按照设定的负载均衡策略，通过调用各个事件服务的RPC接口，将产生的事件消息发送给所有的事件服务；相应地，包括启用的新的事件服务在内的所有事件服务，在接收到事件消息后，则可以将接收的事件消息存储至消息队列集群中对应的消息队列，使得事件消息能够及时地被事件消费服务所消费。

相应地，当服务系统中启用了新的事件服务，事件服务将事件消息存入消息队列的速度得到了提升，即消息队列中存储事件消息的速度得到了提升；为使事件消息能够被及时消费，该管理服务还可以用于调整服务系统中事件消费服务的数量，从而调整服务系统消费事件消息的能力。

因此，请参阅图4，图4示出本申请实施例提供的消息处理方法在扩容时的另一种示意性流程图，可以包括以下步骤：

步骤111，管理服务监听服务系统中运行事件消费服务的第二节点的负载状态；

步骤112，当第二节点的负载状态达到第二阈值时，管理服务在服务系统中除第二节点之外的节点启用新的事件消费服务；

步骤113，新的事件消费服务从消息队列集群中的消息队列获取事件消息进行消费。

在本申请实施例中，管理服务可以将服务系统中运行事件消费服务的服务器作为第二节点，然后监听第二节点的负载状态；当第二节点的负载状态达到第二阈值时，表征运行在第二节点中的事件消费服务当前消耗了第二节点较多的物理资源消费事件消息，即反映了消息队列中待消费的事件消息增多；此时管理服务可以在服务系统中除第二节点以外的节点启用新的事件消费服务。

如此，启用的新的事件消费任务可以从消息队列集群中的消息队列获取事件消息进行消费，从而当需要消费的事件消息增多时，能够动态的提升服务系统消费消息的能力，确保事件消息能够被及时的消费。

另外，相对于事件消息大幅增加的情况，在本申请实施例其他一些可能的应用场景中，事件消息也存在大幅减少的情况；比如在上述网络直播等场景中，当关注度较高的主播关闭直播间时，直播平台上参与互动的用户减少，短时间内产生的事件消息也会减小。

因此，当该服务系统运行有多个事件服务时，为了避免当需要处理的事件消息较少时，服务系统因运行较多的事件服务而占用较多的物理资源，请参阅图5，图5示出本申请实施例提供的消息处理方法在缩容时的一种示意性流程图，可以包括以下步骤：

步骤116，管理服务获得单位处理速度；

步骤117，当单位处理速度小于第三阈值时，管理服务停用多个事件服务中的部分事件服务。

作为一种可能的实现方式，管理服务可以获取服务系统运行的每一事件任务产生事件消息的速度；比如在如图1所示的应用场景中，可以在服务系统中设置记录服务，该记录服务可以用于记录速度信息，该速度信息中记录有每一事件产生事件消息的速度；比如，该记录服务记录的速度信息可以表示如下：

互动直播事件：50条/秒；

开播事件：20条/秒；

送礼事件：200条/秒；

消费事件：140条/秒；

充值事件：130条/秒；

管理服务可以通过读取记录服务记录的速度信息，并按照均衡负载策略计算得到单位处理速度，该单位处理速度表征服务系统运行的多个事件服务中平均每一事件服务处理消息请求的速度；比如按照上述示例，在例如图1所示的场景中，服务系统运行有三个事件服务，则管理服务计算得到的单位处理速度为180条/秒。

如此，管理服务可以基于获得的单位处理速度，将该单位处理速度与第三阈值相比对，当单位处理速度大于或等于第三阈值时，表征每一事件服务需要处理的事件消息较多，无需减小运行的事件服务的数量；当单位处理速度小于第三阈值时，表征每一事件服务需要处理的事件消息较少，当前启用了较多了事件服务对事件消息进行处理，此时可以停用服务系统运行的多个事件服务中的部分事件服务，从而减少服务系统占用的物理资源，避免性能浪费。

其中，在例如基于分布式构建的服务系统中，为了保证服务系统的高可用性，即使需要处理的事件消息较少，也可以启用一定数量的事件服务，从而在确保服务系统的高可用性前提下，尽量的减少服务系统占用的物理资源。

为此，在图5的基础上，请参阅图6，图6示出图5中步骤117的子步骤的一种示意性流程图，作为一种可能的实现方式，步骤117可以包括以下子步骤：

步骤117-1，管理服务根据当前消息处理速度，获得第一需求数值；

步骤117-2，判断第一需求数值是否大于第四阈值；当为是时，执行步骤117-3；当为否时，步骤117-4；

步骤117-3，管理服务保留数量与第一需求数值相对应的事件服务；

步骤117-4，管理服务保留数量与第四阈值相对应的事件服务。

在本申请实施例中，管理服务可以将服务系统启用的所有事件服务的单位处理速度之和作为当前消息处理速度，该当前消息处理速度即表征的是服务系统当前处理消息的速度。

然后，管理服务可以根据该当前消息处理速度，获得第一需求数值，该第一需求数值表征满足该当前消息处理速度的事件服务的数量；比如，管理服务可以将该当前消息处理速度除以第三阈值，并将得到的结果取整，从而获得第一需求数值。

如此，管理服务可以将获得的第一需求数值与第四阈值相比对，该第四阈值表征保证服务系统高可用状态下运行事件服务的最少数量；当第一需求数值大于第四阈值时，表征管理服务保留的事件服务的数量能够满足服务系统高可用状态的需求，此时则保留数量与第一需求数值相对应的事件服务，而将其他的事件服务停用；反之，当第一需求数值小于或等于第四阈值时，表征管理服务保留的事件服务的数量不能满足服务系统高可用状态的需求，此时则保留数量与第四阈值相对应的事件服务。

相对地，当事件消息的产生大幅减少时，事件消费服务能够消费的事件消息也会减小。

因此，当该服务系统运行有多个事件消费服务时，为了避免当需要消费的事件消息较少时，服务系统因运行较多的事件消费服务而占用较多的物理资源，请参阅图7，图7示出本申请实施例提供的消息处理方法在缩容时的另一种示意性流程图，可以包括以下步骤：

步骤121，管理服务获得单位消费速度；

步骤122，当单位消费速度小于第五阈值时，管理服务停用多个事件消费服务中的部分事件消费服务。

作为一种可能的实现方式，管理服务可以获取服务系统运行的每一事件消费服务消费消息的速度；比如可以采用例如上述的记录服务，对每一事件消费服务消费消息的速度进行记录。

如此，管理服务可以通过读取记录服务记录的每一事件消费服务消费消息的速度并进行求和，然后将求和得到的结果除以运行的事件消费服务的数量，得到单位消费速度，该单位消费速度表征服务系统运行的多个事件消费服务中平均每一事件消费服务消费消息的速度。

然后，管理服务可以基于获得的单位消费速度，将该单位消费速度与第五阈值相比对，当单位消费速度大于或等于第五阈值时，表征每一事件消费服务需要消费的事件消息较多，无需减少运行的事件消费服务的数量；当单位消费速度小于第五阈值时，表征每一事件消费服务需要消费的事件消息较少，当前启用了较多的事件消费服务对事件消息进行消费，此时可以停用服务系统运行的多个事件消费服务中的部分事件消费服务，从而减少服务系统占用的物理资源，避免性能浪费。

并且，与上述对事件服务相同的停用策略，为了保证服务系统的高可用性，也可以设置第六阈值作为保证服务系统高可用状态下运行事件消费服务的最少数量。

为此，在图7的基础上，请参阅图8，图8示出图7中步骤122的子步骤的一种示意性流程图，作为一种可能的实现方式，步骤122可以包括以下子步骤：

步骤122-1，管理服务根据当前消费速度，获得第二需求数值；

步骤122-2，判断第二需求数值是否大于第六阈值；当为是时，执行步骤122-3；当为否时，执行步骤122-4；

步骤122-3，管理服务保留数量与第二需求数值相对应的事件消费服务；

步骤122-4，管理服务保留数量与第六阈值相对应的事件消费服务。

在本申请实施例中，管理服务可以将服务系统启用的所有事件消费服务的单位消费速度之和作为当前消费速度，该当前消费速度即表征的是服务系统当前消费消息的速度。

然后，管理服务可以根据该当前消费速度，获得第二需求数值，该第二需求数值表征满足该当前消费速度的事件消费服务的数量；比如，管理服务可以将该当前消费速度除以第五阈值，并将得到的结果取整，从而获得第二需求数值。

如此，管理服务可以将获得的第二需求数值与上述设置的第六阈值相比对，当第二需求数值大于第六阈值时，表征管理服务保留的事件消费服务的数量能够满足服务系统高可用状态的需求，此时则保留数量与第二需求数值相对应的事件消费服务，而将其他的事件消费服务停用；反之，当第二需求数值小于或等于第六阈值时，表征管理服务保留的事件消费服务的数量不能满足服务系统高可用状态的需求，此时则保留数量与第六阈值相对应的事件消费服务。

另外，在例如网络直播等应用场景中，事件消费服务消费消息的情况受环境影响，比如网络波动或者是接口报错等，都有可能导致事件消费服务消费事件消息失败。

为此，作为一种可能的实现方式，还可以为服务系统设置自动重试机制，将事件消费服务消费失败的消息重新置入消息队列中；当然，为避免消息因为被消费失败陷入无限重新置入消息队列死循环，还可以设置消息删除机制。

因此，请参阅图9，图9示出本申请实施例提供的消息处理方法的另一种示意性流程图，可以包括以下步骤：

步骤126，管理服务判断目标消息被消费失败的次数是否达到设定的次数阈值；当为否时，执行步骤127；当为是时，执行步骤128；

步骤127，管理服务将目标消息存储至对应的消息队列；

步骤128，管理服务删除目标消息。

以消息队列存储的所有消息中的之一作为目标消息为例，每当目标消息被事件消费服务消费失败时，管理服务即更新该目标消息被消费失败的次数，也就是将目标消息被消费失败的次数加一；然后，管理服务可以判断目标消息被消费失败的次数是否达到设定的次数阈值；当未达到时，管理服务可以将该目标消息存储至对应的消息队列，即：将目标消息重新置入消息队列中，等待后续的消费；当已达到时，管理服务则可以删除目标消息，从而避免目标消息陷入无限重新置入消息队列的死循环中，浪费服务系统的性能资源。

另外，服务系统在提供服务时，还可以为事件任务配置记录机制，由事件任务通过记录日志文件的形式，记录事件任务的工作状态；如此，当事件任务工作日常时，即可以通过读取日志文件的方式，获得事件任务工作异常的情况。

因此，作为一种可能的实现方式，请参阅图10，图10示出本申请实施例提供的消息处理方法的再一种示意性流程图，可以包括以下步骤：

步骤131，管理服务读取事件任务记录的日志文件；

步骤132，当管理服务读取到错误日志时，管理服务发出告警信息。

在本申请实施例中，管理服务可以读取事件任务记录的日志文件，以获得事件任务的工作状态；其中，当管理服务读取到错误日志时，表征事件任务当前工作异常，管理服务可以发出告警信息，以提醒对任务事件进行维护。

示例性地，以管理服务读取图1中的开播事件记录的日志文件为例，当管理服务读取到“开播事件”的日志文件中的错误日志时，管理服务可以发出告警信息，以提醒用户对“开播事件”这一事件任务进行维护。

其中，管理服务在执行步骤132时，作为一种可能的实现方式，管理服务可以根据错误日志的异常等级，采用与异常等级对应的告警途径发出告警信息。

比如，事件任务在记录错误日志时，还可以记录异常等级；并且，可以预先定义异常等级1对应的告警途径为“邮件通知”；异常等级2对应的告警途径为“短信通知”；异常等级3对应的告警途径为“IM消息通知”。

以上述“开播事件”为例，假定管理服务读取到“开播事件”的日志文件中的错误日志，且读取到的异常等级为“1”时，管理服务可以通过“邮件告知”的形式，通知对应的用户，“开播事件”出现了异常；或者，管理服务读取到“开播事件”的日志文件中的错误日志，且读取到的异常等级为“3”时，管理服务可以通过“IM消息通知”的形式，通过对应的用户，“开播事件”出现了异常。

需要说明的是，作为一种可能的实现方式，上述的管理服务可以是服务系统中的运行一个服务，也可以是服务系统中运行的多个服务的集合；比如在如图1所示的服务系统中，管理服务则可以为“监控服务”、“自动重试服务”及“告警服务”服务的集合。

当然，可以理解的是，图1仅为示意，在本申请实施例其他一些可能的应用场景中，当管理服务为服务系统中运行的多个服务的集合时，与图1示出的“监控服务”、“自动重试服务”及“告警服务”相比，管理服务还可以包括更多或者是更少的服务，本申请实施例对于管理服务包含的服务数量不进行限制。

另外，基于与本申请实施例提供的上述消息处理方法相同的发明构思，本申请实施例还提供一种如图1所示的服务系统，该服务系统运行有事件任务、事件服务、消息队列集群以及事件消费服务。

比如，可以由多台服务器构成服务集群作为该服务系统，每一服务器均可通过例如容器技术运行一个或多个微服务功能组件，每一服务器通过执各自运行的一个或多个微服务功能组件所对应的功能模块，实现例如上述事件任务、事件服务、构成消息队列集群的消息队列以及事件消费服务等中的至少一个的功能。其中：

所述事件任务用于，向所述事件服务发送事件消息；

所述事件服务用于，将接收的事件消息存储至所述消息队列集群中对应的消息队列；

所述事件消费服务用于，从所述消息队列集群中的消息队列获取事件消息进行消费。

可选地，作为一种可能的实现方式，所述服务系统还运行有管理服务；所述方法还包括：

所述管理服务监听所述服务系统中运行所述事件服务的第一节点的负载状态；

当所述第一节点的负载状态达到第一阈值时，所述管理服务还用于，在所述服务系统中除所述第一节点以外的节点启用新的事件服务；

所述新的事件服务接收事件消息，并将接收的事件消息存储至所述消息队列集群中对应的消息队列。

可选地，作为一种可能的实现方式，所述管理服务用于，监听所述服务系统中运行所述事件消费服务的第二节点的负载状态；

当所述第二节点的负载状态达到第二阈值时，所述管理服务还用于，在所述服务系统中除所述第二节点之外的节点启用新的事件消费服务；

所述新的事件消费服务从所述消息队列集群中的消息队列获取事件消息进行消费。

可选地，作为一种可能的实现方式，所述服务系统运行有多个事件服务；

所述管理服务还用于，获得单位处理速度；其中，所述单位处理速度为所述多个事件服务中平均每一事件服务处理消息请求的速度；

当所述单位处理速度小于第三阈值时，所述管理服务还用于，停用所述多个事件服务中的部分事件服务。

可选地，作为一种可能的实现方式，所述管理服务在停用所述多个事件服务中的部分事件服务时，具体用于：

所述管理服务根据当前消息处理速度，获得第一需求数值；其中，所述当前消息处理速度为所有事件服务的单位处理速度之和，所述第一需求数值表征满足所述当前消息处理速度的事件服务的数量；

当所述第一需求数值大于第四阈值时，所述管理服务保留数量与所述第一需求数值相对应的事件服务；

当所述第一需求数值小于或等于所述第四阈值时，所述管理服务保留数量与所述第四阈值相对应的事件服务。

可选地，作为一种可能的实现方式，所述服务系统运行有多个事件消费服务；

所述管理服务还用于，获得单位消费速度；其中，所述单位消费速度为所述多个事件消费服务中平均每一事件消费服务消费消息的速度；

当所述单位消费速度小于第五阈值时，所述管理服务还用于，停用所述多个事件消费服务中的部分事件消费服务。

可选地，作为一种可能的实现方式，所述管理服务在停用所述多个事件消费服务中的部分事件消费服务时，具体用于：

所述管理服务根据当前消费速度，获得第二需求数值；其中，所述当前消费速度为所有事件消费服务的单位消费速度之和，所述第二需求数值表征满足所述当前消费速度的事件消费服务的数量；

当所述第二需求数值大于第六阈值时，所述管理服务保留数量与所述第二需求数值相对应的事件消费服务；

当所述第二需求数值小于或等于所述第六阈值时，所述管理服务保留数量与所述第六阈值相对应的事件消费服务。

可选地，作为一种可能的实现方式，所述管理服务还用于，判断目标消息被消费失败的次数是否达到设定的次数阈值；其中，所述目标消息为消息队列存储的所有消息中的之一；

当未达到时，所述管理服务还用于将所述目标消息存储至对应的消息队列；

当达到时，所述管理服务还用于，删除所述目标消息。

可选地，作为一种可能的实现方式，所述管理服务还用于，读取所述事件任务记录的日志文件；

当所述管理服务读取到错误日志时，所述管理服务还用于，发出告警信息。

可选地，作为一种可能的实现方式，所述管理服务在发出告警信息时，具体用于：

所述管理服务根据所述错误日志的异常等级，采用与所述异常等级对应的告警途径发出所述告警信息。

以上所述仅为本申请的部分实施例而已，并不用于限制本申请，对于本领域的技术人员来说，本申请可以有各种更改和变化。凡在本申请的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本申请的保护范围之内。

对于本领域技术人员而言，显然本申请不限于上述示范性实施例的细节，而且在不背离本申请的精神或基本特征的情况下，能够以其它的具体形式实现本申请。因此，无论从哪一点来看，均应将实施例看作是示范性的，而且是非限制性的，本申请的范围由所附权利要求而不是上述说明限定，因此旨在将落在权利要求的等同要件的含义和范围内的所有变化囊括在本申请内。不应将权利要求中的任何附图标记视为限制所涉及的权利要求。

Claims (11)

1.一种消息处理方法，其特征在于，应用于服务系统，所述服务系统运行有事件任务、事件服务、消息队列集群以及事件消费服务；所述方法包括：

所述事件任务向所述事件服务发送事件消息；

所述事件服务将接收的事件消息存储至所述消息队列集群中对应的消息队列；

所述事件消费服务从所述消息队列集群中的消息队列获取事件消息进行消费。

2.如权利要求1所述的方法，其特征在于，所述服务系统还运行有管理服务；所述方法还包括：

所述管理服务监听所述服务系统中运行所述事件服务的第一节点的负载状态；

当所述第一节点的负载状态达到第一阈值时，所述管理服务在所述服务系统中除所述第一节点以外的节点启用新的事件服务；

所述新的事件服务接收事件消息，并将接收的事件消息存储至所述消息队列集群中对应的消息队列。

3.如权利要求1所述的方法，其特征在于，所述服务系统还运行有管理服务；所述方法还包括：

所述管理服务监听所述服务系统中运行所述事件消费服务的第二节点的负载状态；

当所述第二节点的负载状态达到第二阈值时，所述管理服务在所述服务系统中除所述第二节点之外的节点启用新的事件消费服务；

所述新的事件消费服务从所述消息队列集群中的消息队列获取事件消息进行消费。

4.如权利要求1所述的方法，其特征在于，所述服务系统运行有多个事件服务；所述服务系统还运行有管理服务；所述方法还包括：

所述管理服务获得单位处理速度；其中，所述单位处理速度为所述多个事件服务中平均每一事件服务处理消息请求的速度；

当所述单位处理速度小于第三阈值时，所述管理服务停用所述多个事件服务中的部分事件服务。

5.如权利要求4所述的方法，其特征在于，所述管理服务停用所述多个事件服务中的部分事件服务的步骤，包括：

所述管理服务根据当前消息处理速度，获得第一需求数值；其中，所述当前消息处理速度为所有事件服务的单位处理速度之和，所述第一需求数值表征满足所述当前消息处理速度的事件服务的数量；

当所述第一需求数值大于第四阈值时，所述管理服务保留数量与所述第一需求数值相对应的事件服务；

当所述第一需求数值小于或等于所述第四阈值时，所述管理服务保留数量与所述第四阈值相对应的事件服务。

6.如权利要求1所述的方法，其特征在于，所述服务系统运行有多个事件消费服务；所述服务系统还运行有管理服务；所述方法还包括：

所述管理服务获得单位消费速度；其中，所述单位消费速度为所述多个事件消费服务中平均每一事件消费服务消费消息的速度；

当所述单位消费速度小于第五阈值时，所述管理服务停用所述多个事件消费服务中的部分事件消费服务。

7.如权利要求6所述的方法，其特征在于，所述管理服务停用所述多个事件消费服务中的部分事件消费服务的步骤，包括：

所述管理服务根据当前消费速度，获得第二需求数值；其中，所述当前消费速度为所有事件消费服务的单位消费速度之和，所述第二需求数值表征满足所述当前消费速度的事件消费服务的数量；

当所述第二需求数值大于第六阈值时，所述管理服务保留数量与所述第二需求数值相对应的事件消费服务；

当所述第二需求数值小于或等于所述第六阈值时，所述管理服务保留数量与所述第六阈值相对应的事件消费服务。

8.如权利要求1所述的方法，其特征在于，所述服务系统还运行有管理服务；所述方法还包括：

所述管理服务判断目标消息被消费失败的次数是否达到设定的次数阈值；其中，所述目标消息为消息队列存储的所有消息中的之一；

当未达到时，所述管理服务将所述目标消息存储至对应的消息队列；

当达到时，所述管理服务删除所述目标消息。

9.如权利要求1所述的方法，其特征在于，所述服务系统还运行有管理服务，所述方法还包括：

所述管理服务读取所述事件任务记录的日志文件；

当所述管理服务读取到错误日志时，所述管理服务发出告警信息。

10.如权利要求9所述的方法，其特征在于，所述管理服务发出告警信息的步骤，包括：

所述管理服务根据所述错误日志的异常等级，采用与所述异常等级对应的告警途径发出所述告警信息。

11.一种服务系统，其特征在于，所述服务系统运行有事件任务、事件服务、消息队列集群以及事件消费服务；

所述事件任务用于，向所述事件服务发送事件消息；

所述事件服务用于，将接收的事件消息存储至所述消息队列集群中对应的消息队列；

所述事件消费服务用于，从所述消息队列集群中的消息队列获取事件消息进行消费。

Images