CN114338738A - 基于Actor模型的规则引擎及场景联动实现方法 - Google Patents

Abstract

本申请提供一种基于Actor模型的规则引擎及场景联动实现方法，应用于物联网平台。第一Actor从预设数据库加载所有账户标识信息，生成每个账户标识信息对应的第二Actor。每个第二Actor根据自身账户标识信息对应的规则链生成第三Actor，每个第三Actor生成自身规则链下属的多个第四Actor，每个第四Actor根据业务类型生成不同的业务处理类，并确定自身对应的出关系列表。规则引擎基于各Actor形成，规则引擎进行数据流转和场景联动时，第一Actor至第四Actor都可以根据各自处理逻辑并行执行，为物联网平台提供了场景联动实现方法，提高了消息处理效率，有利于物联网平台的广泛应用。

Description

基于Actor模型的规则引擎及场景联动实现方法

技术领域

本申请涉及通信技术领域，尤其涉及一种基于Actor模型的规则引擎及场景联动实现方法。

背景技术

规则引擎的场景联动在物联网领域，特别是智能家居领域有着很重要的应用价值。场景联动已经成为物联网领域的核心应用之一，设备相互连接并且相互作用，催促着物联网领域不断向前发展。

物联网的场景联动总是条件触发的，触发点可能来着自于下端设备采集的设备数据，亦可能是上层应用的输入，又或是内在既定业务逻辑的驱动，这些自动化业务逻辑运转使得每个设备、场景、人等互相联动，这种规则模型称为TCA模型，一般由触发器(Trigger)、执行条件(Condition)、执行动作(Action)三个部分组成。

然而，目前开源的物联网平台大都缺乏场景联动的功能，又或者采用串行的模型来进行数据的流转处理，执行效率较低。

发明内容

本申请提供一种基于Actor模型的规则引擎及场景联动实现方法，基于Actor模型为物联网平台提供不同节点间的并行处理逻辑及执行方案，实现物联网平台的场景联动。

第一方面，本申请提供一种基于Actor模型的规则引擎，应用于物联网平台，包括：

第一Actor，用于从预设数据库加载所有账户标识信息，以生成每个账户标识信息对应的第二Actor；

所述每个第二Actor用于根据自身账户标识信息对应的规则链生成各自对应的一个或多个第三Actor，所述规则链包括各个账户标识信息与各条业务标识信息之间的映射关系，每条业务标识信息用于对应标识每条业务；

每个第三Actor用于生成自身规则链下属的多个第四Actor；

每个第四Actor，用于根据业务类型生成不同的业务处理类，并确定自身对应的出关系列表，所述出关系列表用于表征所述每个第四Actor在所述规则链中的拓扑关系。

在一种可能的设计中，所述第一Actor还用于根据账户标识信息将上报信息上报给对应的第二Actor；

所述每个第二Actor还用于接收所述待上报消息，并根据所述规则链将所述待上报消息上报给自身对应的所述每个第三Actor；

所述每个第三Actor还用于接收所述待上报消息，并根据首个第四Actor的节点标识信息将所述待上报消息上报给所述第四Actor中的首个第四Actor，所述每个第四Actor通过各自的节点标识信息唯一标识。

在一种可能的设计中，所述第一Actor在根据所述账户标识信息将所述上报信息上报给对应的第二Actor时，具体用于：

监听消息队列，以收到业务设备上报的所述待上报消息，所述待上报消息携带所述业务标识信息；

响应于所述待上报消息，根据所述业务标识信息获取对应的所述账户标识信息；

将所述待上报消息上报给所述账户标识信息对应的第二Actor。

在一种可能的设计中，当所述规则链发生更新时，所述每个第二Actor还用于接收更新消息，并响应于所述更新消息更新所述规则链，以及上报所述更新消息给所述每个第三Actor；

所述每个第三Actor还用于响应于所述更新消息，更新所述规则链，并上报所述更新消息给自身下属的所述每个第四Actor；

所述每个第四Actor还用于根据所述更新消息重新配置规则节点处理类。

在一种可能的设计中，所述每个第四Actor还用于根据所述更新消息重新配置规则节点处理类时，具体用于：

若所述更新消息包括节点配置更新消息，则关闭原始规则节点，并根据所述节点配置更新消息重新配置规则节点处理类。

第二方面，本申请提供一种场景联动实现方法，应用于第一方面提供的任意一种可能的基于Actor模型的规则引擎；所述方法，包括：

每个第三Actor根据目标路由关系将待处理消息发送给第四Actor中的首个第四Actor，所述目标路由关系用于表征所述每个第三Actor与所述第四Actor之间的设备对应关系，所述待处理消息符合所述业务的业务处理条件；

所述首个第四Actor将所述待处理消息透传给目标触发器，由所述目标触发器根据对所述待处理消息的判断结果将所述待处理消息透传给目标执行条件节点；

所述目标执行条件节点对所述待处理消息进行逻辑判断，并根据判断结果发送所述待处理消息给下级的多个执行动作节点，以使每个执行动作节点执行所述待处理消息对应的预设操作。

在一种可能的设计中，所述首个第四Actor将所述待处理消息透传给目标触发器，由所述目标触发器根据对所述待处理消息的判断结果将所述待处理消息透传给所述目标执行条件节点，包括：

所述首个第四Actor将所述待处理消息透传给所述目标触发器中的首个触发器；

所述首个触发器根据第一预设逻辑条件判断所述待处理消息是否为真；

若是，则所述首个触发器将所述待处理消息透传给过渡节点，由所述过渡节点透传所述待处理消息给所述目标执行条件节点；

若否，则所述首个触发器生成反馈消息，并回传所述反馈信息给所述首个第四Actor，所述首个第四Actor透传所述待处理消息给所述目标触发器中的另一个触发器。

在一种可能的设计中，所述目标执行条件节点用于对所述待处理消息进行逻辑判断，并根据判断结果发送所述待处理消息给下级的多个执行动作节点，包括：

首位执行条件节点根据第二预设逻辑条件判断所述待处理消息是否为真；

若是，则所述首位执行条件节点发送所述待处理消息给下一执行条件节点，所述下一执行条件节点根据所述第二预设逻辑条件继续判断所述待处理消息是否为真；

直到末位执行条件节点根据所述第二预设逻辑条件判断所述待处理消息为真时，所述末位执行条件节点同时发送所述待处理消息给所述下级的多个执行动作节点；

其中，所述目标执行条件节点包括所述首位执行条件节点、所述下一执行条件节点以及所述末位执行条件节点。

在一种可能的设计中，所述第二预设逻辑条件包括设备状态条件和/或时间范围条件；

所述设备状态条件是指所述规则引擎缓存的物联设备状态与所述待处理消息携带的物联设备状态是否一致，；

所述时间范围条件是指所述待处理消息携带的时间信息是否为当前时间。

在一种可能的设计中，所述预设操作包括设备操作和/或告警输出；

所述设备操作通过向所述待处理消息对应的业务设备发送对应操作指令实现；

所述告警输出包括生成所述待处理消息对应的告警信息，记录所述告警信息，或者推送所述告警信息至所述待处理信息指向的目标地址。

第三方面，本申请提供一种场景联动实现装置，包括：

发送模块，用于根据目标路由关系将待处理消息发送给第四Actor中的首个第四Actor，所述目标路由关系用于表征每个第三Actor与所述第四Actor之间的设备对应关系，所述待处理消息符合所述业务的业务处理条件；

第一处理模块，用于所述首个第四Actor将所述待处理消息透传给目标触发器，由所述目标触发器根据对所述待处理消息的判断结果将所述待处理消息透传给目标执行条件节点；

第二处理模块，用于所述目标执行条件节点对所述待处理消息进行逻辑判断，并根据判断结果发送所述待处理消息给下级的多个执行动作节点，以使每个执行动作节点执行所述待处理消息对应的预设操作。

第四方面，本申请提供一种电子设备，包括：处理器；以及，

存储器，用于存储计算机程序；

其中，所述处理器配置为经由执行所述计算机程序来执行第二方面所提供的任意一种可能的场景联动实现方法。

第五方面，本申请提供一种计算机可读存储介质，其上存储有计算机程序，所述计算机程序用于执行第二方面所提供的任意一种可能的场景联动实现方法。

第六方面，本申请还提供一种计算机程序产品，包括计算机程序，该计算机程序被处理器执行时实现第二方面所提供的任意一种可能的场景联动实现方法。

本申请提供一种基于Actor模型的规则引擎及场景联动实现方法，应用于物联网平台。规则引擎包括第一Actor、第二Actor、第三Actor及第四Actor。其中，第一Actor，用于从预设数据库加载所有账户标识信息，以生成每个账户标识信息对应的第二Actor。而每个第二Actor则用于根据自身账户标识信息对应的规则链生成各自对应的一个或多个第三Actor，规则链包括各个账户标识信息与各条业务标识信息之间的映射关系，每条业务标识信息用于对应标识每条业务。每个第三Actor用于生成自身规则链下属的多个第四Actor，而每个第四Actor用于根据业务类型生成不同的业务处理类，并确定自身对应的出关系列表。由于规则引擎基于各Actor构建而成，基于该规则引擎进行数据流转和场景联动时，第一Actor至各第四Actor都可以根据各自的处理逻辑并行执行，为物联网平台提供了一种场景联动实现方法，提高了消息处理效率，有利于在物联网平台的广泛应用。

附图说明

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

图1为本申请实施例提供的一种应用场景示意图；

图2为本申请实施例提供的一种规则引擎的启动流程示意图；

图3为本申请实施提供的一种规则引擎的数据流转的流程示意图；

图4为本申请实施例提供的一种更新流程示意图；

图5为本申请实施例提供的一种场景联动实现方法的流程示意图；

图6为本申请实施例提供的另一种场景联动实现方法的流程示意图；

图7为本申请实施例提供的再一种场景联动实现方法的流程示意图；

图8为本申请实施例提供的一种场景联动实现装置的结构示意图；

图9为本申请实施例提供的一种电子设备的结构示意图。

具体实施方式

这里将详细地对示例性实施例进行说明，其示例表示在附图中。下面的描述涉及附图时，除非另有表示，不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本申请相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本申请的一些方面相一致的方法和装置的例子。

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

场景联动已经成为物联网领域的核心应用之一，而目前开源的物联网平台大都缺乏场景联动的功能，又或者采用串行的模型来进行数据的流转处理，执行效率较低。

针对现有技术存在的上述问题，本申请提供一种基于Actor模型的规则引擎及场景联动实现方法，其应用于物联网平台。本申请的发明构思在于：Actor是计算机科学领域中的一个并行计算模型，将Actor当做通用的并行计算原语，一个Actor对接收到的消息做出响应，进行本地决策，则可以创建更多的Actor(子Actor)，或者发送更多的消息，同时还可以接收下一条消息。Actor模型在本质上是并发的，Actor之间仅通过发送消息进行通信，所有的操作都是异步的，不同的Actor可以同时处理各自的信息，使得所形成的整个系统可以获得大规模的并发能力，从而基于Actor模型形成的规则引擎，第一Actor至各第四Actor在数据流转及场景联动时都可以根据各自的处理逻辑并行执行，为物联网平台提供一种场景联动实现方法，提高并行执行效率，有利于物联网平台的广泛应用。

以下，对本申请实施例的示例性应用场景进行介绍。

图1为本申请实施例提供的一种应用场景示意图，如图1所示，本申请实施例提供的基于Actor模型的规则引擎可以应用于物联网平台，其包括第一Actor 100、第二Actor200、第三Actor 300及第四Actor 400，其中，第二Actor 200、第三Actor 300及第四Actor400各自的数量可以根据实际情况决定，对此本申请实施例不作限定。例如，在规则引擎中，第一Actor 100可以被配置为接入单元，启动第一Actor 100则表示启动该规则引擎。第二Actor200可以被配置为一个个的账户单元，每个账户单元都存在各自的业务。第三Actor300可以被配置为规则链单元，用于创建下属的各规则节点单元。而第四Actor 400即可被配置为规则节点单元，用于根据业务类型创建不同的业务处理类，支撑业务层面的业务逻辑规则。

第一Actor至第四Actor所构建成的规则引擎，基于Actor本身的功能属性，使得第一Actor至各第四Actor在数据流转及场景联动时都可以根据各自的处理逻辑并行执行，为物联网平台提供一种场景联动实现方法，提高消息处理效率。

可以理解的是，第一Actor 100至第四Actor 400各自可以配置有相应电子设备实现对应功能及步骤，电子设备的类型可以为智能终端、计算机、服务器、服务器集群等，图1中的均以服务器为例示出。各电子设备之间的连接可以形成一有向无环图，本申请实施例该有向无环图的具体连接不作限定。

需要说明的是，上述应用场景仅仅是示意性的，本申请实施例提供的基于Actor模型的规则引擎及场景联动方法包括但不仅限于上述应用场景。

下面以具体地实施例对本申请的技术方案以及本申请的技术方案如何解决上述技术问题进行详细说明。下面这几个具体的实施例可以相互结合，对于相同或相似的概念或过程可能在某些实施例中不再赘述。下面将结合附图，对本申请的实施例进行描述。

图2为本申请实施例提供的一种规则引擎的启动流程示意图。如图2所示，本申请实施例提供的基于Actor模型的规则引擎的启动流程包括：

S101：第一Actor从预设数据库加载所有账户标识信息，以生成每个账户标识信息对应的第二Actor。

开发人员通过配置第一Actor的职责，使得当启动规则引擎时，第一Actor可以从预设数据库中加载所有账户标识信息，根据每个账户标识信息生成各自对应的第二Actor，完成第二Actor的创建。预设数据库为提前预设，其中包括有规则引擎执行过程中所涉及到的各账户标识信息。

需要说明的是，在第一Actor加载账户标识信息之前，首先由开发人员创建第一Actor，以为规则引擎设置接入单元。

另外，当第一Actor接收到来自外部设备发送的的账户新增消息时，则根据该账户新增消息指征的账户标识信息新增第二Actor。外部设备可以理解为除过构成规则引擎的各Actor的其他任意设备。

S102：每个第二Actor根据自身账户标识信息对应的规则链生成各自对应的一个或多个第三Actor。

其中，规则链包括各个账户标识信息与各条业务标识信息之间的映射关系，每条业务标识信息用于对应标识每条业务。

开发人员通过配置每个第二Actor的职责，使得在规则引擎的启动流程中，每个第二Actor可以从预设数据库中加载其自身下属的各规则链，以生成自身对应的一个或多个第三Actor。

由于规则链包括有各个账户标识信息与各条业务标识信息之间的映射关系，因此每个第二Actor在生成自身对应的一个或多个第三Actor时，从预设数据库中根据自身账户标识信息加载属于自身的规则链，创建该规则链对应的一个或多个第三Actor。另外，各条业务标识信息分别用于对应标识每条业务，业务标识信息例如产品pk。每个第二Actor在创建自身对应的一个或多个第三Actor时需维护第二Actor与第三Actor之间设备对应关系，即路由关系。

需要说明的是，预设数据库中包括有每个第二Actor所涉及到的规则链。

S103：每个第三Actor生成自身规则链下属的多个第四Actor。

开发人员通过配置每个第三Actor的职责，使得在规则引擎的启动流程中，每个第三Actor可以创建自身所属规则链下的所有规则节点Actor，即多个第四Actor。

例如，每个第三Actor从预设数据库中加载自身规则链下的各规则节点，以生成多个第四Actor。

需要说明的是，预设数据库中包括有根据业务需要提前预设的需要设置的各规则节点。

S104：每个第四Actor根据业务类型进行自身的业务处理，并确定自身对应的出关系列表。

其中，出关系列表用于表征每个第四Actor在规则链中的拓扑关系。

开发人员通过配置每个第四Actor的职责，使得在规则引擎的启动流程中，每个第四Actor用于根据业务类型生成不同的业务处理类，并维护自身在规则链中的拓扑关系，即确定自身对应的出关系列表。本申请实施例对于业务类型的具体内容不做限定，其可以为信息初始化、业务操作等类型。

对于多个第四Actor而言，一个第四Actor后还可能对应有一个或多个的下一级的第四Actor，故而每个第四Actor需维护自身在规则链中的拓扑关系，即出关系列表，以链路到与其连接的下一个第四Actor，明确相互之间传输信息的路由关系。

本申请实施例提供的基于Actor模型的规则引擎，其应用于物联网平台，其中包括的第一Actor、第二Actor、第三Actor及第四Actor中的每个都为一Actor模型，都具备Actor模型所具备的功能。从而开发人员通过配置每个Actor的职责，使得在规则引擎的启动流程中，每个Actor都可以根据各自的处理逻辑并行执行相应业务，为物联网平台场景联动的实现提供前提条件。

在上述实施例的基础上，图3为本申请实施提供的一种规则引擎的数据流转的流程示意图。如图3所示，本申请实施例提供的基于Actor模型的规则引擎的数据流转，包括：

S201：第一Actor根据账户标识信息将上报信息上报给对应的第二Actor。

第一Actor根据账户标识信息所标识的第二Actor，将自身接收到的待上报消息上报给账号标识信息所标识的第二Actor。

例如，第一Actor监听消息队列，接收业务设备上报的待上报消息，其中该待上报消息可以携带有标识业务的业务标识信息，例如产品pk。然后，第一Actor响应于该待上报消息，根据规则链中业务标识信息与账户标识信息之间的映射关系，获取到业务标识信息对应的账户标识信息，从而将待上报消息可以直接上报给该账户标识信息所标识的对应第二Actor。

S202：每个第二Actor接收待上报消息，并根据规则链将待上报消息上报给自身对应的每个第三Actor。

每个第二Actor接收待上报消息，并根据规则链中自身所维护的第二Actor与第三Actor之间的设备对应关系，将待上报消息上报给自身对应的每个第三Actor。

S203：每个第三Actor接收待上报消息，并根据首个第四Actor的节点标识信息将待上报消息上报给第四Actor中的首个第四Actor。

其中，每个第四Actor通过各自的节点标识信息唯一标识。

每个第三Actor接收待上报消息，并根据每个第四Actor Actor的节点标识信息，向对应的第四Actor上报待上报消息。

具体地，每个第三Actor首先根据首个第四Actor的节点标识信息将待上报消息上报给首个第四Actor，首个第四Actor的节点标识信息例如first Rule Node Id。首个第四Actor收到待上报消息后，会进行自身的业务逻辑处理，在处理完后会根据其维护的出关系列表将待上报消息和处理结果发送给下一级的第四Actor进行处理。

进一步地，下一级的第四Actor收到待上报消息后，同样进行自身的业务逻辑处理，处理完毕根据维护的出关系列表将自身的处理结果和待上报消息又发送给自身下一级的第四Actor，循环进行，直到没有满足处理结果的出关系为止。

需要说明的是，本申请实施例对于待上报消息的具体内容不作限定。

本申请实施例提供的基于Actor模型的规则引擎，其应用于物联网平台，其中包括的第一Actor、第二Actor、第三Actor及第四Actor中的每个都为一Actor模型，都具备Actor模型所具备的功能。各Actor之间的数据流转遵循Actor模型的并行功能，使得本申请实施例提供的规则引擎在业务处理过程中的数据流转中，每个Actor都可以根据各自的处理逻辑并行执行相应业务，为物联网平台场景联动的实现提供前提条件。

在一些实施例中，可能会由于一些操作导致规则链需要更新，鉴于此，本申请实施例还提供了如图4所示的更新流程的可能实现方式。图4为本申请实施例提供的一种更新流程示意图，如图4所示，本申请实施例包括：

S301：每个第二Actor接收更新消息，响应于更新消息更新规则链，上报更新消息给每个第三Actor。

当规则链需要进行更新时，即规则链发生更新时，每个第二Actor则会接收到来自外部发送的更新信息，继而响应于该更新消息更新规则链，比如重新从预设数据库中加载规则链，并上报更新消息给每个第三Actor。

S302：每个第三Actor响应于更新消息，更新规则链，并上报更新消息给自身下属的每个第四Actor。

每个第三Actor接收到更新消息后，响应于更新消息更新自身规则链，比如从预设数据库中重新加载自身规则链，以更新自身下属的各规则节点，并将更新消息上报给自身下属的每个第四Actor。

S303：每个第四Actor根据更新消息重新配置规则节点处理类。

每个第四Actor接收到更新消息后，根据更新消息可以重新构造规则节点处理类。

比如，若更新消息中包括有规则节点的变更消息，即节点配置更新消息，则第四Actor会关闭之前的原始规则节点，并根据节点配置更新消息重新配置规则节点处理类，相当于重建规则节点。

本申请实施例提供的基于Actor模型的规则引擎，其应用于物联网平台，其中包括的第一Actor、第二Actor、第三Actor及第四Actor中的每个都为一Actor模型，都具备Actor模型所具备的并行计算功能。当规则链需要更新时，则各Actor都遵循Actor模型的并行功能，根据各自的处理逻辑并行执行相应业务，并根据更新消息完成规则引擎中各组件的更新流程，便于规则引擎的正常运行。

规则引擎作为物联网平台的一个重要模块，是处理复杂逻辑的引擎，主要对感知层搜集的数据进行筛选、变型(物解析)、转发、操作等，以实现数据逻辑和上层业务的解耦。通常分为数据转发和设备联动两个子功能，设备联动的应用场景即为场景联动。

在上述各实施例提供的任意一种基于Actor模型的规则引擎的基础上，图5为本申请实施例提供的一种场景联动实现方法的流程示意图。如图5所示，本申请实施例提供的场景联动实现方法包括：

S401：每个第三Actor根据目标路由关系将待处理消息发送给第四Actor中的首个第四Actor。

其中，目标路由关系用于表征每个第三Actor与第四Actor之间的设备对应关系，待处理消息符合业务的业务处理条件。

每个第三Actor根据其与第四Actor之间的设备对应关系将待处理消息发送给第四Actor中的首个第四Actor，以使得每个第四Actor作为规则节点进行业务逻辑处理。其中，待处理消息是指满足业务的业务处理条件的相应消息，本申请实施例对于业务处理条件的具体内容不作限定。

S402：首个第四Actor将待处理消息透传给目标触发器，由目标触发器根据对待处理消息的判断结果将待处理消息透传给目标执行条件节点。

物联网的场景联动总是条件触发的，其实现过程可以由TCA模型得以实现，TCA模型由触发器(Trigger)、执行条件(Condition)、执行动作(Action)三个部分组成。

故而，首个第四Actor可以将待处理消息发送给TCA模型中的触发器，即目标触发器，再由目标触发器根据对待处理消息的判断结果将待处理消息发送给目标执行条件节点。

其中，为了使得待处理消息在首个第四Actor的该规则节点中仅传递一次，则可以将首个第四Actor的该规则节点设置为或关系虚拟节点，即首个第四Actor会透传其收到的所有消息，当第四Actor对应的规则节点中有一个执行为成功，则不再分发消息，进而首个第四Actor会将待处理消息透传给目标触发器。

进一步地，还可以将目标触发器中的各触发器之间的关系也设置为或，即只要一个触发器满足条件则会触发后续规则的执行。因此，目标触发器可以根据待处理消息的判断结果将待处理消息透传给目标执行条件节点。

在一种可能的设计中，本步骤S402可能的实现方式如图6所示。图6为本申请实施例提供的另一种场景联动实现方法的流程示意图。如图6所示，本申请实施例包括：

S4021：首个第四Actor将待处理消息透传给目标触发器中的首个触发器。

S4022：首个触发器根据第一预设逻辑条件判断待处理消息是否为真。

S4023a：若是，则首个触发器将待处理消息透传给过渡节点，由过渡节点透传待处理消息给目标执行条件节点。

S4023b：若否，则首个触发器生成反馈消息，并回传反馈信息给首个第四Actor，首个第四Actor透传待处理消息给目标触发器中的另一个触发器。

目标触发器中包括有多个触发器，例如首个触发器和另一个触发器等等，可以通过预设编码的方式，为每个触发器依次排序，首个第四Actor先透传待处理消息给首个触发器，比如首个触发器，本申请实施例对于触发器的数量不作限定。

首个第四Actor将待处理消息透传给目标触发器中的首个触发器，由首个触发器根据第一预设逻辑条件判断待处理消息是否为真，若为真，即判断结果为是，则由该首个触发器将待处理消息透传为过渡节点。反之，若不为真，即判断结果为否，则首个触发器会生成反馈消息，并回传反馈消息给首个第四Actor，以表示根据第一预设逻辑条件判断待处理消息不满足条件，进而由首个第四Actor将待处理消息透传给目标触发器中的另一个触发器。

进一步地，若另一个触发器对待处理消息的判断结果满足条件，即根据第一预设逻辑条件判断待处理消息为真，则透传待处理消息给过渡节点。反之，则另一个触发器执行步骤S4023b的步骤，其目的在于只要目标触发器中有一个触发器对待处理消息的判断结果满足条件。

在一种可能的设计中，第一预设逻辑条件可以根据目标触发器的类型进行设置，目标触发器的类型可以包括设备触发和定时触发，设备触发可以通过判断待处理消息是否满足指定条件来判断是否触发成功，若满足即为触发成功，待处理消息为真。反之，则待处理消息不为真。定时触发可以通过定时任务来触发，定时任务可以包含规则链的标识消息，其中目标路由关系就是直接通过规则链的标识消息路由到特定规则链。

另一方面，过渡节点可以设置为与关系虚拟节点，其作用在于聚合前面目标触发器透传的消息，并透传给与自身连接的目标执行条件节点。例如，当目标触发器中有一个触发器对待处理消息的判断结果满足条件时，则该触发器透传待处理消息给过渡节点，再由过渡节点透传给目标执行条件节点。

S403：目标执行条件节点对待处理消息进行逻辑判断，并根据判断结果发送待处理消息给下级的多个执行动作节点，以使每个执行动作节点执行待处理消息对应的预设操作。

目标执行条件节点接收到待处理消息后，首先进行逻辑判断，再根据判断结果将待处理消息发送给与其连接的多个执行动作节点，使得每个执行动作节点执行待处理消息对应的预设操作。

在一种可能的设计中，步骤S403中目标执行条件节点可能的实现方式如图7所示，图7为本申请实施例提供的再一种场景联动实现方法的流程示意图。如图7所示，本申请实施例包括：

S501：首位执行条件节点根据第二预设逻辑条件判断待处理消息是否为真。

目标执行条件节点可以设置有线式分布的多个执行条件节点，依次可以包括首位执行条件节点、下一执行条件节点以及末位执行条件节点，其中下一执行条件节点是对首位执行条件节点和末位执行条件节点之间的执行条件节点的统称。

过渡节点透传待处理消息给目标执行条件节点时，其实质是透传给了首位执行条件节点，该首位执行条件节点与过渡节点连接。首位执行条件节点根据第二预设逻辑条件对待处理消息进行判断，以确定其是否为真。若为真，则执行步骤S502，若不为真，则结束待处理消息的传递。

在一种可能的设计中，第二预设逻辑条件包括设备状态条件和/或时间范围条件。

设备状态条件可以是规则引擎缓存的物联设备状态与待处理消息携带的物联设备状态是否一致，若一致，则为真，反之则不为真。其中，物联设备状态是指能够表征业务设备的当前状态的所有信息。

时间范围条件可以是待处理消息携带的时间信息是否为当前真实的物理时间也即当前时间。

S502：若是，则首位执行条件节点发送待处理消息给与下一执行条件节点，下一执行条件节点根据第二预设逻辑条件继续判断待处理消息是否为真。

S503：直到末位执行条件节点根据第二预设逻辑条件判断待处理消息为真时，末位执行条件节点同时发送待处理消息给下级的多个执行动作节点。

在首位执行条件根据第二预设逻辑条件对待处理消息进行判断后得到的判断结果为真时，首位执行条件节点发送待处理消息给下一执行条件节点，由下一执行条件节点根据第二预设逻辑条件继续判断待处理消息是否为真。若为真，则发送待处理消息给末位执行条件节点，直到末位执行条件节点判断结果也为真时，由末位执行条件节点将待处理消息同时发送给下级的多个执行动作节点，其中末位执行条件节点同时连接有多个执行动作节点。

目标执行条件节点中各执行条件节点均需根据第二预设判断条件判断待处理消息为真，否则结束待处理消息的传递。

每个执行动作节点接收到目标执行条件节点发送的待处理消息后，则执行待处理消息对应的预设操作，每个执行结果执行成功或失败均互不影响。

在一种可能的设计中，预设操作包括设备操作和/或告警输出。例如，设备操作可以通过向待处理消息对应的业务设备发送对应操作指令得以实现。告警输出可以包括生成待处理消息对应的告警信息，还可以记录告警信息，或者推送该告警信息至待处理信息指向的目标地址。可以理解的是，本申请实施例对于设备操作及告警信息的具体内容不作限定。

本申请实施例提供的场景联动实现方法，应用于基于Actor模型的规则引擎，将场景联动实现方案中的组件设计为包括有第三Actor、第四Actor中的首个第四Actor以及TCA模型的各组成部分，并设置了待处理消息在各组件之间的数据流转流程，由于Actor具备并行计算功能，从而使得基于Actor模型的规则引擎在实现的设备联动功能时，可以并发执行，极大地提高了消息处理效率，有利于在物联网平台的广泛应用。

图8为本申请实施例提供的一种场景联动实现装置的结构示意图。如图8所示，本申请实施例提供的场景联动实现装置600，包括：

发送模块601，用于根据目标路由关系将待处理消息发送给第四Actor中的首个第四Actor，目标路由关系用于表征每个第三Actor与第四Actor之间的设备对应关系，待处理消息符合业务的业务处理条件；

第一处理模块602，用于首个第四Actor将待处理消息透传给目标触发器，由目标触发器根据对待处理消息的判断结果将待处理消息透传给目标执行条件节点；

第二处理模块603，用于目标执行条件节点对待处理消息进行逻辑判断，并根据判断结果发送待处理消息给下级的多个执行动作节点，以使每个执行动作节点执行待处理消息对应的预设操作。

在一种可能的设计中，第一处理模块602，包括：

透传模块，用于将待处理消息透传给目标触发器中的首个触发器；

第一判断模块，用于根据第一预设逻辑条件判断待处理消息是否为真；

若是，透传模块，还用于将待处理消息透传给过渡节点，由过渡节点透传待处理消息给目标执行条件节点；

若否，生成模块，用于生成反馈消息，透传模块，用于回传反馈信息给首个第四Actor，首个第四Actor透传待处理消息给目标触发器中的另一个触发器。

在一种可能的设计中，第二处理模块603，包括：

第二判断模块，用于根据第二预设逻辑条件判断待处理消息是否为真；

若是，发送模块601，还用于发送待处理消息给下一执行条件节点，下一执行条件节点根据第二预设逻辑条件继续判断待处理消息是否为真；

第二判断模块，还用于直到根据第二预设逻辑条件判断待处理消息为真时，末位执行条件节点同时发送待处理消息给下级的多个执行动作节点。

其中，目标执行条件节点包括首位执行条件节点、下一执行条件节点以及末位执行条件节点。

在一种可能的设计中，第二预设逻辑条件包括设备状态条件和/或时间范围条件；

设备状态条件是指规则引擎缓存的物联设备状态与待处理消息携带的物联设备状态是否一致；

时间范围条件是指待处理消息携带的时间信息是否为当前时间。

在一种可能的设计中，预设操作包括设备操作和/或告警输出；

设备操作通过向待处理消息对应的业务设备发送对应操作指令实现；

告警输出包括生成待处理消息对应的告警信息，记录告警信息，或者推送告警信息至待处理信息指向的目标地址。

本申请实施例提供的场景联动实现装置，可以执行上述方法实施例中的场景联动实现方法的相应步骤，其实现原理和技术效果类似，在此不再赘述。

图9为本申请实施例提供的一种电子设备的结构示意图。如图9所示，该电子设备700可以包括：至少一个处理器701和存储器702。图9示出的是以一个处理器为例的电子设备。

存储器702，用于存放程序。具体地，程序可以包括程序代码，程序代码包括计算机执行指令。

存储器702可能包含高速RAM存储器，也可能还包括非易失性存储器(MoM-volatile memory)，例如至少一个磁盘存储器。

处理器701用于执行存储器702存储的计算机程序，以实现场景联动实现方法。

其中，处理器701可能是一个中央处理器(CeMtral ProcessiMg UMit，简称为CPU)，或者是特定集成电路(ApplicatioM Specific IMtegrated Circuit，简称为ASIC)，或者是被配置成实施本申请实施例的一个或多个集成电路。

可选地，存储器702既可以是独立的，也可以跟处理器701集成在一起。当存储器702是独立于处理器701之外的器件时，电子设备700，还可以包括：

总线703，用于连接处理器701以及存储器702。总线可以是工业标准体系结构(industry standard architecture，简称为ISA)总线、外部设备互连(peripheralcomponent，PCI)总线或扩展工业标准体系结构(extended industry standardarchitecture，EISA)总线等。总线可以分为地址总线、数据总线、控制总线等，但并不表示仅有一根总线或一种类型的总线。

可选的，在具体实现上，如果存储器702和处理器701集成在一块芯片上实现，则存储器702和处理器701可以通过内部接口完成通信。

本申请还提供了一种计算机可读存储介质，该计算机可读存储介质可以包括：U盘、移动硬盘、只读存储器(ROM，Read-OMly Memory)、随机存取存储器(RAM，RaMdomAccessMemory)、磁盘或者光盘等各种可以存储程序代码的介质，具体的，该计算机可读存储介质中存储有程序指令，程序指令用于上述实施例中场景联动实现方法。

本申请还提供了一种计算机程序产品，包括计算机程序，该计算机程序被处理器执行时实现上述实施例中场景联动实现方法。

本领域技术人员在考虑说明书及实践这里公开的发明后，将容易想到本申请的其它实施方案。本申请旨在涵盖本申请的任何变型、用途或者适应性变化，这些变型、用途或者适应性变化遵循本申请的一般性原理并包括本申请未公开的本技术领域中的公知常识或惯用技术手段。说明书和实施例仅被视为示例性的，本申请的真正范围和精神由权利要求书指出。

应当理解的是，本申请并不局限于上面已经描述并在附图中示出的精确结构，并且可以在不脱离其范围进行各种修改和改变。本申请的范围仅由所附的权利要求书来限制。

Claims (13)

1.一种基于Actor模型的规则引擎，其特征在于，应用于物联网平台，包括：

第一Actor，用于从预设数据库加载所有账户标识信息，以生成每个账户标识信息对应的第二Actor；

所述每个第二Actor用于根据自身账户标识信息对应的规则链生成各自对应的一个或多个第三Actor，所述规则链包括各个账户标识信息与各条业务标识信息之间的映射关系，每条业务标识信息用于对应标识每条业务；

每个第三Actor用于生成自身规则链下属的多个第四Actor；

每个第四Actor，用于根据业务类型生成不同的业务处理类，并确定自身对应的出关系列表，所述出关系列表用于表征所述每个第四Actor在所述规则链中的拓扑关系。

2.根据权利要求1所述的规则引擎，其特征在于，所述第一Actor还用于根据账户标识信息将上报信息上报给对应的第二Actor；

所述每个第二Actor还用于接收所述待上报消息，并根据所述规则链将所述待上报消息上报给自身对应的所述每个第三Actor；

所述每个第三Actor还用于接收所述待上报消息，并根据首个第四Actor的节点标识信息将所述待上报消息上报给所述第四Actor中的首个第四Actor，所述每个第四Actor通过各自的节点标识信息唯一标识。

3.根据权利要求2所述的规则引擎，其特征在于，所述第一Actor在根据所述账户标识信息将所述上报信息上报给对应的第二Actor时，具体用于：

监听消息队列，以收到业务设备上报的所述待上报消息，所述待上报消息携带所述业务标识信息；

响应于所述待上报消息，根据所述业务标识信息获取对应的所述账户标识信息；

将所述待上报消息上报给所述账户标识信息对应的第二Actor。

4.根据权利要求1-3任一项所述的规则引擎，其特征在于，当所述规则链发生更新时，所述每个第二Actor还用于接收更新消息，并响应于所述更新消息更新所述规则链，以及上报所述更新消息给所述每个第三Actor；

所述每个第三Actor还用于响应于所述更新消息，更新所述规则链，并上报所述更新消息给自身下属的所述每个第四Actor；

所述每个第四Actor还用于根据所述更新消息重新配置规则节点处理类。

5.根据权利要求4所述的规则引擎，其特征在于，所述每个第四Actor还用于根据所述更新消息重新配置规则节点处理类时，具体用于：

若所述更新消息包括节点配置更新消息，则关闭原始规则节点，并根据所述节点配置更新消息重新配置规则节点处理类。

6.一种场景联动实现方法，其特征在于，应用于权利要求1-5中任一项所述的基于Actor模型的规则引擎；所述方法，包括：

每个第三Actor根据目标路由关系将待处理消息发送给第四Actor中的首个第四Actor，所述目标路由关系用于表征所述每个第三Actor与所述第四Actor之间的设备对应关系，所述待处理消息符合所述业务的业务处理条件；

所述首个第四Actor将所述待处理消息透传给目标触发器，由所述目标触发器根据对所述待处理消息的判断结果将所述待处理消息透传给目标执行条件节点；

所述目标执行条件节点对所述待处理消息进行逻辑判断，并根据判断结果发送所述待处理消息给下级的多个执行动作节点，以使每个执行动作节点执行所述待处理消息对应的预设操作。

7.根据权利要求6所述的场景联动实现方法，其特征在于，所述首个第四Actor将所述待处理消息透传给目标触发器，由所述目标触发器根据对所述待处理消息的判断结果将所述待处理消息透传给所述目标执行条件节点，包括：

所述首个第四Actor将所述待处理消息透传给所述目标触发器中的首个触发器；

所述首个触发器根据第一预设逻辑条件判断所述待处理消息是否为真；

若是，则所述首个触发器将所述待处理消息透传给过渡节点，由所述过渡节点透传所述待处理消息给所述目标执行条件节点；

若否，则所述首个触发器生成反馈消息，并回传所述反馈信息给所述首个第四Actor，所述首个第四Actor透传所述待处理消息给所述目标触发器中的另一个触发器。

8.根据权利要求7所述的场景联动实现方法，其特征在于，所述目标执行条件节点用于对所述待处理消息进行逻辑判断，并根据判断结果发送所述待处理消息给下级的多个执行动作节点，包括：

首位执行条件节点根据第二预设逻辑条件判断所述待处理消息是否为真；

若是，则所述首位执行条件节点发送所述待处理消息给下一执行条件节点，所述下一执行条件节点根据所述第二预设逻辑条件继续判断所述待处理消息是否为真；

直到末位执行条件节点根据所述第二预设逻辑条件判断所述待处理消息为真时，所述末位执行条件节点同时发送所述待处理消息给所述下级的多个执行动作节点；

其中，所述目标执行条件节点包括所述首位执行条件节点、所述下一执行条件节点以及所述末位执行条件节点。

9.根据权利要求7或8所述的场景联动实现方法，其特征在于，所述第二预设逻辑条件包括设备状态条件和/或时间范围条件；

所述设备状态条件是指所述规则引擎缓存的物联设备状态与所述待处理消息携带的物联设备状态是否一致；

所述时间范围条件是指所述待处理消息携带的时间信息是否为当前时间。

10.根据权利要求9所述的场景联动实现方法，其特征在于，所述预设操作包括设备操作和/或告警输出；

所述设备操作通过向所述待处理消息对应的业务设备发送对应操作指令实现；

所述告警输出包括生成所述待处理消息对应的告警信息，记录所述告警信息，或者推送所述告警信息至所述待处理信息指向的目标地址。

11.一种场景联动实现装置，其特征在于，包括：

发送模块，用于根据目标路由关系将待处理消息发送给第四Actor中的首个第四Actor，所述目标路由关系用于表征每个第三Actor与所述第四Actor之间的设备对应关系，所述待处理消息符合所述业务的业务处理条件；

第一处理模块，用于所述首个第四Actor将所述待处理消息透传给目标触发器，由所述目标触发器根据对所述待处理消息的判断结果将所述待处理消息透传给目标执行条件节点；

第二处理模块，用于所述目标执行条件节点对所述待处理消息进行逻辑判断，并根据判断结果发送所述待处理消息给下级的多个执行动作节点，以使每个执行动作节点执行所述待处理消息对应的预设操作。

12.一种电子设备，其特征在于，包括：处理器；以及，

存储器，用于存储计算机程序；

其中，所述处理器配置为经由执行所述计算机程序来执行权利要求6至10任一项所述的场景联动实现方法。

13.一种计算机可读存储介质，其上存储有计算机程序，其特征在于，所述计算机程序被处理器执行时实现权利要求6至10任一项所述的场景联动实现方法。

Images