1、前言
京麥實時消息推送是京東的京麥商家開放平臺的核心組成部分。從消息源到消息中心再到觸達用戶，以及最終根據消息協議呼起操作頁面，京麥實時消息推送是一個完整且健康的生態閉環。下面我會詳細地介紹下京麥實時消息推送是如何在演變中不斷完善的。
京麥消息框架示意圖：
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、本文小結
京麥實時消息推送架構經過一年的成長，在穩定、監控、內容豐富程度上有了長足的發展。下一步的規劃是完整的消息失敗重試機制、提高消息送達率、消息推送產品化等。
京麥是一個年輕且充滿活力的團隊，京麥消息系統伴隨著京麥的成長，不斷地完善優化。
聲明：本文由網站用戶竹子發表，超夢電商平臺僅提供信息存儲服務，版權歸原作者所有。若發現本站文章存在版權問題，如發現文章、圖片等侵權行為，請聯系我們刪除。
