1、前言
京麥實時消息推送是京東的京麥商家開放平臺的核心組成部分。從消息源到消息中心再到觸達用戶，以及最終根據(jù)消息協(xié)議呼起操作頁面，京麥實時消息推送是一個完整且健康的生態(tài)閉環(huán)。下面我會詳細地介紹下京麥實時消息推送是如何在演變中不斷完善的。
京麥消息框架示意圖：
4、消息推送的接入
原有的消息推送接入存在的弊端主要有以下兩點：
1）消息接入方式多樣化：
京麥消息包含業(yè)務系統(tǒng)類消息、服務資訊類消息以及其他各類消息類型，消息來源多種多樣。當時為了快速的接入各種消息源，提供了servlet接入、client接入、JMQ接入等，接入方式多樣化，加上沒有完善的監(jiān)控系統(tǒng)，這樣就導致了一個很尷尬的問題，我們自己都不清楚我們的消息系統(tǒng)到底接入了多少種類型的消息；
2）消息處理中心與消息源相依賴：
Anycall是系統(tǒng)消息的主要入口，從Anycall到原消息處理后臺是通過servlet調用來實現(xiàn)的，系統(tǒng)間的耦合性太強。
我們后期針對新一代消息推送做的改善如下：
1）所有的系統(tǒng)消息統(tǒng)一由Anycall進行接入，清晰化消息類型邊界；
2）京麥消息的接入方式統(tǒng)一：所有京麥消息統(tǒng)一通過JMQ異步化接入，并且根據(jù)不同業(yè)務通過不同的topic進行隔離，避免數(shù)據(jù)量大的業(yè)務（比如訂單消息）對其他業(yè)務的阻塞；
3）麥圈的打造、咚咚離線消息的接入等項目的完成，使得京麥消息的生態(tài)不斷豐富，同時也極大的增加了用戶粘性。
5、MC（京麥消息推送中心）系統(tǒng)的搭建
▲ 原京麥消息推送系統(tǒng)的接入邏輯圖
如上圖所示，原先京麥消息推送的主要痛點如下：
1）接入方式不統(tǒng)一；
2）不穩(wěn)定、大促被降級；
3）消息處理邏輯復雜，接入新的消息源困難；
4）沒有完善的消息追蹤，消息統(tǒng)計。
▲ 新京麥消息推送系統(tǒng)的接入邏輯圖
基于上述原因，重新打造了一個穩(wěn)定、專一的消息處理中心——MC系統(tǒng)（如上圖所示）：
1）統(tǒng)一的JMQ接入，在上一部分已經(jīng)介紹過了；
2）MC系統(tǒng)與其他系統(tǒng)沒有耦合，不再存在由于消息量過大對京麥其他業(yè)務造成影響的問題，實現(xiàn)了在大促時可以提供穩(wěn)定的服務；
3）MC系統(tǒng)使用了broker分發(fā)的模式：模塊化可插拔的處理方式，使得新消息源的接入變的極其簡單，大大的縮短了開發(fā)的周期。正是這種broker分發(fā)模式的存在，咚咚離線消息、ISV消息訂閱等項目實現(xiàn)了快速接入，并提供服務；
4）在MC系統(tǒng)搭建的過程中，全鏈路消息追蹤、消息統(tǒng)計也得到了實現(xiàn)（在第五節(jié)消息監(jiān)控會詳細講解）。
6、推送消息組裝的統(tǒng)一配置化
▲ 新京麥消息推送系統(tǒng)的消息組裝處理邏輯圖
消息過濾、消息組裝、消息存儲、消息推送是京麥消息中心的四大核心。消息組裝是根據(jù)不同消息的不同配置來進行的，而這些配置是在開發(fā)側的config配置中心來配置的，因此產(chǎn)品或者運營想從Anycall新接入一種系統(tǒng)消息所做的工作量是極其大的。
基于這個原因，我們將所有的配置環(huán)節(jié)統(tǒng)一到了一個頁面。配置信息的獲取添加三層緩存（Guava Cache+redis+DB）來應對海量調用。統(tǒng)一配置頁面的存在使得業(yè)務類系統(tǒng)消息的接入變的簡單快捷。
另一個比較大的優(yōu)化是呼起協(xié)議配置化。之前消息的呼起協(xié)議是寫死在消息體里面，極其的不靈活，甚至很多系統(tǒng)消息無法對接呼起協(xié)議直接將鏈接暴露在消息體里，用戶的體驗是很不好的。為此，呼起協(xié)議對接統(tǒng)一協(xié)議管理中心（后面文章會詳細介紹），所有的呼起協(xié)議會根據(jù)消息里攜帶的protocolID從統(tǒng)一協(xié)議管理中心獲取。呼起協(xié)議的中心化、配置化使得消息在系統(tǒng)流轉的過程中不再需要關注具體的呼起協(xié)議，簡化了消息在系統(tǒng)中的處理邏輯。而且協(xié)議中心化之后，協(xié)議的內(nèi)容可以直接呈現(xiàn)給產(chǎn)品和運營，整個消息呼起的過程變得更加的清晰。
7、消息推送的觸達（向客戶端擴散）邏輯
▲ 新京麥消息推送系統(tǒng)的消息觸達邏輯圖
京麥消息觸達分為在線通知和離線通知：
1）在線通知是通過服務端和客戶端的TCP長連接來實現(xiàn)的；
2）離線通知在最開始只有IOS的apns推送，Android系統(tǒng)無法很好的進行離線通知的推送一直是一大痛點。
針對Android系統(tǒng)無法很好的進行離線通知的推送的問題（俗稱Android網(wǎng)絡、進程保活黑科技這些東西，詳見：《應用保活終極總結(一)：Android6.0以下的雙進程守護保活實踐》、《應用保活終極總結(二)：Android6.0及以上的保活實踐(進程防殺篇)》、《應用保活終極總結(三)：Android6.0及以上的保活實踐(被殺復活篇)》），我們開發(fā)了Android推送的開源包，對接了華為、小米、魅族三大廠商，實現(xiàn)了Android離線通知的推送。
8、完整的消息推送路徑監(jiān)控
▲ 京麥消息推送系統(tǒng)的消息監(jiān)控邏輯圖
全鏈路消息追蹤系統(tǒng)，整合從消息源到最終的消息推送，整個鏈路各個節(jié)點消息的流轉狀況，并且異步化存儲。從上圖可以看到系統(tǒng)中的處理方式是，分別訂閱JMQ的同一個topic實現(xiàn)將消息日志分別存儲在ES和HBase，存ES保證了我可以在消息管理后臺對所有消息進行清晰透明化的追蹤查詢，存HBase是為了可以將數(shù)據(jù)長久的保存并且進一步的分析。
消息統(tǒng)計是依托于京東大數(shù)據(jù)平臺來實現(xiàn)的。將HBase里的數(shù)據(jù)導入到京東數(shù)據(jù)集市，從而對消息數(shù)據(jù)進行各個維度的統(tǒng)計分析。
9、本文小結
京麥實時消息推送架構經(jīng)過一年的成長，在穩(wěn)定、監(jiān)控、內(nèi)容豐富程度上有了長足的發(fā)展。下一步的規(guī)劃是完整的消息失敗重試機制、提高消息送達率、消息推送產(chǎn)品化等。
京麥是一個年輕且充滿活力的團隊，京麥消息系統(tǒng)伴隨著京麥的成長，不斷地完善優(yōu)化。
聲明：本文由網(wǎng)站用戶竹子發(fā)表，超夢電商平臺僅提供信息存儲服務，版權歸原作者所有。若發(fā)現(xiàn)本站文章存在版權問題，如發(fā)現(xiàn)文章、圖片等侵權行為，請聯(lián)系我們刪除。
