使用 Notification Manager 构建云原生通知系统

云原生下通知系统的特点

众所周知，在云原生领域，K8s 已经成为了事实上的标准。那么狭义上讲，云原生通知系统就可以理解为 K8s 下的通知系统，基于此，云原生下的通知系统拥有以下特点：

为 Kubernetes 而生
支持对接多种的事件源，告警、事件、审计等
多租户设计
高并发，可以同时处理大量的通知

Notification Manager 是什么

Notification Manager 是 KubeSphere 开源的一款云原生多租户通知管理系统，支持从 Kubernetes 接收告警、事件、审计，根据用户设置的模板生成通知消息并推送给用户，支持将通知消息推送到 DingTalk，Email，Feishu，Pushover，Slack，WeCom，Webhook，短信平台（阿里、腾讯、华为）等。

Notification Manager 会接收来自 Promethus、Alertmanager 发出的警告消息、K8s 产生的审计消息以及 K8s 本身的事件。在规划中我们还会实现接入 Promethus 的告警消息和接入 Cloud Event 。消息在进入缓存之后，会经过静默、抑制、路由、过滤、聚合，最后进行实际的通知，并记录在历史中。

下面是对每个步骤的解析：

缓存（Cache）

缓存的作用有两个，一个是应对告警风暴，同时产生大量告警时减少对系统的影响；另一个是对告警事件做聚合处理，飞书、钉钉和企业微信，对访问频次有限制。

目前采用松耦合设计，支持内存、NATS Streamming（后续）。

静默（Silence）

我们可以根据设定的规则对告警、事件、审计进行静默处理，比如支持设置静默时间，让晚上十点到早上八点不进行通知。同时我们可以支持设置全局静默规则和租户静默规则，全局的规则的会被全部租户启用，而租户规则只对当前租户起作用。

抑制（Inhibit）

一个节点宕机之后会发送大量告警，而这些告警不利于我们排查原因，我们可以通过设置抑制规则不再发送这部分告警给用户。

路由（Route）

告警、事件、审计都是由一个个标签组成的，路由的本质就是根据标签寻找需要接收标签的接收器。

下图就是一个路由，他定义了一个路由，他有以下几部分组成：

标签选择器 alertSelector
接收器 Receiver

接收器定义了我们的通知往哪里发、如何发，有如下特点：

可复用。尽可能复用配置，减少用户运维成本。
多租户。支持定义全局接收器用于接收所有的通知，同时用户可以定义自己的通知接收器用于接收租户相关的通知。
动态加载。为了实现动态加载，我们采用 CRD 的模式定义了 Config 和 Receiver。

Config CRD 定义了发送通知需要的信息，比如钉钉的 APP secret，它来定义我们如何发送信息，还可以通过标签区分全局 Config 和租户 Config 。

Receiver CRD 定义了通知发送到哪里，比如钉钉、Email、飞书、Slack、短信平台、webhook、企业微信等。

我们可以通过下图理解 Receiver 如何选择 Config 的，租户级的 Receiver 只能使用租户级的 Config，全局的 Receiver 只能使用全局的 Config。如果一个租户级的 Receiver 没有找到对应的租户级的 Config 就会使用全局级的 Config，这样就可以通过全局级的 Config 达到降低运维成本的作用。