本文由網(wǎng)易云信李興分享，原題“深度剖析“圈組”深度剖析“圈組”關(guān)系系統(tǒng)設(shè)計”，為了提升內(nèi)容品質(zhì)，本文收錄時有修訂。
1、引言
上篇《百萬級成員實時社群技術(shù)實現(xiàn)（消息系統(tǒng)篇）》中，我們分享了云信“圈組”（“圈組”是云信的類Discord產(chǎn)品實現(xiàn)方案）消息系統(tǒng)的技術(shù)設(shè)計和實踐。
本篇接上篇，將繼續(xù)分享云信“圈組”的關(guān)系系統(tǒng)在技術(shù)架構(gòu)上的設(shè)計和實現(xiàn)。希望帶給你啟發(fā)。
2、系列文章
本文是系列文章中的第 3 篇：
3、作者介紹
李興：網(wǎng)易云信資深服務(wù)端開發(fā)工程師，畢業(yè)于浙江大學，碩士畢業(yè)后加入網(wǎng)易，負責云信 IM等業(yè)務(wù)的服務(wù)器開發(fā)。專注于即時通訊以及相關(guān)中間件等技術(shù)。
4、“圈組”的關(guān)系業(yè)務(wù)特點
4.1概述
在互聯(lián)網(wǎng)行業(yè)盛行一句話，技術(shù)是為業(yè)務(wù)服務(wù)的。具體到技術(shù)實踐中，一個重要方面就是要面向業(yè)務(wù)特點設(shè)計技術(shù)方案。
因此，想要了解“圈組”的關(guān)系系統(tǒng)設(shè)計，就要首先了解“圈組”的關(guān)系業(yè)務(wù)特點。
4.2業(yè)務(wù)特點
“圈組”的關(guān)系業(yè)務(wù)特點是什么？
- 1）其一：是關(guān)系復雜，即關(guān)系主體多、管理機制雜、聯(lián)動耦合重；
- 2）其二：是規(guī)模巨大，即成員數(shù)量可達百萬量級、變更批量可達百萬量級。
所謂關(guān)系復雜，具體來講：首先是關(guān)系主體多。
在“圈組”業(yè)務(wù)中，關(guān)系主體包括：
- 1）服務(wù)器：承載社群關(guān)系，負責社群成員關(guān)系維護；
- 2）頻道：從屬于服務(wù)器，承載內(nèi)容關(guān)系，負責內(nèi)容互動關(guān)系維護；
- 3）身份組：可從屬于服務(wù)器或頻道，承載身份權(quán)限關(guān)系，負責身份設(shè)定和權(quán)限配置；
- 4）頻道分組：從屬于服務(wù)器，又關(guān)聯(lián)一組頻道，承載頻道模版關(guān)系，負責分類頻道和共享配置。
其次是：管理機制雜。
在“圈組”業(yè)務(wù)中，僅就成員管理機制而言：
- 1）服務(wù)器成員采用邀請/申請機制；
- 2）頻道成員采用公開/私密模式+黑/白名單機制；
- 3）身份組成員采用加入/移出機制；
- 4）頻道分組成員與頻道成員采用同步機制。
最后是：聯(lián)動耦合。
在“圈組”業(yè)務(wù)中，以頻道成員維護為例：頻道成員不僅受到公開/私密模式+黑/白名單配置變更的影響，而且會伴隨服務(wù)器成員變更、身份組變更、身份組成員變更等做聯(lián)動變更。
所謂規(guī)模巨大，具體來講：
- 1）一方面：成員數(shù)量可達百萬量級（在“圈組”業(yè)務(wù)中，服務(wù)器成員數(shù)量可以達到數(shù)百萬人）；
- 2）進一步：百萬成員服務(wù)器下的頻道和身份組，其成員數(shù)量也可以達到百萬量級；
- 3）另一面：是變更批量可達百萬量級。
所謂變更批量可達百萬量級，包括：刪除百萬成員的服務(wù)器/頻道/身份組，增刪頻道/頻道分組黑白名單中的百萬成員身份組等。
從“圈組”關(guān)系業(yè)務(wù)的兩大特點出發(fā)，可以發(fā)現(xiàn)：“圈組”關(guān)系是不同于群組關(guān)系的全新業(yè)務(wù)場景，將會面臨全新的技術(shù)難點。
5、“圈組”關(guān)系系統(tǒng)的技術(shù)難點
5.1概述
技術(shù)難點主要有兩個方面：
- 1）其一：是多關(guān)系主體、多管理機制在層級結(jié)構(gòu)下關(guān)聯(lián)耦合導致的業(yè)務(wù)邏輯的復雜性；
- 2）其二：是成員數(shù)量、變更批量規(guī)模巨大導致的業(yè)務(wù)處理在時間、空間、資源等開銷上的復雜性。
5.2業(yè)務(wù)邏輯復雜性
1）首先“圈組”有多級結(jié)構(gòu)：
包括服務(wù)器/頻道二級結(jié)構(gòu)、服務(wù)器/頻道分組/頻道三級結(jié)構(gòu)等。
單個關(guān)系主體變更，不僅涉及自身的變更，而且涉及上下級關(guān)系主體的變更，可以說牽一發(fā)動全身。相比而言，群組是沒有層級的，群組變更只要獨善其身就好。
2）其次“圈組”有身份組：
一個身份組是一組有共同權(quán)限的服務(wù)器成員的集合，不同身份組的成員可以相互交叉，身份組會作為整體參與到成員管理中。
也就是說，成員變更不再只是個別成員（1-100人）的進入退出，將會出現(xiàn)整組成員（1-1000000人）的大進大出。相比而言，群組是沒有身份組的，群組特殊成員包括群主、管理員等也都數(shù)量不多、互不重復。
3）最后“圈組”有多種成員管理機制：
服務(wù)器成員和身份組成員的管理機制與群組類似，頻道成員和頻道分組成員的管理機制卻是全新模式。
頻道分為公開和私密兩種：
- 1）公開模式默認允許所有服務(wù)器成員可見，但要排除黑名單身份組和黑名單成員；
- 2）私密模式默認不許所有服務(wù)器成員可見，但要放開白名單身份組和白名單成員。
除了受到公開/私密模式+黑/白名單配置變更的影響，頻道成員也受到所依賴的關(guān)系主體（服務(wù)器成員、身份組、身份組成員）變更的影響。進一步，頻道成員還受到所同步的頻道分組變更的影響。相比而言，群組成員的邀請/申請機制，可以說是小巫見大巫。
5.3業(yè)務(wù)處理復雜性
1）首先是成員數(shù)量規(guī)模巨大：
由于成員數(shù)量可達百萬，整個成員列表的存儲空間開銷、網(wǎng)絡(luò)傳輸開銷，變得十分巨大，不論全量成員列表數(shù)據(jù)的服務(wù)器緩存，還是全量成員列表數(shù)據(jù)從服務(wù)器到客戶端的同步，都將變得難以實現(xiàn)。
2）其次是變更批量規(guī)模巨大：
單次接口調(diào)用的關(guān)系變更，可能伴隨百萬規(guī)模的聯(lián)動關(guān)系變更，這會導致巨大的處理時間開銷、計算資源開銷，不論所有變更同步完成處理，還是所有變更單機完成處理，都將變得難以實現(xiàn)。
3）最后是通知消息規(guī)模巨大：
關(guān)系系統(tǒng)不僅需要做關(guān)系變更的數(shù)據(jù)處理，而且需要通知變更結(jié)果到客戶端。由于在“圈組”中各個關(guān)系主體的成員數(shù)量規(guī)模巨大，使得單個變更需要擴散為百萬通知同時下發(fā)，所需計算資源開銷、網(wǎng)絡(luò)傳輸開銷十分巨大。
相比而言，群組方案因為成員數(shù)量、變更批量規(guī)模有限，并不涉及這些技術(shù)難點。
從“圈組”關(guān)系系統(tǒng)的兩個方面技術(shù)難點出發(fā)，可以發(fā)現(xiàn)：“圈組”關(guān)系系統(tǒng)面臨不同于群組的全新技術(shù)難點，想要解決這些技術(shù)難點，需要創(chuàng)新的技術(shù)方案。
6、“圈組”的整體架構(gòu)
“圈組”方案的整體架構(gòu)：
上面展示了“圈組”方案的整體架構(gòu)，可以看到“圈組”整體是一個分層架構(gòu)。
從上到下看：
1）客戶層：包括可供客戶端集成的移動端、桌面端、跨平臺 SDK，和可供服務(wù)器調(diào)用的 OpenAPI；
2）接入層：包括 LBS 服務(wù)、長連接服務(wù)和 API 網(wǎng)關(guān)，分別對應(yīng)客戶端 SDK 和用戶服務(wù)器；
3）網(wǎng)絡(luò)層：包括自研的全球?qū)崟r傳輸網(wǎng)絡(luò) WE-CAN；
4）業(yè)務(wù)層：包括用于 SDK 業(yè)務(wù)處理的 App 服務(wù)和用于 OpenAPI 業(yè)務(wù)處理的 WebServer 服務(wù)；
5）服務(wù)層：劃分有登錄、消息、關(guān)系、身份組、支持等服務(wù)模塊，每個服務(wù)模塊包括有多個微服務(wù)或消費者；
6）基礎(chǔ)設(shè)施層：包括系統(tǒng)所用的數(shù)據(jù)庫和中間件。
7、“圈組”關(guān)系系統(tǒng)的架構(gòu)
上圖展示了“圈組”關(guān)系系統(tǒng)的技術(shù)架構(gòu)。可以看到“圈組”關(guān)系系統(tǒng)遍及“圈組”架構(gòu)的接入層、網(wǎng)絡(luò)層、業(yè)務(wù)層和服務(wù)層。
從功能出發(fā)整體上分為三個部分：
- 1）關(guān)系操作同步處理模塊；
- 2）關(guān)系事件異步處理模塊；
- 3）變更通知在線廣播模塊。
下面具體討論三個方案要點的技術(shù)細節(jié)，包括頻道成員關(guān)系管理、變更通知在線廣播和關(guān)系數(shù)據(jù)云端檢索。
8、關(guān)系系統(tǒng)技術(shù)實現(xiàn)1：頻道成員關(guān)系管理
頻道成員關(guān)系管理，是“圈組”中極具挑戰(zhàn)性的問題。
頻道成員涉及多關(guān)系主體、多管理機制、聯(lián)動變更耦合嚴重，成員數(shù)量和變更批量規(guī)模巨大，可以說是“圈組”關(guān)系業(yè)務(wù)的典型代表。
頻道成員關(guān)系管理在業(yè)務(wù)邏輯和業(yè)務(wù)處理兩方面的復雜性可想而知。
針對頻道成員關(guān)系管理問題，“圈組”設(shè)計了兩大機制加以解決。
包括：
- 1）終態(tài)維護與過渡計算相結(jié)合機制；
- 2）事件按序異步并行處理機制。
終態(tài)維護與過渡計算相結(jié)合機制，具體來講：頻道成員關(guān)系數(shù)據(jù)最終被維護在持久化數(shù)據(jù)庫中，并在頻道成員沒有變更的終態(tài)階段，直接支持頻道成員數(shù)據(jù)的查詢需求。當頻道成員發(fā)生變更時，由于變更邏輯和變更處理兩方面的復雜性，完成關(guān)系變更需要一段時間，稱之為過渡階段。
在過渡階段，數(shù)據(jù)庫持久化的頻道成員表數(shù)據(jù)是不完全準確的，無法直接支持頻道成員數(shù)據(jù)的查詢需求。此時轉(zhuǎn)為由頻道成員配置元數(shù)據(jù)直接計算頻道成員以支持查詢需求。因為頻道成員配置元數(shù)據(jù)的變更是同步處理的，所以在過渡階段由頻道成員配置元數(shù)據(jù)直接計算頻道成員可以保證查詢準確性。通過將頻道成員關(guān)系管理分為終態(tài)和過渡兩個階段，并在不同階段采用不同頻道成員查詢方案，不僅解決了單純由計算獲取頻道成員資源開銷大的問題，而且解決了頻道成員變更延遲導致由數(shù)據(jù)庫獲取頻道成員結(jié)果不準確的問題。
除了頻道成員的獲取查詢問題，頻道成員的變更處理也很重要。
事件按序異步并行處理機制，就是用于解決頻道成員的變更處理問題：
- 1）其一：通過將影響頻道成員關(guān)系的變更操作分層級、系統(tǒng)化定義為變更事件，顯著降低頻道成員關(guān)系管理的業(yè)務(wù)邏輯復雜性；
- 2）其二：通過 ID 哈希、分布式鎖、事件版本號控制等保證變更事件的按序處理，有效避免事件處理亂序?qū)е碌某志没瘮?shù)據(jù)錯誤；
- 3）其三：通過消息隊列中轉(zhuǎn)事件并在消費者上異步處理，有效解決聯(lián)動變更批量過大導致接口調(diào)用阻塞的問題；
- 4）其四：通過在單個事件處理中的多線程并行加速和本地緩存重用加速，顯著縮短頻道成員關(guān)系變更的時間延遲。
9、關(guān)系系統(tǒng)技術(shù)實現(xiàn)2：變更通知在線廣播
關(guān)系系統(tǒng)不僅需要做關(guān)系變更的數(shù)據(jù)處理，而且需要通知變更結(jié)果到客戶端。
在百萬量級的“圈組”關(guān)系中，每條關(guān)系變更通知，都會面臨海量擴散的接收者。除了通知分發(fā)量激增，不同接收者對于通知接收的緩急差異也值得關(guān)注。
針對變更通知在線廣播問題， 我們設(shè)計了兩大機制：
- 1）變更分類通知機制；
- 2）數(shù)據(jù)通知拉取機制。
在變更分類通知機制中：一方面，根據(jù)相關(guān)人員在變更中的角色，劃分為參與者和觀察者分類做通知，即參與者一定通知，觀察者按照訂閱需求通知。其中參與者一般是變更中的少數(shù)關(guān)鍵人員，觀察者則是除了參與者之外可以看到變更結(jié)果的其它人員。通過分類通知，不同接收者對于通知接收的緩急差異得到合理關(guān)注，變更通知的擴散規(guī)模也得到精準縮小。
另一方面，觀察者按照訂閱需求通知，可以充分發(fā)揮“圈組”的在線廣播訂閱模式的優(yōu)勢。所謂在線廣播訂閱模式，是指在用戶登陸之后，需要訂閱感興趣的服務(wù)器/頻道的通知，“圈組”系統(tǒng)會記錄下這些訂閱信息，當有新的通知時，“圈組”系統(tǒng)通過訂閱關(guān)系而非成員列表 + 在線狀態(tài)獲取需要在線廣播的用戶列表，從而不再需要遍歷服務(wù)器/頻道的所有成員及其在線狀態(tài)。通過采用在線廣播訂閱模式，不僅顯著降低變更通知在線廣播的計算開銷和帶寬開銷，而且可以實現(xiàn)變更通知在線廣播在長連接服務(wù)集群的并行加速和水平擴展。
變更通知的最終目的是將變更后的數(shù)據(jù)給到客戶端：不同于群組，“圈組”并不將變更后的數(shù)據(jù)直接由通知帶給客戶端，而是采用通知客戶端有變更再觸發(fā)客戶端拉取結(jié)果數(shù)據(jù)的機制。
究其原因，不同于群組將關(guān)系數(shù)據(jù)全量同步到客戶端，“圈組”客戶端不再存儲關(guān)系數(shù)據(jù)的全量鏡像，因此不再需要通過全量歷史 + 增量變更的方式維護客戶端上的關(guān)系數(shù)據(jù)全量鏡像。
與此同時，訂閱變更通知的觀察者也并不是每時每刻都要關(guān)心變更的結(jié)果數(shù)據(jù)，關(guān)心某次變更結(jié)果數(shù)據(jù)的觀察者相比訂閱變更通知的觀察者在數(shù)量上會少很多，因此，數(shù)據(jù)通知拉取機制會顯著降低變更通知的資源開銷。
另外，相比帶變更數(shù)據(jù)通知，只通知有變更，便于直接合并相同類型的通知，而不用關(guān)心合并變更數(shù)據(jù)存在的時序、并發(fā)等問題，如此，數(shù)據(jù)通知拉取機制可以通過短時間內(nèi)通知合并顯著降低服務(wù)器在線廣播開銷和客戶端通知接收開銷。
10、關(guān)系系統(tǒng)技術(shù)實現(xiàn)3：關(guān)系數(shù)據(jù)云端檢索
在“圈組”中，伴隨關(guān)系規(guī)模的大幅增長，群組基于應(yīng)用服務(wù)器全量查詢關(guān)系數(shù)據(jù)或客戶端全量同步關(guān)系數(shù)據(jù)實現(xiàn)精準查詢和靈活排序的方案不再適用。
對此，“圈組”采用了關(guān)系數(shù)據(jù)云端檢索的方案。
“圈組”關(guān)系數(shù)據(jù)云端檢索方案可支持服務(wù)器、頻道、成員等的檢索能力。
從檢索場景上分，包括：
- 1）廣場檢索：用于檢索感興趣的服務(wù)器。可以根據(jù)名稱、類別等多種維度檢索。檢索結(jié)果可以根據(jù)預定義字段（成員數(shù)量等）或自定義值（數(shù)據(jù)熱度等）等進行排序；
- 2）內(nèi)部檢索：用于檢索用戶可見的服務(wù)器、頻道、成員等。可以根據(jù)名稱、昵稱等多種維度檢索。檢索結(jié)果可以根據(jù)預定義字段（創(chuàng)建時間等）或自定義值（數(shù)據(jù)熱度等）等進行排序。
11、相關(guān)資料
[1] 一套億級用戶的IM架構(gòu)技術(shù)干貨(上篇)：整體架構(gòu)、服務(wù)拆分等
[2] 以微博類應(yīng)用場景為例，總結(jié)海量社交系統(tǒng)的架構(gòu)設(shè)計步驟
[3] IM開發(fā)技術(shù)學習：揭秘微信朋友圈這種信息推流背后的系統(tǒng)設(shè)計
[4] 直播系統(tǒng)聊天技術(shù)(四)：百度直播的海量用戶實時消息系統(tǒng)架構(gòu)演進實踐
[5] 喜馬拉雅億級用戶量的離線消息推送系統(tǒng)架構(gòu)設(shè)計實踐
[6] 企業(yè)微信客戶端中組織架構(gòu)數(shù)據(jù)的同步更新方案優(yōu)化實戰(zhàn)
[7] 企業(yè)微信的IM架構(gòu)設(shè)計揭秘：消息模型、萬人群、已讀回執(zhí)、消息撤回等
（本文已同步發(fā)布于：http://www.52im.net/thread-4333-1-1.html）