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