近年来，通知功能已经成为许多应用程序中突出的特性。构建一个能每天发送数百万通知的可扩展系统绝非易事。这正是为什么我觉得有必要记录我在这方面踩坑之路。也叫用户触达系统。
完成这项任务要求对通知生态系统有深刻的理解，否则需求很容易变得模糊和不明确。
1 了解通知系统并确定设计范围
通知是用于向用户提供重要信息的一种方式，如产品更新、提醒事件、优惠等。已成为应用功能清单中的重要组成部分。
通知不仅是移动推送通知。通常，根据接收者的特征
1 通知格式分类
- 移动推送通知
- 短信
- 电子邮件
- 网页推送通知
- 第三方应用通知（类似 Slack、钉钉的应用）
2 功能需求
- 系统支持推送通知、短信、电子邮件和第三方应用通知。
- 准实时系统。希望用户尽快收到通知。然而，若系统负载过高，轻微延迟也可接受
- 支持的设备：移动设备（iOS 和 Android）以及笔记本电脑/台式机
- 通知可以由客户端应用程序事件触发，也可以在服务器端进行计划
- 用户可以选择不再接收将来的通知
- 大致上，我希望每天发送1000万条推送通知、500万封电子邮件和100万条短信
3 顶层设计
首先，我们需要找出一个支持各种通知类型的高级设计：短信、电子邮件、iOS推送通知、Android推送通知和Slack应用通知。
然后，系统应该以以下组件结构化：
- 不同通知类型的配置
- 收集联系信息流
- 通知发送和接收流
4 不同通知类型的高级设计与AWS
每种通知类型在高级层面上的工作原理。
4.1 短信
核心组件
- Producer — 生产者构建并向【SMS Service】发送通知请求。为构建短信的通知请求，生产者应提供数据：带有国家代码的用户电话号码，JSON字典负载下的短信主题/内容。也就是公司内各业务部门
- SMS Service，短信服务，用于处理自定义业务逻辑并触发短信发送
- AWS SNS或第三方短信服务 — 这是AWS用于发送短信的服务，但为增加高可用性和韧性，我添加了第三方短信服务选项。默认，短信服务将调用AWS SNS，但若异常，可切换到其他短信服务
- SMS device，短信设备 — 接收短信的终端客户端
4.2
生产者应提供：
- 用户的email地址
- email内容
给到Email Service函数。
4.3 iOS推送通知
使用SNS + APNS的iOS推送通知
Producer将向Mobile Push Service（移动推送服务）提供用户信息，如：
- 设备令牌
- 通知内容
Mobile Push Service将构建并向SNS发送通知请求。iOS推送通知请求应构建以下数据：
- 设备令牌 — 用于发送推送通知的唯一标识符
- 负载 — 这是APNS定义接受的JSON字典格式
APNS — 这是由Apple提供的远程服务，用于向iOS设备传播推送通知。
4.4 Android推送通知
使用SNS + FCM的Android推送通知
Android有类似通知流。与使用APNS不同，使用Firebase Cloud Messaging（FCM）向Android设备发送推送通知。
4.5 Slack应用通知
producer将适当提供：
- 消息内容
- 主题/频道地址
给第三方应用推送服务。
SQS是用于控制速率限制的消息队列，因为许多第三方API都有这样的限制。我们要有礼貌地调用第三方API！
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中的事件总数和排队通知的总数。如果这两个指标很大，那么通知事件没有被工作人员快速处理。这意味着我们应该扩展，需要更多的工作人员。
- 事件跟踪 — 一些重要的自定义指标，如开放率、点击率和参与度，对于理解客户行为很重要。我们应该为事件分配状态：已创建 → 待处理 → 已发送 → 已打开 → 已点击或错误、已退订。将事件状态集成到通知系统中，我们可以追踪通知事件。
更新的高级架构
带有AWS的优化通知系统
8 结论
文章强调了通知在让我们了解关键信息方面的不可或缺性。旨在阐明可扩展、高可用和可靠的通知系统的蓝图，该系统可适应各种通知类型，包括移动推送通知、短信、电子邮件和第三方应用通知。
为实现目标，我选择基于事件的架构，利用EventBridge和SQS队列解耦系统组件。
设计广泛使用AWS服务，采用无服务器框架，这种选择不仅确保了效率，而且还将定价和运营成本降到了最低。
该设计遵循了十二要素应用的原则，将支持服务视为附加资源，将配置存储在环境中，并将日志视为事件流，其中还考虑了其他一些因素。
