作者｜李晓庆、董泽光

编辑|小智

消息推送作为移动APP运营的关键技术，得到了越来越广泛的应用。本文追溯推送技术的发展历史，剖析其核心原理，对推送服务的关键技术进行深入剖析，重点关注服务不稳定、消息丢失、延迟、访问复杂、缺乏统计等问题，消息推送时发生。问题，提供整套平台级高可用消息推送解决方案。在实践中，借助该平台，不仅可以显着提高消息到达率，还可以提高研发效率，并引入移动开发基础设施的平台架构思想。

推送基础知识

在移动互联网蓬勃发展的今天，大多数移动APP都提供消息推送功能，比如新闻客户端的热点新闻推荐、IM工具的聊天消息提醒、电商产品促销信息、企业应用的通知和审批流程等。推送对于增加产品活跃度、增加功能模块使用率、增加用户粘性、提高用户留存等方面具有重要作用。消息推送作为APP运营中关键的免费渠道，合理利用消息推送可以有效促进目标的实现。

Push最早诞生于中国，用于提醒新消息。在移动互联网时代，更多地应用在移动客户端程序中。从服务器获取数据通常有两种方式：第一种是客户端PULL（拉）方式，即每隔一段时间去服务器获取是否有数据；第一种是客户端PULL（拉）方式，即每隔一段时间去服务器获取是否有数据；第二种是服务器端PUSH（推）方式，服务器有数据时主动发送给客户端。

显然，PULL方案的优点是简单但实时性较差。我们还可以通过提高查询频率来提高实时性，但这会造成过多的电量和流量消耗。相反，PUSH方案是基于TCP长连接方式的。实时性不错，但由于需要保持APP客户端与服务器之间的长期连接心跳，也会造成额外的电量和流量消耗。因此，在整体架构设计上需要做出妥协和平衡。目前主流的推送实现方式都是基于PUSH的方案。

实现移动推送的三种方式

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

轮询模式（PULL）

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

短信推送方式（SMS PUSH）

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

长连接模式（PUSH）

移动推送是基于TCP长连接实现的。客户端主动与服务器建立TCP长连接后，客户端定期向服务器发送心跳包来维持连接。当有消息时，服务器通过已建立的TCP连接直接通知客户端。结尾。虽然长连接也会造成一定的开销，但它是目前针对轮询和短信解决方案缺点的最佳方法，并且通过良好的设计，可以将损失降到最低。但随着客户端数量和消息并发量的增加，消息服务器的性能和稳定性要求受到了很大的考验。因此，这种方法从难度上来说是最昂贵的。

推送解决方案

基于TCP长连接的方式是主流的推送方式。基于这种推送方式，逐渐发展出了一系列系统级和应用级的推送解决方案。

系统级解决方案

iOS 平台 (APN)

iOS 在系统级别与 的 APNs (Push) 服务器建立连接。应用程序通过观察者模式向iOS系统注册感兴趣的消息。系统收到APNs消息后，将其转发给相应的应用程序。整个流程非常清晰，所有APP共享。相同的系统级连接减少了系统开销。虽然APN可以无障碍访问，但在实际使用过程中，时不时会出现延迟、消息丢失的情况。

平台（C2DM）

C2DM(to)采用类似iOS的机制，支持系统层面的消息推送。但由于该服务在国内无法稳定访问，因此该方案对于中国用户来说基本无法使用。

除了官方的解决方案外，国内很多手机厂商也在其定制系统中内置了推送功能，比如小米、华为等。

应用级解决方案

1.第三方推送服务

鉴于C2DM推送平台不可用，国内涌现了大量第三方推送服务商。使用第三方推送服务的系统流程如下：

图1：消息推送流程

目前使用最广泛的第三方推送服务商有个推、极光、友盟、小米、华为、BAT等，大部分APP都会优先使用第三方推送服务。

2、自建推送服务

第三方服务在开发成本和消息到达率方面表现良好，但所有信息都会经过第三方服务器。对于信息敏感的APP来说，需要考虑构建一个自建的消息推送服务，以最大限度地提高安全性，但对于自建的推送服务，如果从头开始，需要解决几个难点：

首先，移动推送服务器维护和管理App客户端的海量长连接。二、App客户端如何保证Push常驻？我们可以发现Push不存在，可以定时拉取。第三，对于通信协议的制定，我们可以使用开源的XMPP方法，也可以自定义协议。无论我们采用哪种方式，都必须保证消息传输到达率的准确性。第四，在移动互联网网络环境中，经常会出现弱网络环境，尤其是2G、3G等网络不稳定的情况。确保消息在弱网络环境下不重复或不丢失也是一个挑战。

有问题

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

解决方案

为了解决上述问题，我们考虑构建一个基于第三方消息推送服务的移动消息推送中间件平台。该消息平台采用低耦合的分层架构设计（如图2所示），分为三层：接入层、传输层和应用层。接入层是业务侧调用的入口。我们使用异步消息队列来为业务系统发送消息提供更高的速度，并且它具有消息缓冲功能。即使高峰期海量消息推送对整个平台影响较小，保护推送系统；

传输层会接收接入层发来的消息并进行解析，检查推送消息的合法性，如果非法则直接丢弃该消息。同时将合法的消息转换为协议发送至相应的第三方推送平台；应用层主要提供统一的SDK供业务使用，将适配第三方推送平台的SDK接口封装成统一接口的SDK。这样，业务APP用户只需关注统一封装的SDK即可实现对业务消息的操作，而无需考虑滤波器权重、标定等各种常见操作。主要特点包括：

整个系统设计由移动推送平台、客户端SDK、应用管理接口三部分组成（第三方推送服务和自建推送服务统称为推送服务）。

图2：系统架构

移动推送平台提供统一服务，为应用层屏蔽推送服务接口，实现推送服务的动态轮换。推送平台将接收到的消息持久化到数据库中，方便消息推送失败的重发以及后续数据的统计分析。

客户端SDK为App提供统一的使用接口，屏蔽推送服务SDK的使用细节，并可实现多个推送SDK的替换，隐藏了SDK复杂的访问流程，方便使用。

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

主要流程

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

图3：消息推送中间件核心流程

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

推送过程中可能出现的异常总结如下：

根据消息发送流程，可以获取消息在生命周期内的状态变化：

图 4：消息状态机

重发机制

消息重发主要有三种场景：系统启动时，查询所有发送失败或者发送成功但没有收到客户端确认的消息，加载到推送队列中进行重发；系统运行时，后台线程定期查询需要重发的消息。 ，进入推送队列；手动触发时，消息直接添加到推送队列中。

由于消息推送中间件服务通常需要高可用性且采用分布式部署，因此必须保证消息重发在单个节点上执行且仅发送一次。需要使用分布式锁的方式来保证重传只进行一次。主流的实现方式有以下三种：

：通过竞争创建临时节点来获取锁。

：作者提出了分布式锁算法。从实现上看，该算法实现了更安全、更可靠的分布式锁管理。

数据库：使用的函数等

本文不详细介绍每种锁机制的特点。您可以根据实际应用需求选择任意一种。

由于iOS平台与平台之间存在差异，消息重发需要考虑平台差异。

使用第三方推送时，如果iOS应用运行在前台，第三方推送所维护的长连接会以透明的方式直接发送到APP，称为应用内消息；当APP在后台时，三方推送将消息推送给APNs，APNs再推送给APP，这就是APNs通知。通过APN推送时，手机收到消息后会在顶部通知栏中显示相关推送内容。此行为是系统级的，无法由 APP 控制。可能会出现这个问题：当APP在后台或者手机被锁定时，如果服务器重新发送消息，手机通知栏中会出现多条通知。

因此，认为APP在后台时，不再重新发送针对iOS平台的消息；只有当APP进入前台时，才会重新发送消息。可以通过第三方推送服务的API获取APP的活动状态。

平台不存在这个问题。

由于消息重发可能会导致客户端收到重复的消息，因此需要在客户端进行消息去重。服务器为每条消息分配一个唯一的ID，并且在重传时该唯一ID保持不变。客户端需要保存收到的每条消息。当接收到新消息时，首先根据唯一id判断该消息是否已被接收。如果已收到，则不会回复。客户端可以使用数据库来保存消息。

安全与控制

客户端SDK与服务器端的通信过程使用并控制权限。是服务器分配给每个应用程序的唯一标识符， 是服务器分配给每个应用程序的密钥。

客户端SDK请求服务端HTTP接口时，会用+进行签名，并将签名值作为签名sign参数，与其他请求参数（业务参数+）一起传输到服务端；服务器拿到请求参数后，也首先使用+进行签名，并与客户端传递的sign参数进行比较，完成权限验证过程。为了灵活控制是否推送，可以实现黑名单管理功能。黑名单中的应用客户端将不再推送消息。黑名单控制的粒度细化到账户级别，也可以根据实际业务需求进行分组管理。

在某些业务场景中，需要对消息进行过滤、分析，借助消息推送平台可以轻松实现相应的处理甚至预警。

SDK设计

客户端SDK基于推送服务的SDK封装实现，对外提供统一的使用接口。 SDK用户不再关注具体使用的第三方推送以及推送服务的接入细节。实现与推送服务完全解耦，降低开发和使用成本。

由于iOS和平台的差异，客户端SDK的封装存在差异。下面介绍两个平台的SDK封装方法。

iOS平台

SDK提供启动和停止方法；同时定义了一个接口，包含了SDK提供的接口。 SDK收到消息或发生错误时会回调该接口。

由于推送访问涉及到生命周期方法，为了避免SDK用户关注这些繁琐的细节，SDK使用了一种方法，将推送时对应的处理函数hook到生命周期方法中。

平台

使用组件来接收收到的消息。基本配置如下所示：

流程如下：推送服务的SDK收到推送的消息后，会发送广播。该广播带有 - 标记。当应用程序中的代码注册了这个-，就可以接收广播并进行后续处理。

系统管理

图5：后端管理示意图

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

1. 申请申请

填写应用名称、应用描述等信息后，会生成该应用的唯一总和。

2.应用服务配置

选择要用于该应用程序的通用移动服务。这些选项包括推送、反馈和版本发布。

3. 推送服务配置

配置应用的推送服务，包括个人推送、极光等；以及推送时使用的优​​先级顺序。

4.消息查询与管理

查看应用发送的消息，包括消息所属应用、所属账户、消息状态、消息发送成功的第三方渠道、消息来源、发件人IP等信息

5、数据统计

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

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

消息推送平台通过无状态设计、统一存储、冗余部署来保证高可用性。对应的状态数据统一存储，保证各个无状态实例共享数据。

对于消息接收和处理，我们通过纯异步和动态多线程提供推送平台的高性能。同时，对于异步接收的消息，我们通过日志来保证消息先落地再处理，进一步保证我们在系统异常过程中可以随时恢复消息，保证消息不丢失。

通过质量保障和全方位、多维度的监控体系（基础监控、错误日志监控、发送数据波动监控、流程监控等监控指标），系统出现问题时可以实现秒级报警并及时处理，保证了系统的正常运行。消息推送平台稳定性高。性别。

写在最后

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

推荐一本好书

“作者写这本书的语气完全教条主义，让人感觉居高临下。”

“作者不允许KOL写推荐？这本书怎么卖？”

“作者的个人履历非常丰富，为什么不同意添加作者简介呢？这是我十年来第一次遇到这种情况。”

“你确定这个作者在网上很受欢迎吗？”

这是出版社金牌编辑的原话。他说的是他出版的第一本书——《谈建筑》。社区中并不缺少架构图，而是缺少架构相关的基础知识。我们花了近两年的时间打磨这本可能注定不会畅销的技术书。不为别的，只是希望能为这个行业贡献一点点力量，引起一些思考也是好的。如果能够帮助一些软件工程师实现更好的工作效率和工作质量，那就超出预期了。

今天的推荐

点击下图阅读

今日头条打造千亿级微服务的实践