第一时间关注技术干货!
免责声明~ 任何文章不要过度深思! 万事万物都经不起审视,因为世上没有同样的成长环境,也没有同样的认知水平,更「没有适用于所有人的解决方案」; 不要急着评判文章列出的观点,只需代入其中,适度审视一番自己即可,能「跳脱出来从外人的角度看看现在的自己处在什么样的阶段」才不为俗人。 怎么想、怎么做,全在乎自己「不断实践中寻找适合自己的大道」
为发送通知,需收集各种信息如移动设备令牌、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
}
]
用户可拥有多个设备、第三方通道,表示可将推送通知发送到用户的所有设备。
初始设计的通知系统:
图从左到右:
外部生产者 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或第三方服务 — 这些服务负责将通知传递给消费者。在与第三方服务集成时,我们需要关注可扩展性和高可用性。可扩展性的一个很好的例子是一个灵活的系统,可以轻松切换第三方服务的开/关。另一个重要考虑因素是第三方服务可能在某种程度上不可用,然后我们应该能够切换到另一个服务,并尽量减小对业务的影响。
在高级设计中,我们讨论了通知系统的三个主要部分:不同类型的通知、收集联系信息流程和通知发送/接收流程。关键是:
事件和推送通知的安全性
通知模板和设置
等创建唯一的通知。我们可以将这些通知模板存储在带有定义前缀的S3桶中。
可靠性和弹性
eventId
来查看它是否以前传递过。如果之前成功传递,则将其丢弃。否则,我们将发送通知。重试机制
速率限制
监视队列中的通知和事件跟踪
更新的高级架构
带有AWS的优化通知系统
文章强调了通知在让我们了解关键信息方面的不可或缺性。旨在阐明可扩展、高可用和可靠的通知系统的蓝图,该系统可适应各种通知类型,包括移动推送通知、短信、电子邮件和第三方应用通知。
为实现目标,我选择基于事件的架构,利用EventBridge和SQS队列解耦系统组件。
设计广泛使用AWS服务,采用无服务器框架,这种选择不仅确保了效率,而且还将定价和运营成本降到了最低。
该设计遵循了十二要素应用的原则,将支持服务视为附加资源,将配置存储在环境中,并将日志视为事件流,其中还考虑了其他一些因素。
参考: