一、从零开始：跨平台通知系统的需求分析

各位同学，今天我们要聊一个实战项目——设计一个跨平台通知系统。说白了，就是让我们的系统能同时发邮件、发短信、还能推送到手机App上。

我这些年做过不少消息推送相关的项目，从早期的短信网关到现在的多通道分发，踩过的坑真不少。今天就把这些经验揉进这个实战项目里，带大家走一遍完整的需求分析流程。

1.1 业务场景：为什么需要跨平台通知？

先想想看，一个用户在你的系统里下单了，你总得通知他吧？

• 重要通知：比如订单确认、支付成功、密码重置——这些必须保证送达，光靠App推送不够，万一用户没开通知权限呢？
• 营销消息：促销活动、新品上架——邮件和短信更合适，用户不一定天天看App。
• 紧急告警：系统故障、安全警告——短信+App双通道，确保第一时间触达。

我遇到过一家电商公司，只做了App推送，结果用户手机没开通知权限，订单超时了都不知道。后来加了短信通道，问题才解决。所以，多通道不是炫技，是刚需。

1.2 核心功能需求

我们来拆解一下，这个系统到底要做什么。

功能模块	说明	优先级
邮件发送	支持SMTP协议，可配置发件人、模板	P0
短信发送	对接第三方短信网关（如阿里云、腾讯云）	P0
App推送	支持iOS（APNs）和Android（FCM/华为）	P0
消息模板	支持占位符替换，统一管理模板	P1
发送记录	记录每条消息的发送状态、时间、接收方	P1
重试机制	发送失败自动重试，最多3次	P1
通道切换	一个通道失败，自动切换到备用通道	P2

嗯，这里要注意，P0是必须做的，P1是建议做的，P2是锦上添花。我建议第一次迭代只做P0，先把核心链路跑通。

1.3 非功能需求：别光顾着功能

很多新手做需求分析，只盯着功能看，忽略了非功能需求。结果上线就崩，我见过太多次了。

• 高可用：通知系统挂了，用户收不到验证码，整个业务就瘫痪了。必须支持多实例部署，单点故障不影响。
• 可扩展：今天支持邮件、短信、App推送，明天可能加个微信模板消息、钉钉机器人。设计时要预留扩展点。
• 异步处理：发通知不能阻塞主业务流程。用户下单后，订单服务只管写库，通知由异步队列处理。
• 幂等性：同一条通知不能重复发送。我遇到过短信网关回调重复，结果用户收到了两条一模一样的验证码。

1.4 架构设计思路：用设计模式解决痛点

好，需求明确了，接下来怎么设计？这里就要用到我们课程里讲的设计模式了。

我画了一张图，帮大家理清思路：

这张图里，三个设计模式各司其职：

• 单例模式：通知核心全局只有一个实例，管理所有通道的注册和调度。
• 工厂模式：根据配置动态创建邮件、短信、App推送等通道对象。新增通道时，只需加一个工厂子类。
• 观察者模式：各通道监听消息队列，发送完成后通知核心更新状态。核心作为被观察者，通道作为观察者。

1.5 避坑指南：我曾经踩过的坑

讲几个真实案例，大家引以为戒。

• 坑一：短信通道限流。有一次做活动，瞬间并发几千条短信，结果被网关限流了，用户收不到验证码。后来加了本地限流和队列削峰，才稳住。
• 坑二：邮件模板乱码。模板里用了中文占位符，结果邮件客户端显示乱码。后来统一用UTF-8编码，模板里只放英文占位符。
• 坑三：App推送证书过期。iOS推送证书一年一换，忘了续费，结果所有iOS用户收不到推送。后来加了证书过期告警，提前一个月通知运维。

1.6 技术选型建议

基于上面的需求，我推荐以下技术栈：

组件	推荐方案	理由
开发语言	Java / Go	生态成熟，适合做高并发服务
消息队列	RabbitMQ / Kafka	异步解耦，削峰填谷
数据库	MySQL + Redis	MySQL存记录，Redis做限流和缓存
邮件	JavaMail / Spring Mail	成熟稳定，支持模板
短信	阿里云短信 / 腾讯云短信	国内主流，API简单
App推送	极光推送 / 个推	封装了APNs和FCM，统一接口

我个人习惯用Java + Spring Boot，因为Spring的依赖注入和AOP特性，很适合实现工厂模式和观察者模式。当然，Go的性能更好，看团队技术栈偏好。

1.7 小结：需求分析的核心产出

好了，这一章我们完成了需求分析。核心产出物有三样：

1. 功能清单：邮件、短信、App推送三大通道，加上模板、记录、重试等辅助功能。
2. 非功能约束：高可用、可扩展、异步、幂等。
3. 架构思路：单例管核心、工厂管创建、观察者管通信。

下一章，我们会进入具体的设计和编码阶段。到时候我会带着大家，一行一行把代码写出来。嗯，今天就到这里，大家消化一下。

---

公众号:蓝海资料掘金营，微信deep3321