浏阳烟花网站建站定位及营销功能,aspx网站配置服务器,wordpress多站点统计,a站网址是什么2019独角兽企业重金招聘Python工程师标准 本文详细讲述58同城高性能移动Push推送平台架构演进的三个阶段#xff0c;并介绍了什么是移动Push推送#xff0c;为什么需要#xff0c;原理和方案对比#xff1b;移动Push推送第一阶段#xff08;单平台#xff… 2019独角兽企业重金招聘Python工程师标准 本文详细讲述58同城高性能移动Push推送平台架构演进的三个阶段并介绍了什么是移动Push推送为什么需要原理和方案对比移动Push推送第一阶段单平台架构如何设计移动Push推送典型性能问题分析解决以及高可用、高性能、高稳定性如何保证。 什么是移动Push推送 移动Push推送是移动互联网最基础的需求之一用于满足移动互联环境下消息到达App客户端。以转转58赶集旗下真实个人的闲置交易平台为例当买家下单后我们通过移动Push推送消息告诉卖家当卖家已经发货时我们通过移动Push消息告诉买家让买卖双方及时掌握二手商品交易的实时订单动态。 为什么需要移动Push推送 移动互联网络环境下经常会出现弱网环境特别是2G、3G等网络环境下网络不够稳定App客户端和相应服务器端的长连接已经断开消息无法触达App客户端。而我们业务需要把Message转转App交易消息等、Operation转转App运营活动等、Alert转转红包未消费提醒等等消息推送给App客户端从而触发用户看到这些消息通过点击这些Push消息达到相应目标。 推送原理和方案对比 移动Push推送主要有以下三种实现方式。 移动App轮询方式PULL App客户端定期发起Push消息查询请求来达到消息推送的目的。PULL方案的优点和缺点都比较明显整体架构简单但实时性较差我们可以通过加快查询频率提高实时性但这会造成电量、流量消耗过高。移动App基于短信推送方式SMS Push 通过短信发送推送消息并在客户端置入短信拦截模块能拦截短信并解析后转发给App应用处理。这个方案实时性好、到达率高但成本很高。移动App长连接方式Push 移动Push推送基于TCP长连接实现消息实时性好这是目前主流的实现方式需要维护App客户端和服务端的长连接心跳会带来额外的电量、流量消耗在架构设计时需要做些折中以避免流量和电量的大量消耗。此外Push推送技术架构复杂度较高维护移动App客户端的海量长连接请求并建立与App客户端通信的加密通道整合成内部少量有限的长连接对通信数据进行压缩与解压以节省流量。目前移动Push推送技术基本都是结合这3个方案进行但对于不同的移动终端平台又有各自不同的实现这里详细介绍iOS和Android平台上的具体实现方案。 iOS平台 对于iOS平台由于其特殊性移动Push推送相对简单iOS应用是不允许service后台常驻的所以你没有别的选择也没办法通过开发自己的Push service来完成推送下发只能通过苹果APNS方式来完成。iOS移动Push推送流程如图1所示。图1 iOS移动PUSH推送流程 Android平台 在Android平台上由于对service常驻没有限制可用的方案就多一些可以通过Google官方C2DM 完成、开源方案例如XMPP、借助第三方或者完全自主研发的移动Push推送方案。 Google C2DM的主要流程如图2所示。 图2 C2DM移动PUSH推送流程 Google C2DM和Apple APNS流程大致类似但其最大的问题是移动Push推送服务器在国外很容易被屏蔽而且Push推送延迟较大。此外由于 Android社区分裂比较严重很多厂商直接就把C2DM模块给去掉了所以在国内这个方案极不可靠变成了一个理论上的方案。 移动Push推送开源方案 对于开源移动Push推送协议常见的有XMPP等, 事实上Google的C2DM底层也是基于XMPP协议实现的我们通过线下测试发现开源移动Push推送方案主要有两个问题第一没有ACK机制消息到达没有保证不可靠第二当移动Push消息请求量并发增大时系统开始变得不稳定甚至出现了模块宕机的情况。因此直接使用移动Push推送开源方案也不是非常可靠我个人建议在大规模使用开源的移动Push推送方案之前必须做到对开源技术方案整体把握住不然一旦出现问题无法及时定位和修复的话带来的后果将会是灾难性的。 借助第三方移动Push推送方案 除此之外目前移动Push推送市场上还有不少第三方推送产品可供选择但需要面临以下几个问题 到达率 虽然第三方移动Push推送产品都宣传到达率高于90%但是实际使用起来发现远远达不到。当然到达率低的问题除了第三方移动Push推送平台本身技术原因外还和业务推送方的用户选取有很大关系如果用户较活跃到达率就会高些如果用户不活跃或者用户已经卸载了相应的App客户端必然造成到达率进一步降低。实时性控制度 第三方移动Push推送产品的推送通道是共用的会面向多个推送客户如果某一个客户Push推送量特别大那么其他的消息实时性可能就会受到影响这些都是业务推送方不可控的会比较被动。 完全自主研发的移动Push推送方案 我们曾经考虑实现一套完全自主的移动Push推送平台如果从零开始来做需要解决几个难点第一移动Push推送服务端对移动App客户端海量长连接的维护管理。第二App客户端常驻 service稳定性如何使Push service常驻我们可以借助父子进程互相监控的方式来做到一旦发现对方进程不在了会重新建立继续循环监控。第三手机内存不足时系统会杀掉Push service甚至有些操作系统比较强势它会向iOS系统一样并不允许第三方Push service 常驻。第四移动Push推送到达率的提高除了技术手段外还有一些PR的手段比如移动App客户端Push service通过在相应操作系统上添加白名单的方式使其永久常驻。总之在移动互联复杂的场景下如何让移动Push推送到达率变得更高不是一件简单的事儿。 58同城移动Push推送方案 我们综合考虑前面讲述的开源、基于第三方、完全自主研发方案58同城并没有选择从零开始完全自主研发而是采用了基于第三方移动Push推送平台和自主研发高性能Provider的方案如图3所示满足每天百亿量级的吞吐量并通过动态组合和扩展的方式结合离线的移动Push推送数据分析不同手机使用不同的推送策略针对性地优化。在Android平台我们融合多种第三方移动Push平台从而有效提升到达率。 图3 58同城移动PUSH推送平台技术架构 第一阶段单平台架构如何设计 背景需求 2011年我们研发了58帮帮这是一款满足58用户和商户之间沟通的即时通讯软件用户间可以互相添加好友、收发消息等。58帮帮的消息推送基于App客户端和服务器的长连接一旦这条长连接断开那么IM服务端的消息将无法推送给App客户端用户也无法看到这些消息。在iOS平台上58帮帮App切换到后台后App与IM的长连接断开消息无法触达这时候我们需要借助iOS APNS机制IM消息需要发送给APNSAPNS再转发对应的消息到58帮帮App。Android切换至后台App与IM的长连接保持IM消息可以正常推送因此在这个阶段我们需要解决的问题是在iOS平台上当58帮帮App切后台后IM在长连接断开后的消息触达需求。 设计目标 基于上述的背景和需求我们在设计移动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、ProvideriOSProvider和AndroidProvider。其中Push Entry是业务方调用的入口我们采用异步消息队列的方式提供了较高的业务方发送的速度并且具备了消息缓冲的功能使得高峰期的海量移动Push消息推送对整个平台冲击较少也起到了保护推送系统的作用。Push Transfer会从Push Entry层接收消息进行解析对推送消息进行合法性检查如果格式不合法直接丢弃同时会进行接收到的推送消息格式转换成内部的消息格式分平台转发到iOSProvider或者AndroidProvider上provider接收到Push Transfer的消息后会按照下游需要的消息格式APNS协议、Android协议进行转换进行消息的下发在下发的过程中会进行消息的重发以确保消息下发到第三方推送平台。 Provider模块内部如何设计以iOSProvider为例它分为三个层次接入逻辑、业务逻辑、APNS出口。其中接入逻辑主要处理网络交互和请求分发业务逻辑主要处理线程分裂扩展、并发处理和错误处理APNS出口处理向APNS的发送逻辑如图8所示。 图8 iOSProvider模块结构图 对于移动Push推送平台来说追求达到率是我们最核心的指标没有之一。因此在Android方面我们融合了多个第三方推送平台通过机型控制对不同的机型使用不同通道进一步提升推送到达率。AndroidProvider层进行消息推送策略的控制先推送一通道根据此推送通道ACK情况是否继续推送其他通道。推送多个Push通道会出现推送消息重复到达App客户端的情形此时需要App客户端根据推送消息ID进行去重收到的重复推送消息忽略处理。 典型性能问题分析解决以及高可用、高性能、高稳定性如何保证 在移动Push推送不断演进的过程中我们遇到了AndroidProvider并发低的问题仔细分析是因为我们采用HTTPS库由于库中HTTPS的连接实现不是线程安全的对每个HTTPS的请求都加锁串行化处理以保证线程的安全性。发现问题后我们通过在线上增加多进程部署的方式暂时解决使得我们有足够的时间分析此问题产生的根本原因。经过深入分析发现原因是我们对HTTPS的库掌握不够导致加锁粒度过大通过HTTPS库提供的更小粒度的锁我们不仅解决了线程不安全的问题也提升了AndroidProvider的并发度如图9所示。 图9 HTTPS库细粒度锁实现方式 总之58同城统一的高性能移动Push推送平台通过无状态化设计和冗余部署等方式确保了推送平台的高可用通过纯异步、动态多线程的支持提供推送平台的高性能通过质量保证、多种监控机制进程监控、语义监控、错误日志监控、数据波动监控等有问题及时发现处理保证了推送平台的高稳定性。 最后我要感谢项目组的同学特别感谢姚劲同学有了你们持续不断的努力和付出才有了今天这篇文章也感谢老婆大人有你在背后默默的支持才有了今天这篇文章。 孙玄58赶集集团系统架构师技术负责人技术委员会架构组主任也是58同城即时通讯、C2C技术负责人负责58核心系统的架构以及优化工作。分布式系统存储专家前百度高级工程师参与社区搜索部多个基础系统的设计与实现。 本文为《程序员》原创文章未经允许不得转载订阅2016年《程序员》请点击 http://dingyue.programmer.com.cn 转载于:https://my.oschina.net/agileai/blog/630299
