wxya（个人网站）千万级消息推送系统的设计与实践b
推送平台支持千万级的通知/消息推送，透传消息，快速触达用户，能够有效提升用户留存率、活跃度。推送平台提供了全链路的移动推送能力，只需接入推送平台的 API 就可以立即将推送消息送达到用户的移动设备。
同时，推送平台还提供了操作便捷的网页端管理后台，方便业务方的老师，进行应用授权，业务管理，推送消息管理，数据大盘查看，方便接入时的调试。
基本概念
什么是移动推送？
推送是指服务器定向将信息实时送达手机的服务，其中涉及到 “服务器” 和 “手机”，服务器为消息的发送者，手机为消息的接收者。“定向”和“实时”则说明推送可以指定接收者，并且需要实时送达。
推送消息分类
- 通知消息
当通知消息到达时，操作系统将负责接收消息，手机的通知栏（状态栏）上会显示的一条通知信息。通知主要用于提示用户的目的，应用于新闻内容、促销活动、产品信息、版本更新提醒、订单状态提醒等多种场景。其在华为、小米、vivo、oppo、iphone 五种机型上能够在开机联网的情况下实时到达，不要求 APP 保活。
- 透传消息
与通知消息不同，透传消息通常不会展示到通知栏上，通过长连接直接送达到应用，应用实时收到信息后解析消息内容，进而根据消息内容处理业务逻辑，透传消息主要用于应用内部业务逻辑，需要 APP 在线时才可以接收到消息，通常需要 APP 保活。
应用内消息就是通过透传消息将推送内容发送到客户端，当客户端收到消息后会解析消息内容，从而进行消息的自定义展示，同时也可以控制消息在指定页面的展示。
推送基本原理
推送通常有三种实现方式：PULL、PUSH、SMS；
PULL 方式：
客户端使用 PULL（拉）的方式，客户端和服务器端不需要维持 TCP 长连接，客户端以一定的时间间隔不断查询服务端是否有新的消息，通常采用 HTTP 方式，但需要考虑轮询频率，频率太小可能导致消息延迟，如果太快，则会大量消耗网络带宽和电池。所以大多数推送服务都不会使用轮询方式。
PUSH 方式：
服务器使用 PUSH（推送）的方式，对于客户端来说是一种被动的方式，而主动权在服务端，客户端和服务器之间需要维持一个 TCP/IP 长连接，当有消息时，服务端会向所注册到推送服务器的客户端推送消息。这种推送方式的优势是实时性强，客户端实现简单。当然也会有不足，如大量的客户端与服务端保持长连接会消耗服务器的资源，在未推送消息时，需要以一定的间隔发送心跳消息以维持连接，通常这种连接主要消耗的是内存资源。例如，200 万用户可能会消耗数 10GB 的内存。因此搭建这种推送机制时要使用性能好的服务器。这个方案可以解决由轮询带来的性能问题，但是会提高手机耗电。
SMS 方式：
在 Android 平台上，可以通过拦截 SMS 消息并且解析消息内容来了解服务器的意图，并获取其显示内容进行处理，这种方式可以归为 PUSH 方式，成本相对比较高，需要向移动公司缴纳相应的费用，基本上很少使用。
目前主流的推送服务都是采用 PUSH 的方式，比如 iOS 平台的 APNS，Android 平台的 GCM，国内第三方推送平台个推，极光，友盟以及各大手机厂商自建的系统级的推送通道。
功能介绍
提供多种推送功能，能够帮助移动业务精准，快速触达 C 端用户。
多种推送形式和方式
提供了多种推送方式，可以满足不同的业务需求。
从展示形式方面来说，我们提供了：
- 通知栏消息。
- 应用内的透传消息。
- 点击跳转消息。
从推送方式来说，我们提供了：
- 按用户推送。（支持一个用户多个设备）
- 按设备推送。（支持对一个用户的单个设备）
- 按模版推送。
- 按指定条件进行推送。
- 定时推送。
推送整体流程
- 客户端 sdk 经过网关的安全验证后链接到接入层服务（push-api）。
- 将从厂商处获得的 token 及 App 用户等信息绑定到服务端。此时会根据不同 App 的用户进行分库分表进行存储。
- 业务方调用推送平台提供的统一 API 发起推送请求。
- 将推送请求写入队列 Kafka。
- 消费服务根据业务方发送的 clientId 或者 userId 查找符合条件的设备。
- 将找到的设备推送给第三方推送平台。
- 第三方推送系统将消息推送给客户端。
- 厂商回调接入层服务触达接口，以完成触达率统计。
- 客户端 SDK 回调接入层点击接口，以完成点击率统计。
服务端设计
- 并创建 token，根据各家厂商时效缓存应用 token。
- 提供统一的接口给业务方使用，屏蔽各家厂商底层推送细节。
- 由于厂商批量推送接口一次最多只能推送 1000 个用户，推送接口会将当出现全量推送的任务，我们会按厂商将任务进行拆分成多个子任务。
- 再次消费子任务直接给厂商进行推送。
- 这时专门的推送模块消费到的子任务就是已经拼装好的各厂商的结构了。这里只负责推送并记录推送结果。供统计使用。
- 当端上收到推送消息后，再回调服务端的接口。
消息生命周期
业务侧
通道侧
规划与展望
- 不同 App 在厂商的活跃用户不一样，被限制发送的速率也不一样。需要增加主动退避的速率限制功能。
- 对接用户画像。由于移动推送中业务方用户的数据来源仅靠客户端 SDK 绑定，信息量较少。为业务方的运营老师更方便的在管理后台上圈选用户群体，我们正在与大数据同学不断迭代用户的画像标签。这样可以在移动推送的管理后台以更多的维度去圈选用户。
- 数据漏斗目前数据维度还不够丰富，计划添加用户，设备，第三方 token 纬度。推送数据方面增加漏斗层级。更高效监控查看推送数据。
- 将推送数据结合机器学习的模型，用以提高召回率。
- 自建长连接能力，提高用户的转化率。
- 接入微信的模版消息，丰富对 c 端通知能力的支持。
- 推送内容审核。
Loading...