摘要：愷英網(wǎng)絡(luò)程序經(jīng)理張皓聰在上，做了直播平臺(tái)系統(tǒng)實(shí)戰(zhàn)的主題分享，介紹了直播平臺(tái)系統(tǒng)的搭建過程。張皓聰年加入愷英網(wǎng)絡(luò)，先后負(fù)責(zé)過多款手游頁游項(xiàng)目，對(duì)和有深入研究。確保所有的壓力是平均的。

分享 | 張皓聰（愷英網(wǎng)絡(luò)程序經(jīng)理）

整理 | 西北

2016年10月29日，由又拍云舉辦的Open Talk No.26在“魔都”上海3W空間成功舉辦，此次活動(dòng)主要邀請(qǐng)直播領(lǐng)域開發(fā)一線的技術(shù)大神們聊一聊直播平臺(tái)的架構(gòu)與優(yōu)化，看他們化解項(xiàng)目選型、開發(fā)上線、迭代過程、性能優(yōu)化中遇到的挑戰(zhàn)與經(jīng)驗(yàn)。

愷英網(wǎng)絡(luò)程序經(jīng)理張皓聰在Open Talk No.26上，做了“直播平臺(tái)IM系統(tǒng)實(shí)戰(zhàn)”的主題分享，介紹了直播平臺(tái)“IM系統(tǒng)”的搭建過程。

張皓聰：2010年加入愷英網(wǎng)絡(luò)，先后負(fù)責(zé)過多款手游頁游項(xiàng)目，對(duì)NodeJS和ZeroMQ有深入研究。目前負(fù)責(zé)愷英網(wǎng)絡(luò)“板栗直播”IM系統(tǒng)的相關(guān)開發(fā)工作。

△ Open Talk No.26現(xiàn)場(chǎng)照片

以下是張皓聰?shù)姆窒砣?/p>

今天我要跟大家分享的是現(xiàn)在非常流行的直播平臺(tái)里的“IM系統(tǒng)”?！鞍謇踔辈ァ盜M系統(tǒng)從立項(xiàng)初期，到發(fā)展致今，已經(jīng)成為一個(gè)功能復(fù)雜，擁有一定穩(wěn)定性的系統(tǒng)。

我們做IM系統(tǒng)1.0版本時(shí)，有以下幾個(gè)需求：

一周出 Demo

差不多能用

演示的時(shí)候不能突然崩潰

萬一崩潰了不能被發(fā)現(xiàn)

性能無所謂

總之，要快速做出來

由于只有一周的時(shí)間，第一版的架構(gòu)搭建得非常簡(jiǎn)單：
服務(wù)端由 PHP 和 NodeJS 組成。PHP 負(fù)責(zé)用戶賬戶，注冊(cè)和登錄。NodeJS 負(fù)責(zé)長(zhǎng)連以及進(jìn)出房間和推送，做成簡(jiǎn)單的交互。
第一個(gè)版本的前端服務(wù)器的結(jié)構(gòu)非常簡(jiǎn)單，功能很少，僅僅負(fù)責(zé)聯(lián)接客戶端，負(fù)責(zé)所有客戶端的聯(lián)接。為了保證 H5 也可以使用，因此在長(zhǎng)連上選擇了WebSocket。

△ IM系統(tǒng)1.0版本架構(gòu)圖

為了確?？蛻舳搜菔镜臅r(shí)候，萬一崩潰了也不能被察覺，我們使用 pm2 守護(hù)了 node進(jìn)程。同時(shí)讓客戶端同學(xué)做了個(gè)自動(dòng)斷線重連。
然后登錄流程是這樣的，先從PHP獲取一個(gè)token，然后帶著這個(gè)token和node 建立連接，node 會(huì)在內(nèi)網(wǎng)向php驗(yàn)證 token 是否有效，然后建立連接。
然后廣播方面，使用了我稱作組的形式進(jìn)行廣播，所有的房間和私信都是通過組的形式進(jìn)行廣播。

首先，用戶在房間里發(fā)言的時(shí)候，實(shí)際上是往特定組發(fā)送廣播。組的名字是用特定字符開頭來歸類的。
舉例來說，需要向10000房間發(fā)送聊天信息時(shí)，實(shí)際上是向 r:10000 這個(gè)組發(fā)送信息。此時(shí)服務(wù)端會(huì)遍歷該組里所有連接，并發(fā)送消息。
當(dāng)需要進(jìn)行全服廣播的時(shí)候，我們使用一個(gè)寫死特殊的 0 號(hào)房間，轉(zhuǎn)換成 gid 也就是 r:0 發(fā)送消息。這將遍歷所有連接，向他們發(fā)送消息。
接下來是推送私聊，這里我為每個(gè)用戶都設(shè)置了一個(gè)私有的 gid，這樣發(fā)送私信的時(shí)候也相當(dāng)于發(fā)送了廣播，服務(wù)端可以用相同邏輯處理。打個(gè)比方向 uid 20000 用戶發(fā)送私信，相當(dāng)于向 u:20000 廣播。以后擴(kuò)展成多進(jìn)程多主機(jī)模式時(shí)，也不必知道這個(gè)用戶目前在哪臺(tái)服務(wù)器上，推送私信就會(huì)很方便。
在這個(gè)設(shè)計(jì)中，一位用戶是允許加入多個(gè)組的。就像群聊一樣，一開始就使用這樣的設(shè)計(jì)，以后可以很容易的進(jìn)行擴(kuò)展。
由于采用了單點(diǎn)連接的形式，并不需要每次進(jìn)房間都建立新連接，客戶端只要首次進(jìn)行連接，之后發(fā)送請(qǐng)求就可以進(jìn)出房間，也節(jié)省了客戶端的開發(fā)工作。

2.0版本需求：

內(nèi)測(cè)版本

支持?jǐn)U容

更高的可用性

禮物信息比聊天優(yōu)先級(jí)高

特定消息要發(fā)送回執(zhí)

當(dāng)1.0版本完成之后，接下來就是要開發(fā) 2.0 版本。
這個(gè)版本里增加了一些必要的需求。
首先，這是一個(gè)內(nèi)測(cè)版本。在內(nèi)測(cè)版本中會(huì)邀請(qǐng)用戶使用，并進(jìn)行測(cè)試。
期間可能由于用戶數(shù)增多，也可能因?yàn)槲覀兇a本身的原因或是 bug 造成服務(wù)器壓力增加，此時(shí)會(huì)有擴(kuò)容方面的需求。
第二個(gè)是要增加廣播優(yōu)先級(jí)的功能，這個(gè)很簡(jiǎn)單，禮物肯定是比普通信息優(yōu)先級(jí)更高的。
最后是特定消息的回執(zhí)發(fā)送，這個(gè)我們目前也還沒有實(shí)現(xiàn)，但是需求一直是在的。

△ IM系統(tǒng)2.0版本的架構(gòu)

上圖中可以看到模塊數(shù)增加了，但是總的來說客戶端需求并沒有變化，基本流程的連接流程仍然是先問 PHP 要 token，再去連接 WS。由于我們?cè)试S把 WS 部署在多個(gè)主機(jī)上，在這中間增加了一步就是訪問 LB 獲得 WS 地址。LB 會(huì)輪詢的告知客戶端本次應(yīng)使用哪個(gè) WS，并把 IP 返回給客戶端。確保所有 WS 的壓力是平均的。
另外還有一處增加的功能是，由于 WS 已經(jīng)分離到多個(gè)進(jìn)程了，那么需要一個(gè)地方可以用來處理廣播。這邊我們選擇了 redis 的進(jìn)行廣播。
同時(shí)另外還部署了一臺(tái) redis 是專門用來保存在線列表等數(shù)據(jù)。

△ 帶有優(yōu)先級(jí)的推送消息

上圖是一個(gè)帶有優(yōu)先級(jí)的推送消息。
大家可注意到，我們?yōu)槊總€(gè)組的gid增加了一個(gè)后綴，這個(gè)后綴是用來區(qū)分優(yōu)先級(jí)的。
比如說用戶進(jìn)入房間 10000，那么我會(huì)把他放到 2 個(gè)組，分別是 r:10000._ 和 r:10000.n。
同時(shí) node 也會(huì)向 redis 訂閱兩個(gè)同名頻道，此時(shí)服務(wù)端就可以從 2 個(gè)頻道收到推送消息，分別是 _（普通） 和 n （優(yōu)先）。
后端會(huì)有聊天信息要推送，會(huì)根據(jù)優(yōu)先級(jí)，是使用普通頻道還是優(yōu)先頻道進(jìn)行廣播。
node 這邊會(huì)開一個(gè)主循環(huán)，比如設(shè)置 12fps ，每一幀會(huì)優(yōu)先轉(zhuǎn)發(fā)優(yōu)先組（頻道）中的消息，然后才是普通消息，根據(jù)當(dāng)時(shí)壓力，將會(huì)選擇拋棄普通消息。

3.0版本需求：

業(yè)務(wù)邏輯越來越多，需要拆分

需要支持熱更

更好的廣播性能

優(yōu)化與其他服務(wù)的通信

日志系統(tǒng)

部署腳本

到了3.0版本時(shí)，需求越來越多，需要拆分。
線上有時(shí)候會(huì)有bug和做活動(dòng)，會(huì)有熱更的需求。
redis 廣播有可能出現(xiàn)瓶頸，在這之前需要需要更好的廣播性能。
同時(shí)還需要優(yōu)化與其他服務(wù)器之間的通信。
最后還需要需要有一個(gè)簡(jiǎn)單的日志搜集器。

△ IM系統(tǒng)3.0版本架構(gòu)

這是3.0版本的架構(gòu)。大家可以看到下面有大量的服務(wù)了。其實(shí)這些服務(wù)原來是在WebSocket里面的，現(xiàn)在把它拆成不同的進(jìn)程。
客戶端連接這塊沒有變化，客戶端仍然需要問 PHP 要 token，問 LB 要地址，最后再連接。
這個(gè)版本的 WS 功能上更加單一，只負(fù)責(zé)消息轉(zhuǎn)發(fā)。
在這個(gè)版本里，我們做了一套 RPC 框架，用來方便調(diào)用內(nèi)網(wǎng)各服務(wù)的接口。
增加了日志搜集器和API的服務(wù)。以及IM系統(tǒng)（私聊）。用戶之間可以聊天和查看聊天記錄等。
總的來說，功能上沒有特別大的變化，尤其是接口方面是向前兼容的。

△ 通過RPC中轉(zhuǎn)的推送消息

下面我介紹一下RPC服務(wù)框架。
我們的 RPC 框架是基于 ZeroMQ 的。利用他的里的Dealer和Router 進(jìn)行消息的收發(fā)。
ZeroMQ 自帶自動(dòng)重連和負(fù)載均衡功能，這方面也不用太操心，節(jié)省了開發(fā)時(shí)間。
數(shù)據(jù)交換格式是JSON，明文傳輸，調(diào)試也會(huì)很方便。

ZeroMQ 性能
-E5-2630，8G 內(nèi)存，千兆網(wǎng)卡的測(cè)試結(jié)果
#local_thr tcp://*:5555 100 10000000
message size: 100 [B]
message count: 10000000
mean throughput: 1097051 [msg/s]
mean throughput: 877.641 [Mb/s]

還有就是我們不再使用 redis 做廣播，而改用 ZeroMQ 的 pub 和 sub 做廣播服務(wù)。這樣廣播性能就有了很大提升。

IM系統(tǒng)4.0版本的需求

廣播和業(yè)務(wù)分離

優(yōu)化PRC協(xié)議

針對(duì)個(gè)別地區(qū)進(jìn)行網(wǎng)絡(luò)優(yōu)化

到了這個(gè)階段，我們遇到了一些個(gè)別地區(qū)網(wǎng)絡(luò)較慢的問題。

我們把 WS 和 LB 放到了代理服務(wù)器后面。LB 可以根據(jù)不同運(yùn)營(yíng)商用戶，返回代理了的 WS 地址。

△ RPC服務(wù)路由

同時(shí)還優(yōu)化了RPC 服務(wù)，我們?yōu)?RPC 服務(wù)增加了路由器，所有的 Worker 都隱藏在他后面，這樣客戶端調(diào)用的時(shí)候并不需要知道具體 Worker 的地址。Worker 的更新重啟也不會(huì)影響其他客戶端。

廣播服務(wù)也得到了業(yè)務(wù)和廣播分離，同時(shí)集群化。