推送服务，每个系统都自行去做一遍，这乃是许多企业内部往昔走过的曲折道路。如今，企业级统一基础推送服务已然成为现代分布式应用的普遍特性，不管你使用Java，或者Go，又或是Python，它都是基础设施层面必定要解决的问题。
从分散到统一的三步走
刚开始业务量少的时候，各个业务系统各自去维护一套推送模块，有的借助短信网关，有的自行对接邮件服务，还有的直接采用第三方推送SDK，这种各自只顾自己不顾整体的做法在2018年前后特别常见，某家电商公司当时作过统计，自身内部居然存在7套不一样的推送实现方式，维持费用让人大吃一惊十分高昂。
针对重复造轮子问题予以解决的情况下，第一阶段的统一框架顺势诞生了。研发团队将各类推送功能里的共性提取出来，把它封装成为一个基础库，各个业务系统借助直接调用这个库去达成推送需求。此方案在2020年前后，助力诸多企业飞快降低了开发成本，起码减少了30%的重复代码量。
阶段之二是将推送能力整合于服务治理框架里。当微服务开启时，框架会自行管理与推送有关的配置以及运维，每个服务无需再去操心推送模块的初始化、连接池管理这类繁杂之事。就拿某头部视频平台来讲，他们于2022年达成了此项改造，上千个微服务统一接入了推送能力。
具有真正意义的服务化沉淀属于第三阶段。从其中剥离出推送功能，使其成为一项独立的基础服务，由特定的团队予以维护、迭代以及运维。此团队需处理高并发、高可用、高性能这“三高”问题，原因在于推送服务承担着全公司的消息触达能力。
原子服务在业务架构中的定位
于典型的业务应用里头，原子服务充当构建复杂系统的根基，以B站来说，评论服务作为原子服务，在视频、文章、社区等好些场景都得用到，所以得独立出来，不可跟任何特定业务相耦合，相仿地，文件存储、数据存储、身份验证、推送服务都沉淀成原子服务。
进行编排以及配置，是业务开发人员基于这些原子服务来达成的，如此便能迅速构建出完整的业务应用。在2024年之后，这种架构模式已然成为主流，开发新业务的时间从原本的几周被缩短至几天，这是由于底层能力都已准备妥当。
入口与模板管理的核心逻辑
客户端借助REST API调用推送服务，能发送单条消息，也能够批量发送。作为入口的服务承担构建通知消息的职责，调用模板服务以获取内容格式，接着靠验证服务校验消息合法性。全部发送的消息都会持久化至数据库，且维护完整的活动日志。
存在着一种模板服务，该服务对全部的消息模板予以管理，这些消息模板包含一次性密码、短信、邮件、聊天以及各类推送通知。有运维人员，其能够借助Web仪表板来实施筛选以及管理的操作，按照日期范围、优先级、用户组等条件去查询消息记录。于2023年的时候，这个仪表板已然变成了各家企业推送平台的标配。
优先级与事件中心的设计思路
推送服务里有优先级排序机制，它把通知划分为高、中、低三个等级。交易时的应用通知是中优先级，批量通知于非工作时间按低优先级发送，带有到期时间的验证码一直按高优先级处理。某银行在2024年实践中，借这个机制保障了交易类通知能秒级送达。
通用出口处理器在接收到消息之后，会依据优先级将其放置于三个不一样的队列之中。高优先级的队列会被优先进行消费，保障重要通知不会被积压。这样一种队列分级的设计，使得企业能够按照业务重要性进而灵活地调配处理资源，并非是对所有消息都同等看待。
适配器与外部通道的对接方式
完成优先级处理之后的通用出口处理器，会顺应通道类型去做消息的进一步分发。适配器层承担着把内部消息格式转化成各类外部通道所需格式的职责，这些格式含有短信、邮件、推送通知等，与此同时适配桌面设备以及移动设备的不同要求。
SaaS服务提供商一般是外部通道 ，像AWS SNS ，还有国内各大云厂商的推送服务。企业依据成本以及覆盖需求挑选适宜通道 ，部分核心业务运用付费网线通道 ，非核心业务就采用普通通道。2025年一项行业调查表明 ，头部企业平均对接了4至6家各异的外部推送通道。
用户偏好与数据分析的落地价值
被用户所选择的服务承担着获取目标用户以及应用程序模块的职责，它具备支持依据用户组进行批量发送的能力。于服务的内部环境之中，它会去调用用户配置服务，以此来对每个用户的通知偏好展开检查。那些将邮件通知予以关闭的用户，是不会接收到邮件的，如此一来，在尊重用户选择这件事上得以达成，并且还削减了无效推送的情况出。
承担分析职责的处理器，要负责从数据库里，去提取与通知相关的元数据，这里面涵盖发送时间、送达状态、再加上通信渠道、消息类型等内容。这些数据会被用来生成使用趋势报告，进而帮助企业去优化推送策略。通知数据库运用主从集群架构，主节点来处理所有写操作，从节点则承担读取任务，以此保证在高并发场景之下的性能以及可靠性。
内部存在重复建设的推送模块在你的企业之中吗，欢迎将你们的技术演进路径于评论区予以分享，点赞数量超过一千我会继续讲述推送服务的高可用架构设计。