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

一.網路傳輸協議的選擇

目前我知曉的所有IM系統傳輸即時訊息無外乎使用UDP、TCP、基於TCP的http這幾種協議中的一種或幾種。比如QQ主要採用UDP協議，MSN主要採用TCP協議，而且他們也都支援HTTP協議的代理模式。更多資料，請參加這篇文章

我們該如何選擇呢？

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

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

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

二.應該選擇什麼格式的資料協議

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

三.架構設計

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

架構考量：

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

• 後臺架構的靈活性、可擴充套件性，支援分散式部署——把網路層、業務邏輯層、資料層分離，網路層和業務層支援負載均衡策略、資料層支援分散式儲存；

• 客戶端SDK的易用性：把網路層、資料層分離、業務邏輯層分離；

後臺架構簡化圖

架構示意圖

架構細化圖

說明

• 從<架構細化圖>中可以看出對於上線服務由於建立的是TCP長連線，對於單臺伺服器往往由於硬體資源、系統資源、網路資源的限制無法做到海量使用者的同時線上，所以設計為根據伺服器負載支援多伺服器上線，同時由於多伺服器上線造成了對整個系統互動（不同的客戶端的互動，協作部門應用服務和客戶的互動）的分割，引入訊息轉發伺服器作為粘合點。另外對於多伺服器上線造成的統一賬戶資訊（線上狀態，訊息）資料的分割，引入統一的資料層（記憶體儲存層：session、狀態資訊儲存、訊息佇列儲存；資料庫：賬號資訊儲存）做到業務和資料的分離，也就做到了支援分散式部署。參見我的這篇文章

  《構建高效能服務的考量》

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

服務端平臺及技術選型

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

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

• 快取儲存層： Redis——支援豐富的儲存結構，支援分散式儲存；

• 資料庫： MySQL——最適合網際網路的資料庫，免授權、高效穩定、可控性高；

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

部分熱點問題考量

• 系統性能考量：

  • 編碼角度：採用高效的網路模型，執行緒模型，I/O處理模型，合理的資料庫設計和操作語句的優化；

  • 垂直擴充套件：通過提高單伺服器的硬體資源或者網路資源來提高效能；

  • 水平擴充套件：通過合理的架構設計和運維方面的負載均衡策略將負載分擔，有效提高效能；後期甚至可以考慮加入資料快取層，突破IO瓶頸；

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

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

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

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

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

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

• 《BasicDB的架構演變》；

• 《微信之道－至簡》；