目标:
设计企业级系统架构,支持使用API集成的电子邮件、短信、聊天和其他公共社交应用程序:
?电子邮件?短信/一次性密码?推送通知(移动设备和Web浏览器)?聊天 – Whatsapp/Telegram
这是一种通用的功能,适用于所有现代分布式应用程序,无论使用任何编程语言和技术。
我试图简化这个设计概念,以满足高可用性、高性能和分析服务的常见用例需求。这是通过微服务架构实现并在Kubernetes容器上部署,使其成为完全云原生的现代系统。让我们开始吧!
功能要求:
?发送通知?对通知进行优先级排序?根据客户的保存偏好发送通知?支持单个/简单的通知消息和批量通知消息?各种通知的分析用例?通知消息的报告
非功能性需求(NFR):
?高性能?高可用性(HA)?低延迟?可扩展/可插拔的设计,以添加更多的客户端、适配器和供应商?支持Android/iOS移动设备和桌面/笔记本电脑的Web浏览器?与所有通知模块的API集成和与客户端和服务提供商/供应商的外部集成?可在本地(VMware Tanzu)和AWS、GCP或Azure等公共云服务上扩展负载
系统设计架构:
注意:请点击图像以查看清晰的视图!
这些是解决方案设计的考虑因素和组件:
1. 通知客户端:
这些客户端将使用API调用请求单个和批量消息。这些客户端将向简单和批量通知服务发送通知消息。
?批量通知客户端:这些客户端发送批量通知。?简单通知客户端:这些客户端发送单个通知。
2. 通知服务:
这些服务是入口服务,将通过暴露REST API与客户端交互。它们负责通过消耗\\”模板服务\\”来构建通知消息。这些消息将使用\\”验证服务\\”进行验证。
?简单通知服务:该服务将暴露API,以将客户端与后端服务集成。它是主要的服务,用于处理简单通知请求。?批量通知服务:该服务将暴露API,以将客户端与后端服务集成。它是主要的服务,用于处理批量通知请求。
此服务还将管理通知消息。它将将发送的消息持久化到数据库并维护活动日志。可以使用这些服务的API重新发送同一条消息。它将提供添加/更新/删除和查看旧消息和新消息的API。它还将提供Web仪表板,该仪表板应具有筛选选项,以根据不同的条件(如日期范围、优先级、模块用户、用户组等)筛选消息。
3. 模板服务:
该服务管理所有可用的OTP、短信、电子邮件、聊天和其他推送通知消息的模板。它还提供REST API来创建、更新、删除和管理模板。它还将提供一个UI仪表板页面,以便从Web控制台检查和管理消息模板。
4. 用户选择服务:
该服务将提供选择目标用户和各种应用程序模块的服务。可能存在将批量消息发送到特定用户组或不同应用程序模块的用例。可能是AD/IAM/eDirectory/用户数据库/用户组,根据客户的偏好。在内部,它将使用\\”用户配置文件服务\\”API来消耗和检查客户的通知偏好。
5. 用户配置文件服务:
该服务将提供各种功能,包括管理用户配置文件和其偏好设置。它还将提供取消订阅通知以及通知接收频率等功能。\\”通知服务\\”将依赖于此服务。
6. 通用通知服务
?定时服务:
该服务将提供API来安排立即或指定时间的通知。可以是以下任何一种:
?秒?分钟?每小时?每天?每周?每月?每年?自定义频率等。
还可能有其他自动触发的服务,基于预定时间进行消息触发。
?验证服务:
该服务完全负责根据业务规则和期望的格式对通知消息进行验证。批量消息应由授权的系统管理员批准。
?优先级服务:
它还将根据高、中和低优先级对通知进行优先级排序。OTP通知消息具有较高的优先级和有时间限制的过期时间,它们将始终以较高优先级发送。\\”通用出站处理程序\\”将消耗消息并根据同样的优先级从高、中和低三个不同的队列中发送和处理。批量消息的另一个用例是在非工作时间使用低优先级发送。在交易过程中的应用程序通知可以发送到中优先级,如电子邮件
等。业务将根据通知的重要性决定优先级。
7. 事件优先级队列(事件中心):
它将提供事件中心服务,从通知服务中消耗高、中和低优先级的消息。它将根据业务优先级发送和接收消息。
它将具有以下三个主题,用于根据业务优先级消耗/发送消息:
?高优先级?中优先级?低优先级
8. 通用出站处理程序:
该服务将通过轮询事件优先级队列来消耗事件中心中的通知消息,根据其优先级进行处理。高优先级将优先给予\\”高\\”队列,依此类推。最后,它将通过事件中心将通知消息发送到特定的适配器。
该服务还将从用户选择服务中获取目标用户/应用程序。
9. 通知数据库:
该数据库将持久化所有通知消息,包括其发送时间、状态等。它将具有一个数据库集群,其中一个领导者将用于执行所有写操作,读取将在读取副本/跟随者上进行。它应该是一个非关系型数据库。
10. 出站事件中心:
它最终将消息传输到各种支持的适配器。这些适配器将基于不同的设备(桌面/移动)和通知类型(短信/OTP/电子邮件/聊天/推送通知)进行转换。
11. 通知适配器:
这些适配器将从事件中心(Kafka)接收传入消息并根据其所支持的格式发送给外部供应商。以下是一些适配器,根据需求可以添加更多:
?OTP适配器服务?短信适配器服务?电子邮件适配器服务?应用内通知适配器服务?WhatsApp聊天通知适配器服务?Telegram通知适配器服务
12. 通知供应商:
这些是外部的SAAS(云上/本地)供应商,使用它们的基础设施和技术提供实际的通知传输。它们可能是像AWS SNS、MailChimp等的付费企业服务。
?短信供应商集成服务?电子邮件供应商集成服务?应用推送通知供应商集成服务?WhatsApp供应商集成服务?Telegram供应商集成服务
13. 通知分析服务
该服务将执行所有的分析工作,并识别通知使用情况、趋势以及进行报告。它将从分析数据库(Cassandra)和通知数据库中提取所有最终的通知消息,用于分析和报告目的。
以下是一些用例:
?每天/每秒的总通知数。?哪个通知系统使用最频繁。?消息的平均大小和频率。?基于优先级过滤消息等等…
14. 通知跟踪器
该服务将持续读取事件中心队列并跟踪所有发送的通知。它捕获通知的元数据,如传输时间、传送状态、通信渠道、消息类型等。
15. Cassandra数据库集群
该数据库集群将持久化所有通知,用于分析和报告。它基于“写入更多,读取更少”的概念。
它将提供良好的性能和低延迟,适应大量的通知,因为它内部管理大量的写操作,并与其他数据库节点同步,并保留高可用性和可靠性的冗余数据/消息。在任何节点崩溃的情况下,消息将始终可用。
原创文章,作者:小技术君,如若转载,请注明出处:https://www.sudun.com/ask/33861.html