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