如何构建一套高可用的移动消息推送平台？

由于消息重发可能会造成客户端收到重复消息,需要在客户端进行消息去重.服务端为每一条消息分配了一个唯一 id,重发时唯一 id 不变.客户端需要保存收到的每一条消息,在接收到新消息时首先根据唯一 id 判断是否已经收到了这条消息,如收到则不响应.客户端保存消息可以采用 sqlite 数据库.

安全和控制

客户端 SDK 与服务端的通信过程使用 appKey 和 appSecret 进行权限控制.appKey 是服务端为每个 app 分配的唯一标识,appSecret 是服务端为每个 app 分配的秘钥.

客户端 SDK 在请求服务端 HTTP 接口时,会将 appKey+appSecret 做一次签名,将签名值作为签名 sign 参数,与其他请求参数(业务参数 +appKey)一同传到服务端；服务端拿到请求参数后,也先用 appKey+appSecret 做一次签名,比较和客户端传来的 sign 参数是否一致,从而完成权限验证过程.为了能够实现灵活控制推送与否,可实现黑名单管理的功能.处于黑名单内的 app 客户端不再进行消息的推送.黑名单控制的粒度到账号级别,也可以根据实际业务需要进行分组管理.

在某些业务场景中,需要对消息进行过滤,分析,做出相应的处理甚至预警,借助于消息推送平台,都能方便的实现.

SDK 设计

客户端 SDK 是基于推送服务的 SDK 封装实现,对外提供统一的使用接口.SDK 的使用者不再关注具体使用了哪些第三方推送、推送服务的接入细节.实现与推送服务的充分解耦,降低开发和使用成本.

由于 iOS 和 Android 平台的差异性,在客户端 SDK 的封装上存在差异,下面分别介绍两个平台的 SDK 封装方式.

iOS 平台

SDK 提供启动和停止的方法；同时定义一个 protocol,包含 SDK 提供的接口.SDK 在收到消息或出现错误时将会回调 protocol 中的接口.

由于推送的接入涉及 AppDelegate 的生命周期方法,为避免 SDK 使用者关注这些繁琐的细节,SDK 使用 Aspects 的方式,将推送时相应的处理函数 hook 到 AppDelegate 的生命周期方法上.

Android 平台

在 Android 中使用 Receiver 组件来接收收到的消息.一个基本的配置如下所示：

流程如下：当推送服务的 SDK 在接收到推送过来的消息后,将发送广播,这个广播的用 intent-filter 标识,当应用中的 Receiver 代码注册了这个 intent-filter,就可以接收到广播,并进行后续处理.

系统管理

图 5：后台管理示意图

消息后台管理系统提供应用申请、应用服务配置、推送服务配置、消息查询与管理等功能.

1、应用申请

填写应用名、应用描述等信息后,生成该应用唯一的 appKey 和 appSecret.

2、应用服务配置

为应用选择要使用的移动端通用服务,可供选择的有推送、反馈、版本发布.

3、推送服务配置

为应用配置推送服务,可供选择个推、极光等；以及推送时使用的优先级顺序.

4、消息查询与管理

查看应用所发出的消息,包括消息所属应用、所属账号、消息的状态、最终发送成功的第三方渠道、消息的来源、发送者 ip 等信息

5、数据统计

通过分析 message 表中的各消息的状态,可统计各应用消息的发送成功率和到达率,以及哪个第三方推送的更优,方便选择.同时,提供每日、每周、每月推送消息量的统计,并提供统计图表.

高可用、高性能、高稳定性

消息推送平台通过无状态设计、统一存储、冗余部署方式保证了高可用,对应的状态数据统一存储到 MySQL、Redis 中保证各个无状态实例共享数据.

对于消息的接收处理我们通过纯异步、动态多线程的方式提供了推送平台的高性能.同时对于异步接收的消息我们通过 log append 的方式保证消息先落地然后再进行处理,进一步确保系统在异常过程中我们可以随时恢复消息,保证不丢失.

通过质量保障、全方位多维度监控体系(基础监控、错误日志监控、发送数据波动监控、进程监控等监控指标)保障系统在出现问题时实现秒级报警、及时处理保证了消息推送平台的高稳定性.

写在最后

本文介绍了一种基于第三方或自建推送服务、但又不强依赖特定推送服务的通用移动消息推送中间件平台,可以实现安全、稳定、可靠的消息推送功能,并提供完善的数据统计,在实际应用中,可以结合邮件、短信、网站消息、用户留言等打造成更加通用的企业消息平台.

文章来自微信公众号：InfoQ

（编辑：衡阳站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!