IM系統架構設計之淺見

背景：除去大名鼎鼎的QQ這款即時聊天工具，還有許多細分行業的IM，比如淘寶阿里旺旺、網易泡泡、YY語音......。恰巧公司產品也要開發一款基於我們自己行業的類IM系統，很有幸我擔當了這個產品的架構師，核心代碼編寫、實現者。下面我近年來從技術上我對IM系統（即時消息的傳輸，不包括語音，視頻，文件的傳輸）的理解和設計分享出來，淺薄之見，望大家別見笑，歡迎給出批評意見。

---

一.網絡傳輸協議的選擇

目前我知曉的所有IM系統傳輸即時消息無外乎使用UDP、TCP、基於TCP的http這幾種協議中的一種或幾種。比如QQ主要採用UDP協議，MSN主要採用TCP協議，而且他們也都支持HTTP協議的代理模式。更多資料，請參加這篇文章《一些常用軟件的網絡端口協議分類介紹》。

我們該如何選擇呢？

• UDP協議實時性更好，但是如何處理安全可靠的傳輸並且處理不同客戶端之間的消息交互是個難題，實現起來過於複雜；

• HTTP協議屬於擴展支持，我們在產品的初始階段可以不用支持；

• 那就非TCP協議莫屬了，要考慮的同樣也有很多，特別是如果有海量用戶的需求。如何保證單機服務器高併發量，如何做到靈活，擴展的架構。

Tips: QQ 爲什麼採用 UDP 協議，而不採用 TCP 協議實現？

二.應該選擇什麼格式的數據協議

二進制格式？文本格式？這個話題轉到我的這篇文章《網絡傳輸數據格式的選擇》，從我們當前的需求和產品週期上我覺得選擇JSON形式的數據協議是最好的。

三.架構設計

首先我們來提煉一下一個IM系統的主要需求，包括賬號，關係鏈，在線狀態顯示，消息交互......。

架構考量：

• 由於採用可靠傳輸協議TCP，考慮到負載問題（短連接實現賬號、關係鏈相關業務，長連接實現上線、信息推送）；

• 後臺架構的靈活性、可擴展性，支持分佈式部署——把網絡層、業務邏輯層、數據層分離，網絡層和業務層支持負載均衡策略、數據層支持分佈式存儲；

• 客戶端SDK的易用性：把網絡層、數據層分離、業務邏輯層分離；

後臺架構簡化圖

架構示意圖

架構細化圖

說明

• 從<架構細化圖>中可以看出對於上線服務由於建立的是TCP長連接，對於單臺服務器往往由於硬件資源、系統資源、網絡資源的限制無法做到海量用戶的同時在線，所以設計爲根據服務器負載支持多服務器上線，同時由於多服務器上線造成了對整個系統交互（不同的客戶端的交互，協作部門應用服務和客戶的交互）的分割，引入消息轉發服務器作爲粘合點。另外對於多服務器上線造成的統一賬戶信息（在線狀態，消息）數據的分割，引入統一的數據層（內存存儲層：session、狀態信息存儲、消息隊列存儲；數據庫：賬號信息存儲）做到業務和數據的分離，也就做到了支持分佈式部署。參見我的這篇文章《構建高性能服務的考量》

• 對於部分業務服務：做到網絡層、業務層、數據層的完全分離。首先對於TCP短連接來說不會如長連接那般消耗資源，即使後期遇到海量的併發訪問請求依然可以從容的通過負載均衡策略和數據分佈式部署策略進行解決。參見我的這篇文章《服務端架構中的“網關服務器”》

服務端平臺及技術選型

• 系統開發平臺： CentOS——Linux發行版的一種，穩定可靠、可定製優化、支持豐富；

• 網絡支撐層： libevent——減小開發成本，增強穩定性；

• 緩存存儲層： Redis——支持豐富的存儲結構，支持分佈式存儲；

• 數據庫： MySQL——最適合互聯網的數據庫，免授權、高效穩定、可控性高；

• 開發語言： C/C++；

部分熱點問題考量

• 系統性能考量：

  • 編碼角度：採用高效的網絡模型，線程模型，I/O處理模型，合理的數據庫設計和操作語句的優化；

  • 垂直擴展：通過提高單服務器的硬件資源或者網絡資源來提高性能；

  • 水平擴展：通過合理的架構設計和運維方面的負載均衡策略將負載分擔，有效提高性能；後期甚至可以考慮加入數據緩存層，突破IO瓶頸；

• 系統的高可用性：（防止單點故障）

  • 在架構設計時做到業務處理和數據的分離，從而依賴分佈式的部署使得在單點故障時能保證系統可用。

  • 對於關鍵獨立節點可以採用雙機熱備技術進行切換。

  • 數據庫數據的安全性可以通過磁盤陣列的冗餘配置和主備數據庫來解決。

主要學習資料： 請自行google。

• 《1.4億在線背後的故事》；

• 《BasicDB的架構演變》；

• 《微信之道－至簡》；