本文由vivo 互聯(lián)網(wǎng)服務(wù)器團(tuán)隊Yu Quan分享，本文收錄時有內(nèi)容修訂和重新排版。

1、引言

如今，Android端的即時通訊IM這類應(yīng)用想實現(xiàn)離線消息推送，難度越來越大（詳見《Android P正式版即將到來：后臺應(yīng)用保活、消息推送的真正噩夢》、《Android保活從入門到放棄：乖乖引導(dǎo)用戶加白名單吧》）。

于是，使用手機(jī)廠商自建的ROOM級消息推送通道進(jìn)行IM離線消息推送是個不得不面對的問題，我們也正好借此文機(jī)會，一窺主流手機(jī)廠商的ROOM級推送通道的技術(shù)實現(xiàn)吧。

vivo手機(jī)的廠商級消息推送系統(tǒng)的現(xiàn)狀是最高推送速度140w/s，單日最大消息量200億，端到端秒級在線送達(dá)率99.9%。同時推送系統(tǒng)具備不可提前預(yù)知的突發(fā)大流量特點。

本文將要分享的是vivo技術(shù)團(tuán)隊針對消息推送系統(tǒng)的高并發(fā)、高時效、突發(fā)流量等特點，從長連接層容災(zāi)、邏輯層容災(zāi)、流量容災(zāi)、存儲容災(zāi)等方面入手，如何保證百億級廠商消息推送平臺的高可用性的。

* 推薦閱讀：vivo技術(shù)團(tuán)隊分享的另一篇消息推送技術(shù)文章《vivo手機(jī)上的系統(tǒng)級消息推送平臺的架構(gòu)設(shè)計實踐》。

2、推送系統(tǒng)介紹

vivo推送平臺是vivo公司向開發(fā)者提供的消息推送服務(wù)，通過在云端與客戶端之間建立一條穩(wěn)定、可靠的長連接，為開發(fā)者提供向客戶端應(yīng)用實時推送消息的服務(wù)，支持百億級的通知/消息推送，秒級觸達(dá)移動用戶。

推送系統(tǒng)主要由3部分組成：

• 1）接入網(wǎng)關(guān)；
• 2）邏輯推送節(jié)點；
• 3）長連接。

其中，長連接負(fù)責(zé)與用戶手機(jī)終端建立連接，及時把消息送達(dá)到手機(jī)終端。

推送系統(tǒng)的特點是：

• 1）并發(fā)高；
• 2）消息量大；
• 3）送達(dá)及時性較高。

下面將針對這幾個方面來分享我們的技術(shù)實踐。

3、長連接層容災(zāi)的技術(shù)實現(xiàn)

長連接是推送系統(tǒng)最重要的部分，長連接的穩(wěn)定性直接決定了推送系統(tǒng)的推送質(zhì)量和性能。因此，需要對長連接層做好容災(zāi)和實時調(diào)度能力。

3.1面臨的問題

原有推送系統(tǒng)架構(gòu)是長連接層都部署在華東，所有vivo IDC邏輯節(jié)點通過VPC與華東的Broker建立連接，手機(jī)端跟華東的broker進(jìn)行長連接通信。

這種部署方式存在以下問題。

1）問題一：華北、華南手機(jī)都需要連接華東的Broker，地域跨度大，長連接網(wǎng)絡(luò)穩(wěn)定性和時效性相對較差。

2）問題二：邏輯層跟華東的Broker之間由一條VPC連接，隨著業(yè)務(wù)的發(fā)展，推送流量越來越大，帶寬會出現(xiàn)瓶頸，有超限丟包的風(fēng)險。另外當(dāng)該VPC出現(xiàn)故障時，會造成全網(wǎng)消息無法送達(dá)。

注：長連接層節(jié)點名為Broker。

原始長連接架構(gòu)圖：

3.2解決方法

基于以上架構(gòu)存在問題，我們對架構(gòu)進(jìn)行了優(yōu)化。即將Broker進(jìn)行三地部署，分別部署在華北、華東、華南。

華北、華東、華南三地用戶采用就近接入方式。

優(yōu)化后的架構(gòu)，不僅可以保證長連接網(wǎng)絡(luò)穩(wěn)定性和時效性。同時具有較強(qiáng)的容災(zāi)能力，華東、華南Broker通過云網(wǎng)跟華北Broker連接，華北Broker通過VPC與vivo IDC連接。當(dāng)華北、華東、華南某個地區(qū)Broker集群故障或者公網(wǎng)故障，不會影響到全網(wǎng)設(shè)備收發(fā)消息。

三地部署后的架構(gòu)圖：

3.3進(jìn)一步優(yōu)化

但是上述這種方式還是存在一個問題，就是某個地區(qū)Broker集群故障或者公網(wǎng)故障，會出現(xiàn)該區(qū)域部分設(shè)備無法收到推送消息的情況。

針對上述單個地區(qū)異常導(dǎo)致該區(qū)域部分設(shè)備無法收到推送消息的問題，我們設(shè)計了一套流量調(diào)度系統(tǒng)，可以做到實時流量調(diào)度和切換。global scheduler節(jié)點負(fù)責(zé)策略調(diào)度和管理。

vivo phone進(jìn)行注冊時：dispatcher會下發(fā)多個地區(qū)的ip地址，默認(rèn)情況下，進(jìn)行就近連接。單多次連接失敗后，嘗試連接其他ip。當(dāng)某個地區(qū)Broker出現(xiàn)長連接數(shù)瓶頸或者VPC出現(xiàn)故障，可以通過global scheduler節(jié)點下發(fā)策略，讓該故障地區(qū)的設(shè)備重新從dispatcher獲取新的ip集的ip，與其他地區(qū)Broker建立長連接，邏輯節(jié)點下發(fā)消息到重連后的Broker。等到該地區(qū)恢復(fù)后，可以重新再下發(fā)策略，進(jìn)行回調(diào)。

流量調(diào)度系統(tǒng)圖：

4、邏輯層容災(zāi)的技術(shù)實現(xiàn)

長連接層做好容災(zāi)后，邏輯層也需要做相應(yīng)容災(zāi)。

之前我們邏輯層都部署在一個機(jī)房，不具備機(jī)房間容災(zāi)能力，當(dāng)一個機(jī)房出現(xiàn)斷電風(fēng)險，會出現(xiàn)服務(wù)整體不可用問題，因此我們做"同城雙活"部署方案改造。

邏輯層單活架構(gòu)：

邏輯層分別在vivo IDC1和vivo IDC2進(jìn)行部署，網(wǎng)關(guān)層根據(jù)路由規(guī)則將流量按照一定比例分別下發(fā)到兩個IDC，實現(xiàn)邏輯層同城雙活。

我們發(fā)現(xiàn)：數(shù)據(jù)中心還是只有一個，部署在vivo IDC1，根據(jù)成本、收益，以及多數(shù)據(jù)中心數(shù)據(jù)同步延遲問題綜合考慮，數(shù)據(jù)中心暫時還是以單數(shù)據(jù)中心為主。

邏輯層雙活架構(gòu)：

5、流量容災(zāi)的技術(shù)實現(xiàn)

5.1概述

做好系統(tǒng)架構(gòu)的容災(zāi)能力后，推送系統(tǒng)的網(wǎng)關(guān)層還需要應(yīng)對突發(fā)流量做相應(yīng)的應(yīng)對措施，做好流量控制，保證系統(tǒng)穩(wěn)定性。歷史上，我們曾經(jīng)因為熱點和突發(fā)新聞事件，并發(fā)推送流量巨大，導(dǎo)致服務(wù)出現(xiàn)異常，可用性降低問題。

為了應(yīng)對突發(fā)大流量，保證突發(fā)流量的情況下，系統(tǒng)可用性不變，同時能兼顧性能和成本。為此，我們分別對比了設(shè)計了以下兩種方案。

5.2常規(guī)方案

常規(guī)的方案是一般是根據(jù)歷史情況估算冗余部署大量機(jī)器，來應(yīng)對突發(fā)流量。

單這種方式成本較高，突發(fā)流量可能只持續(xù)5分鐘或更短時間，而系統(tǒng)為了滿足5分鐘突發(fā)流量，需要冗余部署大量機(jī)器。

一旦流量超過了部署機(jī)器可承擔(dān)的上限，無法及時擴(kuò)容，可能導(dǎo)致可用性下降，甚至出現(xiàn)雪崩效應(yīng)。

傳統(tǒng)方案下的推送架構(gòu)：

那如何設(shè)計一套既可以控制成本，面對突發(fā)大流量彈性擴(kuò)容，又保證消息不漏并兼顧推送性能的方案呢？

5.3優(yōu)化方案

優(yōu)化后的方案：

• 1）在原有架構(gòu)的基礎(chǔ)上，在接入層增加緩沖通道，當(dāng)流量洪峰到來時，對于系統(tǒng)可處理的上限能力外的流量，打入緩沖隊列；
• 2）通過消息隊列形式，增加bypass接入層，限速消費消息隊列；
• 3）在流量洪峰過去后，提升bypass消費速度，處理緩存隊列消息；
• 4）bypass接入層通過docker部署，支持動態(tài)擴(kuò)縮容，默認(rèn)最小化集群，當(dāng)消息隊列積壓很多，并且下游有能力處理時，提升消費速度，bypass根據(jù)CPU負(fù)載動態(tài)擴(kuò)容，快速消費消息隊列；
• 5）處理完畢后動態(tài)縮容。

消息隊列：選用吞吐量較大的KAFKA中間件，并且與離線計算KAFKA集群共用，能充分利用資源。

bypass接入層：采用docker部署，支持根據(jù)CPU負(fù)載和時間動態(tài)擴(kuò)縮容。默認(rèn)最小集群部署。對于已知的流量高峰時段，可以提前擴(kuò)容服務(wù)，保證流量快速處理。未知時段流量高峰，可以bypass接入層，根據(jù)CPU負(fù)載情況進(jìn)行動態(tài)擴(kuò)縮容。

增加緩存隊列后的推送架構(gòu)：

5.4進(jìn)一步優(yōu)化

進(jìn)行上述改造后：還存在一個問題，就是如何進(jìn)行接入層全局控速。

我們采用的方式是：收集下游推送節(jié)點的推送流量情況。

比如：流量達(dá)到系統(tǒng)可承受上限的80%時下發(fā)限速指令，調(diào)整接入層推送速度。讓消息先積壓在消息隊列，等到下游流量降低之后，下發(fā)解除限速指令，讓bypass接入層加速消費消息隊列，進(jìn)行推送。

增加控速后的推送架構(gòu)：

優(yōu)化后方案與傳統(tǒng)方案對比：

6、存儲容災(zāi)的技術(shù)實現(xiàn)

6.1問題

做好并發(fā)流量控制后，能很好的預(yù)發(fā)突發(fā)熱點問題。但在推送系統(tǒng)內(nèi)部，由于使用Redis集群緩存消息，出現(xiàn)過因為Redis集群故障導(dǎo)致消息無法及時送達(dá)問題。

因此：我們考慮對Redis集群做相關(guān)容災(zāi)方案設(shè)計，實現(xiàn)系統(tǒng)在Redis集群故障期間，也能及時推送消息并保證消息不丟失。

推送消息體緩存在Redis集群中，推送時從Redis中獲取消息體，如果Redis集群宕機(jī)，或者內(nèi)存故障，會導(dǎo)致離線消息體丟失。

6.2方案

原有消息流程：

1）方案一：

引入另一個對等Redis集群，采用推送雙寫方式，雙寫兩個Redis集群。該方案需要冗余部署規(guī)模對等的備Redis集群。推送系統(tǒng)需要雙寫Redis操作。

2）方案二：

原有Redis集群，采用RDB+AOF方式同步到另一個備Redis集群。

該方案不在需要推送系統(tǒng)雙寫Redis改造，直接利用將原有Redis集群數(shù)據(jù)同步到另一個備Redis集群。也需要冗余部署規(guī)模對等的備Redis集群。可能存在部分?jǐn)?shù)據(jù)同步延遲導(dǎo)致推送失敗問題。

3）方案三：

應(yīng)用另一個分布式存儲系統(tǒng)，磁盤KV，兼容Redis協(xié)議，同時具有持久化能力。可以保證消息體不丟失。但是為了節(jié)省成本，不再直接使用Redis集群對等資源。

而是根據(jù)推送特點，推送分為單推、群推。單推是一對一推送，一個用戶一條消息體。群推是一對多推送，一個消息體對應(yīng)多個用戶。

群推往往是任務(wù)級別推送。因此我們使用一個相對小一些的磁盤KV集群，主要用于冗余存儲，群推消息體，即任務(wù)級別的消息。對于單推，還是只保存到Redis中，不進(jìn)行冗余存儲。

如果Redis集群故障，對于單推消息，推送系統(tǒng)可以攜帶消息體往下游推送，確保消息可以繼續(xù)下發(fā)。對于群推消息，因為消息體冗余存儲在磁盤KV中，當(dāng)Redis集群故障后，可以降級到讀取磁盤KV。

6.3優(yōu)化

方案三還存在一個問題，就是磁盤KV的寫入性能和Redis集群不是一個數(shù)量級，特別是時延，磁盤KV在平均在5ms左右。

而Redis集群卻在0.5ms。如果在推送系統(tǒng)對群推消息體進(jìn)行雙寫。這個時延是不能接受的。

因此只能采用異步寫入磁盤KV的方式。

這里將備份群推消息體，先寫入消息中間件KAFKA，由bypass節(jié)點消費KAKFA進(jìn)行異步寫入磁盤KV。這樣在使用的災(zāi)備磁盤KV資源較少的前提下，保證推送系統(tǒng)的高并發(fā)能力，同時可以保證群推消息體不丟失，Redis異常時，單推消息攜帶消息體推送，群推消息體讀取磁盤KV。

存儲容災(zāi)方案對比：

7、本文小結(jié)

本文從長連接層容災(zāi)、邏輯層容災(zāi)、流量容災(zāi)、存儲容災(zāi)等幾個方面講述了推送系統(tǒng)容災(zāi)建設(shè)過程。系統(tǒng)容災(zāi)需要根據(jù)業(yè)務(wù)發(fā)展，成本收益，實現(xiàn)難度等多方面考慮。

當(dāng)前我們長連接層已具備三地部署，邏輯層具備同城雙活，數(shù)據(jù)中心為單數(shù)據(jù)中心。后續(xù)我們會持續(xù)研究和規(guī)劃雙數(shù)據(jù)中心，兩地三中心部署架構(gòu)方式來逐步加強(qiáng)推送系統(tǒng)容災(zāi)能力。

8、參考資料

[1] vivo手機(jī)上的系統(tǒng)級消息推送平臺的架構(gòu)設(shè)計實踐

[2] 魅族2500萬長連接的實時消息推送架構(gòu)的技術(shù)實踐分享

[3] 專訪魅族架構(gòu)師：海量長連接的實時消息推送系統(tǒng)的心得體會

[4] 百萬在線的美拍直播彈幕系統(tǒng)的實時推送技術(shù)實踐之路

[5] 京東京麥商家開放平臺的消息推送架構(gòu)演進(jìn)之路

[6] 解密“達(dá)達(dá)-京東到家”的訂單即時派發(fā)技術(shù)原理和實踐

[7] 長連接網(wǎng)關(guān)技術(shù)專題(四)：愛奇藝WebSocket實時推送網(wǎng)關(guān)技術(shù)實踐

[8] 喜馬拉雅億級用戶量的離線消息推送系統(tǒng)架構(gòu)設(shè)計實踐

[9] 微信直播聊天室單房間1500萬在線的消息架構(gòu)演進(jìn)之路

[10] 百度直播的海量用戶實時消息系統(tǒng)架構(gòu)演進(jìn)實踐

[11] 消息推送技術(shù)干貨：美團(tuán)實時消息推送服務(wù)的技術(shù)演進(jìn)之路

[12] 技術(shù)干貨：從零開始，教你設(shè)計一個百萬級的消息推送系統(tǒng)

9、vivo技術(shù)團(tuán)隊分享的其它文章

《IM消息ID技術(shù)專題(七)：深度解密vivo的自研分布式ID服務(wù)(魯班)》

《直播系統(tǒng)聊天技術(shù)(八)：vivo直播系統(tǒng)中IM消息模塊的架構(gòu)實踐》

《IM跨平臺技術(shù)學(xué)習(xí)(三)：vivo的Electron技術(shù)棧選型、全方位實踐總結(jié)》

《vivo手機(jī)上的系統(tǒng)級消息推送平臺的架構(gòu)設(shè)計實踐》

（本文已同步發(fā)布于：http://www.52im.net/thread-4416-1-1.html）