推送服务
🚀 通知消息千万条,监控日志第一条,
🎯 发送失败不报警,排查问题两行泪。
# 为什么我们需要 notify
消息推送服务?📢
“短信不就直接调个 API 发送吗?搞这么复杂干啥?”
一开始,我们可能都这么想。但实际落地的时候,问题一个接一个,远远不止“发出去”那么简单!
# 1. 发送了,但用户说没收到,怎么办?🤷♂️
“运营:用户反馈短信收不到,查一下!”
尴尬了,我们只调用了短信 API,连个日志都没存。
短信 API 发出去了吗?运营商有没有返回状态?限流了吗?压根不知道……
✅ 解决方案
- 记录发送日志:请求时间、手机号、短信内容、返回状态
- 监控失败率,分析短信是否真的发送成功
- 用户反馈“没收到”时,立马查日志,而不是“蒙着头等”
# 2. 现在短信发送量大吗?有限流吗?📊
第三方短信接口可不是无限调用的,比如腾讯云 API 限流 3000QPS,如果量超了,会触发限流,直接发不出去。
但如果我们没有 监控,哪天业务量激增,短信发不出去,大家都慌了!
✅ 解决方案
- 监控短信发送情况:
- 总发送量、成功率、失败率
- 是否被限流?哪个业务触发的?
- 提前预警,避免业务方还在猛发短信,结果全被限流拦下了
有了监控,再也不怕运维半夜来敲门了!🛌
# 3. 业务方不小心发了两次怎么办?📨📨
用户点击了一次验证码,结果收到了 两条一模一样的短信,这体验……直接让人怀疑人生。
如果没有防重机制,短信白白浪费不说,还可能被用户投诉!📢
✅ 解决方案
- 去重策略:
- 同一手机号 N 秒内 不允许重复发送相同内容
- 业务方重复请求时,返回已有的短信发送记录
- 短信模板校验,避免业务方乱发
# 4. 这条短信谁发的?🔍
运营跑来说:“这条短信是我们公司发的吗?哪个业务发的?”
我们一看短信内容:“【XX科技】您的验证码是 123456”,然后???
公司那么多业务,鬼知道是哪边发的?
✅ 解决方案
- 发送日志+业务归属记录
- 每条短信都记录 业务系统、责任人、发送内容,运营要查,秒回!
**避免短信成“孤儿”,让每条消息都有“身份证”!**📇
# 5. 经常要接入新渠道怎么办?🌍
老板:“我们要支持 飞书/邮件/微信服务号,接入一下。”
**如果每次都要改代码、重启、发布,那开发不得炸了?**😵💫
✅ 解决方案
- 设计一个 通用
notify
消息推送服务 - 通过 配置化 实现不同渠道的接入
- 只要写一个 适配器,不用改主流程
- 运营随时调整通知策略,开发不用背锅
# 🌟 Notify 消息推送服务登场!
为了解决这些 痛点,我们设计了一套 统一的通知架构,用 异步 + 监控 + 统一接入 彻底搞定消息推送!👇
# 1. 解耦与高扩展性 🛠️
- MQ 作为中间件:
notify-api
统一接入后,把消息丢进 MQ,而notify-handler
负责具体的下发逻辑,这样 消息发送和业务调用完全解耦。- 业务方(调用方)不用关心具体怎么发短信、邮件、微信通知等,只管调用
notify-api
。 - 未来如果要新增 飞书、邮件、微信服务号,只需要扩展
notify-handler
,不用改调用逻辑!
# 2. 实时 vs 定时,灵活处理 ⏳
notify-admin
支持非实时消息的定时发送,比如营销短信、运营通知。notify-cron
作为 定时任务模块,定期触发通知任务(比如每日账单提醒)。notify-api
提供 实时调用,满足验证码、订单状态变更等 即时通知 的需求。- 实时消息和定时任务 各司其职,避免业务代码中塞一堆
sleep()
或者delayTask()
这类硬编码定时逻辑。 - 运营人员可以在
notify-admin
直接管理消息,减少开发介入。
# 3. 可靠性强,消息不丢失 ✅
- MQ 做消息缓冲 & 失败重试
- 消息发送失败(比如短信服务商宕机),不会直接丢失,而是可以通过 MQ 重试机制,在一定时间后自动重试发送。
- 日志可追溯
- 发送消息的所有环节(业务方 ->
notify-api
-> MQ ->notify-handler
-> 短信/邮件等)都可记录,排查问题时 一目了然!
- 发送消息的所有环节(业务方 ->
# 4. 业务隔离 & 责任清晰 🎯
- 不同的消息类型有独立的 handler
- 运营短信 vs 验证码短信 vs 订单推送,走不同的处理逻辑,互不干扰。
- 不同业务方的消息可追踪
- 运营、营销、支付等团队都可能发短信,通过
notify-api
统一记录 是谁发的,运营再也不会“迷路”了!
- 运营、营销、支付等团队都可能发短信,通过
# 5. 快速接入 & 低成本维护 💡
- 业务方调用
notify-api
,只需关心消息内容和接收人,不用操心短信、邮件、推送的底层实现。 - 新增渠道无需改动业务代码:
- 未来新增 WhatsApp、钉钉,只需要扩展
notify-handler
,不影响notify-api
和 MQ。
- 未来新增 WhatsApp、钉钉,只需要扩展
# 总结:高效、稳定、可扩展的通知系统!🎉
✅ 异步+解耦:不影响业务主流程,失败可重试!
✅ 实时 vs 定时灵活兼容:各种通知场景全覆盖!
✅ 监控 & 追踪:出了问题,能快速定位,不慌!
✅ 扩展性强:未来新增渠道,不改核心代码!
这个架构很适合高并发、高可靠性要求的消息通知系统,是一个 实战性极强的方案! 🚀
**所以,notify
服务,不仅要有,还得设计好!**💡