京東京麥商家開放平臺的訊息推送架構演進之路
本文來自京東商城京麥平臺組開發工程師曹德然的技術分享，感謝作者。
1、前言
京麥實時訊息推送是京東的京麥商家開放平臺的核心組成部分。從訊息源到訊息中心再到觸達使用者，以及最終根據訊息協議呼起操作頁面，京麥實時訊息推送是一個完整且健康的生態閉環。下面我會詳細的介紹下京麥實時訊息推送是如何在演變中不斷完善的。
京麥訊息框架示意圖：
我將從京麥商家開放平臺的訊息接入、MC系統搭建、訊息配置、訊息觸達、訊息監控五個方面來闡述和分享京麥實時訊息推送架構在2017年的成長。
即時通訊技術學習交流：
– 即時通訊開發交流群：215891622[推薦]
– 移動端IM開發推薦文章：《新手入門一篇就夠：從零開發移動端IM》
（本文同步釋出於：http://www.52im.net/thread-1321-1-1.html）
2、京東相關技術文章
《Netty乾貨分享：京東京麥的生產級TCP閘道器技術實踐總結》
3、本文分享者
2016年加入京東，目前就職於京東商城京麥平臺組，從事京東商家開放平臺的相關開發工作；
熱愛技術，熟悉各種常用開源框架，有豐富的大型分散式系統、高併發系統的開發經驗；
熱衷於對大資料的研究，對Hadoop、HBase以及ES有深入研究和理解。
4、訊息推送的接入
原有的訊息推送接入存在的弊端主要有以下兩點：
1）訊息接入方式多樣化：
京麥訊息包含業務系統類訊息、服務資訊類訊息以及其他各類訊息型別，訊息來源多種多樣。當時為了快速的接入各種訊息源，提供了servlet接入、client接入、JMQ接入等，接入方式多樣化，加上沒有完善的監控系統，這樣就導致了一個很尷尬的問題，我們自己都不清楚我們的訊息系統到底接入了多少種型別的訊息；
2）訊息處理中心與訊息源強依賴：
Anycall是系統訊息的主要入口，從Anycall到原訊息處理後臺是通過servlet呼叫來實現的，系統間的耦合性太強。
我們後期針對新一代訊息推送做的改善如下：
1）所有的系統訊息統一由Anycall進行接入，清晰化訊息型別邊界；
2）京麥訊息的接入方式統一：所有京麥訊息統一通過JMQ非同步化接入，並且根據不同業務通過不同的topic進行隔離，避免資料量大的業務（比如訂單訊息）對其他業務的阻塞；
3）麥圈的打造、咚咚離線訊息的接入等專案的完成，使得京麥訊息的生態不斷豐富，同時也極大的增加了使用者粘性。
5、MC（京麥訊息推送中心）系統的搭建
如上圖所示，原先京麥訊息推送的主要痛點如下：
1）接入方式不統一；
2）不穩定、大促被降級；
3）訊息處理邏輯複雜，接入新的訊息源困難；
4）沒有完善的訊息追蹤，訊息統計。
基於上述原因，重新打造了一個穩定、專一的訊息處理中心——MC系統（如上圖所示）：
1）統一的JMQ接入，在上一部分已經介紹過了；
2）MC系統與其他系統沒有耦合，不在存在由於訊息量過大對京麥其他業務造成影響的問題，實現了在大促時可以提供穩定的服務；
3）MC系統使用了broker分發的模式：模組化可插拔的處理方式，使得新訊息源的接入變的極其簡單，大大的縮短了開發的週期。正是這種broker分發模式的存在，咚咚離線訊息、ISV訊息訂閱等專案實現了快速接入，並提供服務；
4）在MC系統搭建的過程中，全鏈路訊息追蹤、訊息統計也得到了實現（在第五節訊息監控會詳細講解）。
6、推送訊息組裝的統一配置化
訊息過濾、訊息組裝、訊息儲存、訊息推送是京麥訊息中心的四大核心。訊息組裝是根據不同訊息的不同配置來進行的，而這些配置是在開發側的config配置中心來配置的，因此產品或者運營想從Anycall新接入一種系統訊息所做的工作量是極其大的。
基於這個原因，我們將所有的配置環節統一到了一個頁面。配置資訊的獲取新增三層快取（Guava Cache+redis+DB）來應對海量呼叫。統一配置頁面的存在使得業務類系統訊息的接入變的簡單快捷。
另一個比較大的優化是呼起協議配置化。之前訊息的呼起協議是寫死在訊息體裡面，極其的不靈活，甚至很多系統訊息無法對接呼起協議直接將連結暴露在訊息體裡，使用者的體驗是很不好的。為此，呼起協議對接統一協議管理中心（後面文章會詳細介紹），所有的呼起協議會根據訊息裡攜帶的protocolID從統一協議管理中心獲取。呼起協議的中心化、配置化使得訊息在系統流轉的過程中不再需要關注具體的呼起協議，簡化了訊息在系統中的處理邏輯。而且協議中心化之後，協議的內容可以直接呈現給產品和運營，整個訊息呼起的過程變得更加的清晰。
7、訊息推送的觸達（向客戶端擴散）邏輯
京麥訊息觸達分為線上通知和離線通知：
1）線上通知是通過服務端和客戶端的TCP長連線來實現的；
2）離線通知在最開始只有IOS的apns推送，Android系統無法很好的進行離線通知的推送一直是一大痛點。
針對Android系統無法很好的進行離線通知的推送的問題（俗稱Android網路、程式保活黑科技這些東西，詳見：《應用保活終極總結(一)：Android6.0以下的雙程式守護保活實踐》、《應用保活終極總結(二)：Android6.0及以上的保活實踐(程式防殺篇)》、《應用保活終極總結(三)：Android6.0及以上的保活實踐(被殺復活篇)》），我們開發了Android推送的開源包，對接了華為、小米、魅族三大廠商，實現了Android離線通知的推送。
8、完整的訊息推送路徑監控
全鏈路訊息追蹤系統，整合從訊息源到最終的訊息推送，整個鏈路各個節點訊息的流轉狀況，並且非同步化儲存。從上圖可以看到系統中的處理方式是，分別訂閱JMQ的同一個topic實現將訊息日誌分別儲存在ES和HBase，存ES保證了我可以在訊息管理後臺對所有訊息進行清晰透明化的追蹤查詢，存HBase是為了可以將資料長久的儲存並且進一步的分析。
訊息統計是依託於京東大資料平臺來實現的。將HBase裡的資料匯入到京東資料集市，從而對訊息資料進行各個維度的統計分析。
9、本文小結
京麥實時訊息推送架鬆經過一年的成長，在穩定、監控、內容豐富程度上有了長足的發展。下一步的規劃是完整的訊息失敗重試機制、提高訊息送達率、訊息推送產品化等。
京麥是一個年輕且充滿活力的團隊，京麥訊息系統伴隨著京麥的成長，不斷的完善優化。
附錄：更多相關技術文章
[1] 有關推送技術的文章：
《iOS的推送服務APNs詳解：設計思路、技術原理及缺陷等》
《信鴿團隊原創：一起走過 iOS10 上訊息推送(APNS)的坑》
《Android端訊息推送總結：實現原理、心跳保活、遇到的問題等》
《一個基於MQTT通訊協議的完整Android推送Demo》
《求教android訊息推送：GCM、XMPP、MQTT三種方案的優劣》
《掃盲貼：淺談iOS和Android後臺實時訊息推送的原理和區別》
《移動端IM實踐：谷歌訊息推送服務(GCM)研究（來自微信）》
《從HTTP到MQTT：一個基於位置服務的APP資料通訊實踐概述》
《基於WebSocket實現Hybrid移動應用的訊息推送實踐(含程式碼示例)》
《Go語言構建千萬級線上的高併發訊息推送系統實踐(來自360公司)》
>> 更多同類文章 ……
[2] 有關IM/推送的通訊格式、協議的選擇：
《強列建議將Protobuf作為你的即時通訊應用資料傳輸格式》
《全方位評測：Protobuf效能到底有沒有比JSON快5倍？》
《詳解如何在NodeJS中使用Google的Protobuf》
《技術掃盲：新一代基於UDP的低延時網路傳輸層協議——QUIC詳解》
>> 更多同類文章 ……
[3] 有關IM/推送的心跳保活處理：
《應用保活終極總結(一)：Android6.0以下的雙程式守護保活實踐》
《應用保活終極總結(二)：Android6.0及以上的保活實踐(程式防殺篇)》
《應用保活終極總結(三)：Android6.0及以上的保活實踐(被殺復活篇)》
《Android端訊息推送總結：實現原理、心跳保活、遇到的問題等》
《微信團隊原創分享：Android版微信後臺保活實戰分享(程式保活篇)》
《微信團隊原創分享：Android版微信後臺保活實戰分享(網路保活篇)》
《移動端IM實踐：WhatsApp、Line、微信的心跳策略分析》
>> 更多同類文章 ……
[4] 有關即時通訊架構設計：
《一套海量線上使用者的移動端IM架構設計實踐分享(含詳細圖文)》
《騰訊QQ1.4億線上使用者的技術挑戰和架構演進之路PPT》
>> 更多同類文章 ……
[5] 開源移動端即時通訊技術框架資料：
《開源移動端IM技術框架MobileIMSDK：常見問題解答》
《開源移動端IM技術框架MobileIMSDK：壓力測試報告》
>> 更多同類文章 ……
[6] 更多即時通訊技術好文分類：
（本文同步釋出於：http://www.52im.net/thread-1321-1-1.html）
相關文章
- 京東物流資料同步平臺“資料蜂巢”架構演進之路架構
- vivo推送平臺架構演進架構
- 京東小程式開放平臺，他來了
- 京東小程式開放平臺終於來了~
- 之家訊息推送平臺的演進（一）——概況與現狀
- 滴滴機器學習平臺架構演進之路機器學習架構
- 愛奇藝平臺的架構設計與演進之路架構
- 京東資料庫智慧運維平臺建設之路資料庫運維
- 新一代雲資料平臺架構演進之路架構
- 京東技術中臺的Flutter實踐之路Flutter
- 京東白條資料架構進化之路：要在資料的不確定性中探索架構的穩定性架構
- 開放平臺架構指南架構
- 開放平臺助力開發者-京東智聯雲釋出“SaaS加速器”
- 京東架構師解析URL監控架構
- 京東技術中臺Flutter實踐之路（二）Flutter
- 獨家解讀 | 滴滴機器學習平臺架構演進之路機器學習架構
- 劉慎寶 :京東集團財務系統架構設計之路架構
- SaaS架構：開放平臺架構設計架構
- 研發協同平臺架構演進架構
- 解密京東千億商品系統核心架構解密架構
- 乾貨 | 京東技術中臺的Flutter實踐之路Flutter
- 今日頭條架構演進之路——高壓下的架構演進專題架構
- 萬字乾貨：從訊息流平臺Serverless之路，看Serverless標準演進Server
- 滴滴機器學習平臺架構演進機器學習架構
- 人人都是架構師-清晰架構 | 京東物流技術團隊架構
- 對話京東安全首席架構師：電商平臺構建安全防護體系關鍵點架構
- 京東到家的持續整合實踐之路
- 實錘！購自京東的茅臺確屬假貨 京東：被掉包
- Android 訊息推送：第三方訊息推送平臺 詳細解析Android
- 京東卡拿不停！開源測試平臺 MeterSphere 眾測啦！
- 開放平臺日誌推送---kafkaKafka
- 廣告引擎平臺化演進之路
- 茅臺回應“京東假茅臺風波”：信任劉強東 京東能查明真相
- 線上公開課 | 京東雲監控系統設計及落地之路 京東雲技術新知
- 京東雲開放“技術百寶箱”，零售商家說今年618就靠它了！
- 騰訊音樂內容庫資料平臺架構演進實踐架構
- 億級流量系統架構演進之路架構
- 京東資深架構師程式碼評審歪詩架構
- 京東科技設計稿轉程式碼平臺介紹