CN112511595B - 一种消息推送方法及消息服务系统 - Google Patents

Abstract

本发明提供了一种消息推送方法及消息服务系统，该消息推送方法，应用于包含若干节点的服务端，包括以下步骤：S1、启动节点服务，并将节点所启动的服务注册至连接节点的数据库，按照更新间隔更新服务；S2、响应客户端发起的操作，从数据库中选取在设定时间段内服务未发生变动的任意一个节点；S3、根据客户端发起的操作，由数据库主动调用在设定时间段内服务未发生变动的节点，并通过节点的回调接口接收事件消息并在服务未发生变动的节点与客户端之间建立消息推送通道。通过本申请，解决了使用消息中间件所存在的逻辑复杂、功能耦合、部署成本过高及资源浪费的问题，并解决了客户端与服务端的操作系统不一致所导致的适配性较差的缺陷。

Description

一种消息推送方法及消息服务系统

技术领域

本发明涉及消息服务技术领域，尤其涉及一种消息推送方法及消息服务系统。

背景技术

在云平台及超融合技术中，通常基于分布式应用架构，而分布式应用架构通常采用消息服务系统。在消息服务系统中，消息系统中间件是消息服务系统的核心组件，其承担连接管理与消息管理的核心功能。基于WebSocket协议的消息推送机制，实现浏览器(或包含浏览器的客户端)与服务端进行全双工通信(Full-Duplex)，以更好地节省服务端的资源和带宽并达到实时通信的目的。

为支持高并发的访问请求，在云平台或者超融合设备等其他场景及系统中通常需要部署数量更多的消息队列服务器，因此传统的云平台或者超融合设备中的消息服务系统存在功能耦合、部署成本过高及资源浪费的问题。消息队列服务器通常使用消息队列(Rabbit MQ)或者基于Redis服务器实现消息中间件功能。同时，消息中间件的配置过程较为复杂。采用消息队列(Rabbit MQ)的基于WebSocket协议的消息推送中，一旦Rabbit MQ挂了，消息无法继续传输；同时，也容易插入重复数据、脏数据并导致大量的积压消息。

Redis作为内存中的数据结构存储，常用作数据库、缓存和消息代理。它支持数据结构，如字符串，散列，列表，集合，带有范围查询的排序集(sorted sets)，位图(bitmaps)，超级日志(hyperloglogs)，具有半径查询和流的地理空间索引。Redis具有内置复制，Lua脚本，LRU驱逐，事务和不同级别的磁盘持久性，并通过Redis Sentinel和Redis Cluster自动分区。虽然采用Redis服务器充当消息中间件虽然能够降低系统的维护成本和实现复杂度，但是采用Redis服务器充当消息中间件的技术方案通常需要维护一个Pending列表，保证消息处理确认，因此导致不能保证消费者消费消息后是否成功处理的问题(宕机或处理异常等)；同时，还存在不能做广播模式(如PUB/SUB，消息发布/订阅模型)，不能重复消费，一旦消费就会被删除，以及不支持分组消费等缺陷。

最后，引入消息中间件在服务端与客户端之间基于WebSocket协议执行消息推送时，如果服务端与客户端的操作系统不同，则需要开发一些绕过操作系统协议栈或者内核的组件即基础开发，开发缓存和网络的中间件开发来达到跨平台及高并发目的，因此如果采用消息中间件作为消息队列缓存机构，则在客户端与服务端的操作系统不同时，也存在一定的限制。

有鉴于此，有必要对现有技术中的基于WebSocket协议的消息推送方法、装置予以改进，以解决上述问题。

发明内容

本发明的目的在于揭示一种消息推送方法及消息服务系统，用以解决现有技术中基于WebSocket协议在客户端与服务端之间执行消息推送时所存在的诸多技术缺陷，避免使用消息中间件所存在的逻辑复杂、功能耦合、部署成本过高及资源浪费的问题，并解决客户端与服务端的操作系统不一致所导致的适配性较差的缺陷。

为实现上述第一个目的，本发明提供了一种消息推送方法，应用于包含若干节点的服务端，包括以下步骤：

S1、启动节点服务，并将节点所启动的服务注册至连接节点的数据库，按照更新间隔更新所述服务；

S2、响应客户端发起的操作，从数据库中选取在设定时间段内服务未发生变动的任意一个节点；

S3、根据客户端发起的操作，由数据库主动调用在设定时间段内服务未发生变动的节点，并通过所述节点的回调接口接收事件消息并在服务未发生变动的节点与客户端之间建立消息推送通道。

作为本发明的进一步改进，所述设定时间段具体为：与数据库连接的任意一个节点按照更新间隔执行更新的操作完成之后所历经的时间段，所述设定时间段的时长大于更新间隔的时长。

作为本发明的进一步改进，在节点所启动的服务注册至数据库后还包括：检测节点与数据库之间的连接状态，并更新节点所启动的服务的服务属性。

作为本发明的进一步改进，所述节点所启动的服务的服务属性包括：节点IP、服务名称、节点与数据库连接的端口号、服务注册时间、服务最后更新时间中的一种或者几种的组合；

所述服务发生变动的节点为节点中服务属性发生变动。

作为本发明的进一步改进，所述更新间隔基于内置于各个节点中部署的定时器所包含的更新逻辑予以确定，所述定时器按照更新逻辑所对应的更新间隔更新所述服务，并修改节点已经注册到数据库中的服务的服务属性。

作为本发明的进一步改进，节点所启动的服务由用户在本地设备和/或图形交互界面中对指定的节点发起的操作而形成；

所述消息推送方法还包括：判断对指定的节点在设定时间段内服务是否未发生变动，

若是，则由指定的节点与客户端之间建立消息推送通道；

若否，则依次执行步骤S2与步骤S3。

作为本发明的进一步改进，所述数据库连接多个节点，每个节点中部署Websocket服务端，所述Websocket服务端配置至少一个与数据库相通信的回调接口，所述回调接口接收其他节点发送的在未发生变动的节点与客户端之间的建立消息推送通道的请求，以通过所述未发生变动的节点的回调接口在所述未发生变动的节点与客户端之间建立消息推送通道，并按照更新间隔所确定的更新逻辑对已经建立消息推送通道的节点注册到数据库中的服务执行更新。

基于相同发明思想，本申请还揭示了一种消息服务系统，包括：

若干节点，以及连接节点的数据库；

所述节点均配置回调接口及定时器，

节点启动服务后将节点所启动的服务注册至连接节点的数据库，按照更新间隔更新所述服务，响应客户端发起的对指定的节点发起的操作，并数据库中选取在设定时间段内服务未发生变动的任意一个节点，根据客户端发起的操作，由数据库主动调用在设定时间段内服务未发生变动的节点，并通过所述节点的回调接口接收事件消息并在服务未发生变动的节点与客户端之间建立消息推送通道。

作为本发明的进一步改进，所述每个节点中部署Websocket服务端，所述Websocket服务端配置至少一个与数据库相通信的回调接口，所述回调接口接收其他节点发送的在未发生变动的节点与客户端之间的建立消息推送通道的请求，以通过所述未发生变动的节点的回调接口在所述未发生变动的节点与客户端之间建立消息推送通道，并按照更新间隔所确定的更新逻辑对已经建立消息推送通道的节点注册到数据库中的服务执行更新。

作为本发明的进一步改进，所述Websocket服务端被封装为一个微服务，所述设定时间段具体为：与数据库连接的任意一个节点按照更新间隔执行更新的操作完成之后所历经的时间段，所述设定时间段的时长大于更新间隔的时长。

与现有技术相比，本发明的有益效果是：

在本申请中，利用数据库及每个节点上所配置的回调接口，由数据库主动调用在设定时间段内服务未发生变动的节点，并通过所述节点的回调接口接收事件消息并在服务未发生变动的节点与客户端之间建立消息推送通道，从而避免使用传统的消息中间件，解决了使用消息中间件所存在的逻辑复杂、功能耦合、部署成本过高及资源浪费的问题；

同时，解决了客户端与服务端的操作系统不一致所导致的适配性较差的缺陷，提高了包含多个节点的集群与客户端之间建立基于WebSocket协议的消息推送通道的便利性。

附图说明

图1为本发明一种消息推送方法的整体流程图；

图2为本发明一种消息服务系统的拓扑图，并示出了在客户端与服务端之间建立基于WebSocket协议的全双工通信连接的实例图；

图3为本发明一种消息推送方法的步骤S1的拓扑图；

图4为节点所启动的服务注册到数据库的详细流程图；

图5为注册到数据库中的服务按照更新间隔执行更新的详细流程图；

图6为通过节点的回调接口接收事件消息并在服务未发生变动的节点(例如节点1与节点3)与多个客户端建立消息推送通道的拓扑图；

图7为操作通过节点的回调接口接收事件消息并在服务未发生变动的节点(例如节点1与节点3)与多个客户端建立消息推送通道详细流程图。

具体实施方式

下面结合附图所示的各实施方式对本发明进行详细说明，但应当说明的是，这些实施方式并非对本发明的限制，本领域普通技术人员根据这些实施方式所作的功能、方法、或者结构上的等效变换或替代，均属于本发明的保护范围之内。

本申请所揭示的一种消息推送方法及其消息服务系统，旨在对服务端1对向客户端40执行消息推送的实现过程予以改进。尤其是的，服务端1在本申请各个实施例中可被理解为运行计算机可执行程序的服务器、物理计算机、虚拟机、虚拟机集群、数据中心，云计算平台、超融合一体机，甚至还可为手持式移动设备(例如手机、可接入网络的可穿戴设备、平板电脑等)等。客户端40在本申请各个实施例中为向服务端1发起访问请求或者操作指令的一种终端设备或者电子设备，并在各个实施例中可被理解为手机、计算机、能够发送访问请求(例如用于网上订购商品的程序或者计算机应用)的移动设备、邮件系统、广播系统等。

尤其的，在本申请中，服务端1与客户端40是相对而言的，彼此之间的角色可根据计算机程序或者各种在线应用的特性进行对调。因此，在本申请中如果消息从一个主体推送至另一个主体时，第一个主体则为服务端，二个主体即为客户端40。以下通过若干实施例对具体实现过程予以阐述。

实施例一：

参图1及图3至图7所示，本实施例揭示了一种消息推送方法的一种具体实施方式。

在本实施例中，一种消息推送方法，应用于包含若干节点的服务端，包括以下步骤S1至步骤S3。结合图6所示，在本实施例中，申请人以服务端包含节点1、节点2及节点3这三个节点为例，予以示范性说明。节点1、节点2及节点3构成集群或者集群服务器。三个节点或者数量更多或者更少的节点构成图2中的服务端1，服务端1中包含若干业务指令集，例如业务指令集101及业务指令集102等，每个业务指令集作为一种线程或者应用，触发与数据库10建立TCP连接的事件，并由数据库10对服务端1进行监听。同时，由服务端1与客户端40建立Websocket连接，从而对用户在客户端40的浏览器41中发起的各种操作、请求等，执行消息推送，以在服务端1的一个节点与客户端40之间建立一条或者多条消息推送通道，即通过图2中多个Websocket连接所建立的多个消息推送通道。

首先，执行步骤S1、启动节点服务，并将节点所启动的服务注册至连接节点的数据库10，按照更新间隔更新所述服务。

结合图3所示，节点1中部署WebSocket服务端a及定时器51，节点2中部署WebSocket服务端b及定时器52，节点3中部署WebSocket服务端c及定时器53。每个节点中WebSocket服务端启动后执行步骤S11，从而将服务启动后保存至数据库10中。在节点所启动的服务注册至数据库10后还包括：检测节点与数据库10之间的连接状态，并更新节点所启动的服务的服务属性。节点所启动的服务的服务属性包括：节点IP、服务名称、节点与数据库10连接的端口号、服务注册时间、服务最后更新时间中的一种或者几种的组合。尤其的，在本实施例中，服务发生变动的节点为节点中服务属性发生变动。具体的，只要上述任意一种或者几种服务属性发生了变化，则判定已经注册到数据库10中的服务发生了变动，否则，则判定已经注册到数据库10中的服务未发生变动。

结合图4所示，步骤110、服务启动。步骤111、判断数据库10中是否已有该服务信息，即判断数据库10中是否已经保存某个节点在数据库10中完成服务注册，若否，则证明该节点未完成服务注册，从而需要执行步骤112、保存服务信息到数据库10中，并标记对应节点的状态为可用(Active)；若数据库10中已有该服务信息，则按照更新逻辑更新服务信息到数据库10中。更新逻辑保存于定时器中，并根据更新逻辑所对应更新时间更新节点服务，并修改节点已经注册到数据库10中的服务的服务属性。

更新间隔基于内置于各个节点中部署的定时器51～53所包含的更新逻辑予以确定，所述定时器按照更新逻辑所对应的更新间隔更新所述服务，并修改节点已经注册到数据库10中的服务的服务属性。具体的，参图5所示，201)定时器启动，202)定时器按照更新逻辑所对应的更新间隔更新本节点的服务信息到数据库10中。

在本实施例中，更新间隔选定为10秒(10s)，更新所述服务作为一种线程，由每个节点中的定时器51、52及53所包含的更新逻辑触发更新服务的事件。节点1～节点3可以依次地按照更新逻辑对节点所启动的服务注册至数据库10的服务的服务属性进行更新，以确保该节点的环境变量、存活状态(Aactive或者Inactive)，从而使得最终与客户端40所建立的消息推送通道能够及时响应用户在客户端40中所发起的各种操作。同时，节点1～节点3还可以同步地执行更新对应节点上已经注册的服务。当某个节点出现不可用或者节点中服务属性发生变动时，则可通过对服务的更新，确保后续建立的消息推送通道的可靠性。因为，在某些场景中，例如节点2的节点IP发生冲突时，会导致该节点2不可用。用户在客户端40发起的操作旨在基于节点2与WebSocket客户端是无法建立消息推送通道的。因此，需要根据更新间隔更新所述服务。

然后，执行步骤S2、响应客户端40发起的操作，从数据库10中选取在设定时间段内服务未发生变动的任意一个节点。节点所启动的服务由用户在本地设备和/或图形交互界面(GUI)中对指定的节点发起的操作而形成。本地设备和/或图形交互界面可被视为计算机系统、软件、或者可接收用户以键盘、触摸、语音等输入方式输入请求的用户界面，例如浏览器。数据库10连接多个节点，每个节点中部署Websocket服务端，所述Websocket服务端配置至少一个与数据库10相通信的回调接口，所述回调接口接收其他节点发送的在未发生变动的节点与客户端之间的建立消息推送通道的请求，以通过所述未发生变动的节点的回调接口在所述未发生变动的节点与客户端40之间建立消息推送通道，并按照更新间隔所确定的更新逻辑对已经建立消息推送通道的节点注册到数据库10中的服务执行更新。客户端40中部署Websocket客户端c、Websocket客户端d及Websocket客户端e。

在本实施例中，该回调接口按照RESTful风格定义，并属于API接口。用于通过回调接口接收其他节点发送的事件消息，然后再通过WebSocket服务端与客户端建立消息推送通道。

需要说明的是，Websocket客户端的数量并不需要与节点的数量相匹配。例如，图6中的操作20由用户在客户端40中发起的一种具体的操作，例如在网站上对商品的执行购买商品已经签收的订单确认，或者在微信(一种APP)的可视化图形界面上发送文本消息的事件等。

最后，执行步骤S3、根据客户端发起的操作，由数据库10主动调用在设定时间段内服务未发生变动的节点，并通过所述节点的回调接口接收事件消息并在服务未发生变动的节点与客户端之间建立消息推送通道。设定时间段具体为：与数据库10连接的任意一个节点按照更新间隔执行更新的操作完成之后所历经的时间段，所述设定时间段的时长大于更新间隔的时长。例如，设定时间段的时长可为20秒(20s)。由于设定时间段的时长大于更新间隔的时长，从而在存在多个节点时，确保存在至少一个服务未发生变动的节点，并由该服务未发生变动的节点所配置的回调接口通过http方式调用状态为不正常的节点上由用户在客户端40所发起的操作20，从而提高了建立消息推送通道的可靠性与准确性。

消息推送方法还包括：判断对指定的节点在设定时间段内服务是否未发生变动，

若是，则由指定的节点与客户端40之间建立消息推送通道；

若否，则依次执行步骤S2与步骤S3。

参图7所示，401)操作20在节点2中产生事件消息。402)节点服务2从数据库10中根据当前时间获取在设定时间段内有更新的节点服务信息。403)判断获得的节点服务信息是否是节点2已经注册到数据库10中的服务信息。若否，则执行404)将事件消息通过http方式调用非节点2的回调接口(即节点1或者节点2的回调接口)。若是，则执行405)；由所在节点接收事件消息，通过WebSocket服务端将事件消息发送给客户端。上述所谓的“所在节点”可以是节点1或者节点2或者节点3。

在本实施例中，节点2基于操作20所产生的事件消息即使无法通过节点2与前端的WebSocket客户端建立消息推送通道，也可以通过节点1或者及节点3所配置的回调接口以http方式被主动调用，并与端的WebSocket客户端(例如图4中的Websocket客户端c、Websocket客户端d或者Websocket客户端e)建立消息推送通道。http是一个简单的请求-响应协议，它通常运行在TCP之上，并指定了客户端40可能发送给服务器什么样的消息以及得到什么样的响应。请求和响应消息的头以ASCII码形式给出；而消息内容则具有一个类似MIME的格式。因此，在建立消息推送通道的过程中，与Websocket客户端与节点中的Websocket服务端所使用的操作系统(OS)没有任何关系，只要消息推送过程遵循http协议即可。因此，有效地解决了客户端40与服务端1的操作系统不一致所导致的适配性较差的缺陷。

WebSocket服务端a部署回调接口a1，WebSocket服务端b部署回调接口a2，WebSocket服务端c部署回调接口a3。回调接口a1～回调接口a3基于操作20由数据库10主动调用在设定时间段内服务未发生变动的节点。如果节点2在20秒内服务已经发生变动，则可通过WebSocket服务端a和/或WebSocket服务端c分别执行步骤S32或者步骤34。

步骤S32、根据获取到集群服务信息调用节点1服务的回调接口a1或者步骤S34、根据获取到集群服务信息调用节点3服务的回调接口a3。节点1发现有WebSocket客户端c连接，则通过回调接口a1推送事件消息至WebSocket客户端c(即步骤S35)。节点1发现有WebSocket客户端d连接，则通过回调接口a1推送事件消息至WebSocket客户端d(即步骤S36)。节点3发现有WebSocket客户端e连接，则通过回调接口a3推送事件消息至WebSocket客户端e(即步骤S37)。在本实施例中，如果节点2在设定时间段内服务未发生变动，则也可以通过节点2与对应的WebSocket客户端建立消息推送通道，即参图6中的步骤S33。

本实施例所揭示的消息推送方法，利用数据库10及每个节点上所配置的回调接口，由数据库10主动调用在设定时间段内服务未发生变动的节点，并通过所述节点的回调接口接收事件消息并在服务未发生变动的节点与客户端之间建立消息推送通道，从而避免使用传统的消息中间件，解决了现有技术中使用消息中间件所存在的逻辑复杂、功能耦合、部署成本过高及资源浪费的问题。

同时，解决了客户端40与服务端1的操作系统不一致所导致的适配性较差的缺陷，提高了包含多个节点的集群与客户端之间建立基于WebSocket协议的消息推送通道的便利性。

实施例二：

结合图2所示，基于实施例一所揭示的一种消息推送方法，本实施例还揭示了一种消息服务系统。

基于实施例一所揭示的一种消息推送方法所应用的场景中，可在服务端1包含的若干业务指令集，例如业务指令集101及业务指令集102等，服务端1自发地推送消息，可在服务端1对客户端40进行自动消息推送，例如客户端40所安装的某个软件(APP)执行版本升级或者插件安装时，由客户端10定期且主动地向客户端40推送含有安装程序或者系统升级程序的消息。于此场景中，使用本实施例一所揭示的消息推送方法，能够防止服务端1频繁无序或重复地向客户端40推送“系统升级”的消息及升级数据包。避免用户在已经安装了升级数据包后，在客户端40的浏览器41或者其他形式的用户可视化界面(GUI)中重复的弹出提示用户升级系统或者软件的对话框，并间接地提高了用户体验。

结合图2所示，本实施例所揭示额一种消息服务系统，包括：

若干节点(即节点1～节点3)，以及连接节点的数据库10。

所述节点均配置回调接口(即回调接口a1～回调接口a3)及定时器(即定时器51～定时器53)。

节点启动服务后将节点所启动的服务注册至连接节点的数据库10，按照更新间隔更新所述服务，响应客户端发起的对指定的节点发起的操作，并数据库中选取在设定时间段内服务未发生变动的任意一个节点，根据客户端40发起的操作，由数据库10主动调用在设定时间段内服务未发生变动的节点，并通过所述节点的回调接口接收事件消息并在服务未发生变动的节点与客户端之间建立消息推送通道。

每个节点中部署Websocket服务端，所述Websocket服务端配置至少一个与数据库10相通信的回调接口，所述回调接口接收其他节点发送的在未发生变动的节点与客户端之间的建立消息推送通道的请求，以通过所述未发生变动的节点的回调接口在所述未发生变动的节点与客户端之间建立消息推送通道，并按照更新间隔所确定的更新逻辑对已经建立消息推送通道的节点注册到数据库中的服务执行更新。Websocket服务端a～Websocket服务端c被封装为一个微服务，所述设定时间段具体为：与数据库10连接的任意一个节点按照更新间隔执行更新的操作完成之后所历经的时间段，所述设定时间段的时长大于更新间隔的时长。

本实施例与实施例一中具有相同部分的技术方案，请参实施例一所示，在此不再赘述。

本发明实施例中所描述的各种说明性的逻辑块，或单元都可以通过通用处理器，数字信号处理器，专用集成电路(ASIC)，现场可编程门阵列或其它可编程逻辑装置，离散门或晶体管逻辑，离散硬件部件，或上述任何组合的设计来实现或操作所描述的功能。通用处理器可以为微处理器，可选地，该通用处理器也可以为任何传统的处理器、控制器、微控制器或状态机。处理器也可以通过计算装置的组合来实现，例如数字信号处理器和微处理器，多个微处理器，一个或多个微处理器联合一个数字信号处理器核，或任何其它类似的配置来实现。

上文所列出的一系列的详细说明仅仅是针对本发明的可行性实施方式的具体说明，它们并非用以限制本发明的保护范围，凡未脱离本发明技艺精神所作的等效实施方式或变更均应包含在本发明的保护范围之内。

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

此外，应当理解，虽然本说明书按照实施方式加以描述，但并非每个实施方式仅包含一个独立的技术方案，说明书的这种叙述方式仅仅是为清楚起见，本领域技术人员应当将说明书作为一个整体，各实施例中的技术方案也可以经适当组合，形成本领域技术人员可以理解的其他实施方式。

Claims (9)

1.一种消息推送方法，应用于包含若干节点的服务端，其特征在于，包括以下步骤：

S1、启动节点服务，并将节点所启动的服务注册至连接节点的数据库，按照更新间隔更新所述服务；

S2、响应客户端发起的操作，从数据库中选取在设定时间段内服务未发生变动的任意一个节点，所述设定时间段具体为：与数据库连接的任意一个节点按照更新间隔执行更新的操作完成之后所历经的时间段，所述设定时间段的时长大于更新间隔的时长；

S3、根据客户端发起的操作，由数据库主动调用在设定时间段内服务未发生变动的节点，并通过所述节点的回调接口接收事件消息并在服务未发生变动的节点与客户端之间建立消息推送通道。

2.根据权利要求1所述的消息推送方法，其特征在于，在节点所启动的服务注册至数据库后还包括：检测节点与数据库之间的连接状态，并更新节点所启动的服务的服务属性。

3.根据权利要求2所述的消息推送方法，其特征在于，所述节点所启动的服务的服务属性包括：节点IP、服务名称、节点与数据库连接的端口号、服务注册时间、服务最后更新时间中的一种或者几种的组合；

将节点所启动的服务的服务属性发生变动的节点作为服务发生变动的节点，将节点所启动的服务的服务属性未发生变动的节点作为服务未发生变动的节点。

4.根据权利要求3所述的消息推送方法，其特征在于，所述更新间隔基于内置于各个节点中部署的定时器所包含的更新逻辑予以确定，所述定时器按照更新逻辑所对应的更新间隔更新所述服务，并修改节点已经注册到数据库中的服务的服务属性。

5.根据权利要求1所述的消息推送方法，其特征在于，节点所启动的服务由用户在本地设备和/或图形交互界面中对指定的节点发起的操作而形成；

所述消息推送方法还包括：判断对指定的节点在设定时间段内服务是否未发生变动，

若是，则由指定的节点与客户端之间建立消息推送通道；

若否，则依次执行步骤S2与步骤S3。

6.根据权利要求1或者5所述的消息推送方法，其特征在于，所述数据库连接多个节点，每个节点中部署Websocket服务端，所述Websocket服务端配置至少一个与数据库相通信的回调接口，所述回调接口接收其他节点发送的在未发生变动的节点与客户端之间的建立消息推送通道的请求，以通过所述未发生变动的节点的回调接口在所述未发生变动的节点与客户端之间建立消息推送通道，并按照更新间隔所确定的更新逻辑对已经建立消息推送通道的节点注册到数据库中的服务执行更新。

7.一种消息服务系统，其特征在于，包括：

若干节点，以及连接节点的数据库；

所述节点均配置回调接口及定时器，

节点启动服务后将节点所启动的服务注册至连接节点的数据库，按照更新间隔更新所述服务，响应客户端发起的对指定的节点发起的操作，并数据库中选取在设定时间段内服务未发生变动的任意一个节点，根据客户端发起的操作，由数据库主动调用在设定时间段内服务未发生变动的节点，并通过所述节点的回调接口接收事件消息并在服务未发生变动的节点与客户端之间建立消息推送通道，所述设定时间段具体为：与数据库连接的任意一个节点按照更新间隔执行更新的操作完成之后所历经的时间段，所述设定时间段的时长大于更新间隔的时长。

8.根据权利要求7所述的消息服务系统，其特征在于，每个节点中部署Websocket服务端，所述Websocket服务端配置至少一个与数据库相通信的回调接口，所述回调接口接收其他节点发送的在未发生变动的节点与客户端之间的建立消息推送通道的请求，以通过所述未发生变动的节点的回调接口在所述未发生变动的节点与客户端之间建立消息推送通道，并按照更新间隔所确定的更新逻辑对已经建立消息推送通道的节点注册到数据库中的服务执行更新。

9.根据权利要求8所述的消息服务系统，其特征在于，所述Websocket服务端被封装为一个微服务。

Images