某大型电商平台消息中台

统一消息平台负责接收各业务系统的通知请求，完成模板校验、接收人识别和发送通道路由，再将消息投递到短信、邮件、App Push、微信或小程序、站内信等渠道，并统一记录发送结果。

该平台自 2015 年开始建设，后续持续演进至 2023 年。它将原本分散在不同业务系统中的消息发送能力集中管理，使订单、会员、营销和运营系统不必分别对接多个外部供应商。

建设背景

如果每个业务系统分别接入短信、邮件或推送供应商，会产生三类问题：接口和错误处理重复建设；手机号、邮箱、设备号和 OpenID 等用户信息缺少统一管理；更换供应商或增加新渠道时，需要同时修改大量业务应用。

统一消息平台的目标，是在业务系统与发送渠道之间建立稳定边界。业务方只描述发送对象、消息模板和业务参数，平台负责完成后续的校验、账号转换、通道选择、发送和记录。

职责与关键工作

在消息中台建设与演进阶段，我承担平台负责人的职责，工作范围覆盖架构设计、接口规范、供应商接入、交付上线与运行治理，主要包括：

• 设计统一的同步、异步和高优先级接口，明确业务系统与消息平台之间的责任边界；
• 建立模板组、模板参数和发送方式的管理机制，使内容与通道选择可以通过配置维护；
• 统一会员账号转换，将业务侧的会员标识解析为手机号、邮箱、设备号或 OpenID 等通道账号；
• 抽取短信、邮件、App Push、微信、小程序和站内信的发送能力，并隔离不同供应商 SDK 与错误码差异；
• 将频率控制、黑名单、免打扰、发送记录、回执、上行短信和计费主体纳入平台治理；
• 推动系统从早期集中实现演进为 Core、Service、API 和 VIP 等清晰模块，并逐步接入配置中心、限流、指标和日志能力。

除了方案设计，接口清单、联调测试、上线验收、供应商切换和后续的版本治理我也一路跟到底，从建设一直做到运营。

多通道发送如何统一

业务系统提交一条通知时，平台首先校验模板及参数，再根据会员标识取得对应的手机号、邮箱、设备号或社交平台账号。之后，平台按照模板配置选择发送渠道，并将请求交给相应的供应商适配器。

这种设计把稳定的业务接口与经常变化的外部通道分开。新增短信供应商或调整 App Push 服务时，主要修改平台内部的适配逻辑，业务系统可以继续使用原有接口。

对于不同渠道无法完全统一的能力，平台保留明确差异。例如，短信需要处理回执、上行内容和退订记录，站内信需要面向大量用户进行分片存储，App Push 则需要维护设备与送达状态。统一的是调用流程和治理规则，而不是强行将所有渠道处理成相同模型。

发送治理与运行控制

消息发送不仅要求“发出去”，还要控制发送对象、时间、频率和结果。

平台通过频控和日累计限制避免重复打扰，通过黑名单与退订记录阻止不应继续发送的消息；免打扰时段内的请求进入待发送记录，由定时任务在允许的时间继续处理。发送记录、供应商回执和状态刷新则为问题排查与业务核对提供依据。

这些能力把合规、用户体验、供应商成本和运行稳定性放到同一套平台规则下管理，避免各业务系统自行实现且标准不一致。

持续演进与架构判断

平台先后经历了短信和彩信、邮件、WebService 接入，到主动推送、App Push、微信与小程序、站内信、超级短信和虚拟号等阶段。供应商、框架和部署环境不断变化，但模板、账号归一化和发送记录等核心能力保持稳定。

到 2023 年，仍有几件事留在我的清单上：把异步发送全面转为持久化任务、统一早期接口各不相同的结果模型，以及用通道策略替换中心编排里堆积的条件分支。这些属于下一阶段，和平台已经做成的能力应该分开看。

项目价值

统一消息平台减少了业务系统对发送渠道和供应商的直接依赖，使新渠道接入、供应商切换、发送治理和故障排查能够在平台内部集中完成。

从业务抽象、接口与模块设计，到多供应商集成、运行控制和长期演进，这个项目让我完整地承担了一个平台从首次上线到持续治理的架构责任。