1、引言

經(jīng)歷過稍有些規(guī)模的IM系統(tǒng)開發(fā)的同行們都有體會，要想實現(xiàn)大規(guī)模并發(fā)IM（比如億級用戶和數(shù)十億日消息量這樣的規(guī)模），在架構(gòu)設(shè)計上需要一些額外的考慮，尤其是要解決用戶高并發(fā)、服務(wù)高可用，架構(gòu)和實現(xiàn)細(xì)節(jié)上都需要不短時間的打磨。

我在過往的工作經(jīng)歷里，親手設(shè)計和實現(xiàn)了一套億級用戶量的IM，平臺上線并經(jīng)過6年多的驗證，穩(wěn)定性和可用性被驗證完全達(dá)到預(yù)期。

這套IM系統(tǒng)，從上線至今已6年有余，本人也已經(jīng)離職創(chuàng)業(yè)近2年，但當(dāng)初設(shè)計和開發(fā)這套系統(tǒng)時積累和收獲了大量的第一手實踐經(jīng)驗和技術(shù)心得。

因此，想借本文把當(dāng)時的架構(gòu)設(shè)計經(jīng)歷記錄下來，作為同行交流和參考，希望能提供一些啟發(fā)，少走彎路。

本文已同步發(fā)布于“即時通訊技術(shù)圈”公眾號，歡迎關(guān)注。公眾號上的鏈接是：點此進(jìn)入。

2、系列文章

為了更好以進(jìn)行內(nèi)容呈現(xiàn)，本文拆分兩了上下兩篇。

本文是2篇文章中的第1篇：

《一套億級用戶的IM架構(gòu)技術(shù)干貨(上篇)：整體架構(gòu)、服務(wù)拆分等》（本文）

《一套億級用戶的IM架構(gòu)技術(shù)干貨(下篇)：可靠性、有序性、弱網(wǎng)優(yōu)化等（稍后發(fā)布...）》

本篇主要總結(jié)和分享這套IM架構(gòu)的總體設(shè)計和服務(wù)拆分等。

3、原作者

本文基于鄧昀澤的“大規(guī)模并發(fā)IM服務(wù)架構(gòu)設(shè)計”一文進(jìn)行的擴(kuò)展和修訂，感謝原作者的分享。

鄧昀澤：畢業(yè)于北京航空航天大學(xué)，現(xiàn)藍(lán)貓微會創(chuàng)始人兼CEO，曾就職于美團(tuán)、YY語音、微軟和金山軟件等公司，有十多年研發(fā)管理經(jīng)驗。

4、技術(shù)指標(biāo)

在這套IM系統(tǒng)的架構(gòu)上，技術(shù)上我們堅持高要求，經(jīng)過數(shù)年的驗證，也確實達(dá)到了設(shè)計預(yù)期。

這4大技術(shù)指標(biāo)是：

具體解釋就是：

• 1）高可靠：確保不丟消息；
• 2）高可用：任意機(jī)房或者服務(wù)器掛掉，不影響服務(wù)；
• 3）實時性：不管用戶在哪里，在線用戶消息在1秒內(nèi)達(dá)到（我們實際是75%消息可以做到120ms）；
• 4）有序性：確保用戶消息的有序性，不會出現(xiàn)發(fā)送和接受的亂序。

5、架構(gòu)拆分

從整體架構(gòu)上來說，億級用戶量的IM架構(gòu)整體上偏復(fù)雜。

傳統(tǒng)開源的IM服務(wù)喜歡把所有服務(wù)做到1-2個服務(wù)里（Connector+Service模型)，這樣帶來的問題比較嚴(yán)重。

傳統(tǒng)開源的IM的問題主要體現(xiàn)在：

• 1）服務(wù)代碼復(fù)雜，難以持續(xù)開發(fā)和運維；
• 2）單一業(yè)務(wù)邏輯出問題，可能會影響到其它邏輯，導(dǎo)致服務(wù)的全面不可用。

因此，我在做架構(gòu)設(shè)計的時候盡量追求微服務(wù)化。即把整體架構(gòu)進(jìn)行分拆為子系統(tǒng)，然后子系統(tǒng)內(nèi)按照業(yè)務(wù)邏輯分拆為微服務(wù)。

系統(tǒng)拆分如下圖：

4個子系統(tǒng)的職責(zé)是：

• 1）IM業(yè)務(wù)系統(tǒng)：服務(wù)IM相關(guān)的業(yè)務(wù)邏輯（比如好友關(guān)系、群關(guān)系、用戶信息等）；
• 2）信令系統(tǒng)：負(fù)責(zé)用戶登錄，用戶在線狀態(tài)的維護(hù)，以及在線用戶的下行推送；
• 3）推送系統(tǒng)：負(fù)責(zé)消息的在線推送和離線推送；
• 4）存儲系統(tǒng)：負(fù)責(zé)消息和文件的存儲和查詢；

其中：信令系統(tǒng)和推送系統(tǒng)是基礎(chǔ)設(shè)施，不只是可以為IM業(yè)務(wù)服務(wù)，也可以承載其它類似的業(yè)務(wù)邏輯（比如客服系統(tǒng)）。

在部署層面：采用存儲3核心機(jī)房，信令和推送節(jié)點按需部署的方式（國內(nèi)業(yè)務(wù)推薦8-10個點）。實際上我們只做了了北京3個機(jī)房，上海1個機(jī)房和香港一個機(jī)房的部署，就基本上滿足了大陸+香港的業(yè)務(wù)需求。

下面將逐個介紹這4個子系統(tǒng)的細(xì)節(jié)方面。

6、IM業(yè)務(wù)系統(tǒng)

一說到IM，很多人腦海里跳出的第一個關(guān)鍵就是“即時通信”，技術(shù)上理所當(dāng)然的聯(lián)想到了socket，也就是大家成天嘴上說的：“長連接”。換句話說，很多對IM不了解或了解的不多的人，認(rèn)為IM里的所有數(shù)據(jù)交互、業(yè)務(wù)往來都是通過“長連接”來實現(xiàn)的，這樣話，對于本文章中拆分出的“IM業(yè)務(wù)系統(tǒng)”就有點不理解了。

實際上，早期的IM（比如20年前的QQ、MSN、ICQ），確實所有數(shù)據(jù)基本都是通過“長連接”（也就是程序員所說的“socket”）實現(xiàn)。

但如今，移動端為主端的IM時代，IM系統(tǒng)再也不是一個條“長連接”走天下。

現(xiàn)在，一個典型的IM系統(tǒng)數(shù)據(jù)往來通常拆分成兩種服務(wù)：

• 1）socket長連接服務(wù)（也就是本文中的“推送服務(wù)”）；
• 2）http短連接服務(wù)（就是最常用的http rest接口那些，也就是本文中的“IM業(yè)務(wù)系統(tǒng)”）。

通俗一點，也也就現(xiàn)在的IM系統(tǒng)，通常都是長、短連接配合一起實現(xiàn)的。 

比如論壇里很多熱門技術(shù)方案都是這樣來做的，比如最典型的這兩篇：《IM單聊和群聊中的在線狀態(tài)同步應(yīng)該用“推”還是“拉”？》、《IM消息送達(dá)保證機(jī)制實現(xiàn)(二)：保證離線消息的可靠投遞》，文記里提到的“推”其實就是走的“長連接”、“拉”就上指的http短連接。

對于socket長連接服務(wù)就沒什么好說，就是大家最常理解的那樣。

IM業(yè)務(wù)系統(tǒng)詳細(xì)來說，就是專注處理IM相關(guān)的業(yè)務(wù)邏輯，比如：

• 1）維護(hù)用戶數(shù)據(jù)：用戶基本信息等；
• 2）維護(hù)好友關(guān)系：好友請求、好友列表、好友信息等；
• 3）維護(hù)群組信息：群創(chuàng)建、解散、成員管理等；
• 4）提供數(shù)據(jù)：離線拉取、歷史記錄同步；
• 5）其它邏輯：比如通過存儲和推送系統(tǒng)，存儲消息和發(fā)送通知；

按照微服務(wù)的原則，IM業(yè)務(wù)系統(tǒng)也被分拆為多個服務(wù)，比如：

• 1）GInfo服務(wù)：群組信息維護(hù)；
• 2）IM服務(wù)：處理1V1消息；
• 3）GIM服務(wù)：處理群組消息。

7、信令系統(tǒng)

7.1 基本情況

信令系統(tǒng)主要職責(zé)是3部分： 

 

1）維護(hù)用戶在線狀態(tài)：

因為用戶規(guī)模龐大，必然是多個集群，每個集群多臺服務(wù)器為用戶提供服務(wù)。

考慮到服務(wù)器運維的復(fù)雜性，我們要假定任何一個集群，任何一個服務(wù)器都可能會掛掉，而且在這種情況下要能夠繼續(xù)為用戶提供服務(wù)。

在這種情況下，如果用戶A給用戶B發(fā)消息，我們需要知道用戶B在哪個服務(wù)器上，才能把消息正確推送給用戶B。用戶在哪個信令服務(wù)，這個信息就是在線狀態(tài)數(shù)據(jù)。

2）下行消息推送：

跟上一個職責(zé)有關(guān)，用戶在線的時候，如果有其它用戶給他發(fā)消息，那就最好不要走離線推送，而是走在線推送。

在線推送的最后一個環(huán)節(jié)，是把用戶消息推送給用戶設(shè)備，因為就需要知道用戶登錄到哪個服務(wù)器上。

3）業(yè)務(wù)分發(fā)：

信令服務(wù)不只可以處理IM請求，也可以處理其它類型的業(yè)務(wù)請求。為了處理不同的業(yè)務(wù)，就需要有分發(fā)能力。

具體做法是通過一個SVID（service id）來實現(xiàn)，不同的業(yè)務(wù)攜帶不同的SVID，信令服務(wù)就知道如何分發(fā)了。

用戶通過登錄服務(wù)把數(shù)據(jù)（比如IM消息）發(fā)送到信令系統(tǒng)，信令系統(tǒng)根據(jù)SVID轉(zhuǎn)發(fā)給IM系統(tǒng)。不管后臺有多少個業(yè)務(wù)，用戶只需要一條鏈接到信令。

7.2 服務(wù)拆分

信令系統(tǒng)為了實現(xiàn)以上這3個職責(zé)，同時要確保我們服務(wù)可平行擴(kuò)展的能力和穩(wěn)定性，在實際的技術(shù)實現(xiàn)上，我們實際上把信令服務(wù)分拆為3個服務(wù)模塊。

如下圖所示： 

下面將逐個介紹這3個子服務(wù)。

7.3 Login服務(wù)

Login服務(wù)主要負(fù)責(zé)維護(hù)用戶長鏈接：

• 1）每個用戶一條鏈接到Login服務(wù)，并按時間發(fā)心跳包給Login服務(wù)；
• 2）服務(wù)定時檢查用戶鏈接狀態(tài)和心跳包，比如發(fā)現(xiàn)2個心跳周期都沒收到心跳，就認(rèn)為用戶掉線了（有假在線問題，有興趣同學(xué)可回貼討論）。

Login服務(wù)收到用戶登錄請求以后，驗證uid/cookie，如果成功就把這個用戶的登錄信息發(fā)送給online。

此過程主要記錄的信息包含：

• 1）uid（用戶id）；
• 2）Login服務(wù)器IP/Port；
• 3）Route服務(wù)器的IP/Port。

如果用戶發(fā)送IM消息，先發(fā)送到Login，Login轉(zhuǎn)發(fā)給Route，Route根據(jù)服務(wù)的類型（SVID），發(fā)現(xiàn)是IM協(xié)議就發(fā)送給后端的IM服務(wù)。

Login對并發(fā)要求比較高，一般要支持TCP+UDP+Websocket幾種方式，單服務(wù)可以做到10-250萬之間。從服務(wù)穩(wěn)定性角度觸發(fā)，建議是控制VM的CPU/內(nèi)存，單服務(wù)器以20-50萬為合適。

Login服務(wù)器本身沒有狀態(tài)，任何一個Login服務(wù)斷掉，用戶端檢測到以后重連另一個Login服務(wù)器就可以了，對整體服務(wù)可靠性基本沒有影響。

7.4 Online服務(wù)

Online服務(wù)主要負(fù)責(zé)維護(hù)用戶的在線信息：

• 1）如果用戶掉線，Online服務(wù)里信息就是空；
• 2）如果用戶在線，Online就能找到用戶登錄在哪個集群，哪個Login服務(wù)器上。

Online業(yè)務(wù)相對簡單：多個Login服務(wù)器會連接到Online，定期同步用戶登錄和離線信息。

Online主要職責(zé)是：把用戶狀態(tài)信息存儲在Redis集群里。因此也是無狀態(tài)的，任何一個Online服務(wù)掛掉，不影響整體服務(wù)能力。

如果集群規(guī)模不大，用戶規(guī)模也不大，Online服務(wù)也可以收到Login服務(wù)里去。

如果規(guī)模比較大，建議分拆出來，一方面簡化Login的邏輯復(fù)雜度，同時避免寫Redis的慢操作放在Login服務(wù)里。因為Login要同時處理50萬以上的并發(fā)鏈接，不適合在循環(huán)里嵌入慢操作。

7.5 Route服務(wù)

Route服務(wù)的設(shè)計核心，是作為信令系統(tǒng)跟其它子系統(tǒng)的交互層。Route下接Login服務(wù)，可以接受用戶業(yè)務(wù)信息（IM），也可以往用戶推送下行消息。

多個后端業(yè)務(wù)系統(tǒng)可以接入到Route，按照服務(wù)類型（SVID, service id）注冊。比如IM服務(wù)可以接入到Route, 注冊SVID_IM。這樣Login接收到SVID=SVID_IM的消息，轉(zhuǎn)發(fā)給Route，Route就可以根據(jù)SVID轉(zhuǎn)發(fā)給IM相關(guān)的服務(wù)。

Route簡單的根據(jù)SVID做轉(zhuǎn)發(fā)，不處理具體的業(yè)務(wù)邏輯，因此也是無狀態(tài)的。一個信令集群可以有多個Route服務(wù)，任何服務(wù)掛了不影響整體服務(wù)能力。

8、推送系統(tǒng)

推送系統(tǒng)的核心任務(wù)：是接收到給用戶發(fā)送下行消息的請求以后，去信令服務(wù)查詢用戶是否在線，如果在線走信令推送，如果不在線走離線推送（如iOS的APNS、華為推送、小米推送等）。

因為推送服務(wù)可能出現(xiàn)大規(guī)模并發(fā)蜂擁，比如大群激烈討論的時候，會觸發(fā)億級的TPS。因此推送服務(wù)用Kafka做了削峰。

我在實際的技術(shù)實現(xiàn)上，將推送系統(tǒng)進(jìn)行了如下細(xì)分： 

具體就是：

• 1）PushProxy：接受用戶的推送請求，寫入Kafka；
• 2）Kafka：緩存推送服務(wù)；
• 3）PushServer：從Kafka獲取推送請求，判斷用戶是否在線；
• 4）PushWorker：真正推送給信令或者APNS，華為推送等。

這里同樣，除了Kafka以外每個服務(wù)都是無狀態(tài)的，因為也可以實現(xiàn)平行擴(kuò)展和容錯，任何服務(wù)掛掉不影響整體服務(wù)可用性。

9、存儲系統(tǒng)

存儲服務(wù)主要是負(fù)責(zé)消息的存儲和查詢，因為消息量巨大，對存儲服務(wù)的并發(fā)能力和存儲量要求巨大。

為了平衡性能、空間和成本，存儲服務(wù)按數(shù)據(jù)的熱度進(jìn)行了分級和區(qū)別對待。

具體是：

• 1）短期消息(7天)：存儲在Redis里；
• 2）近期消息(1-3個月)：存儲在Mysql里，以備用戶實時查詢；
• 3）歷史信息：存儲在HBase里，作為歷史數(shù)據(jù)慢查詢。

同時，為了應(yīng)對超大群的大量消息處理，存儲服務(wù)在實際的技術(shù)實現(xiàn)上，也做了比較細(xì)的分拆。

存儲服務(wù)具體拆分如下圖：

具體的業(yè)務(wù)劃分就是：

• 1）MsgProxy：負(fù)責(zé)接受IM子系統(tǒng)的存儲請求，寫入Kafka；
• 2）MsgWriter：從Kafka獲取寫請求，按需寫入Redis和Mysql；
• 3）MsgReader：接受用戶的消息查詢請求，從Redis，Mysql或者HBase讀數(shù)據(jù)；
• 4）運維工具：主要是數(shù)據(jù)庫的運維需求。

消息隊列（Kafka）在這里角色比較重要，因為對于高并發(fā)請求（100萬人公眾號），需要通過消息隊列來做削峰和并行。

在具體部署上：可能是3-4個MsgProxy，后端可以對應(yīng)15個左右的MsgWriter。MsgWriter是比較慢的，需要同時操作多個數(shù)據(jù)庫，還要保證操作的原子性。

10、本篇小結(jié)

本篇主要總結(jié)了這套億級用戶量IM系統(tǒng)的總體架構(gòu)設(shè)計，為了高性能和橫向擴(kuò)展性，基于微信的理念將整個架構(gòu)在實現(xiàn)上分成了4個子系統(tǒng)，分別是：IM業(yè)務(wù)系統(tǒng)、信令系統(tǒng)、推送系統(tǒng)、存儲系統(tǒng)。

針對這4個子系統(tǒng)，在實際的技術(shù)應(yīng)用層上，又進(jìn)行了進(jìn)一步的服務(wù)拆分和細(xì)化，使得整個架構(gòu)伸縮性大大增強(qiáng)。

—— 下篇《一套億級用戶的IM架構(gòu)技術(shù)干貨(下篇)：可靠性、有序性、弱網(wǎng)優(yōu)化等》稍后發(fā)布，敬請期待 ——

附錄：相關(guān)文章

《淺談IM系統(tǒng)的架構(gòu)設(shè)計》

《簡述移動端IM開發(fā)的那些坑：架構(gòu)設(shè)計、通信協(xié)議和客戶端》

《一套海量在線用戶的移動端IM架構(gòu)設(shè)計實踐分享(含詳細(xì)圖文)》（* 力薦）

《一套原創(chuàng)分布式即時通訊(IM)系統(tǒng)理論架構(gòu)方案》（* 力薦）

《從零到卓越：京東客服即時通訊系統(tǒng)的技術(shù)架構(gòu)演進(jìn)歷程》（* 力薦）

《蘑菇街即時通訊/IM服務(wù)器開發(fā)之架構(gòu)選擇》

《騰訊QQ1.4億在線用戶的技術(shù)挑戰(zhàn)和架構(gòu)演進(jìn)之路PPT》

《微信后臺基于時間序的海量數(shù)據(jù)冷熱分級架構(gòu)設(shè)計實踐》

《移動端IM中大規(guī)模群消息的推送如何保證效率、實時性？》

《現(xiàn)代IM系統(tǒng)中聊天消息的同步和存儲方案探討》（* 力薦）

《以微博類應(yīng)用場景為例，總結(jié)海量社交系統(tǒng)的架構(gòu)設(shè)計步驟》

《一套高可用、易伸縮、高并發(fā)的IM群聊、單聊架構(gòu)方案設(shè)計實踐》（* 力薦）

《社交軟件紅包技術(shù)解密(一)：全面解密QQ紅包技術(shù)方案——架構(gòu)、技術(shù)實現(xiàn)等》

《社交軟件紅包技術(shù)解密(二)：解密微信搖一搖紅包從0到1的技術(shù)演進(jìn)》

《社交軟件紅包技術(shù)解密(三)：微信搖一搖紅包雨背后的技術(shù)細(xì)節(jié)》

《社交軟件紅包技術(shù)解密(四)：微信紅包系統(tǒng)是如何應(yīng)對高并發(fā)的》

《社交軟件紅包技術(shù)解密(五)：微信紅包系統(tǒng)是如何實現(xiàn)高可用性的》

《社交軟件紅包技術(shù)解密(六)：微信紅包系統(tǒng)的存儲層架構(gòu)演進(jìn)實踐》

《社交軟件紅包技術(shù)解密(七)：支付寶紅包的海量高并發(fā)技術(shù)實踐》

《社交軟件紅包技術(shù)解密(八)：全面解密微博紅包技術(shù)方案》

《從游擊隊到正規(guī)軍(一)：馬蜂窩旅游網(wǎng)的IM系統(tǒng)架構(gòu)演進(jìn)之路》（* 力薦）

《從游擊隊到正規(guī)軍(二)：馬蜂窩旅游網(wǎng)的IM客戶端架構(gòu)演進(jìn)和實踐總結(jié)》

《從游擊隊到正規(guī)軍(三)：基于Go的馬蜂窩旅游網(wǎng)分布式IM系統(tǒng)技術(shù)實踐》

《瓜子IM智能客服系統(tǒng)的數(shù)據(jù)架構(gòu)設(shè)計（整理自現(xiàn)場演講，有配套PPT）》

《阿里釘釘技術(shù)分享：企業(yè)級IM王者——釘釘在后端架構(gòu)上的過人之處》

《微信后臺基于時間序的新一代海量數(shù)據(jù)存儲架構(gòu)的設(shè)計實踐》

《一套億級用戶的IM架構(gòu)技術(shù)干貨(上篇)：整體架構(gòu)、服務(wù)拆分等》

>> 更多同類文章 ……

 

本文已同步發(fā)布于“即時通訊技術(shù)圈”公眾號。

▲ 本文在公眾號上的鏈接是：點此進(jìn)入。同步發(fā)布鏈接是：http://www.52im.net/thread-3393-1-1.html