一套億級用戶的IM架構技術乾貨(上篇)：總體架構、服務拆分等

一、引言

經歷過稍有些規模的IM系統開發的同行們都有體會，要想實現大規模併發IM（好比億級用戶和數十億日消息量這樣的規模），在架構設計上須要一些額外的考慮，尤爲是要解決用戶高併發、服務高可用，架構和實現細節上都須要不短期的打磨。

我在過往的工做經歷裏，親手設計和實現了一套億級用戶量的IM，平臺上線並通過6年多的驗證，穩定性和可用性被驗證徹底達到預期。

這套IM系統，從上線至今已6年有餘，本人也已經離職創業近2年，但當初設計和開發這套系統時積累和收穫了大量的第一手實踐經驗和技術心得。

所以，想借本文把當時的架構設計經歷記錄下來，做爲同行交流和參考，但願能提供一些啓發，少走彎路。

本文已同步發佈於「即時通信技術圈」公衆號，歡迎關注。公衆號上的連接是：點此進入。

二、系列文章

爲了更好以進行內容呈現，本文拆分兩了上下兩篇。

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

《一套億級用戶的IM架構技術乾貨(上篇)：總體架構、服務拆分等》（本文）

《一套億級用戶的IM架構技術乾貨(下篇)：可靠性、有序性、弱網優化等（稍後發佈...）》

本篇主要總結和分享這套IM架構的整體設計和服務拆分等。

三、原做者

本文基於鄧昀澤的「大規模併發IM服務架構設計」一文進行的擴展和修訂，感謝原做者的分享。

鄧昀澤：畢業於北京航空航天大學，現藍貓微會創始人兼CEO，曾就任於美團、YY語音、微軟和金山軟件等公司，有十多年研發管理經驗。

四、技術指標

在這套IM系統的架構上，技術上咱們堅持高要求，通過數年的驗證，也確實達到了設計預期。

這4大技術指標是：

具體解釋就是：

• 1）高可靠：確保不丟消息；
• 2）高可用：任意機房或者服務器掛掉，不影響服務；
• 3）實時性：無論用戶在哪裏，在線用戶消息在1秒內達到（咱們實際是75%消息能夠作到120ms）；
• 4）有序性：確保用戶消息的有序性，不會出現發送和接受的亂序。

五、架構拆分

從總體架構上來講，億級用戶量的IM架構總體上偏複雜。

傳統開源的IM服務喜歡把全部服務作到1-2個服務裏（Connector+Service模型)，這樣帶來的問題比較嚴重。

傳統開源的IM的問題主要體如今：

• 1）服務代碼複雜，難以持續開發和運維；
• 2）單一業務邏輯出問題，可能會影響到其它邏輯，致使服務的全面不可用。

所以，我在作架構設計的時候儘可能追求微服務化。即把總體架構進行分拆爲子系統，而後子系統內按照業務邏輯分拆爲微服務。

系統拆分以下圖：

4個子系統的職責是：

• 1）IM業務系統：服務IM相關的業務邏輯（好比好友關係、羣關係、用戶信息等）；
• 2）信令系統：負責用戶登陸，用戶在線狀態的維護，以及在線用戶的下行推送；
• 3）推送系統：負責消息的在線推送和離線推送；
• 4）存儲系統：負責消息和文件的存儲和查詢；

其中：信令系統和推送系統是基礎設施，不僅是能夠爲IM業務服務，也能夠承載其它相似的業務邏輯（好比客服系統）。

在部署層面：採用存儲3核心機房，信令和推送節點按需部署的方式（國內業務推薦8-10個點）。實際上咱們只作了了北京3個機房，上海1個機房和香港一個機房的部署，就基本上知足了大陸+香港的業務需求。

下面將逐個介紹這4個子系統的細節方面。

六、IM業務系統

一說到IM，不少人腦海裏跳出的第一個關鍵就是「即時通訊」，技術上理所固然的聯想到了socket，也就是你們整天嘴上說的：「長鏈接」。換句話說，不少對IM不瞭解或瞭解的很少的人，認爲IM裏的全部數據交互、業務往來都是經過「長鏈接」來實現的，這樣話，對於本文章中拆分出的「IM業務系統」就有點不理解了。

實際上，早期的IM（好比20年前的QQ、MSN、ICQ），確實全部數據基本都是經過「長鏈接」（也就是程序員所說的「socket」）實現。

但現在，移動端爲主端的IM時代，IM系統不再是一個條「長鏈接」走天下。

如今，一個典型的IM系統數據往來一般拆分紅兩種服務：

• 1）socket長鏈接服務（也就是本文中的「推送服務」）；
• 2）http短鏈接服務（就是最經常使用的http rest接口那些，也就是本文中的「IM業務系統」）。

通俗一點，也也就如今的IM系統，一般都是長、短鏈接配合一塊兒實現的。 

好比論壇裏不少熱門技術方案都是這樣來作的，好比最典型的這兩篇：《IM單聊和羣聊中的在線狀態同步應該用「推」仍是「拉」？》、《IM消息送達保證機制實現(二)：保證離線消息的可靠投遞》，文記裏提到的「推」其實就是走的「長鏈接」、「拉」就上指的http短鏈接。

對於socket長鏈接服務就沒什麼好說，就是你們最常理解的那樣。

IM業務系統詳細來講，就是專一處理IM相關的業務邏輯，好比：

• 1）維護用戶數據：用戶基本信息等；
• 2）維護好友關係：好友請求、好友列表、好友信息等；
• 3）維護羣組信息：羣建立、解散、成員管理等；
• 4）提供數據：離線拉取、歷史記錄同步；
• 5）其它邏輯：好比經過存儲和推送系統，存儲消息和發送通知；

按照微服務的原則，IM業務系統也被分拆爲多個服務，好比：

• 1）GInfo服務：羣組信息維護；
• 2）IM服務：處理1V1消息；
• 3）GIM服務：處理羣組消息。

七、信令系統

7.1 基本狀況

信令系統主要職責是3部分： 

 

1）維護用戶在線狀態：

由於用戶規模龐大，必然是多個集羣，每一個集羣多臺服務器爲用戶提供服務。

考慮到服務器運維的複雜性，咱們要假定任何一個集羣，任何一個服務器均可能會掛掉，並且在這種狀況下要可以繼續爲用戶提供服務。

在這種狀況下，若是用戶A給用戶B發消息，咱們須要知道用戶B在哪一個服務器上，才能把消息正確推送給用戶B。用戶在哪一個信令服務，這個信息就是在線狀態數據。

2）下行消息推送：

跟上一個職責有關，用戶在線的時候，若是有其它用戶給他發消息，那就最好不要走離線推送，而是走在線推送。

在線推送的最後一個環節，是把用戶消息推送給用戶設備，由於就須要知道用戶登陸到哪一個服務器上。

3）業務分發：

信令服務不僅能夠處理IM請求，也能夠處理其它類型的業務請求。爲了處理不一樣的業務，就須要有分發能力。

具體作法是經過一個SVID（service id）來實現，不一樣的業務攜帶不一樣的SVID，信令服務就知道如何分發了。

用戶經過登陸服務把數據（好比IM消息）發送到信令系統，信令系統根據SVID轉發給IM系統。無論後臺有多少個業務，用戶只須要一條連接到信令。

7.2 服務拆分

信令系統爲了實現以上這3個職責，同時要確保咱們服務可平行擴展的能力和穩定性，在實際的技術實現上，咱們實際上把信令服務分拆爲3個服務模塊。

以下圖所示： 

下面將逐個介紹這3個子服務。

7.3 Login服務

Login服務主要負責維護用戶長連接：

• 1）每一個用戶一條連接到Login服務，並按時間發心跳包給Login服務；
• 2）服務定時檢查用戶連接狀態和心跳包，好比發現2個心跳週期都沒收到心跳，就認爲用戶掉線了（有假在線問題，有興趣同窗可回貼討論）。

Login服務收到用戶登陸請求之後，驗證uid/cookie，若是成功就把這個用戶的登陸信息發送給online。

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

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

若是用戶發送IM消息，先發送到Login，Login轉發給Route，Route根據服務的類型（SVID），發現是IM協議就發送給後端的IM服務。

Login對併發要求比較高，通常要支持TCP+UDP+Websocket幾種方式，單服務能夠作到10-250萬之間。從服務穩定性角度觸發，建議是控制VM的CPU/內存，單服務器以20-50萬爲合適。

Login服務器自己沒有狀態，任何一個Login服務斷掉，用戶端檢測到之後重連另外一個Login服務器就能夠了，對總體服務可靠性基本沒有影響。

7.4 Online服務

Online服務主要負責維護用戶的在線信息：

• 1）若是用戶掉線，Online服務裏信息就是空；
• 2）若是用戶在線，Online就能找到用戶登陸在哪一個集羣，哪一個Login服務器上。

Online業務相對簡單：多個Login服務器會鏈接到Online，按期同步用戶登陸和離線信息。

Online主要職責是：把用戶狀態信息存儲在Redis集羣裏。所以也是無狀態的，任何一個Online服務掛掉，不影響總體服務能力。

若是集羣規模不大，用戶規模也不大，Online服務也能夠收到Login服務裏去。

若是規模比較大，建議分拆出來，一方面簡化Login的邏輯複雜度，同時避免寫Redis的慢操做放在Login服務裏。由於Login要同時處理50萬以上的併發連接，不適合在循環裏嵌入慢操做。

7.5 Route服務

Route服務的設計核心，是做爲信令系統跟其它子系統的交互層。Route下接Login服務，能夠接受用戶業務信息（IM），也能夠往用戶推送下行消息。

多個後端業務系統能夠接入到Route，按照服務類型（SVID, service id）註冊。好比IM服務能夠接入到Route, 註冊SVID_IM。這樣Login接收到SVID=SVID_IM的消息，轉發給Route，Route就能夠根據SVID轉發給IM相關的服務。

Route簡單的根據SVID作轉發，不處理具體的業務邏輯，所以也是無狀態的。一個信令集羣能夠有多個Route服務，任何服務掛了不影響總體服務能力。

八、推送系統

推送系統的核心任務：是接收到給用戶發送下行消息的請求之後，去信令服務查詢用戶是否在線，若是在線走信令推送，若是不在線走離線推送（如iOS的APNS、華爲推送、小米推送等）。

由於推送服務可能出現大規模併發蜂擁，好比大羣激烈討論的時候，會觸發億級的TPS。所以推送服務用Kafka作了削峯。

我在實際的技術實現上，將推送系統進行了以下細分： 

具體就是：

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

這裏一樣，除了Kafka之外每一個服務都是無狀態的，由於也能夠實現平行擴展和容錯，任何服務掛掉不影響總體服務可用性。

九、存儲系統

存儲服務主要是負責消息的存儲和查詢，由於消息量巨大，對存儲服務的併發能力和存儲量要求巨大。

爲了平衡性能、空間和成本，存儲服務按數據的熱度進行了分級和區別對待。

具體是：

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

同時，爲了應對超大羣的大量消息處理，存儲服務在實際的技術實現上，也作了比較細的分拆。

存儲服務具體拆分以下圖：

具體的業務劃分就是：

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

消息隊列（Kafka）在這裏角色比較重要，由於對於高併發請求（100萬人公衆號），須要經過消息隊列來作削峯和並行。

在具體部署上：多是3-4個MsgProxy，後端能夠對應15個左右的MsgWriter。MsgWriter是比較慢的，須要同時操做多個數據庫，還要保證操做的原子性。

十、本篇小結

本篇主要總結了這套億級用戶量IM系統的整體架構設計，爲了高性能和橫向擴展性，基於微信的理念將整個架構在實現上分紅了4個子系統，分別是：IM業務系統、信令系統、推送系統、存儲系統。

針對這4個子系統，在實際的技術應用層上，又進行了進一步的服務拆分和細化，使得整個架構伸縮性大大加強。

—— 下篇《一套億級用戶的IM架構技術乾貨(下篇)：可靠性、有序性、弱網優化等》稍後發佈，敬請期待 ——

附錄：相關文章

《淺談IM系統的架構設計》

《簡述移動端IM開發的那些坑：架構設計、通訊協議和客戶端》

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

《一套原創分佈式即時通信(IM)系統理論架構方案》（* 力薦）

《從零到卓越：京東客服即時通信系統的技術架構演進歷程》（* 力薦）

《蘑菇街即時通信/IM服務器開發之架構選擇》

《騰訊QQ1.4億在線用戶的技術挑戰和架構演進之路PPT》

《微信後臺基於時間序的海量數據冷熱分級架構設計實踐》

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

《現代IM系統中聊天消息的同步和存儲方案探討》（* 力薦）

《以微博類應用場景爲例，總結海量社交系統的架構設計步驟》

《一套高可用、易伸縮、高併發的IM羣聊、單聊架構方案設計實踐》（* 力薦）

《社交軟件紅包技術解密(一)：全面解密QQ紅包技術方案——架構、技術實現等》

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

《社交軟件紅包技術解密(三)：微信搖一搖紅包雨背後的技術細節》

《社交軟件紅包技術解密(四)：微信紅包系統是如何應對高併發的》

《社交軟件紅包技術解密(五)：微信紅包系統是如何實現高可用性的》

《社交軟件紅包技術解密(六)：微信紅包系統的存儲層架構演進實踐》

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

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

《從游擊隊到正規軍(一)：馬蜂窩旅遊網的IM系統架構演進之路》（* 力薦）

《從游擊隊到正規軍(二)：馬蜂窩旅遊網的IM客戶端架構演進和實踐總結》

《從游擊隊到正規軍(三)：基於Go的馬蜂窩旅遊網分佈式IM系統技術實踐》

《瓜子IM智能客服系統的數據架構設計（整理自現場演講，有配套PPT）》

《阿里釘釘技術分享：企業級IM王者——釘釘在後端架構上的過人之處》

《微信後臺基於時間序的新一代海量數據存儲架構的設計實踐》

《一套億級用戶的IM架構技術乾貨(上篇)：總體架構、服務拆分等》

>> 更多同類文章 ……

 

本文已同步發佈於「即時通信技術圈」公衆號。

▲ 本文在公衆號上的連接是：點此進入。同步發佈連接是：http://www.52im.net/thread-3393-1-1.html