设计目标

基于上述的背景和需求，我们在设计移动Push推送第一阶段（单平台）架构时，首先要满足在iOS平台上，当IM长连接断开后，IM消息的能够触达到App客户端。其次我们的移动Push推送协议设计也具备很好的扩展性，在可以预见的未来，Push推送平台将逐步接入更多的App，因此我们设计目标iOSProvider是一个通用的iOS推送服务。不同App通过使用不同的移动Push推送证书借助同一iOSProvider完成移动Push消息推送，对于不同App的接入，我们采用了配置文件方式动态扩展接入，iOSProvider根据所配置App证书与APNS建立并维护多条TSL连接。配置文件的格式如下：

其中，第一个域为推送服务类型Type，以备扩展，1为APNS；第二个域为内部定义的APPID号，对应服务的App；第三个域为App的Apple证书文件名；第四个域为与APNS建立的连接数； 
每个App接入的配置为一行，举例如下：

除此之外，iOSProvider需要对每个接入App的APNS连接池进行管理，动态增删TSL连接，具备动态重连机制，并具有单独的反馈接收线程，用于异步接收APNS返回无效的Token，反馈给移动Push推送业务方，用于下次移动Push消息推送的优化。iOSProdiver根据Type、APPID选择对应的APNS连接，通过推送线程组装APNS包发送到APNS服务器，如图4所示。

图4 iOSProvider架构图

第二阶段（多平台）：架构如何设计优化

随着移动互联时代的到来，58同城研发了多个App，每一个App都有移动Push消息推送的需求（消息、运营活动、过期提醒等），并且每一款App同时具有多个终端：Android版、iOS版等。在这样的需求背景下，我们的移动Push推送平台需要继续演进，如何演进呢？

iOS移动Push推送通道可以很好的满足业务推送需求，但目前还不具备Android移动Push推送的能力，因此我们急需要研发Android移动Push推送通道。如何做？综合目前可选择的方案，我们选择了基于第三方推送平台以及自主研发高性能AndroidProvider的方案。

首先重点讲述针对Android移动Push推送的流程：第一，App客户端向第三方移动Push推送平台注册，获取对应的App唯一标示（Token）。第二，App将Token信息发送给AndroidProvider并集中存储，以便后续基于Token的移动Push推送。第三，AndroidProvider通过HTTPS或者TSL的方式和第三方移动Push推送平台建立连接，并把需要推送的消息发送到第三方移动Push推送平台。第四，第三方移动Push推送平台收到AndroidProver推送的消息后，会把此消息及时推送到App，从而完成整个推送过程，如图5所示。

图5 Android移动PUSH推送流程

AndroidProvider子系统整体结构分为四个层次，第一层为业务方移动Push推送接入，用于众多移动Push推送业务方的接入。第二层为网络交互层，用于接收移动Push推送业务方的消息数据以及发送请求处理层的处理数据给业务推动调用。第三层为请求处理层，用于处理网络交互层放入请求队列的数据，组装成第三方移动Push推送接口需要的数据，通过HTTP或者HTTPS的方式调用下游的接口，并等待请求结果的返回，把请求返回的结果放入回应队列。第四层为第三方移动Push推送平台，由第三方提供，开放给使用方接口，供调用其功能，如图6所示。

图6 AndroidProiver系统架构图

随着越来越多的移动App接入，移动Push推送需求趋向多样化，同时移动Push推送业务逻辑复杂化（多终端、批量发送、业务规则多样），公共策略每个业务方重复开发（深夜防打扰功能、发送频率和发送速率的限制等），造成开发效率低下。为了解决这些问题，我们抽象了公共的逻辑，并进行了统一的封装，对业务调用方透明，这些公共的逻辑包括：通用的策略和通用的控制，如图7所示。

图7 Android移动PUSH推送演进业务架构

在移动Push推送第二阶段（多平台）阶段，我们具备了Android、iOS的通道服务能力，满足推送消息的需求。但是我们没有提供统一的发送接口，业务方需要各自组包（Android、iOS）发送不同的推送通道，除此之外，推送通道性能方面还有待提升，推送通道稳定性还有待提升，此外推送通道包含了相对共同的业务逻辑，推送通道还不够“纯粹”。

第三阶段：架构和协议如何设计和优化

移动Push推送第二阶段还存在一系列的问题，因此在第三阶段需要解决，并且随着更多App接入，我们需要提供公司级统一的高性能移动Push推送平台。基于第三方移动Push推送平台，我们自主研发了满足每天推送百亿量级的高性能Provider，推送平台具备了高稳定性、接入方便，并提供了较高的推送到达率。

移动Push推送平台第三阶段我们如何架构和设计？首先我们满足对下游接入方多种连接的管理（HTTP、HTTPS、TCP、SSL、TSL），具备了多种连接动态伸缩性，从而满足Provider层对移动Push推送连接的要求。其次平台要具备高并发的特性，通过完全异步的设计和多线程支持，做到了高并发和支持10万QPS吞吐量。再次我们需要对接入下游的错误进行处理，一旦发现连接被断开等错误后，要能够自动使用新的连接，并且对已经发出还没到达App客户端的推送消息进行重发，以保证消息不丢失。第四我们需要对通道进行封装，对外提供统一的友好接入接口，屏蔽底层iOS和Android接入的差异性。最后在Android移动推送方面，我们接入了更多的第三方推送平台，以达到更高的到达率。

基于这些方面的考虑，58同城移动Push推送平台采用了低耦合的分层架构设计（如图3所示），分为三层Push Entry、Push Transfer、Provider（iOSProvider和AndroidProvider）。其中Push Entry是业务方调用的入口，我们采用异步消息队列的方式，提供了较高的业务方发送的速度，并且具备了消息缓冲的功能，使得高峰期的海量移动Push消息推送对整个平台冲击较少，也起到了保护推送系统的作用。Push Transfer会从Push Entry层接收消息进行解析，对推送消息进行合法性检查，如果格式不合法，直接丢弃，同时会进行接收到的推送消息格式转换成内部的消息格式，分平台转发到iOSProvider或者AndroidProvider上；provider接收到Push Transfer的消息后，会按照下游需要的消息格式（APNS协议、Android协议）进行转换，进行消息的下发，在下发的过程中，会进行消息的重发，以确保消息下发到第三方推送平台。

Provider模块内部如何设计？以iOSProvider为例，它分为三个层次：接入逻辑、业务逻辑、APNS出口。其中接入逻辑主要处理网络交互和请求分发；业务逻辑主要处理线程分裂扩展、并发处理和错误处理；APNS出口处理向APNS的发送逻辑，如图8所示。

图8 iOSProvider模块结构图