通知渠道抽象怎么设计？一次讲清站内信、短信、邮件、Push 的统一模型与扩展方式

大家好，我是一名有 4 年工作经验的 Java 后端开发。
做通知平台时，第一个很容易被低估的问题就是：不同通知渠道到底怎么统一。
因为站内信、短信、邮件、Push 看起来都叫“通知”，但它们的数据结构、发送方式和回执能力其实差别很大。
这篇文章我想系统聊一聊通知渠道抽象到底该怎么设计。

🦅个人主页
🐼

---

一、为什么渠道抽象这么关键

如果没有统一抽象，后面通常会变成：

• 业务系统直接调用短信 SDK
• 某个服务自己发邮件
• 某个模块单独写站内信表

最后通知能力会越来越散。

所以渠道抽象的核心价值是：

让业务方面对的是统一通知能力，而不是不同供应商和不同介质的差异。

---

二、不同渠道到底有什么差异

例如：

2.1 站内信

• 强状态化
• 有已读未读
• 可长期保存

2.2 短信

• 一次性触达
• 成本高
• 依赖供应商

2.3 邮件

• 内容相对长
• 有标题和正文
• 到达和阅读不一定可控

2.4 Push

• 强实时
• 依赖移动端
• 可能需要设备 token

所以统一抽象时一定不能硬把这些差异抹平，而是要：

在统一接口下保留渠道特性。

---

三、推荐的抽象方式

我更建议至少拆两层：

3.1 统一通知模型

例如：

• 通知对象
• 模板编号
• 渠道列表
• 变量参数

3.2 渠道适配器

不同渠道各自实现：

• 参数转换
• 发送逻辑
• 结果映射

也就是说：

• 上层统一
• 下层适配

---

四、最关键的几个设计点

4.1 渠道能力差异要允许表达

比如：

• 站内信有已读状态
• 短信有发送回执
• 邮件有主题和正文

4.2 结果状态要统一映射

例如统一成：

• INIT
• SENDING
• SUCCESS
• FAIL

4.3 新渠道接入成本要低

比如以后再加：

• 企业微信
• 钉钉
• 语音通知

不应该改动一堆业务代码。

---

五、最容易踩的坑

5.1 为了统一，把渠道特性全抹掉

最后模型会很别扭。

5.2 每个业务自己做一层渠道适配

平台价值会很快消失。

5.3 返回状态不统一

后面日志和回执会很难分析。

---

六、面试中怎么回答

如果面试官问你：

通知渠道抽象一般怎么设计？

你可以这样回答：

第一，我通常不会让业务方直接感知短信、邮件、Push、站内信这些底层差异，而会在平台层先抽一个统一通知模型，比如接收对象、模板编号、变量参数、发送渠道等，再让不同渠道在下面各自做适配。

第二，这种设计的关键不是把所有渠道做成完全一样，而是在统一入口下保留渠道自身差异，比如站内信有已读状态，短信有供应商回执，邮件有标题正文，这些特性都应该在适配层得到表达。

第三，真正落地时我会特别关注结果状态统一映射和新渠道接入成本，这决定了通知平台能不能长期扩展。

---

七、总结

渠道抽象真正难的，不是“包一层接口”，而是如何做到：

• 上层统一
• 下层灵活
• 状态可追
• 新渠道可扩

如果只记一句结论，我觉得可以记住这句：

通知渠道抽象最稳的做法，不是强行把所有渠道做成一样，而是“统一入口、适配差异、保留特性”。

---

八、结尾

如果你觉得这篇文章对你有帮助，欢迎点赞、收藏、关注。
后面这个通知平台系列我会继续往下写模板中心和实时推送的设计。