消息推送平台

承接各种消息类型的推送，如短信、邮件等。

统一管理多类型消息推送，支持实时/定时下发，实现消息处理流程标准化与全链路追踪。

参考项目：https://github.com/ZhongFuCheng3y/austin

技术栈：SpringBoot + Apollo + MySQL + Redis + Kafka + XXL-JOB + Flink

各个模块：

• 接入层：基于责任链模式，对消息进行前置检查、参数拼装、后置检查，发送消息至消息队列。
• 消息队列：不同渠道、不同类型消息间相互隔离，基于动态线程池对各消息者组的消费能力进行动态配置。
• 消费层：基于责任链模式，对消息进行夜间屏蔽、消息去重、敏感词过滤、限流。
• 定时任务：集成 XXL-JOB，通过三个线程池对定时任务的批量执行进行调控。
• 链路追踪：在关键处理阶段进行埋点，将埋点信息收集至 Kafka，Flink 清洗处理，数据写入 Redis，方面后续定位问题。

为什么会诞生这样一个系统？

传统方法

渠道账号、消息模板、发送参数强耦合。

比如发送一个邮件：

• 程序要配置操纵邮件的 API Key。
• 程序要配置哪段消息内容是公共的，哪段消息内容是每个接收者独有的。
• 程序要指定接收者与内容参数进行发送。

改进方法-简化

将渠道账号、消息模板抽象为平台功能：

• 将短信/邮件等渠道的密钥、配置方式抽象为“渠道账号”。
• 将发送的文本抽象为“消息模板”，接收者独有内容设置为占位符。

改进后，发送一条消息的方式就变为：

• 在消息推送平台创建“渠道账号”。
• 在消息推送平台创建“消息模板”，绑定“渠道账号”。
• 在程序中调用消息推送平台对应模板的 URL。

这样，业务侧仅需关心“接收者”与“内容参数”，即发送“什么内容”给“谁”。

相当于寄快递：

• 原先需要自己安排哪辆车去送，快递用什么包装。
• 现在仅需要将物品与地址交给快递中心，后续操作无需自己关系。

改进方法-增强

除了简化消息的发送外，平台还提供了一系列增强功能：

• 夜间屏蔽、消息去重、敏感词过滤、限流等。
• 消息生命链路追踪，通过解析日志查看消息下发的详细情况。