刷微博是許多人每天的“例行指部鍛煉”，一掃一劃，就能評論熱點話題，訂閱熱門動态。當然，也有不少人對明星不感興趣，轉而去刷 Reddit、貼吧、虎撲、知識星球或是其他 BBS 社區。對于 90、80 後來說，這個被“刷”的對象可能是曾經的即刻、糗百，天涯、貓撲。
可以說，“聚衆看熱鬧”是人類永恒不變的愛好，但我們看熱鬧的方式卻并不豐富：要麼刷 BBS 社區，要麼紮進社交軟件的群聊。
不知你有沒有想過，如果将二者合二為一，讓微博、貼吧這樣的社區，全部變成即時聊天，各個博主、吧友的動态，全部以群聊消息的形式推送給你，你又可以即時地回複、互動，甚至和這些博主、吧友連麥視頻，情況會是怎樣的？
這将是一個超級社區，或者更準确地說，這将是一個無人數上限的“超級群”。
可是，這個“超級群”，實現起來将非常困難。在程序員看到産品設計的那一刻，就有精神崩潰的風險。
真正的服務器壓力“崩潰”主要源自技術挑戰，更确切地說，是服務器面臨的巨大的讀寫壓力和存儲壓力。
微博曾出現過幾次著名的故障：趙麗穎領證、關曉彤官宣、王寶強離婚。在調侃微博崩潰的各種網絡段子背後，我們能看到的是，一個架構師面對一條微博下幾秒新增數萬條評論，服務器壓力瞬間暴漲幾十倍的無奈身影。
與此類似的是直播彈幕的分發場景。無論是近期的視頻号五月天跨年演唱會，還是 B 站春晚，彈幕過百萬輕而易舉（“二零一九最美的夜”bilibili 晚會彈幕超過 170 萬條）。
理論上講，每一條彈幕都要向直播間内觀衆做全量分發。以五月天跨年演唱會為例，當晚有 1,680 萬人在線上觀看，如果保守假設當晚共發送 100 萬條彈幕，那麼單是彈幕的寫操作，就至少要執行 16,800,000 x 1,000,000 次。因為實際支撐有困難，又要顧及用戶的屏幕根本無法同屏顯示上萬條評論，所以彈幕的轉發一般都是降級處理 —— 隻分發一小部分給你看，其他的略過。
而如果将微博評論、直播彈幕，全部“群聊化”，問題會更加恐怖。“群聊化”後，産品形态成為“超級群”，問題進入 IM 場景，可以做相應的流控，但不能丢棄信息。且無論是微博評論還是直播彈幕，對信息上下文的關注度都不高，但這恰恰是 IM 關注的重點。
可以說，至少在 3 年以前，能夠系統解決這些問題并将其打磨為一個成熟産品的人不多。直到 2018 年，國外出現了一個名叫 Discord 的軟件，網友才體驗到了這種全新的社區形式。Discord 最初隻服務于遊戲語音連麥，但很快演化為一個超級社區。2021 年，據 CNN 報道，Discord 已有超過 1.4 億名注冊用戶，微軟正在談判以 100 億美元收購它。而在 npr 的采訪中，美國芝加哥地區的一名 18 歲少年表示，他 2020 年的大部分時間都在 Discord 上閑逛，并将其形容為“Reddit 和群聊的混合體”。元宇宙的支持者們也驚奇地發現，所謂的“Discord 模式”，不就是未來元宇宙虛拟社區的基礎模式麼？在元宇宙裡，總不能先加個 500 人的群再開始聊天吧。
抛開模式創新不談，如果要深究 Discord 的技術核心，恰恰就是我們前面所描述的“超級群”。而在 2022 年 1 月 11 日，融雲也發布了一款名為“超級群”的 PaaS 産品，以此為例，我們或許能搞清楚，這種帶了點科幻色彩的未來社區，究竟是如何實現的。
超級群的設計架構和實施方案超級群的底層技術支撐能力，可以簡單分為兩部分來談，分别是超級群業務能力、IM 底層技術能力。
超級群的業務能力，在架構設計層面共分為四層，分别是加速網絡、接入層、核心服務層以及底層存儲。之所以要做這樣的劃分，是為了充分利用融雲自身的統一加速網絡機制, 保障網絡連通性以及連接質量，讓超級群可以根據自身業務需求, 在連接通道的基礎上，專心實現更高效的業務交互。
在融雲，傳統的群消息建立在收發模型（收件箱、發件箱）的基礎上，獨立維護會話列表和曆史消息存儲。從用戶發送群消息，到群内 (成員數量為 N ) 接收群消息。整個過程将産生四類消息：
消息存儲投遞流程為：
終端 A -> 發送消息 -> 接入服務 -> 群管理 (群消息上行) -> 分發 -> 群聊消息分發節點 -> 消息節點 -> 通知拉取 (直接發送) -> 終端 B/C/D
在這樣的流程下，消息分發節點與消息節點交互密切，通常合并部署。同時，消息節點也會直接觸發收件箱、發件箱的消息存儲。
但在超級群的場景下，群成員數量理論上是無上限的，無論是消息的上行、下行，還是消息在存儲層的寫入和查詢，都将導緻空前的服務承載壓力，以上方案因此不再适用。于是，融雲在現有連接機制之上, 針對超級群做了交互設計優化，設計了兩種分發模型: 分别叫做消息驅動模型和會話驅動模型。
對于消息驅動模型而言，消息節點将不再直接觸發收件箱存儲操作。融雲特别設計了一個環狀消息隊列, 通過内存搭配外部緩存的方式，完成最近 N 條消息的緩存, 并通過對消息存儲模型優化, 完成熱點數據的快速讀寫。對消息的下行，則做聚合處理，保障客戶端能夠處理大量消息變更通知，并且盡量減少交互次數，也讓消息的拉取變得更快速、精準。
會話驅動模型則是在消息驅動模型的基礎之上, 做進一步的優化。
首先，消息節點不會再通知客戶端拉取消息，而是通過觸發實時會話, 通知客戶端會話發生變更。而這裡的實時會話，則是實現客戶端訂閱機制的基礎, 讓客戶端可以隻獲知已訂閱的會話變更消息，從而進一步縮小需要處理的會話以及消息數量。
其次，客戶端在收到會話變更通知後, 會根據通知，判斷是否要發起會話消息查詢操作。如果是，則按照一定的機制查詢最新或特别範圍的消息。
除消息分發層面的優化外，對存儲的優化也非常關鍵。融雲超級群的所有服務，均按照業務維度進行一緻性哈希分發。比如，上行服務可以按照群 ID 或 channel ID 做哈希，分發服務可以按照接收方 ID 做哈希。核心目标在于确保熱數據的命中，優先使用内存、LRU 緩存、再使用分布式緩存、磁盤冷存儲。
APP、群組、信令級别的流控，則是另一重保障，它将一個看似無邊界的産品需求，轉化為了可琢磨、可實現的技術問題。因此，雖然流控不是超級群實現方案的重點，但依然不可或缺。
整體而言，融雲的超級群構建方案可以分為四個要點：
那麼，有了以上方案，是否就可以構建出一個“超級群”呢？顯然還不夠，在超級群的場景之下，IM 底層技術能力的積累可能更為重要。
IM 底層技術能力與網絡層性能優化如果要對融雲超級群所依賴的 IM 基礎能力做一個解讀，恐怕一本迷你書也寫不完，其粗略架構圖如下：
但好在，關于超級群，我們隻需重點關注其在網絡層面的依賴即可。對于所有的 IM 服務而言，底層網絡的加速能力都是關鍵。融雲的底層服務網絡全稱是融雲全球通信網絡 (以下簡稱為 SD-CAN，Software Defined - Communication Accelerate Network) ，集合了 BGP anycast、SD-WAN、對等連接、動态 CDN、智能 DNS 等多種網絡加速方式。
對于超級群來說，SD-CAN 允許客戶端 SDK 通過查詢和探測确定地域和運營商以及最後一公裡的網絡情況，将用戶就近調度到融雲的網絡邊緣節點, 邊緣節點依據信令的請求目标地址投遞到路由節點，完成數據彙集，再由路由節點識别并轉發到對應的數據中心。
舉個例子，如果北美用戶要訪問中國國内的數據中心，典型的兩條路徑是:
客戶端會按照服務下發的策略，做并行探測并同時建立連接。對最優鍊路的選擇，依賴于建連延遲、心跳間隔、鍊路發送接收狀況等信息。服務器也會定期檢查連接的健康度，主動關閉長尾連接，結合客戶端的重連機制，一起保障對最優鍊路的調用。
PaaS 産品接近完備，或将填補元宇宙到來前的空白除了技術實現，挑戰也出現在産品設計層面。
由于超級群中的信息量太大，需要支持将群分割為不同的頻道，類似傳統的 topic 或 channel。即使相同的群和群成員，通過不同的頻道，仍然能将會話、消息、未讀數分門别類聚合。用戶可以更關注自己感興趣的部分，提升用戶黏性。
這也反映了用戶在超級群場景下的真正需求：我或許會希望在一個有數十萬網友的超級群中建立社交關系，但卻不希望被數十萬消息打擾生活。
此外，對于融雲來說，超級群是個 PaaS 産品，這意味着要為客戶端留下充裕的可定制空間，在不同的場景，對信息推送的方式、邏輯、頻率都有不同的要求。同時，将信息和聊天結合的場景，一般都有多端的需求。不同的平台，比如 Android、iOS、Web 等，在海量消息的網絡請求和存儲方面都有不同的技術特點，甚至同平台不同廠商的推送通道特性也不同，這些都需要一一考慮。
最近幾年，社交領域的新興公司新增不多，整體增長呈下降趨勢。這一方面是因為流量向頭部高度集中，擠壓了新玩家的空間；另一方面也是因為缺少新模式，大家仍在圍繞存量用戶做競争。
超級群這一新應用形态，可能會對社交軟件整體的發展，産生巨大的牽引作用，從而帶來新的機會。同時，PaaS 産品的完備，也标志着實現産品創新的技術基礎已經夯實，這或将在産品層面，填補從微信、語聊房邁入元宇宙的最後一段空白。
,更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!
zpostcode 
Recruit 
weather 
mreligion 
Yellowpages 
sport 
constellation 
shopping 
name 
game 
directory 
literature 
Word 
tour 
furnish 
Lottery 
tftnews 
lyrics 
News 
digital 
car 
dir 
Edu 
Finance 
