高可用的移动消息推送平台方案.docx

高可用的移动消息推送平台方案.docx

《高可用的移动消息推送平台方案.docx》由会员分享，可在线阅读，更多相关《高可用的移动消息推送平台方案.docx（8页珍藏版）》请在冰豆网上搜索。

高可用的移动消息推送平台方案

高可用的移动消息推送平台方案

消息推送作为移动APP运营中的一项关键技术，已经被越来越广泛的运用。

本文追溯了推送技术的发展历史，剖析了其核心原理，并对推送服务的关键技术进行深入剖析，围绕消息推送时产生的服务不稳定性，消息丢失、延迟，接入复杂性，统计缺失等问题，提供了一整套平台级的高可用消息推送解决方案。

实践中，借助于该平台，不仅能提能显著提高消息到达率，还能提高研发效率，并道出了移动开发基础设施的平台化架构思路。

推送基础

移动互联网蓬勃发展的今天，大部分手机APP都提供了消息推送功能，如新闻客户端的热点新闻推荐，IM工具的聊天消息提醒，电商产品促销信息，企业应用的通知和审批流程等等。

推送对于提高产品活跃度、提高功能模块使用率、提升用户粘性、提升用户留存率起到了重要作用，作为APP运营中一个关键的免费渠道，对消息推送的合理运用能有效促进目标的实现。

推送最早诞生于Email中，用于提醒新的消息，而移动互联网时代则更多的运用在了移动客户端程序。

要获取服务器的数据，通常有两种方式：

第一种是客户端PULL（拉）方式，即每隔一段时间去服务器获取是否有数据；第二种是服务端PUSH（推）方式，服务器在有数据的时候主动发给客户端。

很显然，PULL方案优点是简单但是实时性较差，我们也可以通过提高查询频率来提高实时性，但这又会造电量、流量的消耗过高，反之PUSH方案基于TCP长连接方式实现，消息实时性好，但是由于要保持APP客户端和服务端的长连接心跳，也会带来额外的电量和流量消耗。

因此在整体架构设计中需要折中平衡，目前主流的推送实现方式都是基于PUSH的方案。

移动推送的三种实现方式

目前移动推送技术实现方式主要有以下三种：

轮询方式（PULL）

客户端和服务器定期的建立连接，通过消息队列等方式来查询是否有新的消息，需要控制连接和查询的频率，频率不能过慢或过快，过慢会导致部分消息更新不及时，过快会消耗更多的资源（流量、电量等），对用户体验有较大伤害。

短信推送方式（SMSPUSH）

通过短信发送推送消息，并在客户端植入短信拦截模块（主要针对Android平台），可以实现对短信进行拦截并提取其中的内容转发给App应用处理，这个方案借助于运营商的短消息，能够保证最好的实时性和到达率，但此方案对于成本要求较高，开发者需要为每一条SMS支付费用。

长连接方式（PUSH）

移动Push推送基于TCP长连接实现，客户端主动和服务器建立TCP长连接之后,客户端定期向服务器发送心跳包用于保持连接,有消息的时候,服务器直接通过这个已经建立好的TCP连接通知客户端。

尽管长连接也会造成一定的开销，对于轮询和SMS方案的硬伤来说，目前已经是最优的方式，而且通过良好的设计，可以将损耗降至最低。

不过，随着客户端数量和消息并发量的上升，对于消息服务器的性能和稳定性要求提出了非常大的考验。

因此，就难度而言，此方式代价最高。

推送解决方案

基于TCP长连接的方式是主流的推送方式，基于该推送方式逐步发展出系统级、应用级一系列的推送解决方案。

系统级方案iOS平台（APNs）

iOS在系统层面与苹果APNs（ApplePushNotificationservice）服务器建立连接，应用通过观察者模式向ioS系统注册关注的消息，系统收到APNsServer消息后转发到相应的应用程序，整个过程很清晰，并且所有APP都共用同一个系统级的连接，减少了系统开销，虽然APNs能无障碍的访问，但实际使用过程中，发现延时和丢消息的情况偶有发生。

Android平台（C2DM）

Android的C2DM（AndroidCloudtoDeviceMessaging）采取与iOS类似的机制，都是由系统层面来支持消息推送，但是由于Google的服务在国内不能稳定的访问，此方案对于中国用户来说基本是无法使用的。

除了Google官方提供的方案，中国众多的手机厂商在其定制的系统中也内置了推送功能，如小米、华为等。

应用级方案1.第三方推送服务

鉴于Android平台C2DM推送的不可用性，国内涌现出大量的第三方推送服务提供商，采用第三方推送服务的系统流程如下图：

图1：

消息推送流程

目前应用最为广泛的第三方推送服务提供商包括个推、极光、友盟、小米、华为、BAT等，绝大部分APP都会优先考虑采用第三方推送服务。

2.自建推送服务

第三方服务在开发成本和消息到达率上表现都不错，但所有信息会经过第三方服务器，对于信息敏感类APP而言，有必要考虑自建一套消息推送服务，能最大化保证安全，但对于自建推送服务，如果从零开始来做需要解决几个难点：

第一，移动推送服务器对App客户端海量长连接的维护管理。

第二，App客户端如何保证PushService常驻，对于Android我们可以通过发现pushservice不存在可以定时拉起的方式。

第三，通信协议的制定，我们可以采用开源的XMPP方式实现，也可以自定义协议，不管哪种方式我们都要保证消息传送的到达率的准确性。

第四，在移动互联网网络环境下，经常出现弱网环境，特别是2G、3G等网络不稳定的情况下，如果保证消息在弱网环境下不重、不丢也是一个挑战。

存在问题

无论是第三方推送服务，还是自建推送服务，在实际的使用过程中，发现都存在以下问题：

∙应用服务端与推送服务强耦合。

当推送服务不可用时，造成整个业务系统无法推送，甚无法正常工作。

∙缺乏ACK机制。

推送的过程是异步的，从应用服务端发送到推送服务时，可以得知发送是否成功，但是从第三方推送服务下发到APP时，无法得知客户端是否接收到。

iOS平台中，从推送服务发送到苹果APNs服务时，同样无法确定APNs是否收到。

同时，第三方推送服务通常使用共享的推送通道，受其他推送方的影响，可能造成消息的延迟和丢失。

∙服务会被杀死。

尤其在Android平台上，后台推送service会被各种主动或者被动原因kill掉，导致消息丢失。

∙缺乏消息的持久化。

对于推送服务而言，消息推送是来一条推一条，无法追溯历史消息和消息状态。

∙缺乏重传机制。

整个推送过程涉及多个环节，当其中某个环节出现问题，造成客户端接收不到推送的消息时，就导致消息丢失，再无法接收到。

∙客户端接入逻辑复杂。

每接入一个新的APP，都要进行重复的接入工作，接入逻辑完全一致，代码无法复用，需要在不同项目中拷贝。

∙客户端与推送服务的SDK强耦合。

客户端使用推送服务的接口，而各推送服务提供的接口不统一，如果需要替换推送服务，那么接入部分代码需完全重写。

∙缺乏数据监控和统计。

每个应用每天推送了多少消息，成功到达app多少，失败多少，目前均没有统计。

解决之道

为了解决以上问题，我们考虑基于第三方消息推送服务构建一套移动消息推送中间件平台，该消息平台采用了低耦合的分层架构设计（如图2所示），分为三层：

接入层、传输层和应用层。

其中接入层是业务方调用的入口，我们采用异步消息队列的方式提供了较高的业务系统发送消息的速度，并且具备了消息缓冲功能，即使高峰期的海量消息推送对整个平台冲击较少，保护了推送系统；

传输层会从接入层接收消息并进行解析，对推送消息进行合法性检查校验，如果消息不合法直接丢弃，同时将合法的消息进行协议转换并发送到对应的第三方推送平台；应用层主要是提供统一的SDK供业务使用，封装适配第三方推送平台的SDK接口到统一的接口SDK中，这样业务APP使用方只关注统一封装的SDK即可实现业务消息的操作，而不需要考虑各种滤重、校验等通用操作。

主要功能包括：

∙屏蔽推送接口，实现业务与推送服务解耦，提供一套通用的客户端SDK，简化客户端接入。

∙实现多点接入，可同时接入多套推送服务，根据历史推送成功率动态选择最优推送路径，当一条路径失效可选择备用路径进行推送，保证消息推送万无一失。

∙引入消息持久化机制，方便追溯和统计。

∙引入消息的ACK机制和重传机制，提高消息的到达率。

∙实现数据监控和统计机制，提供相关数据的统计分析，和报警预警功能。

∙提供web管理后台，便于进行APP设置、推送设置、查看数据报表，提高系统维护的工作效率。

整个系统设计由三部分组成：

移动推送平台、客户端SDK、应用管理界面（第三方推送服务和自建推送服务统称为推送服务）。

图2：

系统架构

移动推送平台提供统一的服务，对于应用层屏蔽推送服务接口，且实现推送服务可动态轮替。

推送平台将接收到的消息持久化到数据库中，方便进行消息推送失败后的重发，以及后续数据的统计分析。

客户端SDK对App提供统一的使用接口，屏蔽推送服务SDK使用细节，且实现多种推送SDK可替换，隐藏SDK复杂的接入过程，方便使用。

应用管理系统面向App开发人员，实现应用申请，推送服务配置，消息查询与管理，数据统计与分析。

主要流程

消息推送涉及的主要模块是消息推送平台和客户端SDK，主要流程如下图所示：

图3：

消息推送中间件核心流程

正常情况下，消息推送过程如下：

∙系统接收到业务方的推送请求后，首先进行权限的验证，这包括应用appKey的验证、接口参数的验证、黑名单验证等。

∙验证不通过，返回错误信息；验证通过后，为此条消息分配一个唯一id（uuid），将消息内容持久化到数据库中，此时消息的状态为待发送。

∙消息进入推送队列中，将之后推送接口请求的响应返回给业务方。

∙推送队列的消费者从队列中取出待发送的消息，标记该条消息的状态为发送中，然后调用第三方推送服务接口进行发送。

∙如果调用成功，那么标记该消息的状态为发送成功客户端未收到。

∙客户端SDK在收到推送后，回调服务端接口，发送收到推送的回执；服务端收到客户端回执后，标记消息状态为发送成功客户端已收到。

对于推送过程中可能出现的异常情况，总结如下：

∙在调用第三方推送服务接口时，可能出现调用失败的情况；此时需要标记消息的状态为发送失败，留待重发。

∙在调用第三方推送服务接口成功后、第三方推送服务在下发至客户端的过程中，可能由于某种原因，造成客户端无法收到消息；此时消息的状态为发送成功客户端未收到，对于这种状态，需要重发。

∙客户端在收到推送的消息后、向服务端发送ACK回执时，可能由于网络环境的问题，造成服务端没有收到客户端发送的回执，此时消息的状态为发送成功客户端未收到，对于这种状态，需要重发。

∙消息在重发N次（N次可配置）、仍然没有进入发送成功客户端已收到的状态，那么将不再进行自动重发；管理界面将提供手动重发消息的操作入口，如有需要，可以手动再进行重发。

监控平台对于一直重复不成功的消息会报警通知操作人员，这样操作人员可以及时通过手动方式处理。

根据消息发送流程，可以得到消息在生命周期中状态的变迁如下图：

图4：

消息状态机

重发机制

消息重发主要存在三种场景：

系统启动时，查询所有的发送失败或发送成功未收到客户端回执的消息，加载到推送队列重发；系统运行时，后台线程定时查询需要重发的消息，进入推送队列；手动触发时，直接将消息加入推送队列。

由于消息推送中间件服务通常要求高可用，为分布式部署，消息重发必须保证在单一节点执行，且保证只发送一次。

需采用分布式锁的方式，保证重发只发一次，主流实现方式有三种：

1.ZooKeeper：

通过竞争创建临时节点的方式获取锁。

2.Redis：

Redlock是Redis作者的提出了一种分布式锁的算法，基于Redis实现，该算法实现了一种更安全、可靠的分布式