CN110569056B - 一种规则服务信息的更新方法及装置 - Google Patents

Abstract

本发明实施例公开了一种规则服务信息的更新方法，包括：当规则服务后台检测到有更新的规则服务信息后，将更新的规则服务信息保存到ZK系统相对应的ZK节点中；运行在docker容器中的执行引擎通过docker容器的应用标识定位ZK节点，并监听ZK节点中是否有有更新的规则服务信息；所述docker容器的应用标识与所述ZK节点存在关联关系；当运行在docker容器中的执行引擎监听到ZK节点中有更新的规则服务信息时，所述执行引擎根据ZK节点中存储的规则服务信息，更新所述执行引擎中的规则服务信息。这样，实现了对docker容器中的执行引擎中的规则服务信息的及时更新。

Description

一种规则服务信息的更新方法及装置

技术领域

本发明涉及数据处理领域，尤其涉及一种规则服务信息的更新方法及装置。

背景技术

当前，很多业务在上线后需要进行风险控制，风险控制主要是对访问业务的数据进行识别，确定风险等级，并将风险等级反馈给业务方。其中，一个业务中包含有多个微服务，不同的微服务可以实现不同的功能，为了对每个微服务进行防护，在每个微服务的docker的执行引擎中设置了用于风险控制的规则服务信息，并且，在微服务发生改变后，用于风险控制的规则服务信息也需要进行更新。规则服务信息存储于后台服务器中，后台服务器一般是通过docker容器的IP地址定位docker容器，并将更新后的规则信息发送给docker容器的执行引擎。

但是，现有技术中，在对微服务改造时，docker容器会因为重启而改变IP地址，在这种情况下，后台服务器无法定位到docker容器，也就无法及时的更新docker容器的执行引擎中的规则服务信息，也就无法对业务进行有效的风险控制。

发明内容

有鉴于此，本发明实施例公开了一种规则服务信息的更新方法，解决了现有技术中，由于docker容器IP地址发生改变，无法及时的更新运行在docker容器中的执行引擎中的规则服务信息的问题。

本发明实施例公开了一种规则服务信息的更新方法，包括：

当规则服务后台检测到有更新的规则服务信息后，将所述更新的规则服务信息保存到ZK系统中相对应的ZK节点中；

运行在docker容器中的执行引擎通过docker容器的应用标识定位ZK节点，并监听ZK节点中是否有更新的规则服务信息；所述docker容器的应用标识与所述ZK节点存在关联关系；

当运行在docker容器中的执行引擎监听到ZK节点中有更新的规则服务信息时，所述执行引擎根据ZK节点中存储的规则服务信息，更新所述执行引擎中的规则服务信息。

可选的，所述当规则服务后台检测到有更新的规则服务信息后，将所述更新的规则服务信息保存到ZK系统中相对应的ZK节点中，包括：

若ZK系统中的第一ZK节点中存储有所述更新的规则服务信息的历史版本，将所述更新的规则服务信息存储到所述第一ZK节点中；

若所述ZK系统中没有任何一个ZK节点中存储有所述更新的规则服务信息的历史版本，创建新的路径，并将所述更新的规则服务信息存储到创建的所述新的路径对应的第二ZK节点中。

可选的，所述运行在docker容器中的执行引擎通过docker容器的应用标识定位ZK节点，包括：

所述docker容器中的执行引擎确定包含docker容器的应用标识的ZK节点的路径；

通过包含有docker容器的应用标识的ZK节点的路径定位ZK节点。

可选的，还包括：

所述规则服务后台响应于更新检测指令，判断所述执行引擎中的规则服务信息与所述更新的规则服务信息是否一致；

若所述执行引擎中的规则服务信息与所述更新的规则服务信息不一致，向所述ZK节点发送回滚指令，以使所述ZK节点基于历史操作进行回滚。

可选的，还包括：

所述规则服务后台响应于定期巡检指令，判断所述规则服务后台中的目标规则服务信息、存储所述目标规则服务信息的ZK节点中的目标规则服务信息以及docker容器中的目标规则服务信息是否一致；

若所述规则服务后台中的目标规则服务信息、存储所述目标规则服务信息的ZK节点中的目标规则服务信息以及docker容器中的目标规则服务信息不一致，则发起异常告警；

确定异常告警产生的原因。

本发明实施例还公开了一种规则服务信息的更新装置，该装置包括：

推送单元，用于当规则服务后台检测到有更新的规则服务信息后，将所述更新的规则服务信息保存到ZK系统中相对应的ZK节点中；

监听单元，用于运行在docker容器中的执行引擎通过docker容器的应用标识定位ZK节点，并监听ZK节点中是否有更新的规则服务信息；所述docker容器的应用标识与所述ZK节点存在关联关系；

更新单元，用于当运行在docker容器中的执行引擎监听到ZK节点中有更新的规则服务信息时，所述执行引擎根据ZK节点中存储的规则服务信息，更新所述执行引擎中的规则服务信息。

可选的，所述推送单元，包括：

第一推送子单元，用于若ZK系统中的第一ZK节点中存储有所述更新的规则服务信息的历史版本，将所述更新的规则服务信息存储到所述第一ZK节点中；

第二推送子单元，用于若所述ZK系统中没有任何一个ZK节点中存储有所述更新的规则服务信息的历史版本，创建新的路径，并将所述更新的规则服务信息存储到创建的新的路径对应的第二ZK节点中。

可选的，所述监听单元，包括：

确定子单元，用于所述docker容器中的执行引擎确定包含docker容器的应用标识的ZK节点的路径；

定位子单元，用于通过包含有docker容器的应用标识的ZK节点的路径定位ZK节点。

可选的，还包括：

第一判断单元，用于所述规则服务后台响应于更新检测指令，判断所述执行引擎中的规则服务信息与所述更新的规则服务信息是否一致；

回滚单元，用于若所述执行引擎中的规则服务信息与所述更新的规则服务信息不一致，向所述ZK节点发送回滚指令，以使所述ZK节点基于历史操作进行回滚。

可选的，还包括：

第二判断单元，用于所述规则服务后台响应于定期巡检指令，判断所述规则服务后台中的目标规则服务信息、存储所述目标规则服务信息的ZK节点中的目标规则服务信息以及docker容器中的目标规则服务信息是否一致；

异常告警单元，用于若所述规则服务后台中的目标规则服务信息、存储所述目标规则服务信息的ZK节点中的目标规则服务信息以及docker容器中的目标规则服务信息不一致，则发起异常告警；

原因确定单元，用于确定异常告警产生的原因。

本发明实施例公开了一种规则服务信息的更新方法，包括：当规则服务后台检测到有更新的规则服务信息后，将更新的规则服务信息保存到ZK系统相对应的ZK节点中；运行在docker容器中的执行引擎通过docker容器的应用标识定位ZK节点，并监听ZK节点中是否有有更新的规则服务信息；所述docker容器的应用标识与所述ZK节点存在关联关系；当运行在docker容器中的执行引擎监听到ZK节点中有更新的规则服务信息时，所述执行引擎根据ZK节点中存储的规则服务信息，更新所述执行引擎中的规则服务信息。这样，实现了对docker容器中的执行引擎中的规则服务信息的及时更新，并且本方案是通过docker容器的应用标识与ZK节点之间的关系定位ZK节点，这就使得docker容器中的执行引擎中的规则服务信息的更新不再依赖于docker容器的IP地址，除此之外，由于docker容器的应用标识是不会发生改变的，解决了由于IP地址的改变从而使得docker容器中的执行引擎中的规则服务信息无法及时更新的问题。

附图说明

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

图1示出了本发明实施例提供的一种规则服务信息的更新方法的流程示意图；

图2示出了ZK系统的树形结构示意图；

图3示出了本发明实施例公开的规则服务信息的更新装置的结构示意图。

实施方式

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

参考图1，示出了本发明实施例提供的一种规则服务信息的更新方法的流程示意图，在本实施例中，该方法包括：

S101：当规则服务后台检测到有更新的规则服务信息后，将所述更新的规则服务信息保存到ZK系统中相对应的ZK节点中；

本实施例中，ZK系统为Zookeerer系统，是一种分布式系统。

其中，Z系统中包括至少一个ZK节点，每个ZK节点中可以存储数据，例如存储规则服务信息，当需要访问ZK节点中的数据，需要通过ZK节点的路径找到该ZK节点。

但是若要新生成一个新的ZK节点，需要在ZK系统中先创建一个路径，并将ZK节点挂靠在该路径上。

举例说明：如图2所示，ZK系统采用树形结构层次化的目录结构，每个目录叫做一个ZK节点，每个ZK节点拥有一个唯一的路径标识，例如一个路径标识为:mubiao/zimubiao，或者另外一个路径标识为：yejiedian/1 yejiedian通过该路径可以找到在该路径下的ZK节点，该ZK节点中可以存储数据。

本实施例中，将规则服务信息存储到ZK节点中，并且，在规则服务信息出现更新的情况下，或者可以理解为在规则服务信息的版本更新的情况下，可以将更新的规则服务信息替换掉之前的版本，但是对于一种新的规则服务信息，则需要创建新的路径，并将该新的规则服务信息存储在该新的路径对应的ZK节点中，具体的，S101包括：

若ZK系统中的第一ZK节点中存储有所述更新的规则服务信息的历史版本，将所述更新的规则服务信息存储到所述第一ZK节点中；

若所述ZK系统中没有任何一个ZK节点中存储有所述更新的规则服务信息的历史版本，创建新的路径，并将所述更新的规则服务信息存储到创建的新的路径对应的第二ZK节点中。

本实施例中，若ZK系统中没有任何一个ZK节点中存储有所述更新的规则服务信息的历史版本，则可以理解为该更新的规则服务信息为一种新的规则服务信息，对于新的规则服务信息。

举例说明：对于规则服务信息1，ZK节点中存储有该规则服务信息1的某一个版本，但是当该规则服务信息1更新后，即规则服务后台中出现了新版本的规则服务信息1，将新版本的规则服务信息1替换ZK节点中存储的历史版本的规则服务信息。但是若新生成了规则服务信息2，该新的规则服务信息是未在ZK节点中存储的，那么需要创建新的路径，在新的节点中存储该规则服务信息2。

S102：运行在docker容器中的执行引擎通过docker容器的应用标识定位ZK节点，并监听ZK节点中是否有更新的规则服务信息；所述docker容器的应用标识与所述ZK节点存在关联关系；

本实施例中，docker容器的应用标识与所述ZK节点的关系可以有多种形式，在本实施例中不进行限定，例如可以通过如下的两种方式实现：

方式一、docker容器的应用标识与所述ZK节点存在映射关系，即在生成了ZK节点后，设置了ZK节点和docker容器的应用标识的映射关系。

由此，通过上述预先设置的ZK节点和docker容器的应用标识的映射关系， docker容器中的执行引擎可以通过docker容器的应用标识找到ZK节点，进而获取到ZK节点中的规则服务信息。

方式二、将docker容器的应用标识设置到ZK节点的路径中，那么也就建立了ZK节点和docker容器的应用标识的关系。

举例说明：对于ZK节点路径的设计，可以包括如下的信息：工程信息，工业信息、docker容器的应用标识和规则版本信息，例如ZK节点的路径设计如下：

/projects/${project_name}/${app_name}/${business_name}/${rule_set_id}；

其中，其中project_name变量代表最顶层的工程名,app_name变量代表执行引擎所在docker容器的应用标识,一个应用标识由多个docker容器组成,business_name变量代表规则服务所在的业务组名,而最后rule_set_id变量代表具体的规则版本信息。

由此，docker容器中的执行引擎可以基于docker容器的应用标识所在的路径找到ZK节点，具体的，包括：

所述docker容器中的执行引擎确定包含docker容器的应用标识的ZK节点的路径；

通过包含有docker容器的应用标识的ZK节点的路径定位ZK节点。

本实施例中，之所以采用docker容器的应用标识与ZK节点之前的关系定位ZK节点，是因为docker容器的应用标识对于docker容器来说是唯一的，不会发生改变的。

docker容器中的执行引擎在定位到ZK节点后，对ZK节点的状态进行监听，监听ZK节点中是否有更新的规则服务信息。

其中，实现docker容器中的执行引擎对ZK节点的监听方法可以包括多种，本实施例中不进行限定，例如可以通过monitor接口对ZK节点进行监听。

S103：当运行在docker容器中的执行引擎监听到ZK节点中有更新的规则服务信息时，所述执行引擎根据ZK节点中存储的规则服务信息，更新所述执行引擎中的规则服务信息。

本实施例中，当监听到ZK节点中的规则服务信息发生变化时，即ZK节点中的规则服务信息出现了更新，那么相应的docker容器中的执行引擎中的规则服务信息也需要进行更新。本实施例中，可以根据ZK节点中的规则服务信息更新docker容器中的执行引擎中的规则服务信息。

本实施例中，当规则服务后台检测到有更新的规则服务信息后，将更新的规则服务信息保存到ZK系统相对应的ZK节点中；运行在docker容器中的执行引擎通过docker容器的应用标识定位ZK节点，并监听ZK节点中是否有规则服务信息的变化；所述docker容器的应用标识与所述ZK节点存在关联关系；当运行在docker容器中的执行引擎监听到ZK节点中规则服务信息发生变化时，所述执行引擎根据ZK节点中存储的规则服务信息，更新所述执行引擎中的规则服务信息。这样，实现了对docker容器中的执行引擎中的规则服务信息的及时更新，并且本方案是通过docker容器的应用标识与ZK节点之间的关系定位ZK节点，这就使得docker容器中的执行引擎中的规则服务信息的更新不再依赖于docker容器的IP地址，除此之外，由于docker容器的应用标识是不会发生改变的，解决了由于IP地址的改变从而使得docker容器中的执行引擎中的规则服务信息无法及时更新的问题。

进一步的，为了保证ZK节点和docker容器中的执行引擎对规则服务信息进行同步更新，在规则服务后台还可以对更新情况进行查看，具体的，还包括：

所述规则服务后台响应于更新检测指令，判断所述执行引擎中的规则服务信息与所述更新的规则服务信息是否一致；

若所述执行引擎中的规则服务信息与所述更新的规则服务信息不一致，向所述ZK节点发送回滚指令，以使所述ZK节点基于历史操作进行回滚。

其中，更新检测指令可以是人为触发的，也可以是自动触发的，本实施例中不进行限定。

在执行引擎中的规则服务信息与更新的规则服务信息不一致的情况下，向ZK节点发送回滚指令，这样，ZK节点基于历史操作进行回滚。

其中，回滚可以理解为基于按照上一次操作的反向操作执行，例如若上一次的操作为将历史版本的规则服务信息更新为新版本的规则服务信息，则回滚操作为，将新版本的规则服务信息回滚为历史版本的规则服务信息；若上一次的操作为创建了新的路径，并在新的路径对应的节点上存储了规则服务信息，对应的回滚操作可以为，上述该节点上存储的规则服务信息，并删除该路径。

进一步的，在运行的过程中，若ZK节点或者docker容器出现故障时，导致存储的规则服务信息出现问题，那么就有可能造成规则服务后台、ZK节点或者docker容器中存储的规则服务信息不一致的情况，出现故障的情况下，技术人员需要确定引起问题的原因，并即使消除故障，保障正常运行。

具体的，还包括：

所述规则服务后台响应于定期巡检指令，判断所述规则服务后台中的目标规则服务信息、存储所述目标规则服务信息的ZK节点中的目标规则服务信息以及docker容器中的目标规则服务信息是否一致；

若所述规则服务后台中的目标规则服务信息、存储所述目标规则服务信息的ZK节点中的目标规则服务信息以及docker容器中的目标规则服务信息不一致，则发起异常告警；

确定异常告警产生的原因。

其中，目标规则服务信息为规则服务后台中存储的任何一个规则服务信息。

本实施例中，确定异常告警产生的原因的方式可以包括多种，本实施例中不进行限定，例如可以包括如下的两种方式：

方式一、通过人为查验的方式确定异常告警原因；

方式二、通过预先设置的规则确定异常告警原因，例如预先设置了告警信息和异常原因的映射关系，当出现某种情况的告警时，会自动确定出异常原因。

其中，异常告警原因有多种，例如可以包括：执行引擎系统故障，网络传输出现问题或者规则服务信息有误等；其中，执行引擎系统故障或者错误的规则服务信息均可以通过日志排查定位的方式进行排查，网络传输问题可以通过检测网络连通性进行排查。

本实施例中，通过对规则服务后台、ZK节点以及docker容器中的规则服务信息进行定期巡检，避免了由于任何一方故障导致的规则服务信息不一致的问题。

参考图3，示出了本发明实施例公开的规则服务信息的更新装置的结构示意图，在本实施例中，该装置包括：

推送单元301，用于当规则服务后台检测到有更新的规则服务信息后，将所述更新的规则服务信息保存到ZK系统中相对应的ZK节点中；

监听单元302，用于运行在docker容器中的执行引擎通过docker容器的应用标识定位ZK节点，并监听ZK节点中是否有更新的规则服务信息；所述docker容器的应用标识与所述ZK节点存在关联关系；

更新单元303，用于当运行在docker容器中的执行引擎监听到ZK节点中有更新的规则服务信息时，所述执行引擎根据ZK节点中存储的规则服务信息，更新所述执行引擎中的规则服务信息。

可选的，所述推送单元，包括：

第一推送子单元，用于若ZK系统中的第一ZK节点中存储有所述更新的规则服务信息的历史版本，将所述更新的规则服务信息存储到所述第一ZK节点中；

第二推送子单元，用于若所述ZK系统中没有任何一个ZK节点中存储有所述更新的规则服务信息的历史版本，创建新的路径，并将所述更新的规则服务信息存储到创建的新的路径对应的第二ZK节点中。

可选的，所述监听单元，包括：

确定子单元，用于所述docker容器中的执行引擎确定包含docker容器的应用标识的ZK节点的路径；

定位子单元，用于通过包含有docker容器的应用标识的ZK节点的路径定位ZK节点。

可选的，还包括：

第一判断单元，用于所述规则服务后台响应于更新检测指令，判断所述执行引擎中的规则服务信息与所述更新的规则服务信息是否一致；

回滚单元，用于若所述执行引擎中的规则服务信息与所述更新的规则服务信息不一致，向所述ZK节点发送回滚指令，以使所述ZK节点基于历史操作进行回滚。

可选的，还包括：

第二判断单元，用于所述规则服务后台响应于定期巡检指令，判断所述规则服务后台中的目标规则服务信息、存储所述目标规则服务信息的ZK节点中的目标规则服务信息以及docker容器中的目标规则服务信息是否一致；

异常告警单元，用于若所述规则服务后台中的目标规则服务信息、存储所述目标规则服务信息的ZK节点中的目标规则服务信息以及docker容器中的目标规则服务信息不一致，则发起异常告警；原因确定单元，用于确定异常告警产生的原因。

本实施例中，通过本实施例的装置，实现了对docker容器中的执行引擎中的规则服务信息的及时更新，并且本方案是通过docker容器的应用标识与ZK节点之间的关系定位ZK节点，这就使得docker容器中的执行引擎中的规则服务信息的更新不再依赖于docker容器的IP地址，除此之外，由于docker容器的应用标识是不会发生改变的，解决了由于IP地址的改变从而使得docker容器中的执行引擎中的规则服务信息无法及时更新的问题。

需要说明的是，本说明书中的各个实施例均采用递进的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间相同相似的部分互相参见即可。

对所公开的实施例的上述说明，使本领域专业技术人员能够实现或使用本发明。对这些实施例的多种修改对本领域的专业技术人员来说将是显而易见的，本文中所定义的一般原理可以在不脱离本发明的精神或范围的情况下，在其它实施例中实现。因此，本发明将不会被限制于本文所示的这些实施例，而是要符合与本文所公开的原理和新颖特点相一致的最宽的范围。

Claims (8)

1.一种规则服务信息的更新方法，其特征在于，包括：

当规则服务后台检测到有更新的规则服务信息后，将所述更新的规则服务信息保存到ZK系统中相对应的ZK节点中；

运行在docker容器中的执行引擎通过docker容器的应用标识定位ZK节点，并监听ZK节点中是否有更新的规则服务信息；所述docker容器的应用标识与所述ZK节点存在关联关系；

当运行在docker容器中的执行引擎监听到ZK节点中有更新的规则服务信息时，所述执行引擎根据ZK节点中存储的规则服务信息，更新所述执行引擎中的规则服务信息；

所述当规则服务后台检测到有更新的规则服务信息后，将所述更新的规则服务信息保存到ZK系统中相对应的ZK节点中，包括：

若ZK系统中的第一ZK节点中存储有所述更新的规则服务信息的历史版本，将所述更新的规则服务信息存储到所述第一ZK节点中；

若所述ZK系统中没有任何一个ZK节点中存储有所述更新的规则服务信息的历史版本，创建新的路径，并将所述更新的规则服务信息存储到创建的所述新的路径对应的第二ZK节点中。

2.根据权利要求1所述的方法，其特征在于，所述运行在docker容器中的执行引擎通过docker容器的应用标识定位ZK节点，包括：

所述docker容器中的执行引擎确定包含docker容器的应用标识的ZK节点的路径；

通过包含有docker容器的应用标识的ZK节点的路径定位ZK节点。

3.根据权利要求1所述的方法，其特征在于，还包括：

所述规则服务后台响应于更新检测指令，判断所述执行引擎中的规则服务信息与所述更新的规则服务信息是否一致；

若所述执行引擎中的规则服务信息与所述更新的规则服务信息不一致，向所述ZK节点发送回滚指令，以使所述ZK节点基于历史操作进行回滚。

4.根据权利要求1所述的方法，其特征在于，还包括：

所述规则服务后台响应于定期巡检指令，判断所述规则服务后台中的目标规则服务信息、存储所述目标规则服务信息的ZK节点中的目标规则服务信息以及docker容器中的目标规则服务信息是否一致；

若所述规则服务后台中的目标规则服务信息、存储所述目标规则服务信息的ZK节点中的目标规则服务信息以及docker容器中的目标规则服务信息不一致，则发起异常告警；

确定异常告警产生的原因。

5.一种规则服务信息的更新装置，其特征在于，包括：

推送单元，用于当规则服务后台检测到有更新的规则服务信息后，将所述更新的规则服务信息保存到ZK系统中相对应的ZK节点中；

监听单元，用于运行在docker容器中的执行引擎通过docker容器的应用标识定位ZK节点，并监听ZK节点中是否有更新的规则服务信息；所述docker容器的应用标识与所述ZK节点存在关联关系；

更新单元，用于当运行在docker容器中的执行引擎监听到ZK节点中有更新的规则服务信息时，所述执行引擎根据ZK节点中存储的规则服务信息，更新所述执行引擎中的规则服务信息；

所述推送单元，包括：

第一推送子单元，用于若ZK系统中的第一ZK节点中存储有所述更新的规则服务信息的历史版本，将所述更新的规则服务信息存储到所述第一ZK节点中；

第二推送子单元，用于若所述ZK系统中没有任何一个ZK节点中存储有所述更新的规则服务信息的历史版本，创建新的路径，并将所述更新的规则服务信息存储到创建的新的路径对应的第二ZK节点中。

6.根据权利要求5所述的装置，其特征在于，所述监听单元，包括：

确定子单元，用于所述docker容器中的执行引擎确定包含docker容器的应用标识的ZK节点的路径；

定位子单元，用于通过包含有docker容器的应用标识的ZK节点的路径定位ZK节点。

7.根据权利要求5所述的装置，其特征在于，还包括：

第一判断单元，用于所述规则服务后台响应于更新检测指令，判断所述执行引擎中的规则服务信息与所述更新的规则服务信息是否一致；

回滚单元，用于若所述执行引擎中的规则服务信息与所述更新的规则服务信息不一致，向所述ZK节点发送回滚指令，以使所述ZK节点基于历史操作进行回滚。

8.根据权利要求5所述的装置，其特征在于，还包括：

第二判断单元，用于所述规则服务后台响应于定期巡检指令，判断所述规则服务后台中的目标规则服务信息、存储所述目标规则服务信息的ZK节点中的目标规则服务信息以及docker容器中的目标规则服务信息是否一致；

异常告警单元，用于若所述规则服务后台中的目标规则服务信息、存储所述目标规则服务信息的ZK节点中的目标规则服务信息以及docker容器中的目标规则服务信息不一致，则发起异常告警；

原因确定单元，用于确定异常告警产生的原因。

Images