发表于 2018-09-12

| 分类于 Edge Computing

| 0

| 阅读次数:

SupportingServices - Alerts&Notifications：

• Introducion to Alert&Notifications
• Data Model
• Data Dictionary
• High Level Interaction Diagrams
• Configuration Propertie
• Configure Mail Server

1. Introducion to Alert&Notifications

当需要通知另一个系统或某人时，以及需要通知另一个微服务在节点上发现的事情， Alert&Notifications微服务能够提供这些信息。具体示例，其他服务可能需要广播，包括传感器数据超出范围（通常由Rules Engine服务检测到）或系统或服务故障（通常由System Management服务检测到）。

Notifications是提供信息的，而Alerts通常具有更重要、关键或紧急的性质，可能需要立即采取措施。

该图显示了Alerts and Notifications 的高级体系结构。在左侧，API是为其他微服务、机上应用程序和离线应用程序所提供，API可以是REST、AMQP、MQTT或任何标准应用程序协议。目前在EdgeX Foundry中，提供了RESTful接口。

在右侧，the notification receiver 可以是人，也可以是在云端或服务器中的应用系统。通过调用Subscription RESTful接口来订阅指定类型的通知。在事件发生时，the receiver 通过已定义的接收途径获得适当的通知。接收途径包括SMS消息，电子邮件，REST回调，AMQP，MQTT等。目前在EdgeX Foundry中，提供了电子邮件和REST回调的接收途径。

当Alerts and Notifications从任意接口接收通知时，通知将在内部传递给<通知处理器>Notifications Handler。 Notifications Handler首先会保留接收的通知，并将严重的通知立即传递给<分发协调器>Distribution Coordinator。对于正常通知，它们等待<消息调度器>Message Scheduler批量处理。

severity =“CRITICAL” // 严重通知
severity =“NORMAL”   // 正常通知

Alerts and Notifications是可扩展的，添加更多的严重性描述，并设置相应的Message Schedulers来处理它们。例如，正常严重程度(normal severity)的通知每两小时触发一次Message Schedulers，次要严重性(minor severity)的通知每24小时触发一次(每天凌晨)。

当Distribution Coordinator接收到通知时，它首先查询订阅以获取需要获得该通知的接收者及其接收途径信息。根据接收途径信息，Distribution Coordinator将该通知传递给相应途径的发送者。然后，途径发送者将通知发送给订阅的接收者。

2. Data Model

MongoDB被选中用于Alerts and Notifications的持久化，因此数据模型设计没有外键并且基于文档结构的范例。

3. Data Dictionary

4. High Level Interaction Diagrams

本节显示了有关Alerts and Notifications的一些更重要或复杂事件的序列图。

• 关键通知序列 Critical Notifications Sequence

当收到关键通知（ SEVERITY =“CRITICAL” ）时，它会先保存通知信息，并立即触发Distribution Process。更新通知状态后，Alerts and Notifications将响应客户端，以表示通知已接受。

• 正常通知序列 Normal Notifications Sequence

当收到正常通知（ SEVERITY =“NORMAL” ）时，它会先保存通知，并立即响应客户端以示通知已被接受。在经过某个持续时间段(可配置)之后，Message Scheduler将触发Distribution Pocess对其进行批量处理。

• 关键重发序列 Critical Resend Sequence

在发送关键通知期间遇到任何错误时，将安排单个重发任务，并且每个传输记录仍然存在。如果重发任务保持失败并且重发计数超过限制(可配置限制次数)，则会触发升级过程。升级的通知被发送到指定订阅的指定接收者（ slug =“ESCALATION” ）。

• 重新发送序列 Resend Sequence

对于其他非关键通知，重新发送操作由Resend Sceduler触发。

• 清理序列 Cleanup Sequence

清理服务删除旧的通知和传输记录。

5. Configuration Propertie (略，详情查看官方文档)

默认配置文件位于源代码的/ src / main / resources文件夹中。 与Configuration Management微服务合作时，配置将位于Consul Key / Value Store中的/ config / iot-support-notifications名称空间下。

6. Configure Mail Server (略，详情查看官方文档)

所有带有“spring.mail”前缀的属性都用于邮件服务器配置。 适当配置邮件服务器以发送警报和通知。 正确的值取决于使用的邮件服务器。

参考文献
SupportingServices-Alerts&Notifications