难得的好文:如何构建一套高可用的 APP 消息推送平台

  • 时间:
  • 浏览:2
  • 来源:uu直播快3_UU快3直播平台

基于 TCP 长连接的措施是主流的推送措施,基于该推送措施逐步发展出系统级、应用级一系列的推送补救方案。

iOS 在系统层面与苹果7手机手机 APNs(Apple Push Notification service)服务器建立连接,应用通过观察者模式向 ioS 系统注册关注的消息,系统收到 APNs Server 消息后转发到相应的守护进程运行运行,整个过程很清晰,而且所有 APP 都共用同有有四个 系统级的连接,减少了系统开销,确实 APNs 能无障碍的访问,但实际使用过程中,发现延时和丢消息的状态偶有位于。

移动推送的本身措施

2. Redis:Redlock 是 Redis 作者的提出了本身分布式锁的算法,基于 Redis 实现,该算法实现了本身更安全、可靠的分布式锁管理。3. 数据库:如使用 MySQL 的 GET_LOCK 函数

对于主次锁机制的特点本文不全部介绍,根据实际应用需要任选本身即可。

轮询措施(PULL)

短信推送措施(SMS PUSH)

2. 自建推送服务

移动互联网蓬勃发展的今天,大主次手机 APP 都提供了消息推送功能,如新闻客户端的热点新闻推荐,IM 工具的聊天消息提醒,电商产品促销信息,企业应用的通知和审批流程等等。推送对于提高产品活跃度、提高功能模块使用率、提升用户粘性、提升用户留存率起到了重要作用,作为 APP 运营中有 有四个 关键的免费渠道,对消息推送的合理运用能有效有益于目标的实现。

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

1、应用申请

本文作者:李晓清、董泽光

推送补救方案

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

图 2:系统架构

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

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

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

 

2、应用服务配置

 

原因分析分析推送的接入涉及 AppDelegate 的生命周期措施,为补救 SDK 使用者关注本身繁琐的细节,SDK 使用 Aspects 的措施,将推送时相应的补救函数 hook 到 AppDelegate 的生命周期措施上。

客户端和服务器定期的建立连接,通过消息队列等措施来查询与非 有新的消息,需要控制连接和查询的频率,频率不还要能过慢或过快,过慢会原因分析分析主次消息更新不及时,过快会消耗更多的资源(流量、电量等),对用户体验有较大伤害。

原因分析分析 iOS 和 Android 平台的差异性,在客户端 SDK 的封装上位于差异,下面分别介绍有有四个 平台的 SDK 封装措施。

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

Android平台

主要流程

SDK 提供启动和停止的措施;一起定义有有四个 protocol,中有 SDK 提供的接口。SDK 在收到消息或出現错误时原因分析分析回调 protocol 中的接口。

iOS 平台(APNs)

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

图 5:后台管理示意图

原因分析分析 iOS 平台和 Android 平台的差异,消息重发需要考虑平台差异性。

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

 

  ●  实现多点接入,可一起接入多套推送服务,根据历史推送成功率动态选泽最优推送路径,当两根路径失效可选泽备用路径进行推送,保证消息推送万无一失。  ●  引入消息持久化机制,方便追溯和统计。  ●  引入消息的 ACK 机制和重传机制,提高消息的到达率。  ●  实现数据监控和统计机制,提供相关数据的统计分析,和报警预警功能。  ●  提供 web 管理后台,便于进行 APP 设置、推送设置、查看数据报表,提高系统维护的工作时延。

整个系统设计由三主次组成:移动推送平台、客户端 SDK、应用管理界面(第三方推送服务和自建推送服务统称为推送服务)。

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

目前移动推送技术实现措施主要有以下本身:

原因分析分析消息重发原因分析分析会造成客户端收到重复消息,需要在客户端进行消息去重。服务端为每两根消息分配了有有四个 唯一 id,重发时唯一 id 不变。客户端需要保存收到的每两根消息,在接收到新消息时首先根据唯一 id 判断否原因分析分析收到了这条消息,如收到则不响应。客户端保存消息还要能采用 sqlite 数据库。

正常状态下,消息推送过程如下:

对于消息的接收补救大家 通过纯异步、动态多守护进程运行的措施提供了推送平台的高性能。一起对于异步接收的消息大家 通过 log append 的措施保证消息先落地而且再进行补救,进一步确保系统在异常过程中大家 还要能随时恢复消息,保证不丢失。

SDK设计

图 1:消息推送流程

Android 平台不位于该大间题。

3、推送服务配置

  ●  验证不通过,返回错误信息;验证通之前 ,为此条消息分配有有四个 唯一 id(uuid),将消息内容持久化到数据库中,此时消息的状态为待发送。  ●  消息进入推送队列中,将之前 推送接口请求的响应返回给业务方。  ●  推送队列的消费者从队列中取出待发送的消息,标记该条消息的状态为发送中,而且调用第三方推送服务接口进行发送。  ●  原因分析分析调用成功,那么标记该消息的状态为发送成功客户端未收到。  ●  客户端 SDK 在收到推送后,回调服务端接口,发送收到推送的回执;服务端收到客户端回执后,标记消息状态为发送成功客户端已收到。

对于推送过程中原因分析分析出現的异常状态,总结如下:

传输层会从接入层接收消息并进行解析,对推送消息进行合法性检查校验,原因分析分析消息不合法直接丢弃,一起将合法的消息进行协议转换并发送到对应的第三方推送平台;应用层主而且提供统一的 SDK 供业务使用,封装适配第三方推送平台的 SDK 接口到统一的接口 SDK 中,原本业务 APP 使用方只关注统一封装的 SDK 即可实现业务消息的操作,而需要考虑各种滤重、校验等通用操作。主要功能包括:

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

位于大间题

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

使用第三方推送时,原因分析分析 iOS 应用在前台运行,那么将通过第三方推送维护的长连接,以透传的措施直接采集到 APP,称为应用内消息;而当 APP 在后台时,则第三方推送将消息推送到 APNs,由 APNs 推送到 APP,称为 APNs 通知。当通过 APNs 推送时,手机在收到消息后将在顶部的通知栏出現相关推送内容,本身行为是系统级别的,APP 无法控制。原因分析分析会出現本身大间题:当 APP 在后台原因分析分析手机锁屏的状态下,原因分析分析服务端重发了消息,手机的通知栏将出現多条通知。

流程如下:当推送服务的 SDK 在接收到推送过来的消息后,将发送广播,本身广播的用 intent-filter 标识,当应用中的 Receiver 代码注册了本身 intent-filter,就还要能接收到广播,并进行后续补救。

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

 

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

  ●  在调用第三方推送服务接口成功后、第三方推送服务在采集至客户端的过程中,原因分析分析原因分析分析本身原因分析分析,造成客户端无法收到消息;此时消息的状态为发送成功客户端未收到,对于本身状态,需要重发。  ●  客户端在收到推送的消息后、向服务端发送 ACK 回执时,原因分析分析原因分析分析网络环境的大间题,造成服务端那么收到客户端发送的回执,此时消息的状态为发送成功客户端未收到,对于本身状态,需要重发。  ●  消息在重发 N 次(N 次可配置)、仍然那么进入发送成功客户端已收到的状态,那么将不再进行自动重发;管理界面将提供手动重发消息的操作入口,如有需要,还要能手动再进行重发。监控平台对于无缘无故重复不成功的消息会报警通知操作人员,原本操作人员还要能及时通过手动措施补救。

根据消息发送流程,还要能得到消息在生命周期中状态的变迁如下图:

 

连接措施(PUSH)

安全和控制

 

消息重发主要位于本身场景:系统启动时,查询所有的发送失败或发送成功未收到客户端回执的消息,加载到推送队列重发;系统运行时,后台守护进程运行定时查询需要重发的消息,进入推送队列;手动触发时,直接将消息加入推送队列。

5、数据统计

通过短信发送推送消息,并在客户端植入短信拦截模块(主要针对 Android 平台),还要能实现对短信进行拦截并提取其中的内容转发给 App 应用补救,本身方案借有益于运营商的短消息,要能保证最好的实时性和到达率,但此方案对于成本要求较高,开发者需要为每两根 SMS 支付费用。

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

 

原因分析分析消息推送顶端件服务通常要求高可用,为分布式部署,消息重发需要保证在单一节点执行,且保证只发送一次。需采用分布式锁的措施,保证重发只发一次,主流实现措施有本身:

移动 Push 推送基于 TCP 长连接实现, 客户端主动和服务器建立 TCP 长连接之前 , 客户端定期向服务器发送心跳包用于保持连接, 有消息的之前 , 服务器直接通过本身原因分析分析建立好的 TCP 连接通知客户端。尽管长连接也会造成一定的开销,对于轮询和 SMS 方案的硬伤来说,目前原因分析分析是最优的措施,而且通过良好的设计,还要能将损耗降至最低。不过,随着客户端数量和消息并发量的上升,对于消息服务器的性能和稳定性要求提出了非常大的考验。而且,就难度而言,此措施代价最高。

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

Android 的 C2DM(Android Cloud to Device Messaging)采取与 iOS 你这一的机制,都是由系统层面来支持消息推送,而且原因分析分析 Google 的服务在国内不还要能稳定的访问,此方案对于中国用户来说基本是无法使用的。

系统级方案

推送最早诞生于 Email 中,用于提醒新的消息,而移动互联网时代则更多的运用在了移动客户端守护进程运行。要获取服务器的数据,通常有本身措施:第本身是客户端 PULL(拉)措施,即每隔一段时间去服务器获取与非 有数据;第二种是服务端 PUSH(推)措施,服务器在有数据的之前 主动发给客户端。

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

在或多或少业务场景中,需要对消息进行过滤,分析,做出相应的补救甚至预警,借有益于消息推送平台,都能方便的实现。

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

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

消息推送作为移动 APP 运营中的一项关键技术,原因分析分析被那么广泛的运用。本文追溯了推送技术的发展历史,剖析了其核心原理,并对推送服务的关键技术进行深入剖析,围绕消息推送时产生的服务不稳定性,消息丢失、延迟,接入错综错综复杂,统计缺失等大间题,提供了一整套平台级的高可用消息推送补救方案。实践中,借有益于该平台,不仅能提能显著提高消息到达率,还能提高研发时延,并道出了移动开发基础设施的平台化架构思路。

很显然,PULL 方案优点是简单而且实时性较差,大家 也还要能通过提高查询频率来提高实时性,但这又会造电量、流量的消耗缺乏,反之 PUSH 方案基于 TCP 长连接措施实现,消息实时性好,而且原因分析分析要保持 APP 客户端和服务端的长连接心跳,也会带来额外的电量和流量消耗。而且在整体采集中需要折中平衡,目前主流的推送实现措施都是基于 PUSH 的方案。

 本文来自云栖社区媒体相互合作伙伴“Java技术栈”,了解相关信息还要能关注“Java技术栈”。

原文发布时间为:2018-10-18

 

而且,考虑当 APP 在后台时,针对 iOS 平台的消息不再进行重发;不还要能当 APP 进入前台,才重新进行重发。APP 的活动状态通过第三方推送服务的 api 还要能获取到。

Android 平台(C2DM)

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

在 Android 中使用 Receiver 组件来接收收到的消息。有有四个 基本的配置如下所示:

重发机制

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

无论是第三方推送服务,还是自建推送服务,在实际的使用过程中,发现都位于以下大间题:

4、消息查询与管理

第三方服务在开发成本和消息到达率上表现都是错,但所有信息会经过第三方服务器,对于信息敏感类 APP 而言,有必要考虑自建一套消息推送服务,能最大化保证安全,但对于自建推送服务,原因分析分析从零之前 刚始于来做需要补救多少难点:

推送基础

1. 第三方推送服务

为了补救以上大间题,大家 考虑基于第三方消息推送服务构建一套移动消息推送顶端件平台,该消息平台采用了低耦合的分层采集(如图 2 所示),分为三层:接入层、传输层和应用层。其中接入层是业务方调用的入口,大家 采用异步消息队列的措施提供了较高的业务系统发送消息的时延,而且具备了消息缓冲功能,即使高峰期的海量消息推送对整个平台冲击较少,保护了推送系统;

图 3:消息推送顶端件核心流程

  ●  缺乏 ACK 机制。推送的过程是异步的,从应用服务端发送到推送服务时,还要能得知发送与非 成功,而且从第三方推送服务采集到 APP 时,无法得知客户端与非 接收到。iOS 平台中,从推送服务发送到苹果7手机手机 APNs 服务时,同样无法选泽 APNs 与非 收到。一起,第三方推送服务通常使用共享的推送通道,受或多或少推送方的影响,原因分析分析造成消息的延迟和丢失。  ●  服务会被杀死。尤其在 Android 平台上,后台推送 service 会被各种主动原因分析分析被动原因分析分析 kill 掉,原因分析分析消息丢失。  ●  缺乏消息的持久化。对于推送服务而言,消息推送是来两根推两根,无法追溯历史消息和消息状态。  ●  缺乏重传机制。整个推送过程涉及多个环节,当其中某个环节出現大间题,造成客户端接收不还要能推送的消息时,就原因分析分析消息丢失,再无法接收到。  ●  客户端接入逻辑错综复杂。每接入有有四个 新的 APP,都是进行重复的接入工作,接入逻辑全部一致,代码无法复用,需要在不同项目中拷贝。  ●  客户端与推送服务的 SDK 强耦合。客户端使用推送服务的接口,而各推送服务提供的接口不统一,原因分析分析需要替换推送服务,那么接入主次代码需全部重写。  ●  缺乏数据监控和统计。每个应用每天推送了多少消息,成功到达 app 多少,失败多少,目前均那么统计。

补救之道

第一,移动推送服务器对 App 客户端海量长连接的维护管理。第二,App 客户端咋样保证 Push Service 常驻,对于 Android 大家 还要能通过发现 push service 不位于还要能定时拉起的措施。第三,通信协议的制定,大家 还要能采用开源的 XMPP 措施实现,也还要能自定义协议,不管哪种措施大家 都是保证消息传送的到达率的准确性。第四,在移动互联网网络环境下,无缘无故出現弱网环境,一阵一阵是 2G、3G 等网络不稳定的状态下,原因分析分析保证消息在弱网环境下不重、不丢也是有有四个 挑战。

ios平台

图 4:消息状态机

写在最后

应用级方案