聊聊 消息推送 架构设计
构建企业级统一基础推送服务，支持通过多渠道推送，能够统一集成的电子邮件、短信、聊天、钉钉、企业微信和其他公共社交应用：
- 聊天 - 微信Wechat/QQ
- 站内推送通知（移动设备和Web浏览器）
- 站外推送通知（移动设备，APP没有开启）
- 短信（如登录密码、营销活动）
- 电子邮件
- 钉钉
- 企业微信
企业级统一基础推送服务，是一个通用特性，适用于所有现代分布式应用，无论采用何种编程语言和技术。
推送能力的演进
第一阶段（模块化）：各自为政、各自封装
企业内部，早期业务量比较少，各系统基本都是有自己的推送模块，类型也是五花八门：
- 聊天模块
- 短信模块
- 电子邮件模块
- websocket 模块
各自封装模块比较简单，但是实现分散、各系统模块的质量也很难统一保证。
第二阶段（框架化）：集成框架
为了减少重复性设计、开发成本， 设计了统一的推送框架
同一套微服务框架，共用一个统一的推送框架
为了解决上述分散实现的问题，企业内部统一实现了一个综合各类推送功能的基础库，供业务方统一调用。
- 聊天基础starter
- 短信基础starter
- 电子邮件基础starter
- websocket 基础starter
于是，我们把 springboot-starter的逻辑封装到了服务治理框架内，微服务服务启动时，每一个服务对各种的starter进行运维管理、配置管理。
第三阶段（服务化）：推送服务
集成到框架，每一套服务，都需要重复性的解决3高问题。
- 推送服务，数据量大，需要解决跨库查询问题
- 推送服务，性能要求高，需要解决高并发问题
大数据量、并发量高，意味着：
- 硬件资源投入大
- 运维成本高
这样的基础服务，需要进行沉淀，剥离，集中成统一的、基础服务，由专门团队负责维护、迭代、运维。降低重复投入、重复建设成本， 真正的降本增效。
于是， 推送框架 演进为 推送服务
推送服务在业务系统中的位置
一个业务应用， 基本上有很多原子服务编排、整合而来，最终构建出一个完整的架构图。
- 接入层，这是外部请求进入内部系统的门户，所有的请求都必须通过 API 网关。
- 应用层