CN114615284A - 集群内消息通知方法、接收方法及装置 - Google Patents

Abstract

本公开提供一种集群内消息通知方法、接收方法及装置，该方法包括：每一微服务器根据从注册中心获取的消息通知服务列表向包括于所述消息服务通知列表的至少一个微服务器广播消息；其中，所述消息通知服务列表为所述注册中心根据每一所述微服务器及其对应的地址信息生成。该方法可以减少接入成本及维护成本。

Description

集群内消息通知方法、接收方法及装置

技术领域

本公开涉及云计算技术领域，尤其涉及一种集群内消息通知方法、接收方法及装置。

背景技术

当前微服务下，集群内消息通知依赖于各消息中间件，如消息队列、或者是可借助特定机制，来实现消息通知，又或者是通过定时数据同步来进行消息同步。然而现有技术至少存在如下问题：微服务环境下需要实现如消息集群管理、高可用等功能时，对于轻量消息通知的接入来讲，集群内消息通知依赖于各消息中间件有着较高的维护成本及接入成本。

发明内容

针对现有技术存在的问题，本公开实施例提供一种集群内消息通知方法、接收方法及装置。

第一方面，本公开提供一种集群内消息通知方法，包括：每一微服务器根据从注册中心获取的消息通知服务列表向包括于所述消息服务通知列表的至少一个微服务器广播消息；其中，所述消息通知服务列表为所述注册中心根据每一所述微服务器及其对应的地址信息生成。

根据本公开提供的一种集群内消息通知方法，所述方法还包括：根据所述注册中心定时推送的消息通知服务列表对每一所述微服务器内的当前消息通知服务列表进行更新；和/或每一所述微服务器定时访问所述注册中心重新获取更新后的消息通知服务列表。

根据本公开提供的一种集群内消息通知方法，所述消息包括消息主题和承载消息内容的消息体；所述消息主题用于接收消息的微服务器对监听到的多个消息进行基于本地预设关注主题的过滤。

根据本公开提供的一种集群内消息通知方法，所述消息还包括消息ID；所述向包括于所述消息服务通知列表的至少一个微服务器广播消息之前，还包括：根据当前消息的消息ID，判断所述当前消息是否已经发送，并在已经发送的情况下，结束所述当前消息的发送。

根据本公开提供的一种集群内消息通知方法，在所述当前消息未发送的情况下，在所述向包括于所述消息服务通知列表的至少一个微服务器广播消息之前还包括：确认发送所述当前消息的微服务器已向所述注册中心进行消息通知服务注册。

根据本公开提供的一种集群内消息通知方法，在向包括于所述消息服务通知列表的至少一个微服务器广播消息后，还包括：获取消息发送结果；在确认所述发送结果为失败后，启动消息的同步重试发送；或，将发送失败的消息存储至异常消息发送队列中，并根据预先设定的时间间隔从所述异常消息发送队列中取出发送失败的消息，再次异步启动广播重试发送。

第二方面，本公开提供一种集群内消息接收方法，包括：每一微服务器根据从注册中心获取的消息通知服务列表监听包括于所述消息服务通知列表的至少一个微服务器所广播的消息；其中，

所述消息通知服务列表为所述注册中心根据每一所述微服务器及其对应的地址信息生成。

根据本公开提供的一种集群内消息接收方法，所述消息包括消息主题和用于承载消息内容的消息体；所述方法还包括，根据本地预设关注主题，对监听所获取的消息的消息主题进行匹配，获取所述关注主题下的消息的消息体。

根据本公开提供的一种集群内消息接收方法，所述消息还包括消息ID；在获取所述关注主题下的消息的消息体后，所述方法还包括，对所述消息体所关联的消息ID进行记录。

根据本公开提供的一种集群内消息接收方法，所述获取所述关注主题下的消息的消息体后，还包括：依据所述消息体内容，对所述消息进行处理；若判断消息处理不成功，则将该消息存入异常消息处理队列，并定时从所述异常消息处理队列中取出并再次执行消息处理操作。

第三方面，本公开还提供一种集群内消息通知装置，应用于包括注册中心以及多个微服务器的集群，该装置包括广播模块，其中，广播模块，用于每一所述微服务器根据从所述注册中心获取的消息通知服务列表向包括于所述消息服务通知列表的至少一个微服务器广播消息；其中，所述消息通知服务列表为所述注册中心根据每一所述微服务器及其对应的地址信息生成。

第四方面，本公开还提供一种集群内消息接收装置，应用于包括注册中心以及多个微服务器的集群，该装置包括监听模块，其中，监听模块，用于每一所述微服务器根据从所述注册中心获取的消息通知服务列表监听包括于所述消息服务通知列表的至少一个微服务器所广播的消息；其中，所述消息通知服务列表为所述注册中心根据每一所述微服务器及其对应的地址信息生成。

第五方面，本公开还提供一种电子设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，所述处理器执行所述程序时实现如上述任一种所述集群内消息通知方法的步骤。

第六方面，本公开还提供一种电子设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，所述处理器执行所述程序时实现如上述任一种所述集群内消息接收方法的步骤。

第七方面，本公开还提供一种非暂态计算机可读存储介质，其上存储有计算机程序，该计算机程序被处理器执行时实现如上述任一种所述集群内消息通知方法的步骤。

第八方面，本公开还提供一种非暂态计算机可读存储介质，其上存储有计算机程序，该计算机程序被处理器执行时实现如上述任一种所述集群内消息接收方法的步骤。

第九方面，本公开还提供一种计算机程序产品，包括计算机程序，所述计算机程序被处理器执行时实现如上述任一种所述集群内消息通知方法的步骤。

第十方面，本公开还提供一种计算机程序产品，包括计算机程序，所述计算机程序被处理器执行时实现如上述任一种所述集群内消息接收方法的步骤。

本公开提供的集群内消息通知、接收及传输方法及装置，通过每一微服务器根据从注册中心获取的消息通知服务列表向包括于所述消息服务通知列表的至少一个微服务器广播消息；其中，所述消息通知服务列表为所述注册中心根据每一所述微服务器及其对应的地址信息生成。微服务器可以根据消息通知服务列表向包括于所述消息服务通知列表的至少一个微服务器直接广播消息，而不用依赖于各消息中间件或者是借助特殊机制，来实现消息通知，也不用通过定时数据同步来进行消息同步，降低了维护成本及接入成本。

附图说明

为了更清楚地说明本公开或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作一简单地介绍，显而易见地，下面描述中的附图是本公开的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1是本公开提供的集群内消息通知、接收及传输方法的系统架构图；

图2是本公开提供的集群内消息通知方法的流程示意图；

图3a是本公开提供的集群内消息通知方法中的消息通知服务列表获取的步骤流程示意图；

图3b是本公开提供的集群内消息通知方法的具体实施例的流程示意图；

图4是本公开提供的集群内消息通知装置的结构示意图；

图5a是本公开提供的集群内消息接收方法的流程示意图；

图5b是本公开提供的集群内消息通知方法的具体实施例的流程示意图；

图6是本公开提供的集群内消息接收装置的结构示意图；

图7是本公开提供的电子设备的结构示意图。

具体实施方式

为使本公开实施例的目的、技术方案和优点更加清楚，下面将结合本公开实施例中的附图，对本公开实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本公开实施例一部分实施例，而不是全部的实施例。基于本公开实施例中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本公开实施例保护的范围。

微服务是指由单一应用程序构成的小服务。每个微服务拥有自己的进程，其可以通过轻量级通信机制，例如基于超文本传输协议的应用程序编程接口，实现与其他微服务的通信。

微服务架构是一种将应用(尤其是大型应用，如电商系统)拆分成若干个微服务的架构，例如，具有较低侵入性的Spring Cloud、Dubbo等经典架构。与传统单体架构将所有功能服务集中在一个容器相比，微服务架构通过将功能分解到各个离散的服务中，实现了业务解耦。每个业务团队分别维护各自业务对应的微服务，降低了维护复杂度，提高了维护效率。而且单个微服务出现故障时，其他微服务仍可继续工作，提高了系统稳定性。

当前微服务架构下，在集群内部，集群消息的通知依赖于各种消息中间件，例如：

(1)通过MQ消息队列、Redis消息队列实现消息通知；

(2)借助类似Zookeeper的watcher机制，实现消息通知；

(3)通过定时数据同步来进行消息同步。

上述解决方案，虽然都实现了集群内的消息通知功能，但由于消息队列的引入，导致整个微服务体系架构系统的复杂性增加，例如，需要引入的消息队列具有高可用性，能够提供现成的支持，而不是自己写代码手动去实现；需要考虑消息队列中的数据存储方式，诸如存储位置(磁盘或数据库等)、同步存储或是异步存储；各个微服务如何获得消息队列中的数据，如何避免消息的重复消费，如何保证消息是绝对有顺序。

也就是说，由于各种消息中间件的引入，需要诸如消息集群管理等等功能的配合，这对于消息的接入(尤其是轻量级消息的接入)而言，存在较高的接入成本及维护成本。

参照图1，为本公开集群内消息通知、接收及传输方法的系统架构图。图1所示的系统架构包括包含注册中心12和多个微服务器14。

在实际应用时，微服务器14通常为计算设备，服务器、个人计算机以及其他终端，可以为物理机，也可以是经过虚拟化后的虚拟机。每一微服务器14包括一个或多个处理器、存储器、通信接口，各组成通过总线连接。每一微服务器14上部署有不同的微服务，实现不同的功能。当然，微服务器14也可以借助于多个计算设备形成的集群实现一个微服务功能。

其中的注册中心12也为计算设备，可以为由一台物理计算机，也可以是由多台服务器组成的服务集群。注册中心12可以是只占用一台计算机的一部分，也可以是分别占用多台计算机的各自的一部分或全部的虚拟集群服务器。在本公开中，注册中心12记录有微服务器和服务地址的映射关系，作为消息生产方的某一微服务14可以通过从注册中心12获取的上述映射关系向其他微服务广播消息通知，相应地，作为消息消费方的其他微服务器14可以也可以通过从注册中心获取的上述映射关系监听消息通知。

本公开实施例提供一种集群内消息通知方法，该实施例从作为消息生产方的微服务器对集群内消息通知方法进行说明，具体包括：

每一微服务器根据从注册中心获取的消息通知服务列表向包括于消息服务通知列表的至少一个微服务器广播消息；其中，消息通知服务列表为注册中心根据每一微服务器及其对应的地址信息生成。

参照图2，上述方法可以通过如下步骤执行：

步骤S201、从注册中心获取消息通知服务列表。

该步骤中，消息通知服务列表中包含微服务器获取时已在注册中心注册过的所有微服务器及其对应地址。

步骤S203、依据消息通知服务列表，向包括于消息服务通知列表的至少一个微服务器广播消息。

具体来说，广播，指微服务器向一个或多个微服务器发送消息，在具体实施中，可以为向集群内消息通知服务列表上除自身外所有微服务器发送消息。

本公开实施例提供的集群内消息通知方法，通过每一微服务器根据从注册中心获取的消息通知服务列表向包括于消息服务通知列表的至少一个微服务器广播消息；其中，消息通知服务列表为注册中心根据每一微服务器及其对应的地址信息生成。微服务器可以根据消息通知服务列表向包括于消息服务通知列表的至少一个微服务器直接广播消息，而不用依赖于各消息中间件如MQ消息、Redis的消息队列、或者是可借助类似Zookeeper的watcher机制，来实现消息通知，也不用通过定时数据同步来进行消息同步，降低了维护成本及接入成本。

在一个优选实施例中，参照图3a，消息通知服务列表可以通过如下步骤获取：

步骤S2011、初始化消息通知服务；

步骤S2013、获取注册中心的地址；

步骤S2015、基于注册中心的地址，向注册中心注册消息通知服务。

对于本领域技术人员所习知的是，在注册时，也需要获取所述注册中心预先存储的消息发送协议，或者称为消息发送配置信息。

在一个优选实施例中，步骤S2015中的注册消息通知服务具体包括：

步骤S20151、发送当前微服务器的地址；

步骤S20153、获取注册中心基于集群内每一微服务提供的地址所形成的消息通知服务列表。

在具体实施中，以第i个微服务器向注册中心注册消息通知服务为例，解释说明第i个微服务器如何注册消息通知服务，首先，在第i个微服务器注册消息通知服务前，可以理解的是，已经有i-1个微服务器已经向注册中心注册过消息通知服务，第i个微服务器获取注册中心的地址，并基于注册中心的地址向注册中心发送其对应的地址，即第i个微服务器对应的地址。注册中心在收到第i个微服务器对应的地址后，基于第i个微服务器对应的地址基于之前收到的i-1个微服务器对应的地址，形成消息通知服务列表。此时的消息通知服务列表中在具体实施中可以包含i个微服务器编号以及每一微服务器对应的地址。注册中心基于第i个微服务器发送的第i个微服务器对应的地址，发送消息通知服务列表给第i个微服务器。与此同时，对于本领域技术人员所习知的是，在注册时，也需要获取注册中心预先存储的消息发送协议，或者称为消息发送配置信息，以支持各个微服务器之间的通信。

在一个可选实施例中，集群内消息通知方法还包括：

对每一微服务器内的当前消息通知服务列表进行定时更新。

具体来说，由于微服务器根据消息通知服务列表中包含的微服务器广播消息，若之前已经获取到消息通知服务列表的微服务器长时间不更新消息通知服务列表，则新增的，已经在注册中心注册过的微服务器在该微服务器获取得到的消息通知服务列表不存在，两个微服务器之间无法进行信息收发，或者当微服务器不再处理对应的微服务或该微服务器存在故障时，再向该微服务器发送消息或接收该微服务器发送的消息会造成资源浪费，因此，需要对注册中心注册过的集群内的每一微服务器内的当前消息通知服务列表进行定时更新。

在一个优选实施例中，对每一微服务器内的当前消息通知服务列表进行定时更新，可以为：

根据注册中心定时推送的消息通知服务列表对每一微服务器内的当前消息通知服务列表进行更新。

具体来说，注册中心可以定时依据最新的消息通知服务列表中的每一微服务器对应地址，向每一微服务器推送最新的消息通知服务列表，以保证消息通知服务列表中的各个微服务器可以向消息通知服务列表中的至少一个微服务器进行广播。

在一个优选实施例中，对每一微服务器内的当前消息通知服务列表进行定时更新，还可以为：每一微服务器定时访问注册中心重新获取更新后的消息通知服务列表。

具体来说，微服务器获取到消息通知服务列表后，可以设定该微服务器定时访问注册中心重新获取更新后的消息通知服务列表，如每隔5分钟便访问一次注册中心以获取更新后的消息通知服务列表。

在一种具体实施例中，也可以同时采用上述两种方式对每一微服务器内的当前消息通知服务列表进行定时更新，以更及时的更新每一微服务器内的当前消息通知服务列表，即对每一微服务器内的当前消息通知服务列表进行定时更新既包括根据注册中心定时推送的消息通知服务列表对每一微服务器内的当前消息通知服务列表进行更新，也包括每一微服务器定时访问注册中心重新获取更新后的消息通知服务列表。

在一个实施例中，消息包括消息主题和承载消息内容的消息体；消息主题用于接收消息的微服务器对监听到的多个消息进行基于本地预设关注主题的过滤。

接收消息的微服务器对监听到的多个消息进行基于本地预设关注主题的过滤，以保证本地预设关注主题的信息被处理，而其监听到的非本地预设关注主题的信息则不进行处理。

除消息主题和承载消息内容的消息体外，消息还包括消息ID。因消息ID具有唯一性，可以方便获悉当前待广播通知的消息是否已经发送。参照图3b,在一个具体实施例中，可以通过如下步骤实现：

步骤S3011、消息内容初始化，设置消息ID、消息主题和消息内容。

步骤S3012、根据当前消息的消息ID，判断当前消息是否已经发送。

具体来说，若当前消息未发送，则在已经发送的情况下，结束当前消息的发送。在当前消息未发送的情况下，执行步骤S3013。

步骤S3013、确认发送当前消息的微服务器已向注册中心进行消息通知服务注册。

具体来说，若发送当前消息的微服务器未向注册中心进行消息通知服务注册，则微服务器先向注册中心进行消息通知服务注册，在进行消息发送。

步骤S3014、根据从注册中心获取的消息通知服务列表向包括于消息服务通知列表的至少一个微服务器广播消息。

步骤S3015、获取消息发送结果。

具体来说，消息发送结果有两种，一种为消息发送成功，另一种为消息发送失败，若消息发送结果为消息发送成功则，结束当前消息的发送。

步骤S3016、在确认发送结果为失败后，启动消息发送重试。

消息发送重试可以为同步重试发送；或，可以为将发送失败的消息存储至异常消息发送队列中，并根据预先设定的时间间隔从异常消息发送队列中取出发送失败的消息，再次异步启动广播重试发送。或使用上述两种方式共同实现。

具体来说，同步的含义的是，确认发送结果为失败，立即启动重发。相对应的，异步的含义是，先将确认发送结果为失败的消息存储至异常消息发送队列中，根据预设的时间对发送错误的消息启动重发。在具体实施中，也可以先启动消息的同步重试发送，在同步重试发送失败的情况下，将发送失败的消息存储至异常消息发送队列中，并根据预先设定的时间间隔从异常消息发送队列中取出发送失败的消息，再次异步启动广播重试发送。这样，若只是短暂的消息无法发送，同步重试发送实时性更好，若实施中出现消息无法发送持续时间较长，不断同步重试发送为徒劳，可将发送失败的消息存储至异常消息发送队列中，并根据预先设定的时间间隔从异常消息发送队列中取出发送失败的消息，再次异步启动广播重试发送。这样组合应用在保证了每条消息均可以发出的情况下，对资源应用更合理。

下面对本公开实施例提供的集群内消息通知装置进行描述，下文描述的集群内消息通知装置与上文描述的集群内消息通知方法可相互对应参照。

参照图4，本公开实施例提供一种集群内消息通知装置，设置于消息发送方，即消息生产方的微服务器内，包括广播模块40，其中，广播模块40用于每一微服务器根据从注册中心获取的消息通知服务列表向包括于消息服务通知列表的至少一个微服务器广播消息；其中，消息通知服务列表为注册中心根据每一微服务器及其对应的地址信息生成。

具体来说，消息通知服务列表中包含微服务器获取时已在注册中心注册过的所有微服务器及其对应地址。

本公开实施例提供的集群内消息通知装置，广播模块40通过每一微服务器根据从注册中心获取的消息通知服务列表向包括于消息服务通知列表的至少一个微服务器广播消息；其中，消息通知服务列表为注册中心根据每一微服务器及其对应的地址信息生成。微服务器可以根据消息通知服务列表向包括于消息服务通知列表的至少一个微服务器直接广播消息，而不用依赖于各消息中间件如MQ消息、Redis的消息队列、或者是可借助类似Zookeeper的watcher机制，来实现消息通知，也不用通过定时数据同步来进行消息同步，降低了维护成本及接入成本。

在一个优选实施例中，消息通知服务列表可以通过如下方式获取：初始化消息通知服务，获取注册中心的地址，基于注册中心的地址，向注册中心注册消息通知服务。对于本领域技术人员所习知的是，在注册时，也需要获取所述注册中心预先存储的消息发送协议，或者称为消息发送配置信息。

在一个优选实施例中，注册消息通知服务具体包括：发送当前微服务器的地址，获取注册中心基于集群内每一微服务提供的地址所形成的消息通知服务列表。

在一个可选实施例中，集群内消息通知装置还包括：

更新模块42，用于对每一微服务器内的当前消息通知服务列表进行定时更新。

具体来说，由于微服务器根据消息通知服务列表中包含的微服务器广播消息，若之前已经获取到消息通知服务列表的微服务器长时间不更新消息通知服务列表，则新增的，已经在注册中心注册过的微服务器在该微服务器获取得到的消息通知服务列表不存在，两个微服务器之间无法进行信息收发，或者当微服务器不再处理对应的微服务或该微服务器存在故障时，再向该微服务器发送消息或接收该微服务器发送的消息会造成资源浪费，因此，需要对注册中心注册过的集群内的每一微服务器内的当前消息通知服务列表进行定时更新。

在一个优选实施例中，更新模块42用于对每一微服务器内的当前消息通知服务列表进行定时更新定时更新可以为，用于根据注册中心定时推送的消息通知服务列表对每一微服务器内的当前消息通知服务列表进行更新。

具体来说，注册中心可以定时依据最新的消息通知服务列表中的每一微服务器对应地址，向每一微服务器推送最新的消息通知服务列表，以保证消息通知服务列表中的各个微服务器可以向消息通知服务列表中的至少一个微服务器进行广播。

在一个优选实施例中，更新模块42用于对每一微服务器内的当前消息通知服务列表进行定时更新可以为，用于每一微服务器定时访问注册中心重新获取更新后的消息通知服务列表。

具体来说，微服务器获取到消息通知服务列表后，可以设定该微服务器定时访问注册中心重新获取更新后的消息通知服务列表，如每隔5分钟便访问一次注册中心以获取更新后的消息通知服务列表。

在一种具体实施例中，也可以同时采用上述两种方式对每一微服务器内的当前消息通知服务列表进行定时更新，以更及时的更新每一微服务器内的当前消息通知服务列表，即对每一微服务器内的当前消息通知服务列表进行定时更新既包括根据注册中心定时推送的消息通知服务列表对每一微服务器内的当前消息通知服务列表进行更新，也包括每一微服务器定时访问注册中心重新获取更新后的消息通知服务列表。

在一种实施例中，消息包括消息主题和承载消息内容的消息体；消息主题用于接收消息的微服务器对监听到的多个消息进行基于本地预设关注主题的过滤。

接收消息的微服务器对监听到的多个消息进行基于本地预设关注主题的过滤，以保证本地预设关注主题的信息被处理而其监听到的非本地预设关注主题的信息，则不进行处理。

除消息主题和承载消息内容的消息体外，消息还包括消息ID。因消息ID具有唯一性，可以方便获悉当前待广播通知的消息是否已经发送。在一个具体实施例中，广播模块40具体包括：

判断单元401，用于根据当前消息的消息ID，判断当前消息是否已经发送。

具体来说，若当前消息未发送，则在已经发送的情况下，结束当前消息的发送。在当前消息未发送的情况下，执行确认单元403。

确认单元403，用于确认发送当前消息的微服务器已向注册中心进行消息通知服务注册。

具体来说，若发送当前消息的微服务器未向注册中心进行消息通知服务注册，则微服务器先向注册中心进行消息通知服务注册，在进行消息发送。

广播单元405，用于根据从注册中心获取的消息通知服务列表向包括于消息服务通知列表的至少一个微服务器广播消息。

获取单元407，用于获取消息发送结果。

具体来说，消息发送结果有两种，一种为消息发送成功，另一种为消息发送失败，若消息发送结果为消息发送成功则，结束当前消息的发送。

重发单元409，用于在确认发送结果为失败后，启动消息发送重试。

消息发送重试可以为同步重试发送；或，可以为将发送失败的消息存储至异常消息发送队列中，并根据预先设定的时间间隔从异常消息发送队列中取出发送失败的消息，再次异步启动广播重试发送。或使用上述两种方式共同实现。

具体来说，同步的含义的是，确认发送结果为失败，立即启动重发。相对应的，异步的含义是，先将确认发送结果为失败的消息存储至异常消息发送队列中，根据预设的时间对发送错误的消息启动重发。在具体实施中，也可以先启动消息的同步重试发送，在同步重试发送失败的情况下，将发送失败的消息存储至异常消息发送队列中，并根据预先设定的时间间隔从异常消息发送队列中取出发送失败的消息，再次异步启动广播重试发送。这样，若只是短暂的消息无法发送，同步重试发送实时性更好，若实施中出现消息无法发送持续时间较长，不断同步重试发送为徒劳，可将发送失败的消息存储至异常消息发送队列中，并根据预先设定的时间间隔从异常消息发送队列中取出发送失败的消息，再次异步启动广播重试发送。这样组合应用在保证了每条消息均可以发出的情况下，对资源应用更合理。

本公开实施例还提供一种集群内消息接收方法，该实施例从作为消息接收方的微服务器对集群内消息接收方法进行说明。具体包括：

每一微服务器根据从注册中心获取的消息通知服务列表监听包括于消息服务通知列表的至少一个微服务器所广播的消息；其中，消息通知服务列表为注册中心根据每一微服务器及其对应的地址信息生成。

参照图5a，该方法可以通过如下步骤执行：

步骤S501、从注册中心获取消息通知服务列表。

该步骤中的消息通知服务列表中包含微服务器获取时已在注册中心注册过的所有微服务器及其对应地址。

步骤S503、依据消息通知服务列表，监听包括于消息服务通知列表的至少一个微服务器所广播的消息。

该步骤中的监听是指时刻关注消息通知服务列表中除自身以外的微服务器是否有广播信息。

本公开实施例提供的集群内消息接收方法，以作为信息接收端的微服务器作为执行主体，通过每一微服务器根据从注册中心获取的消息通知服务列表监听包括于消息服务通知列表的至少一个微服务器所广播的消息；其中，消息通知服务列表为注册中心根据每一微服务器及其对应的地址信息生成。微服务器可以通过监听包括于消息服务通知列表的至少一个微服务器所广播的消息，而不用依赖于各消息中间件如MQ消息、Redis的消息队列、或者是可借助类似Zookeeper的watcher机制，来实现消息通知，也不用通过定时数据同步来进行消息同步，降低了维护成本及接入成本。

在一种可选实施例中，消息包括消息主题和用于承载消息内容的消息体；集群内消息接收方法还包括：

根据本地预设关注主题，对监听所获取的消息的消息主题进行匹配，获取关注主题下的消息的消息体。

具体来说，在消息仅包括消息主题和用于承载消息内容的消息体的情况下，根据本地预设关注主题，对监听所获取的消息的消息主题进行匹配可以在监听所获取的消息筛选出本地预设关注主题对应的消息，即该微服务器所需处理的消息。

进一步地，除消息主题和承载消息内容的消息体外，消息还包括消息ID。在获取关注主题下的消息的消息体后，集群内消息接收方法还包括：

对消息体所关联的消息ID进行记录。

具体来说，在消息包括消息主题、消息ID和用于承载消息内容的消息体的情况下，消息ID用于鉴别是否有重复消息发送，在确定该消息除本次外未曾被获取后，根据本地预设关注主题，对监听所获取的消息的消息主题进行匹配可以在监听所获取的消息筛选出本地预设关注主题对应的消息，即该微服务器所需处理的消息。

进一步地，参照图5b，在一种优选实施例中，集群内消息接收方法具体包括：

步骤S511、初始化消息通知服务。

步骤S513、基于获取到的注册中心地址，向注册中心注册消息通知服务，以获取消息通知服务列表。

该步骤中的消息通知服务列表中包含微服务器获取时已在注册中心注册过的所有微服务器及其对应地址。

步骤S515、根据本地预设关注主题，对基于消息通知服务列表监听所获取的消息的消息主题进行匹配，获取关注主题下的消息的消息体，并对消息体所关联的消息ID进行记录。

该步骤消息ID用于鉴别是否有重复消息发送，在确定该消息除本次外未曾被获取后，根据本地预设关注主题，对监听所获取的消息的消息主题进行匹配可以在监听所获取的消息筛选出本地预设关注主题对应的消息，即该微服务器所需处理的消息。

步骤S517、依据消息体内容，对消息进行处理。

该步骤中的处理指基于消息体获取消息体所承载的消息内容。

步骤S519、若判断消息处理不成功，则将该消息存入异常消息处理队列，并定时从异常消息处理队列中取出并再次执行消息处理操作。

具体来说，消息处理不成功即无法获悉消息体所承载的消息内容。定时从异常消息处理队列中取出并再次执行消息处理操作保证了需要处理的消息不会因为处理失败而丢弃或不被处理。下面对本公开实施例提供的集群内消息接收装置进行描述，下文描述的集群内消息接收装置与上文描述的集群内消息接收方法可相互对应参照。

参照图6，本公开实施例还提供一种集群内消息接收装置，设置于消息接收方的微服务器内，包括监听模块60，其中，监听模块60用于每一微服务器根据从注册中心获取的消息通知服务列表监听包括于消息服务通知列表的至少一个微服务器所广播的消息；其中，消息通知服务列表为注册中心根据每一微服务器及其对应的地址信息生成。

具体来说，监听是指时刻关注消息通知服务列表中除自身以外的微服务器是否有广播信息。

本公开实施例提供的集群内消息接收装置，监听模块60通过每一微服务器根据从注册中心获取的消息通知服务列表监听包括于消息服务通知列表的至少一个微服务器所广播的消息；其中，消息通知服务列表为注册中心根据每一微服务器及其对应的地址信息生成。微服务器可以通过监听包括于消息服务通知列表的至少一个微服务器所广播的消息，而不用依赖于各消息中间件如MQ消息、Redis的消息队列、或者是可借助类似Zookeeper的watcher机制，来实现消息通知，也不用通过定时数据同步来进行消息同步，降低了维护成本及接入成本。

在一种可选实施例中，消息包括消息主题和用于承载消息内容的消息体；集群内消息接收装置还包括：

匹配模块62，用于根据本地预设关注主题，对监听所获取的消息的消息主题进行匹配，获取关注主题下的消息的消息体。

具体来说，在消息仅包括消息主题和用于承载消息内容的消息体的情况下，根据本地预设关注主题，对监听所获取的消息的消息主题进行匹配可以在监听所获取的消息筛选出本地预设关注主题对应的消息，即该微服务器所需处理的消息。

基于上述任一实施例，消息包括消息主题、消息ID和用于承载消息内容的消息体；在获取关注主题下的消息的消息体后，集群内消息接收装置还包括：

记录模块64，用于对消息体所关联的消息ID进行记录。

具体来说，在消息包括消息主题、消息ID和用于承载消息内容的消息体的情况下，消息ID用于鉴别是否有重复消息发送，在确定该消息除本次外未曾被获取后，根据本地预设关注主题，对监听所获取的消息的消息主题进行匹配可以在监听所获取的消息筛选出本地预设关注主题对应的消息，即该微服务器所需处理的消息。

基于上述任一实施例，获取关注主题下的消息的消息体后，还包括：

处理模块66，用于依据消息体内容，对消息进行处理。

具体来说，处理指基于消息体获取消息体所承载的消息内容。

异常模块68，用于若判断消息处理不成功，则将该消息存入异常消息处理队列，并定时从异常消息处理队列中取出并再次执行消息处理操作。

具体来说，消息处理不成功即无法获悉消息体所承载的消息内容。

在一个优选实施例中，集群内消息接收装置还包括：初始化模块，其中初始化模块用于初始化消息通知服务。需要说明的是，初始化模块在第一次获取消息通知服务列表时运行。

图7示例了一种电子设备的实体结构示意图，如图7所示，该电子设备可以包括：处理器(processor)710、通信接口(Communications Interface)720、存储器(memory)730和通信总线740，其中，处理器710，通信接口720，存储器730通过通信总线740完成相互间的通信。处理器710可以调用存储器730中的逻辑指令，以执行上述各实施例所述的集群内消息通知方法或集群内消息接收方法。

此外，上述的存储器730中的逻辑指令可以通过软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本公开实施例的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本公开各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，Random Access Memory)、磁碟或者光盘等各种可以存储程序代码的介质。

另一方面，本公开还提供一种计算机程序产品，所述计算机程序产品包括存储在非暂态计算机可读存储介质上的计算机程序，所述计算机程序包括程序指令，当所述程序指令被计算机执行时，计算机能够执行上述各方法所提供的集群内消息通知方法或集群内消息接收方法。

又一方面，本公开还提供一种非暂态计算机可读存储介质，其上存储有计算机程序，该计算机程序被处理器执行时实现以执行上述各提供的集群内消息通知方法或集群内消息接收方法。

以上所描述的装置实施例仅仅是示意性的，其中所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。本领域普通技术人员在不付出创造性的劳动的情况下，即可以理解并实施。

通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到各实施方式可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件。基于这样的理解，上述技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品可以存储在计算机可读存储介质中，如ROM/RAM、磁碟、光盘等，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行各个实施例或者实施例的某些部分所述的方法。

最后应说明的是：以上实施例仅用以说明本公开的技术方案，而非对其限制；尽管参照前述实施例对本公开进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本公开各实施例技术方案的精神和范围。

Claims (15)

1.一种集群内消息通知方法，其特征在于，包括：

每一微服务器根据从注册中心获取的消息通知服务列表向包括于所述消息服务通知列表的至少一个微服务器广播消息；其中，

所述消息通知服务列表为所述注册中心根据每一所述微服务器及其对应的地址信息生成。

2.根据权利要求1所述的集群内消息通知方法，其特征在于，所述方法还包括：

根据所述注册中心定时推送的消息通知服务列表对每一所述微服务器内的当前消息通知服务列表进行更新；和/或

每一所述微服务器定时访问所述注册中心重新获取更新后的消息通知服务列表。

3.根据权利要求1或2所述的集群内消息通知方法，其特征在于，

所述消息包括消息主题和承载消息内容的消息体；

所述消息主题用于接收消息的微服务器对监听到的多个消息进行基于本地预设关注主题的过滤。

4.根据权利要求3所述的集群内消息通知方法，其特征在于，

所述消息还包括消息ID；

所述向包括于所述消息服务通知列表的至少一个微服务器广播消息之前，还包括：

根据当前消息的消息ID，判断所述当前消息是否已经发送，并在已经发送的情况下，结束所述当前消息的发送。

5.根据权利要求4所述的集群内消息通知方法，其特征在于，

在所述当前消息未发送的情况下，在所述向包括于所述消息服务通知列表的至少一个微服务器广播消息之前还包括：

确认发送所述当前消息的微服务器已向所述注册中心进行消息通知服务注册。

6.根据权利要求1所述的集群内消息通知方法，其特征在于，在向包括于所述消息服务通知列表的至少一个微服务器广播消息后，还包括：

获取消息发送结果；

在确认所述发送结果为失败后，启动消息的同步重试发送；或，将发送失败的消息存储至异常消息发送队列中，并根据预先设定的时间间隔从所述异常消息发送队列中取出发送失败的消息，再次异步启动广播重试发送。

7.一种集群内消息接收方法，其特征在于，包括：

每一微服务器根据从注册中心获取的消息通知服务列表监听包括于所述消息服务通知列表的至少一个微服务器所广播的消息；其中，

所述消息通知服务列表为所述注册中心根据每一所述微服务器及其对应的地址信息生成。

8.根据权利要求7所述的集群内消息接收方法，其特征在于，

所述消息包括消息主题和用于承载消息内容的消息体；

所述方法还包括，根据本地预设关注主题，对监听所获取的消息的消息主题进行匹配，获取所述关注主题下的消息的消息体。

9.根据权利要求8所述的集群内消息接收方法，其特征在于，

所述消息还包括消息ID；

在获取所述关注主题下的消息的消息体后，所述方法还包括，对所述消息体所关联的消息ID进行记录。

10.根据权利要求8所述的集群内消息接收方法，其特征在于，所述获取所述关注主题下的消息的消息体后，还包括：

依据所述消息体内容，对所述消息进行处理；

若判断消息处理不成功，则将该消息存入异常消息处理队列，并定时从所述异常消息处理队列中取出并再次执行消息处理操作。

11.一种集群内消息通知装置，其特征在于，应用于包括注册中心以及多个微服务器的集群，该装置包括：

广播模块，用于每一所述微服务器根据从所述注册中心获取的消息通知服务列表向包括于所述消息服务通知列表的至少一个微服务器广播消息；其中，

所述消息通知服务列表为所述注册中心根据每一所述微服务器及其对应的地址信息生成。

12.一种集群内消息接收装置，其特征在于，应用于包括注册中心以及多个微服务器的集群，该装置包括：

监听模块，用于每一所述微服务器根据从所述注册中心获取的消息通知服务列表监听包括于所述消息服务通知列表的至少一个微服务器所广播的消息；其中，

所述消息通知服务列表为所述注册中心根据每一所述微服务器及其对应的地址信息生成。

13.一种电子设备，包括存储器、处理器及存储在所述存储器上并可在所述处理器上运行的计算机程序，其特征在于，所述处理器执行所述程序时实现：

如权利要求1至6任一项所述的集群内消息通知方法的步骤；或

如权利要求7至10中任一项所述的集群内消息接收方法的步骤。

14.一种非暂态计算机可读存储介质，其上存储有计算机程序，其特征在于，所述计算机程序被处理器执行时实现：

如权利要求1至6任一项所述的集群内消息通知方法的步骤；或

如权利要求7至10中任一项所述的集群内消息接收方法的步骤。

15.一种计算机程序产品，包括计算机程序，其特征在于，所述计算机程序被处理器执行时实现：

如权利要求1至6任一项所述的集群内消息通知方法的步骤；或

如权利要求7至10中任一项所述的集群内消息接收方法的步骤。

Images