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

一.網(wǎng)絡(luò)傳輸協(xié)議的選擇

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

我們該如何選擇呢？

• UDP協(xié)議實時性更好，但是如何處理安全可靠的傳輸并且處理不同客戶端之間的消息交互是個難題，實現(xiàn)起來過于復(fù)雜；

• HTTP協(xié)議屬于擴展支持，我們在產(chǎn)品的初始階段可以不用支持；

• 那就非TCP協(xié)議莫屬了，要考慮的同樣也有很多，特別是如果有海量用戶的需求。如何保證單機服務(wù)器高并發(fā)量，如何做到靈活，擴展的架構(gòu)。

Tips: QQ 為什么采用 UDP 協(xié)議，而不采用 TCP 協(xié)議實現(xiàn)？

二.應(yīng)該選擇什么格式的數(shù)據(jù)協(xié)議

二進制格式？文本格式？這個話題轉(zhuǎn)到我的這篇文章《網(wǎng)絡(luò)傳輸數(shù)據(jù)格式的選擇》，從我們當前的需求和產(chǎn)品周期上我覺得選擇JSON形式的數(shù)據(jù)協(xié)議是***的。

三.架構(gòu)設(shè)計

首先我們來提煉一下一個IM系統(tǒng)的主要需求，包括賬號，關(guān)系鏈，在線狀態(tài)顯示，消息交互......。

架構(gòu)考量：

• 由于采用可靠傳輸協(xié)議TCP，考慮到負載問題（短連接實現(xiàn)賬號、關(guān)系鏈相關(guān)業(yè)務(wù)，長連接實現(xiàn)上線、信息推送）；

• 后臺架構(gòu)的靈活性、可擴展性，支持分布式部署——把網(wǎng)絡(luò)層、業(yè)務(wù)邏輯層、數(shù)據(jù)層分離，網(wǎng)絡(luò)層和業(yè)務(wù)層支持負載均衡策略、數(shù)據(jù)層支持分布式存儲；

• 客戶端SDK的易用性：把網(wǎng)絡(luò)層、數(shù)據(jù)層分離、業(yè)務(wù)邏輯層分離；

后臺架構(gòu)簡化圖

架構(gòu)示意圖

架構(gòu)細化圖

說明

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

• 對于部分業(yè)務(wù)服務(wù)：做到網(wǎng)絡(luò)層、業(yè)務(wù)層、數(shù)據(jù)層的完全分離。首先對于TCP短連接來說不會如長連接那般消耗資源，即使后期遇到海量的并發(fā)訪問請求依然可以從容的通過負載均衡策略和數(shù)據(jù)分布式部署策略進行解決。參見我的這篇文章《服務(wù)端架構(gòu)中的“網(wǎng)關(guān)服務(wù)器”》

服務(wù)端平臺及技術(shù)選型

• 系統(tǒng)開發(fā)平臺： CentOS——Linux發(fā)行版的一種，穩(wěn)定可靠、可定制優(yōu)化、支持豐富；

• 網(wǎng)絡(luò)支撐層： libevent——減小開發(fā)成本，增強穩(wěn)定性；

• 緩存存儲層： Redis——支持豐富的存儲結(jié)構(gòu)，支持分布式存儲；

• 數(shù)據(jù)庫： MySQL——最適合互聯(lián)網(wǎng)的數(shù)據(jù)庫，免授權(quán)、高效穩(wěn)定、可控性高；

• 開發(fā)語言： C/C++；

部分熱點問題考量

• 系統(tǒng)性能考量：

  • 編碼角度：采用高效的網(wǎng)絡(luò)模型，線程模型，I/O處理模型，合理的數(shù)據(jù)庫設(shè)計和操作語句的優(yōu)化；

  • 垂直擴展：通過提高單服務(wù)器的硬件資源或者網(wǎng)絡(luò)資源來提高性能；

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

• 系統(tǒng)的高可用性：（防止單點故障）

  • 在架構(gòu)設(shè)計時做到業(yè)務(wù)處理和數(shù)據(jù)的分離，從而依賴分布式的部署使得在單點故障時能保證系統(tǒng)可用。

  • 對于關(guān)鍵獨立節(jié)點可以采用雙機熱備技術(shù)進行切換。

  • 數(shù)據(jù)庫數(shù)據(jù)的安全性可以通過磁盤陣列的冗余配置和主備數(shù)據(jù)庫來解決。

主要學(xué)習資料： 請自行g(shù)oogle。

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

• 《BasicDB的架構(gòu)演變》；

• 《微信之道－至簡》；

本文出自51博客 “永遠的朋友” ，轉(zhuǎn)載請務(wù)必保留此出處http://yaocoder.blog.51cto.com/2668309/1412029