消息推送架构设计

最新推荐文章于 2023-09-03 18:00:22 发布

40岁资深老架构师尼恩

最新推荐文章于 2023-09-03 18:00:22 发布

阅读量798

点赞数

分类专栏：面试文章标签：面试架构后端数据库 mysql 系统架构

本文链接：https://blog.csdn.net/crazymakercircle/article/details/132561087

版权

面试专栏收录该内容

202 篇文章 110 订阅

订阅专栏

说在前面

在40岁老架构师尼恩的读者社区(50+)中，最近有小伙伴拿到了一线互联网企业如阿里、网易、有赞、希音、百度、网易、滴滴的面试资格，遇到一几个很重要的面试题：

企业级消息通知系统有哪些需求？如何满足？
企业级消息通知系统，该如何做架构设计？

尼恩提示，系统架构相关的问题，是架构的核心知识，又是线上的重点难题。

所以，这里尼恩给大家做一下系统化、体系化的梳理，使得大家可以充分展示一下大家雄厚的 “技术肌肉”，让面试官爱到 “不能自已、口水直流”。

也一并把这个题目以及参考答案，收入咱们的《尼恩Java面试宝典》V103版本，供后面的小伙伴参考，提升大家的 3高架构、设计、开发水平。

最新《尼恩架构笔记》《尼恩高并发三部曲》《尼恩Java面试宝典》的PDF，请关注本公众号【技术自由圈】获取，回复：领电子书

架构目标：

构建企业级统一基础推送服务，支持通过多渠道推送，能够统一集成的电子邮件、短信、聊天、钉钉、企业微信和其他公共社交应用：

聊天 - 微信Wechat/QQ
站内推送通知（移动设备和Web浏览器）
站外推送通知（移动设备，APP没有开启）
短信（如登录密码、营销活动）
电子邮件
钉钉
企业微信

企业级统一基础推送服务，是一个通用特性，适用于所有现代分布式应用，无论采用何种编程语言和技术。

推送能力的演进

第一阶段（模块化）：各自为政、各自封装

企业内部，早期业务量比较少，各系统基本都是有自己的推送模块，类型也是五花八门：

聊天模块
短信模块
电子邮件模块
websocket 模块

各自封装模块比较简单，但是实现分散、各系统模块的质量也很难统一保证。

第二阶段（框架化）：集成框架

为了减少重复性设计、开发成本，设计了统一的推送框架

同一套微服务框架，共用一个统一的推送框架

为了解决上述分散实现的问题，企业内部统一实现了一个综合各类推送功能的基础库，供业务方统一调用。

聊天基础starter
短信基础starter
电子邮件基础starter
websocket 基础starter

于是，我们把 springboot-starter的逻辑封装到了服务治理框架内，微服务服务启动时，每一个服务对各种的starter进行运维管理、配置管理。

第三阶段（服务化）：推送服务

集成到框架，每一套服务，都需要重复性的解决3高问题。

推送服务，数据量大，需要解决跨库查询问题
推送服务，性能要求高，需要解决高并发问题

大数据量、并发量高，意味着：

硬件资源投入大
运维成本高

这样的基础服务，需要进行沉淀，剥离，集中成统一的、基础服务，由专门团队负责维护、迭代、运维。降低重复投入、重复建设成本，真正的降本增效。

于是，推送框架演进为推送服务

推送服务在业务系统中的位置

一个业务应用，基本上有很多原子服务编排、整合而来，最终构建出一个完整的架构图。

接入层，这是外部请求进入内部系统的门户，所有的请求都必须通过 API 网关。
应用层，也被称为聚合层，它为相关业务提供聚合接口，并调用中台服务进行组合。
原子服务，包括就是原子技术服务，原子业务服务，根据业务需求提供相关的接口。原子服务为整个架构提供可复用的能力。

例如，在B站视频网站平台上，评论服务作为一项原子服务，在B站的视频、文章、社区都需要，那么为了提高复用性，评论服务就可以独立为原子服务，不能与特定需求紧密耦合。

在这种情况下, 评论服务，需要供一种可以适应不同场景的复用能力。

注意：请点击图像以查看清晰的架构图！

类似的，文件存储、数据存储、推送服务、身份验证服务等功能，都会沉淀为原子服务，业务开发人员，在原子服务基础上，进行编排、配置、组合，可以快速构建业务应用。

当然，本文仅仅聚焦推送服务。其他的原子服务， 40岁老架构师尼恩，会以其他的文章进行专文介绍，具体请大家持续关注尼恩的公众号，技术自由圈。

推送服务功能要求：

发送通知
对通知进行优先级排序
根据客户的保存偏好发送通知
支持单个/简单的通知消息和批量通知消息
各种通知的分析用例
通知消息的报告

推送非功能性需求（NFR）：

高性能： qps > 1W
高可用性（HA）： 99.99%
低延迟： TP99 在10ms以下
高扩展：可扩展/可插拔的设计，以便添加更多适配器和提供商，与所有通知模块的API集成以及与客户端和服务提供商/供应商的外部集成
跨平台：支持Android/iOS移动设备和桌面/笔记本电脑的Web浏览器
自伸缩：可在本地（VMware Tanzu）和 AWS、GCP 或 Azure 等公共云服务上扩展负载

推送系统设计架构：

注意：请点击图像以查看清晰的架构图！

这些解决方案设计的考虑因素和组件包括：

1. 通知客户端：

这些客户端通过 API 调用请求单个和批量消息。它们将向简单和批量通知服务发送通知消息。

简单通知客户端：专门用于发送单个通知的客户端，负责向用户发送单一通知。这些客户端通常用于向特定用户发送重要通知，例如密码找回或账户异常提醒。
批量通知客户端：专门用于发送批量通知的客户端，负责向用户批量推送通知。这些客户端通常用于需要通知大量用户的场景，例如企业内部通知或营销活动。

2. 通知服务：

作为入口点的这些服务，通过暴露 REST API 与客户端互动。

它们负责构建通知消息，通过调用"模板服务"。这些消息将使用"验证服务"进行验证。

简单通知服务：该服务将提供 API，主要负责处理简单通知请求，提供与后端服务集成的 API，以便将通知发送给用户。这种服务通常用于处理较少的通知请求，例如针对特定用户或事件的简单通知。
批量通知服务：该服务将提供 API，主要负责处理批量通知请求，提供与后端服务集成的 API，以便批量发送通知。这种服务通常用于处理大量的通知请求，例如企业内部的批量通知或营销活动的批量推送。

此服务还将管理通知消息。它将发送的消息持久化到数据库并维护活动日志。

可以使用这些服务的 API 重新发送同一条消息。

它将提供添加/更新/删除和查看旧消息和新消息的 API。

它还将提供 Web 仪表板，该仪表板应具有筛选选项，以根据不同的条件（如日期范围、优先级、模块用户、用户组等）筛选消息。