SupportingServices - Alerts&Notifications

SupportingServices - Alerts&Notifications:

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

1.png

1. Introducion to Alert&Notifications

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

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

2.png

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

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

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

1
2
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.png

3. Data Dictionary

table-1.png

4. High Level Interaction Diagrams

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

  • 关键通知序列 Critical Notifications Sequence

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

4.png

  • 正常通知序列 Normal Notifications Sequence

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

5.png

  • 关键重发序列 Critical Resend Sequence

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

6.png

  • 重新发送序列 Resend Sequence

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

7.png

  • 清理序列 Cleanup Sequence

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

8.png

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

------ 本文结束感谢您的阅读 ------