前言:
前面都在講述如何實現一個簡單的聊天室, 並回顧了websocket的協議, 以及Netty 4.x的簡單使用.
但如果僅局限於單機的聊天室實現, 那顯然難登"大雅之堂". 借這個機會, 想嘗試聊一下千萬級聊天室的實現. 同時淺談一下游戲中, 公共的聊天室資源服務定位.
本系列的文章鏈接如下:
1). websocket協議和javascript版的api
2). 基於Netty 4.x的Echo服務器實現
3). 簡易聊天室的實現
架構演進:
這邊講述一下聊天室服務的思考過程.
• 單進程聊天室
優點是實現簡單, 當然缺點也顯而易見. 雖然現在的服務器, 衡量高並發連接的性能時, 言必稱C1000K. 但實際上, 為了服務可靠穩定, 其經驗的鏈接上限值, 往往限定在萬級別. 甚至更低, 畢竟聊天室的連接是高活躍的.
• 以群分割的聊天室架構
聊天室服務, 多是以地域/興趣來構建和划分. 同群用戶只要在同一個進程即可, 但不同群的用戶, 未必需要在同一個進程中. 因此基於這個假定, 以群來分割分布式聊天室集群.
整個聊天室服務, 擁有多個服務節點. 每個節點承擔多個地域/興趣群.
那用戶如何進入指定的聊天室進程節點呢? 需要有一個專門的聊天室群管理節點, 用於路由決策, 同時管理擴容/縮容集群的過程.
但是, 由於聊天的用戶, 可能來自五湖四海, 直連聊天器節點, 每個用戶的體驗是有差異的. 為了能夠讓用戶能夠就近接入服務器節點, 又不破壞同群同節點的設定. 看來需要在chatserver之前, 再加入一層接入節點.
• 連接/業務分離的聊天室架構
接入層Connector維護與客戶端的連接, 同時在特定的chatserver注冊自己的狀態. 這樣既能讓用戶就近接入網絡, 又能保持同群同節點.
該架構參考了網易的pomelo開源系統, 具體可參考如下鏈接: 分布式聊天服務器.
注: gate服務用於connector的智能選擇(就近接入, 負載均衡). master用於chatserver節點的管理和房間的分配.
其優點描述如下:
負載分離：這種架構將承載連接的邏輯與后端的業務處理邏輯完全分離.
擴展性好: 用戶數的擴展可通過增加connector進程數來簡單實現. 房間/頻道的擴展也是, 解決了理論上的頻道/用戶無限擴展.
進一步設想:
我非常認可接入/業務分離的架構, 其實其他很多服務的架構也是類似的形態.
當然我這邊設定的聊天室是基於websocket來實現的. 而至今還有很多瀏覽器並不完全支持H5. 因此如果想要實現全瀏覽器的聊天室的話, 還是選用其他方式來借助, 比如借助Flash Socket, Comet技術.
由此, 我們簡單的繪制架構如下:
總結:
畫圖永遠是簡單的, 真正去操作實踐才是最難的. 架構的發展, 也是工程經驗的不斷嘗試, 積累的產物.
寫在最后：
如果你覺得這篇文章對你有幫助, 請小小打賞下. 其實我想試試, 看看寫博客能否給自己帶來一點小小的收益. 無論多少, 都是對樓主一種由衷的肯定.
