用友iUAP马太航：私有平台级推送服务技术构建方案
2015-08-26 13:10:27   豫闻网   评论：0

　　“移动时代”推送技术已成为开发移动应用的必备服务之一，公有推送BaaS服务也在近几年内快速发展，并取得了市场的认可。在一些特定场景下应用开发者受网络、区域、安全等因素影响，需要构建私有推送服务，不依赖第三方组织，这需要开发者自行构建服务，如何绕过一些“坑”将是本文的重点。

　　官方推送(Android、IOS、WinPhone)服务GCM、APNS、MPNS受国内外网络因素影响，体验相对较差，只有苹果APNS表现尚可，但也存在一些问题，如：推送延迟、即时性无法保障等，另外从系统占有率角度考虑，可以忽略WinPhone的推送实现。服务划分可以将推送划分为客户端设计和服务端设计两个方面。

　　服务端方面需要考虑到平台化要素，服务设计无状态化，非专有服务，服务本身不存储业务数据这是一个大前提。设计之初需要规划推送服务的规模，支撑10万人与100万人的推送服务从架构角度存在巨大的不同，从这个角度出发，可以将服务划分为单机架构与集群架构，其中提升单机负载是一个技术体系，集群稳定是另外一个技术体系，从技术特性上分析，推送与即时通讯非常雷同，但是存在一些差异，即时通讯是具备业务属性关系的，例如：用户A给用户B发消息，用户A需要知道用户B在哪台服务器上，这就涉及到服务状态的管理的问题，需要存在一个中心节点管理状态，而推送服务本身不存在这类问题，只有平台给用户发消息，服务本身挂掉后无需关注状态迁移等问题，只需要关注通讯的即时性和稳定性。

　　由于弱化了状态的属性，单机性能最大化原则成为了单机技术架构设计的重点，可以体现为高性能、高并发等特性，这里不推荐使用一些功能非常全面的服务框架如：Androidpn(Android Push Notification) ，不推荐的理由包含几个因素：1、成熟度;2、处理能力;3、支持协议;4、开发便利性;功能越全的框架对性能和扩展性的提升难度越大，不适用于平台级或者企业级推送。这里拿Androidpn进行框架剖析，他的层级关系为：Androidpn基于Openfire/XMPP，Openfire/XMPP基于Mina，Mina基于Java NIO，最后到达网络，涉及的技术点比较多，优化难度大。这里推荐仅使用网络开发库或纯网络开发的方式搭建服务平台，公有云的方案包含：Erlang/OPT、C/C++ Boost asio、Libevent等，私有推送服务需综合开发成本、开发能力、开发周期等要素，可以选择一些Java 的网络开发框架如：Mina、Netty，在仅维持心跳的情况下，单台4C8G的虚拟机可以支撑至少C100的连接场景。

　　服务端实现流程，可以划分为2个部分：1、业务逻辑实现层，主要处理当前设备主线及单一任务;2、共享逻辑实现层，处理群组消息，通知消息，及复杂消息业务。业务逻辑层从功能角度划分包含：设备管理(如注册、登录)、位置管理、消息回执、设备标签、在线情况等，任务应处于一个单独的Work工作线程。共享逻辑层，主要面向集群及单机连接管理，独立于服务线程之外，对内管理整个任务线程池，对外接收集群任务。处理对于性能的考虑，任务本身避免直接访问数据库和集群资源，应独立出资源适配层，批量处理资源任务，并下发结果给工作线程。

　　合适的通讯协议非常重要，基于HTTP轮询、伪长连协议占用资源大，性能不佳、不适用于平台级推送。基于TCP长连协议包含很多种，例如XMPP、MQTT等，相对较重、协议体过长、交互次数多，不适合成为终端通讯的协议，可以作为集群内部通讯协议的补充。推荐方案应设计基于TCP的私有协议，规定定长数据包头加消息体，消息体可以采用JSON数据格式，包含:设备注册登录、心跳消息与响应、消息体、消息类型、位置、回执、扩展等基础属性。加密层可以选择三四层组合方式，如：Ipsec、ssl/tls。

　　客户端设计区别于服务端，需要针对平台版本进行适配，提供SDK提升易用性，如：Android 4以下版本，Android 4以上版本、IOS 7、8等。IOS受其多任务模型的影响，需要对消息即时性调整预期，当应用关闭时候，只能依靠APNS方式实现消息送达。Android平台则无需考虑这类问题，并且可以进行一定的通讯优化，如采用单通方式，多个应用共用一个Service进行与后端服务通讯，减少请求次数。

　　最后一点：服务端管理工具和服务端API，工具主要是针对服务本身的管理及统计分析信息。服务端API可以采用开放平台的方式进行服务提供。以上几点组成了一个推送服务的基本构建方案，当然还存在一些深入到开发细节的问题，需要开发人员根据特定场景逐类攻破。