超越架构师！消息通知系统优化设计-编程知识

5 收集联系信息流程

为发送通知，需收集各种信息如移动设备令牌、email、phone和第三方通道信息。

用于存储联系信息的简化的数据库表模式。它是个带有电子邮件、电话、设备令牌和外部通道的单个NoSQL DynamoDB表。Contacts table schema：

device_tokens 应以 JSON 格式存储。示例：

[{"deviceToken": "[设备令牌UUID]","platform": "apns"},{"deviceToken": "[设备令牌UUID]","platform": "fcm"}
]

external_channels 字段

[{"platform": "slack","url": "[通道的唯一URL]","status": true},{"platform": "another-service","url": "...","status": false}
]

用户可拥有多个设备、第三方通道，表示可将推送通知发送到用户的所有设备。

6 通知发送和接收流程

初始设计的通知系统：

图从左到右：

外部生产者 1~N — 代表希望通过通知系统提供的API发送通知的不同服务。如结算服务发送短信提醒客户付款到期，或者购物网站的交付消息到他们的客户。

API网关 将为生产者提供API接口，并将请求正确地路由到通知服务（Lambda）。

通知服务 类似后端服务，功能如下：

执行基本验证，以验证电子邮件、电话号码、设备令牌等。
查询数据库以获取生成通知事件所需的数据。
将通知数据推送到事件总线以进行并行处理。

联系人数据库 — 存储有关用户、联系信息、设置等数据的DynamoDB表。

EventBridge，AWS服务，将其用作事件总线。还需定义事件规则以正确将事件路由到队列。

这是通知事件的示例。每个 detail-type 将针对一个通知类型。因此，SQS队列根据属性模式过滤事件。

{"id": "<required::uuid>","source": "payment_request_event","detail-type": ["payment_notification_sms"],"resources": ["payments"],"detail": {...}"time": "<required>","region": "<required>","account": "<required>"
}

消息队列 — 它们用于消除组件之间的依赖关系。SQS队列在需要发送大量通知时充当缓冲区。每种通知事件类型都分配到一个独立的消息队列，以便一个发送服务的中断不会影响其他通知类型。

Worker — 从SQS队列轮询通知事件并将其发送到相应的服务的Lambda服务列表。

SNS或第三方服务 — 这些服务负责将通知传递给消费者。在与第三方服务集成时，我们需要关注可扩展性和高可用性。可扩展性的一个很好的例子是一个灵活的系统，可以轻松切换第三方服务的开/关。另一个重要考虑因素是第三方服务可能在某种程度上不可用，然后我们应该能够切换到另一个服务，并尽量减小对业务的影响。

7 优化

在高级设计中，我们讨论了通知系统的三个主要部分：不同类型的通知、收集联系信息流程和通知发送/接收流程。关键是：

事件和推送通知中的安全性
通知模板和设置
可靠性和弹性
重试机制
速率限制
监视队列中的通知和事件跟踪

事件和推送通知的安全性

在存储敏感数据的情况下，我们应该启用DynamoDB的数据保护，如静态加密，并集成AWS Key Management Service（AWS KMS）以管理用于加密表的加密密钥。并使用IAM角色对DynamoDB的访问进行身份验证。
在访问资源方面实施最小权限原则
通过使用SSL/TLS与AWS资源通信，启用EventBridge的数据保护，以在传输中进行加密。建议使用TLS 1.3。
对于iOS和Android应用，appKey和appSecret用于保护推送通知API。只有经过身份验证或经过验证的客户端才允许使用API发送推送通知。这些凭据应通过Secret Manager或Parameter Store存储和加密。

通知模板和设置

我们应该为相同通知类型创建一个通知模板，其遵循相似的格式。它可以被重用，并避免从头开始构建每个通知内容。
通知模板是预格式化的通知内容，通过自定义参数、跟踪链接

等创建唯一的通知。我们可以将这些通知模板存储在带有定义前缀的S3桶中。

为了为用户提供对通知设置的细粒度控制，我们可以将其存储在单独的通知设置表中。在向用户发送任何通知之前，我们首先检查用户是否愿意接收这种类型的通知。

可靠性和弹性

防止数据丢失 — 通知系统中最重要的非功能性要求之一是不能丢失数据。通知可能会延迟或重新排序，但不应该丢失。为了满足此要求，通知系统将通知数据持久保存在另一个日志表中，并实施重试机制。
接收一条通知确切地一次吗？ — 不，不可以。根据第三方服务提供商的SLA，尽管通知大多数时候确切地传递一次，但分布式性质可能导致重复的通知。我们可以减少重复的发生，然后引入去重机制并小心处理故障。
这是一个简化的逻辑：当通知事件首次到来时，我们通过检查 eventId 来查看它是否以前传递过。如果之前成功传递，则将其丢弃。否则，我们将发送通知。
弹性基础设施 — 我们应该考虑在多个可用区部署，您可以设计和操作可以在可用区之间自动故障转移而不中断的应用程序和数据库。可用区比传统的单一或多数据中心基础设施更具高可用性、容错性和可扩展性。

重试机制

当SNS/第三方服务无法发送通知时，通知将被添加到死信队列进行重试。如果问题仍然存在，将向负责的开发人员发送警报。

速率限制

我们应该考虑礼貌地发送通知。为了避免向用户发送过多通知，通过使用SQS并限制用户在一段时间内可以接收的通知数量，我们可以提高通知系统的礼貌度。

监视队列中的通知和事件跟踪

我们应该使用AWS CloudWatch指标监视通知系统。要监视的关键指标是EventBirdge中的事件总数和排队通知的总数。如果这两个指标很大，那么通知事件没有被工作人员快速处理。这意味着我们应该扩展，需要更多的工作人员。
事件跟踪 — 一些重要的自定义指标，如开放率、点击率和参与度，对于理解客户行为很重要。我们应该为事件分配状态：已创建 → 待处理 → 已发送 → 已打开 → 已点击或错误、已退订。将事件状态集成到通知系统中，我们可以追踪通知事件。

更新的高级架构