摘 要：“移動時代”推送技術已成為開發移動應用的必備服務之一，公有推送BaaS服務也在近幾年內快速發展，并取得了市場的認可。在開發者自行構建服務，如何繞過一些“坑”將是本文的重點。
“移動時代”推送技術已成為開發移動應用的必備服務之一，公有推送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可以采用開放平臺的方式進行服務提供。以上幾點組成了一個推送服務的基本構建方案，當然還存在一些深入到開發細節的問題，需要開發人員根據特定場景逐類攻破。
