4、“圈組”的技術(shù)特點(diǎn)

在介紹“圈組”的技術(shù)細(xì)節(jié)之前，我們先了解一下圈組的技術(shù)特點(diǎn)。

“圈組”產(chǎn)品最大的特點(diǎn)是什么？

• 1）首先：是 server/channel 的二級(jí)結(jié)構(gòu)；

• 2）其次：是構(gòu)建在二級(jí)結(jié)構(gòu)之上的大規(guī)模社群（單個(gè) server 數(shù)十萬(wàn)甚至上百萬(wàn)成員）；

• 3）以及：使用復(fù)雜的身份組系統(tǒng)來(lái)管理如此規(guī)模的社群組織和成員。

那么對(duì)于這樣一個(gè)新穎的 IM 系統(tǒng)，在技術(shù)上應(yīng)該如何實(shí)現(xiàn)呢？

5、“圈組”和傳統(tǒng)IM群組的技術(shù)差異

5.1概述

一種簡(jiǎn)單的思路是改造已有的 IM 系統(tǒng)，對(duì)于“圈組”這樣的類 Discord 社群，第一個(gè)思路是拓展我們的群組功能，猛一看在很多方面確實(shí)挺像的。

我們做了個(gè)簡(jiǎn)單的對(duì)比：

從上面的表格可以看到，“圈組”和群組最大的不同：

• 1）是容量的區(qū)別；

• 2）是二級(jí)結(jié)構(gòu)。

其他的諸如身份組、個(gè)性化推送策略，似乎只要適配的做一下就可以了。

那么是不是只要想辦法提升一下群組的容量，再在業(yè)務(wù)層封裝一下二級(jí)結(jié)構(gòu)就可以了呢？

答案顯然是否定的，或者至少說(shuō)基于群組去擴(kuò)展不是一個(gè)很好的想法。

5.2二級(jí)結(jié)構(gòu)的差異

首先是二級(jí)結(jié)構(gòu)。

在類 Discord 的二級(jí)結(jié)構(gòu)中，成員的管理在 server 層，而 channel 成員是繼承自 server 的，而且在 channel 之上還有很多可見(jiàn)性的配置（我們的“圈組”提供了黑白名單機(jī)制，而Discord 則提供了查看頻道權(quán)限）。

在這種機(jī)制之下，任何 server 層面的成員變動(dòng)，都可能影響全部或者部分頻道的成員列表。

面對(duì)這種復(fù)雜的結(jié)構(gòu)，群組有兩種思路去實(shí)現(xiàn)：

• 1）一種是 N 個(gè)群，邏輯上隸屬于同一個(gè) server；

• 2）一種是一個(gè)群映射為一個(gè) server。

不管哪種方式，先不說(shuō)消息投遞這塊的邏輯，僅成員管理上邏輯的耦合和交織的復(fù)雜性，足以勸退任何人。

5.3容量的差異

常規(guī)IM群組的容量一般只有數(shù)百，最多可以擴(kuò)展到數(shù)千。

對(duì)于IM群組成員的管理，我們一般采取全量+增量同步相結(jié)合的方案，客戶端和服務(wù)器映射到相同的群組鏡像（群信息+群成員等）。此時(shí)很多操作，例如群成員的展示、檢索，消息的艾特等，都可以基于純客戶端進(jìn)行。

而“圈組”要求幾十萬(wàn)甚至上百萬(wàn)的容量，顯然客戶端無(wú)法一次性獲取到所有成員，如果你一次性加入多個(gè) server，那成員的數(shù)量將更加膨脹。

因此在“圈組”這種大規(guī)模社群的設(shè)計(jì)中，很多邏輯都會(huì)轉(zhuǎn)向云端，此時(shí)不管是 SDK 還是服務(wù)器，均需要修改原有的設(shè)計(jì)邏輯。

5.4消息規(guī)模差異

此外，大規(guī)模社群帶來(lái)的是消息爆炸。

在原有的IM群組設(shè)計(jì)中，假設(shè)一個(gè)人同時(shí)加入了 1000 個(gè)群，那么這 1000 個(gè)群內(nèi)的所有消息均會(huì)在第一時(shí)間下發(fā)給給客戶端。

但是在一般的業(yè)務(wù)場(chǎng)景中，不會(huì)所有的群都同時(shí)活躍，假設(shè)這 1000 個(gè)群變成了 1000 個(gè)服務(wù)器/頻道，作為一種社群組織，同時(shí)活躍的可能性將大大增加，而且每個(gè)服務(wù)器/頻道的人數(shù)遠(yuǎn)遠(yuǎn)超過(guò)普通的群組，疊加之后帶來(lái)的消息爆炸現(xiàn)象在原有的群組體系中將帶來(lái)極大的壓力。

壓力包括多方面：

• 1）首先是海量消息的存儲(chǔ)壓力；

• 2）其次是海量消息在線廣播/離線消息推送帶來(lái)的帶寬和服務(wù)器壓力；

• 3）以及客戶端在面對(duì)大量消息沖擊時(shí)如何有效地接受和合理的展示。

5.5小結(jié)

除了容量、二級(jí)結(jié)構(gòu)、消息規(guī)模，包括身份組、成員管理、個(gè)性化推送策略等等都存在巨大差異。

是否真的適合在群組中添加這些復(fù)雜邏輯呢，強(qiáng)行綁定在一起會(huì)不會(huì)既沒(méi)有一個(gè)好用的類 Discord 平臺(tái)，也使得原始的群組功能繁雜，反而降低了易用性呢？

經(jīng)過(guò)上面的一些分析，我們基本可以得出一個(gè)結(jié)論：在已有的群組基礎(chǔ)上擴(kuò)展來(lái)實(shí)現(xiàn)一個(gè)類 Discord 功能的社群，顯然不是一個(gè)很好的思路。

那么還有其他“捷徑”嗎？

IM聊天室也是一個(gè)潛在的選項(xiàng)，聊天室的一大特點(diǎn)就是支持超大規(guī)模同時(shí)在線（參見(jiàn)《千萬(wàn)級(jí)實(shí)時(shí)直播彈幕的技術(shù)實(shí)踐》），容量似乎已經(jīng)不是問(wèn)題，但是當(dāng)考慮添加其他一些強(qiáng)社交關(guān)系的特性時(shí)（如成員、身份組等）就顯得有點(diǎn)為難了，聊天室本身就是來(lái)去自如的一個(gè)開放空間，這個(gè)和圈組的產(chǎn)品本身定位互相沖突的。

因此基于聊天室擴(kuò)展的方案也基本 pass 掉了。

6、“圈組”的技術(shù)難點(diǎn)

基于上述種種的思考和討論，最終選擇脫離已有 IM 體系，從零研發(fā)一套全新的社群方案“圈組”，“圈組”不是一個(gè)簡(jiǎn)單的 IM 功能，而是一套可以獨(dú)立運(yùn)行的 IM 系統(tǒng)。

經(jīng)過(guò)上面的討論，相信大家對(duì)“圈組”本身的技術(shù)特點(diǎn)和難點(diǎn)也有所理解。

可以歸納為以下幾點(diǎn)：

• 1）二級(jí)結(jié)構(gòu)下成員無(wú)上限的社交關(guān)系系統(tǒng)設(shè)計(jì)；

• 2）超大社群下消息系統(tǒng)設(shè)計(jì)；

• 3）復(fù)雜高效的身份組系統(tǒng)設(shè)計(jì)；

7、“圈組”技術(shù)實(shí)現(xiàn)之整體架構(gòu)??

“圈組”整體架構(gòu)：

上面展示了“圈組”服務(wù)整體的架構(gòu)。

可以看到整個(gè)“圈組”服務(wù)是一個(gè)分層的架構(gòu)：

• 1）首先是接入層，包括 LBS 服務(wù)和長(zhǎng)鏈接服務(wù)器以及 API 網(wǎng)關(guān)，對(duì)應(yīng)客戶端 SDK 和用戶服務(wù)器；

• 2）后面是網(wǎng)絡(luò)層，包括大網(wǎng) WE-CAN 和協(xié)議路由服務(wù)；

• 3）其次是服務(wù)層，劃分了多個(gè)服務(wù)模塊，每個(gè)模塊都包括多個(gè)微服務(wù)；

• 4）最后是基礎(chǔ)設(shè)施。

8、“圈組”技術(shù)實(shí)現(xiàn)之消息系統(tǒng)架構(gòu)

這其中和消息系統(tǒng)相關(guān)聯(lián)的包括接入層、網(wǎng)絡(luò)層、以及后端的登錄/訂閱/消息/檢索等模塊。

基本架構(gòu)如下：

消息系統(tǒng)中第一個(gè)要討論的點(diǎn)就是消息的存儲(chǔ)和分發(fā)方式，包括在線廣播、離線推送、歷史消息三個(gè)維度。

下面幾節(jié)我們將對(duì)消息系統(tǒng)中各模塊分別展開介紹。

9、“圈組”消息系統(tǒng)技術(shù)實(shí)現(xiàn)1：在線廣播

對(duì)于一般的IM群組來(lái)說(shuō)，在線廣播的一般過(guò)程是這樣的：依次查詢?nèi)航M里的所有人的在線狀態(tài)，如果在線，則將消息發(fā)送給對(duì)應(yīng)的長(zhǎng)鏈接服務(wù)器。

顯然這種機(jī)制無(wú)法復(fù)制到“圈組”，因?yàn)樵凇叭M”的一個(gè)服務(wù)器里可能存在超過(guò) 100w 的人。

此外：IM聊天室的廣播模式也不能直接復(fù)用，因?yàn)樵诹奶焓壹軜?gòu)中，每個(gè)長(zhǎng)鏈接映射到一個(gè)聊天室，因此當(dāng)你登錄到某個(gè)聊天室的時(shí)候，你只會(huì)收到該聊天室的消息。而對(duì)于“圈組”來(lái)說(shuō)，每個(gè)用戶會(huì)同時(shí)加入多個(gè)服務(wù)器/頻道，而且會(huì)同時(shí)收到多個(gè)服務(wù)器/頻道的消息。

針對(duì)“圈組”的上述特點(diǎn)：我們?cè)O(shè)計(jì)了消息訂閱模式，也就是用戶登錄之后，需要訂閱感興趣的相關(guān)服務(wù)器/頻道，服務(wù)器會(huì)記錄下這個(gè)訂閱信息。當(dāng)有新消息的時(shí)候，服務(wù)器通過(guò)訂閱關(guān)系（而不是在線狀態(tài)）查詢到需要廣播的列表，通過(guò)這種方式就不再需要遍歷服務(wù)器/頻道里的所有用戶。

但是當(dāng)一個(gè)服務(wù)器/頻道里在線人數(shù)非常多的時(shí)候，這個(gè)訂閱關(guān)系仍然是巨大的。

為此：我們?cè)O(shè)計(jì)了一種兩層訂閱模型，即所有的訂閱關(guān)系會(huì)保存在長(zhǎng)鏈接服務(wù)器上（QChatLink/QChatWebLink），同時(shí)長(zhǎng)鏈接服務(wù)器會(huì)定時(shí)發(fā)送心跳給后端的訂閱服務(wù)器，心跳信息相比原始的訂閱信息會(huì)大大簡(jiǎn)化，比如長(zhǎng)鏈接服務(wù)器上會(huì)記錄賬號(hào) A 訂閱了某個(gè)頻道 A 的消息，如果有 1w 個(gè)賬號(hào)，則有 1w 條訂閱記錄，而心跳信息里只會(huì)上報(bào)有 1w 個(gè)人訂閱了某個(gè)頻道 A 的消息，具體的賬號(hào)列表則被精簡(jiǎn)掉了。當(dāng)一條消息需要廣播時(shí)，消息服務(wù)會(huì)訪問(wèn)訂閱服務(wù)，獲取到該服務(wù)器/頻道被訂閱的長(zhǎng)鏈接服務(wù)器列表，并依次給該列表中的長(zhǎng)鏈接服務(wù)器發(fā)送消息下發(fā)通知，長(zhǎng)鏈接服務(wù)器收到通知后會(huì)根據(jù)訂閱詳情再?gòu)V播給所有客戶端。

此外：我們還提供了多種訂閱類型，當(dāng)你非常關(guān)心某個(gè)頻道消息時(shí)（比如頁(yè)面正停留在該頻道），此時(shí)你可以訂閱該頻道的消息。對(duì)于其他頻道，如果你僅僅需要知道該頻道有多少條未讀消息（或者有無(wú)未讀消息），則可以選擇訂閱該頻道的未讀計(jì)數(shù)（或者未讀狀態(tài)），此時(shí)服務(wù)下發(fā)時(shí)僅會(huì)廣播精簡(jiǎn)的消息體用于維護(hù)客戶端未讀計(jì)數(shù)，并且當(dāng)未讀計(jì)數(shù)達(dá)到一定閾值之后（比如 99+），服務(wù)器可以選擇不再下發(fā)任何通知消息而不影響用戶體驗(yàn)。

通過(guò)上文介紹的消息訂閱模型，極大地提高了超大型的圈組頻道/服務(wù)器消息在線廣播的效率，降低了服務(wù)器壓力。

除此之外：我們還設(shè)計(jì)了針對(duì)小型頻道的特殊策略，對(duì)于小型頻道，即使不訂閱，服務(wù)器也會(huì)下發(fā)消息通知給頻道里所有人，從而減輕端側(cè)消息訂閱模型的維護(hù)成本。針對(duì)消息訂閱機(jī)制本身，后續(xù)我們也會(huì)根據(jù)不同的業(yè)務(wù)場(chǎng)景，提供更多一站式的策略來(lái)幫助降低接入成本，提升整體的易用性。

10、“圈組”消息系統(tǒng)技術(shù)實(shí)現(xiàn)2：離線推送

在強(qiáng)社交的場(chǎng)景下，離線消息推送對(duì)于維持用戶粘性+提升產(chǎn)品體驗(yàn)有很大的作用。

從技術(shù)角度看的話，主要解決2個(gè)問(wèn)題：

1）第一個(gè)是超大型服務(wù)器/頻道的消息推送的效率問(wèn)題；

2）另一個(gè)是提供足夠豐富的推送策略來(lái)幫助 C 端用戶，避免被過(guò)量的推送消息給打擾。

針對(duì)第一個(gè)問(wèn)題，我們針對(duì)不同規(guī)模的服務(wù)器/頻道采取了不同的策略：

• 1）對(duì)于小型頻道：采用類似于群組的消息推送模型；

• 2）對(duì)于大型頻道：對(duì)于每一條需要推送的消息，會(huì)根據(jù)目標(biāo)用戶的 ID 進(jìn)行任務(wù)分片，多個(gè)節(jié)點(diǎn)并行操作，提高推送效率。

此外：分片會(huì)采用一致性策略，保證單個(gè)用戶固定為某些節(jié)點(diǎn)，從而提高緩存命中效率。

針對(duì)第二個(gè)問(wèn)題，推送策略可以用以下幾句話來(lái)描述：

• 1）既關(guān)注促活，又保證不打擾；

• 2）大型 server 是游樂(lè)場(chǎng)，只推送與用戶相關(guān)的重要消息（如 @消息）；

• 3）小型 server 是與朋友相處的小天地，支持消息的全部推送。

并且：未來(lái)用戶還可以自定義消息的高低優(yōu)先級(jí)，并搭配不同的推送配置（如不同的免打擾配置等），如下圖所示。

11、“圈組”消息系統(tǒng)技術(shù)實(shí)現(xiàn)3：歷史消息

歷史消息的存儲(chǔ)在“圈組”的場(chǎng)景中也需要一些特別的設(shè)計(jì)。

同樣以傳統(tǒng)IM群組為例，一般來(lái)說(shuō)消息的存儲(chǔ)方式有兩種，寫擴(kuò)散和讀擴(kuò)散。在小型的IM群組或者多人會(huì)話中，寫擴(kuò)散模式可以簡(jiǎn)化設(shè)計(jì)，但是當(dāng)群組規(guī)模擴(kuò)大到一定程度（如萬(wàn)人群），讀擴(kuò)散就成了選擇。

而對(duì)于“圈組”這種單個(gè)服務(wù)器可能上百萬(wàn)人的“群組”中，除了常規(guī)的讀擴(kuò)散之外，我們還設(shè)計(jì)了多級(jí)緩存的結(jié)構(gòu)來(lái)應(yīng)對(duì)海量的讀請(qǐng)求。

基本的存儲(chǔ)架構(gòu)大致如下：

消息的存儲(chǔ)主要包括兩部分：

• 1）一部分是消息本身；

• 2）一部分是未讀計(jì)數(shù)。

首先是寫入：對(duì)于上述兩者，我們都會(huì)使用中心化的緩存服務(wù)器來(lái)存儲(chǔ)最近的數(shù)據(jù)，并使用異步+批量+聚合等手段，通過(guò) MQ 異步落庫(kù)，從而平衡寫入效率（單條寫入性能低）和寫入讀取延遲（異步寫入有延遲）的問(wèn)題，并且針對(duì)不同數(shù)據(jù)類型的特點(diǎn)，我們也選擇了不同的存儲(chǔ)方案（歷史消息使用分布式時(shí)間序列數(shù)據(jù)庫(kù)，未讀計(jì)數(shù)使用分布式 k-v 數(shù)據(jù)庫(kù)），最大化地提升消息存儲(chǔ)和查詢的性能和效率。

有寫就有讀，針對(duì)讀取操作：

• 1）所有最近的消息和未讀計(jì)數(shù)均會(huì)存儲(chǔ)在中心化緩存中，并通過(guò)先進(jìn)先出和緩存過(guò)期等不同的策略來(lái)確保緩存中存儲(chǔ)的永遠(yuǎn)是最新和最熱的數(shù)據(jù)；

• 2）對(duì)于消息 ID 和消息內(nèi)容本身，中心化緩存中也會(huì)有不同的數(shù)據(jù)結(jié)構(gòu)和過(guò)期策略，來(lái)平衡緩存命中率和緩存容量消耗；

• 3）當(dāng)緩存過(guò)期了，如果有關(guān)聯(lián)的讀寫請(qǐng)求，將會(huì)觸發(fā)緩存的重建，以保證緩存的命中率始終保持在較高水位；

• 4）當(dāng)有高頻的讀請(qǐng)求，還會(huì)觸發(fā)熱點(diǎn) cache 的檢測(cè)，并將一部分讀請(qǐng)求下沉到各個(gè)計(jì)算節(jié)點(diǎn)的內(nèi)存中，以應(yīng)對(duì)突發(fā)流量的沖擊。

上述針對(duì)“圈組”的特別設(shè)計(jì)，消息存儲(chǔ)系統(tǒng)可以應(yīng)對(duì)幾十?dāng)?shù)百人的小型圈組頻道，也可以從容應(yīng)對(duì)上百萬(wàn)的超大型頻道。

12、相關(guān)資料

[1]?IM群聊消息究竟是存1份(即擴(kuò)散讀)還是存多份(即擴(kuò)散寫)？

[2]?網(wǎng)易云信技術(shù)分享：IM中的萬(wàn)人群聊技術(shù)方案實(shí)踐總結(jié)

[3]?企業(yè)微信的IM架構(gòu)設(shè)計(jì)揭秘：消息模型、萬(wàn)人群、已讀回執(zhí)、消息撤回等

[4]?融云IM技術(shù)分享：萬(wàn)人群聊消息投遞方案的思考和實(shí)踐

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

[6]?百萬(wàn)人在線的直播間實(shí)時(shí)聊天消息分發(fā)技術(shù)實(shí)踐

[7]?千萬(wàn)級(jí)實(shí)時(shí)直播彈幕的技術(shù)實(shí)踐

[8]?深度解密釘釘即時(shí)消息服務(wù)DTIM的技術(shù)設(shè)計(jì)

[9]?深度揭密RocketMQ在釘釘IM系統(tǒng)中的應(yīng)用實(shí)踐

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

[11]?一套億級(jí)用戶的IM架構(gòu)技術(shù)干貨(下篇)：可靠性、有序性、弱網(wǎng)優(yōu)化等

[12]?從新手到專家：如何設(shè)計(jì)一套億級(jí)消息量的分布式IM系統(tǒng)

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