聊聊Push系统

最近一年多工作的主要精力都放在了Push系统的开发上，投入了不少心血在里面，但是这一年多的时间一直在写代码埋头赶路，疏于总结，借此机会回顾总结下系统的相关设计，希望对自己与读者都有所帮助。

概念

Push：有主动推的意思，实际上就是一个服务端主动推送消息到用户App的一个系统。从用户的视角Push

• App外部：主要展示形式为手机通知(手机系统功能，样式固定)。
• App内部：展示根据需求可以定制展示样式，各种Pop

从技术的角度来看，主动推送的东西主要是数据，数据可以用作上面的展示，也可以推一些无需展示内部处理的数据到客户端端上，但最终目的都是为了用户的体验。

架构

Push系统初始状态下包含的元素，只有发送者，系统通道，接收者。

发送者：生产推送内容的人，生产内容的方式 系统通道：将生产的内容触达的用户的通道，可以看做Push系统的核心

• 能对接各大手机厂商，用户设备离线状态下交给厂商发送
• 自建服务器与用户App的长连接通道，在线状态下直接通过自建通道触达用户

接收者：用户，内容在用户手机上展示

以上肯定比较简化，想要让其真正成为一个系统，还需要更多的事情在其中，比如说单次发送1亿条用户呢？ 系统上则需要将人群进行分片，分到不同的机器上处理这件事情，还有最好能灰度发送，如果对系统有一定压力还需要进行限流。当然还有对后续的效果有一定的监控措施，实时的数据表现。

• 大数据处理：任务分发
• 并发处理：灰度，限流
• 数据监控：数据平台

当然还可以在运营侧做一些东西，降低风险，增加一些审批流，所有发送内容数据管控，运营之外还有许多需要用到通道的业务进行支持。

• 内容系统：所有的用户可接触内容
• 开放平台：系统功能对外服务，支持横线业务
• 审批流：保护系统安全，防止一些胡乱操作

如果用户量较大，纯手动方式肯定是无法完成的，需要一些精细化的控制，个性化服务，内容个性化，时间个性化。此时系统的各种入口在抢占通道资源，还需要对通道做一些优先级分配，一些监控报警。

到这里基本上大致的元素都具备了，还能做的是一些细节的打磨，还有组件的职责，做一些决策：

• 通过系统定义运营的工作流程
• 整个开放平台，运营平台的易用性
• 系统的稳定性，扩展性；一些压测链路改造，模型的设计。除了Push，系统还可以是什么？

服务组成

其中一些比较重要的的服务或者依赖的平台：

• 内容平台
  • 内容安全工具
• 审批流平台
• 算法平台
• 数据平台
• 长连接平台
• 配置中心
• 监控报警中心
• …

技术使用

主要用到的技术：

• 缓存，限流，降级
• 配置中心，消息队列，调度中心，集群存储，RPC调用，日志管理
• 实时计算平台，离线计算平台
• 多线程知识，一些设计模式

想法

技术上不见得多么高深，主要因为用户基数较大，一定程度上增加了系统的复杂性。在技术上，在内部都有对应的平台封装了技术难点，真正技术难点的地方在一些底层或者中间件那边处理。

而业务开发主要做的事情，目前变成了理清楚业务重点，识别技术阻碍，推动项目进行。对分析能力，社交能力的要求高于技术的能力。

当然因为自己是技术，还是不能停下对技术的学习和探索上。

最后

时间有限，能想到的Push中比较有印象的东西应该都有提到，希望能对读者有所帮助。

作者：Real_man