加入收藏 | 设为首页 | 会员中心 | 我要投稿 牡丹江站长网 (https://www.0453zz.com/)- 科技、建站、经验、云计算、5G、大数据,站长网!
当前位置: 首页 > 服务器 > 安全 > 正文

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

发布时间:2021-01-13 03:13:17 所属栏目:安全 来源:网络整理
导读:《如何构建一套高可用的移动消息推送平台?》要点: 本文介绍了如何构建一套高可用的移动消息推送平台?,希望对您有用。如果有疑问,可以联系我们。 作者:李晓清、董泽光 编辑:小智 消息推送作为移动 APP 运营中的一项关键技术,已经被越来越广泛的运用.本文
副标题[/!--empirenews.page--]

《如何构建一套高可用的移动消息推送平台?》要点:
本文介绍了如何构建一套高可用的移动消息推送平台?,希望对您有用。如果有疑问,可以联系我们。

 

作者:李晓清、董泽光

编辑:小智

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

推送基础

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

推送最早诞生于 Email 中,用于提醒新的消息,而移动互联网时代则更多的运用在了移动客户端程序.要获取服务器的数据,通常有两种方式:第一种是客户端 PULL(拉)方式,即每隔一段时间去服务器获取是否有数据;第二种是服务端 PUSH(推)方式,服务器在有数据的时候主动发给客户端.

很显然,PULL 方案优点是简单但是实时性较差,我们也可以通过提高查询频率来提高实时性,但这又会造电量、流量的消耗过高,反之 PUSH 方案基于 TCP 长连接方式实现,消息实时性好,但是由于要保持 APP 客户端和服务端的长连接心跳,也会带来额外的电量和流量消耗.因此在整体架构设计中需要折中平衡,目前主流的推送实现方式都是基于 PUSH 的方案.

移动推送的三种实现方式

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

轮询方式(PULL)

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

短信推送方式(SMS PUSH)

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

长连接方式(PUSH)

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

推送解决方案

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

系统级方案

iOS 平台(APNs)

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

Android 平台(C2DM)

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

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

应用级方案

1. 第三方推送服务

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

图 1:消息推送流程

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

2. 自建推送服务

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

第一,移动推送服务器对 App 客户端海量长连接的维护管理.第二,App 客户端如何保证 Push Service 常驻,对于 Android 我们可以通过发现 push service 不存在可以定时拉起的方式.第三,通信协议的制定,我们可以采用开源的 XMPP 方式实现,也可以自定义协议,不管哪种方式我们都要保证消息传送的到达率的准确性.第四,在移动互联网网络环境下,经常出现弱网环境,特别是 2G、3G 等网络不稳定的情况下,如果保证消息在弱网环境下不重、不丢也是一个挑战.

存在问题

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

  • 应用服务端与推送服务强耦合.当推送服务不可用时,造成整个业务系统无法推送,甚无法正常工作.
  • 缺乏 ACK 机制.推送的过程是异步的,从应用服务端发送到推送服务时,可以得知发送是否成功,但是从第三方推送服务下发到 APP 时,无法得知客户端是否接收到.iOS 平台中,从推送服务发送到苹果 APNs 服务时,同样无法确定 APNs 是否收到.同时,第三方推送服务通常使用共享的推送通道,受其他推送方的影响,可能造成消息的延迟和丢失.
  • 服务会被杀死.尤其在 Android 平台上,后台推送 service 会被各种主动或者被动原因 kill 掉,导致消息丢失.
  • 缺乏消息的持久化.对于推送服务而言,消息推送是来一条推一条,无法追溯历史消息和消息状态.
  • 缺乏重传机制.整个推送过程涉及多个环节,当其中某个环节出现问题,造成客户端接收不到推送的消息时,就导致消息丢失,再无法接收到.
  • 客户端接入逻辑复杂.每接入一个新的 APP,都要进行重复的接入工作,接入逻辑完全一致,代码无法复用,需要在不同项目中拷贝.
  • 客户端与推送服务的 SDK 强耦合.客户端使用推送服务的接口,而各推送服务提供的接口不统一,如果需要替换推送服务,那么接入部分代码需完全重写.
  • 缺乏数据监控和统计.每个应用每天推送了多少消息,成功到达 app 多少,失败多少,目前均没有统计.

解决之道

(编辑:牡丹江站长网)

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