CN111885180A - 消息下发方法及装置 - Google Patents

Abstract

本发明提供了一种消息下发方法及装置，该方法包括：获取消息下发配置界面中的参数，所述参数至少包括数据源的标识信息；根据预设的配置规则对所述参数进行解析以生成所述数据源的消息下发规则；在所述数据源的上报数据满足下发条件的情况下，按照所述消息下发规则进行消息下发。在本发明中，通过为不同数据源提供统一的发规则配置逻辑和参数结构，从而可通过配置界面来生成对应数据源的消息下发规则，以进行消息的下发，解决了相关技术中数据源不同，数据结构不统一，导致需要进行重复性开发的问题，进而达到了规范研发流程、降低开发难度的效果。

Description

消息下发方法及装置

技术领域

本发明数据开发领域，具体而言，涉及一种消息下发方法及装置。

背景技术

现有的采用Flink开发框架进行数据开发时，通常是采用一种烟筒式穿透开发，即，对应不同的数据源(Topic)上报的数据，以及不同类型的下发消息消息，需要不同的Flink逻辑处理程序。

因此，无数个下发消息需求应用产生无数个性化Flink项目，对应服务端的多个集群项目，为了降低维护管理难度，迫切需要将此类需求归一管理。并且由于数据来源(Topic)多个，结构不统一，因此，针对不同的Topic需要进行重复性开发工作。

如果以上类似需求较多时，项目的维护和管理，升级、新增、下架将会变得越来越复杂，项目仍会产生新的需求，项目仍然需要编写代码以反映新的业务需求。

发明内容

本发明实施例提供了一种消息下发方法及装置，以至少解决相关技术中针对不同数据源的上报数据需要重复开发的问题。

根据本发明的一个实施例，提供了一种消息下发方法，包括：获取消息下发配置界面中的参数，所述参数至少包括数据源；根据预设的配置规则对所述参数进行解析以生成所述数据源的消息下发规则；在所述数据源的上报数据满足下发条件的情况下，按照所述消息下发规则进行消息下发。

进一步地，所述下发消息的类型包括至少以下之一：APP消息、语音消息、设备消息、设备控制指令。

在一个示意性实施例中，所述消息下发配置界面中包括多个参数配置字段，对于不同数据源和/或不同类型的下发消息，同一参数配置字段具有相同的配置逻辑和参数结构。。

在一个示意性实施例中，在所述数据源的上报数据满足下发条件的情况下，按照所述消息下发规则进行消息下发之前，还包括：接收来自所述数据源的上报数据，并按照预设条件对所述上报数据进行筛选。

在一个示意性实施例中，按照预设条件对所述上报数据进行筛选包括至少以下之一：过滤掉所述上报数据中的异常数据；根据数据属性丢弃所述上报数据中非关注的数据；丢弃所述上报数据中数据上报间隔不满足条件的数据；丢弃所述上报数据中过期的数据。

在一个示意性实施例中，按照预设条件对所述上报数据进行筛选之后，还包括：判断筛选后的所述上报数据是否满足下发条件，在满足所述下发条件的情况下进行消息下发。

在一个示意性实施例中，在满足下发条件的情况下发送所述下发消息包括以下之一：所述上报数据中的指定属性为第一指定值时，发送所述下发消息；所述上报数据中的指定属性由第二指定值变为第三指定值时，发送所述下发消息；所述上报数据中的指定属性在预定时长内保持为第四指定值时，在间隔预定时间发送所述下发消息。

根据本发明的另一个实施例，还提供了一种消息下发装置，包括：获取模块，用于获取消息下发配置界面中的参数，所述参数至少包括数据源；生成模块，用于根据预设的配置规则对所述参数进行解析以生成所述数据源的消息下发规则；下发模块，用于在所述数据源的上报数据满足下发条件的情况下，按照所述消息下发规则进行消息下发。

根据本发明的又一个实施例，还提供了一种存储介质，所述存储介质中存储有计算机程序，其中，所述计算机程序被设置为运行时执行上述任一项方法实施例中的步骤。

根据本发明的又一个实施例，还提供了一种电子装置，包括存储器和处理器，所述存储器中存储有计算机程序，所述处理器被设置为运行所述计算机程序以执行上述任一项方法实施例中的步骤。

在本发明的上述实施例中，通过提供统一的发规则配置逻辑和参数结构，可依据用户在UI界面配置的下发内容生成下发消息，因此，可以解决相关技术中数据开发流程不规范、开发难度大的问题，达到规范研发流程、降低开发难度的效果。

附图说明

此处所说明的附图用来提供对本发明的进一步理解，构成本申请的一部分，本发明的示意性实施例及其说明用于解释本发明，并不构成对本发明的不当限定。在附图中：

图1是根据本发明实施例的消息下发方法的流程图；

图2是根据本发明可选实施例的消息下发方法的流程图；

图3是根据本发明实施例的消息下发装置的结构框图；

图4是根据相关技术的传统烟筒式开发方式的示意图；

图5是根据本实施例的下发消息配置界面示意图；

图6是根据本实施例的数据流架构示意图。

具体实施方式

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

需要说明的是，本发明的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本发明的实施例能够以除了在这里图示或描述的那些以外的顺序实施。此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。

为了更好的理解本发明实施例以及可选实施例的技术方案，以下对本发明实施例以及可选实施例中可能出现的应用场景进行说明，但不用于限定以下场景的应用。

实施例1

在本实施例中提供了一种消息下发方法，图1是根据本发明实施例的消息下发方法的流程图，如图1所示，该流程包括如下步骤：

步骤S101，获取消息下发配置界面中的参数，所述参数至少包括数据源标识信息。在本实施例中，用户可以在消息下发配置界面的多个输入字段中输入对应的参数，例如，数据源标识、设备类型、设备型号、消息级别、消息类型、发送参数、发送间隔等。在本实施例中，当用户在配置界面的字段中输入参数时，无需考虑下发消息的数据源，也无需考虑下发消息的类型，因为，在本实施例中，对于不同数据源，或不同类型的下发消息，同一个参数配置字段具有相同的配置逻辑和参数结构，从而为不同数据源和不同下发消息类型提供统一的参数配置界面。

步骤S102，根据预设的配置规则对所述参数进行解析以生成所述数据源的消息下发规则。在本实施例中，配置规则可以预先生成并存储，在获取到用户在消息下发配置界面中的输入的参数后，读取存储的配置规则对所输入的参数进行解析，生成一条针对该数据源的消息下发规则。每个数据源字段下可生成多条消息下发规则。

步骤S103，在所述数据源的上报数据满足下发条件的情况下，按照所述消息下发规则进行消息下发。在本实施例中，可针对该数据源预先生成并存储该下发条件，并通过在配置界面中选定该下发条件。如果该数据源的上报数据满足下发条件，按照消息下发规则进行消息下发。在本实施例中，可以是通过Kafka消息订阅，或APP消息等形式进行消息下发。

在本实施例中，所述下发消息的类型包括至少以下之一：APP消息、语音消息、设备消息、设备控制指令。在本实施例中同一消息下发配置界面可以对应不同类型的消息下发。

在本实施例的步骤S101之前，还可包括步骤：在所述消息下发配置界面中为不同数据源和不同类型的下发消息提供统一的配置逻辑和参数结构。在本实施例中，对来自不同数据源的数据，以及语音、App、设备消息和指令的消息下发提供统一的配置逻辑和参数结构，使得配置下发无需开发人员开发代码，直接界面配置参数，如同填写参数表一样，勾勾选选即可生成对外的语音、App、设备下发消息规则。

在本实施例的步骤S102之前，还可包括：接收来自所述数据源的上报数据，并按照预设条件对所述上报数据进行筛选，以过滤掉不合格以及不需要的数据。例如，过滤掉所述上报数据中的异常数据，根据数据属性和数据类型丢弃所述上报数据中非关注的数据(即，可基于数据属性或数据类型判断是否属于需要的数据，如果不需要则可丢弃该部分数据)，丢弃所述上报数据中数据上报间隔不满足条件的数据，丢弃所述上报数据中过期的数据等。

在本实施例中，按照预设条件对所述上报数据进行筛选之后，还可包括：判断筛选后的所述上报数据是否满足下发条件，在满足所述下发条件的情况下进行消息下发。例如，所述上报数据中的指定属性为第一指定值时，发送所述下发消息；所述上报数据中的指定属性由第二指定值变为第三指定值时，发送所述下发消息；所述上报数据中的指定属性在预定时长内保持为第四指定值时，在间隔预定时间发送所述下发消息。

上述的下发条件可以根据用户设备的消息订阅要求，设备的类型、下发的消息的类型等来灵活的设定。例如，对于设备的故障类消息，可以增加时长的限定条件，只有在故障出现满足设定时长的情况下，才下发对应的消息。又例如，对于某些类型的下发消息，无需添加时长限定条件，只有设备某一参数满足设定值时，立即下发相关的消息。

通过上述步骤，由于依据用户在UI界面配置的下发内容生成下发消息，因此，解决了相关技术中数据开发流程不规范、开发难度大的问题，提高了研发流程的规范程度、降低了开发难度。

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

实施例2

在本实施例中还提供了一种消息下发装置，该装置用于实现上述实施例及优选实施方式，已经进行过说明的不再赘述。如以下所使用的，术语“模块”可以实现预定功能的软件和/或硬件的组合。尽管以下实施例所描述的装置较佳地以软件来实现，但是硬件，或者软件和硬件的组合的实现也是可能并被构想的。

图2是根据本发明实施例的消息下发装置的结构框图，如图2所示，该装置包括获取模块10、生成模块20及下发模块30。

获取模块10，用于获取消息下发配置界面中的参数，所述参数至少包括数据源的标识信息。在本实施例中，通过获取模块10可或缺用户在消息下发配置界面的多个输入字段中输入对应的参数，例如，数据源标识、设备类型、设备型号、消息级别、消息类型、发送参数、发送间隔等。

生成模块20，用于根据预设的配置规则对所述参数进行解析以生成所述数据源的消息下发规则。在本实施例中，配置规则可以预先生成并存储，生成模块20在获取到用户在消息下发配置界面中的输入的参数后，读取存储的配置规则对所输入的参数进行解析，生成一条针对该数据源的消息下发规则。每个数据源字段下可生成多条消息下发规则。

下发模块30，用于在所述数据源的上报数据满足下发条件的情况下，按照所述消息下发规则进行消息下发。在本实施例中，下发模块30可针对该数据源预先生成并存储该下发条件，并通过在配置界面中选定该下发条件。如果该数据源的上报数据满足下发条件，按照消息下发规则进行消息下发。在本实施例中，可以是通过Kafka消息订阅，或APP消息等形式进行消息下发。

上报数据满足的下发条件可以根据用户设备的消息订阅要求，设备的类型、下发的消息的类型等来灵活的设定。例如，对于设备的故障类消息，可以增加时长的限定条件，只有在故障出现满足设定时长的情况下，才下发对应的消息。又例如，对于某些类型的下发消息，无需添加时长限定条件，只有设备某一参数满足设定值时，立即下发相关的消息。

在本实施例中，由于消息下发装置可依据用户在UI界面配置的下发内容生成下发消息，因此，解决了相关技术中数据开发流程不规范、开发难度大的问题，提高了研发流程的规范程度、降低了开发难度。

需要说明的是，上述各个模块是可以通过软件或硬件来实现的，对于后者，可以通过以下发式实现，但不限于此：上述模块均位于同一处理器中；或者，上述各个模块以任意组合的形式分别位于不同的处理器中。

实施例3

为了便于对本发明所提供的技术方案的理解，下面将结合具体场景的实施例进行详细阐述。

本发明实施例针对以下需求背景：用户业务数据技能已具备，数据已存在，但是内含有价值数据不足，生产有价数据的能力不具备，已存在的部分生产能力基础功能存在重复开发、复用能力不足的问题，应用上线后出现问题排查困难和解决不及时。

同时，需求方期望有新的开放需求时开发能快速交付，新增需求时无需修改代码，需求变更时无需修改代码，同类需求不再重复造轮子，需求个性化修改无需修改代码，单独规则单独配置，变更需求或变更方案时维护简单。

相关技术一般采用Flink开发框架进行数据上报。图3是根据相关技术的传统烟筒式开发方法的流程图，由图3所示，烟筒式穿透开发的流程一般为：通过Flink开发框架将用户数据、设备状态或者设备故障信息上报到kafka平台，进而通过Flink逻辑处理程序进行客户端消息下发。同时，相关技术还给出了通过Flink开发框架经过App消息推送，进而进行客户端消息下发的方法。

相关技术来主要的缺点在于：

首先，数据研发流程不统一，平台基础功能存在重复开发、复用能力不足的问题，应用上线后出现问题排查困难和解决不及时。

其次，规范数据开发流程，为应用开发者提供数据开发基础库、通用模板、辅助工具和统一开发API，以提高平台复用能力和整体开发和运维效率。

再者，开发人员的开发难度大，每个需求都需要单独开发flink程序。

最后，Topic来源多个，结构不统一，需要无限进行重复性开发工作。

针对相关技术的缺点，在本实施例中，将传统开发烟筒式接口暴露模式进行包装和整理，抽象为界面配置的形式，使得开发人员只需要在首次开启一个数据源时配置一条基本SQL，之后继续在同一源Topic时只需要新增一条配置，并通过勾勾选选，填填关键参数值即可生成对下下发的四种消息下发结构，项目经理和产品经理只需要关注核心业务即可，无需关心开发实现。因此本发明实施例不仅解决了现有技术中开发人员的技术时间，而且还解决了运维人员的运维复杂度和流程多样化。从而提高了用户体验和加速了家电设备和运营团队下发消息的业务逻辑开发的速度。

本发明实施例提出了一种通过界面配置关键规则值以及下发相关参数即可生成一条对应的下发规则的开发方式，在本实施例中，下发规则可包括下发给APP消息以及语音音箱消息。图4是本实施例相对于相关技术的改进方法的流程图，如图4所示，本实施例的主要包括如下步骤：

步骤S401，UI界面开发者开发界面。图5为本实施例的消息配置界面示意图。如图5所示，在本实施例中，该消息配置界面上设置有多个可供用户输入的参数字段，例如，数据源标识(RuleID)、设备类型、设备型号、消息级别、消息类型、发送参数、发送间隔等。

步骤S402，用户在界面配置下发规则。在本实施例中，用户可根据不同的数据源以及下发消息的类型在消息配置界面上填写或勾选相应的参数。从而完成对该消息下发规则的配置。

步骤S403，后端开发重启服务，或后期升级自动重启服务。在本实施例中，后端通过启动服务，根据用户所配置的参数，基于上报数据进行消息的下发条件的判断和下发。

本发明实施例是一种主动服务。主动服务的设计目标是通过直观性和易用性来简化应用程序的开发难度和维护成本，主动服务的核心设计模拟了大多数人对配置界面，人机交互界面的看法-在终端与服务端交互，配置相关参数。

在本发明的上述实施例中，实现如下改进：

第一，对语音、App、设备下发消息和指令提供统一的配置逻辑和参数结构，配置下发无需开发人员开发代码，直接界面配置参数，如同填写参数表一样，通过勾勾选选即可生成对外的语音、App、设备下发消息规则。

第二，可以针对单个Topic来源启动一遍，原则上单个Topic即便有一万条规则也可只起一个服务，维护一套代码，下发支持RestFul接口、dubboRpc接口、kafka接口、Redis。

第三，不同启动只有启动对应的ruleID不同，一个Topic来源生成一个ruleID。同时，来源Topic为json格式。

本发明实施例的实现逻辑可为：将Flink配置规则保存在MySQL，一个Topic源创建一个唯一标示RuleId,一个RuleId对应无数个Flink下发规则，kafka数据只读取一次保证性能，一个Flink启动对应一个RuleId。通过启动时的入参传入，代码只有一份，根据配置参数自动读取相应规则，程序启动之后将Flink下发规则和配置规则从MySQL读取一次写入Redis和内存，通过三级缓存模式保证，Flink读取的迅捷运行性能。

下面对本实施例的数据流架构进行描述，如图6所述，在本实施例中，数据接入的形式可以为Kafka，数据输出的形式可以为Kafka对外走消息订阅，或APP消息对外走Ums消息下发。数据接入的范围可以是任意JSON存储的kafka数据。

在本发明的实施例中，将设备状态、用户状态数据、设备故障数据等数据上报至Kafka，对上报的数据进行分析，满足条件的数据才下发。例如，可根据实际业务抽象为如下场景：

a)数据上报中指定属性满足指定条件时下发消息；

b)数据上报中指定属性的具体值由之前值变更为新值时下发消息；

c)数据上报中指定属性的具体值持续上报指定时间后继续上报时下发规则。

同时，在本发明实施例的界面管理端，可将主动服务引擎的所有规则进行抽象，并以类型标识(typeId)和关键属性作为一条规则的唯一主键进行设计。

本实施例提供的界面管理端支持以下特性：

1)本实施例中的界面可使用，例如，Ruoyi开源框架进行二次开发；

2)可对规则表中的所有字段可以进行增删改查；

3)可根据下拉选择的需要设计数据字典。

综上所述，本发明实施例具有以下有益效果：

1.用户体验好，开发人员可以完全不懂编码即可完成开发，降低了开发难度；

2.接口开发效率提升，开发人员无需经过庞杂的编码即可完成业务需求，提升了交付速度；

3.效率高，开发人员单位时间内可交付大量消息下发需求，而无需维护大量相似而不相同的代码源码，提升了开发体验以及维护体验。

实施例4

本发明的实施例还提供了一种存储介质，该存储介质中存储有计算机程序，其中，该计算机程序被设置为运行时执行上述任一项方法实施例中的步骤。

可选地，在本实施例中，上述存储介质可以被设置为存储用于执行以下步骤的计算机程序：

S1，获取消息下发配置界面中的参数，所述参数至少包括数据源；

S2，根据预设的配置规则对所述参数进行解析以生成所述数据源的消息下发规则；

S3，在所述数据源的上报数据满足下发条件的情况下，按照所述消息下发规则进行消息下发。

可选地，在本实施例中，上述存储介质可以包括但不限于：U盘、只读存储器(Read-Only Memory，简称为ROM)、随机存取存储器(Random Access Memory，简称为RAM)、移动硬盘、磁碟或者光盘等各种可以存储计算机程序的介质。

实施例5

本发明的实施例还提供了一种电子装置，包括存储器和处理器，该存储器中存储有计算机程序，该处理器被设置为运行计算机程序以执行上述任一项方法实施例中的步骤。

可选地，上述电子装置还可以包括传输设备以及输入输出设备，其中，该传输设备和上述处理器连接，该输入输出设备和上述处理器连接。

可选地，在本实施例中，上述处理器可以被设置为通过计算机程序执行以下步骤：

S1，获取消息下发配置界面中的参数，所述参数至少包括数据源；

S2，根据预设的配置规则对所述参数进行解析以生成所述数据源的消息下发规则；

S3，在所述数据源的上报数据满足下发条件的情况下，按照所述消息下发规则进行消息下发。

可选地，本实施例中的具体示例可以参考上述实施例及可选实施方式中所描述的示例，本实施例在此不再赘述。

显然，本领域的技术人员应该明白，上述的本发明的各模块或各步骤可以用通用的计算装置来实现，它们可以集中在单个的计算装置上，或者分布在多个计算装置所组成的网络上，可选地，它们可以用计算装置可执行的程序代码来实现，从而，可以将它们存储在存储装置中由计算装置来执行，并且在某些情况下，可以以不同于此处的顺序执行所示出或描述的步骤，或者将它们分别制作成各个集成电路模块，或者将它们中的多个模块或步骤制作成单个集成电路模块来实现。这样，本发明不限制于任何特定的硬件和软件结合。

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

Claims (10)

1.一种消息下发方法，其特征在于，包括：

获取消息下发配置界面中的参数，所述参数至少包括数据源的标识信息；

根据预设的配置规则对所述参数进行解析以生成所述数据源的消息下发规则；

在所述数据源的上报数据满足下发条件的情况下，按照所述消息下发规则进行消息下发。

2.根据权利要求1所述的方法，其特征在于，其中，所述下发消息的类型包括至少以下之一：APP消息、语音消息、设备消息、设备控制指令。

3.根据权利要求1所述的方法，其特征在于，其中，所述消息下发配置界面中包括多个参数配置字段，对于不同数据源和/或不同类型的下发消息，同一参数配置字段具有相同的配置逻辑和参数结构。

4.根据权利要求1所述的方法，其特征在于，在所述数据源的上报数据满足下发条件的情况下，按照所述消息下发规则进行消息下发之前，还包括：

接收来自所述数据源的上报数据，并按照预设条件对所述上报数据进行筛选。

5.根据权利要求1所述的方法，其特征在于，按照预设条件对所述上报数据进行筛选包括至少以下之一：

过滤掉所述上报数据中的异常数据；

丢弃所述上报数据中数据类型和/或数据属性不满足条件的数据；

丢弃所述上报数据中数据上报间隔不满足条件的数据；

丢弃所述上报数据中过期的数据。

6.根据权利要求5所述的方法，其特征在于，按照预设条件对所述上报数据进行筛选之后，还包括：

判断筛选后的所述上报数据是否满足下发条件，在满足所述下发条件的情况下进行消息下发。

7.根据权利要求6所述的方法，其特征在于，在满足下发条件的情况下发送所述下发消息包括以下之一：

所述上报数据中的指定属性为第一指定值时，发送所述下发消息；

所述上报数据中的指定属性由第二指定值变为第三指定值时，发送所述下发消息；

所述上报数据中的指定属性在预定时长内保持为第四指定值时，发送所述下发消息。

8.一种消息下发装置，其特征在于，包括：

获取模块，用于获取消息下发配置界面中的参数，所述参数至少包括数据源；

生成模块，用于根据预设的配置规则对所述参数进行解析以生成所述数据源的消息下发规则；

下发模块，用于在所述数据源的上报数据满足下发条件的情况下，按照所述消息下发规则进行消息下发。

9.一种计算机可读存储介质，其特征在于，所述存储介质中存储有计算机程序，其中，所述计算机程序被设置为运行时执行所述权利要求1至7任一项中所述的方法。

10.一种电子装置，包括存储器和处理器，其特征在于，所述存储器中存储有计算机程序，所述处理器被设置为运行所述计算机程序以执行所述权利要求1至7任一项中所述的方法。

Images