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

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

整理 | 西北

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

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

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

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

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

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

一周出 Demo

差不多能用

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

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

性能無(wú)所謂

總之，要快速做出來(lái)

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

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

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

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

2.0版本需求：

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

支持?jǐn)U容

更高的可用性

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

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

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

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

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

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

上圖是一個(gè)帶有優(yōu)先級(jí)的推送消息。
大家可注意到，我們?yōu)槊總€(gè)組的gid增加了一個(gè)后綴，這個(gè)后綴是用來(lái)區(qū)分優(yōu)先級(jí)的。
比如說(shuō)用戶(hù)進(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ì)開(kāi)一個(gè)主循環(huán)，比如設(shè)置 12fps ，每一幀會(huì)優(yōu)先轉(zhuǎn)發(fā)優(yōu)先組（頻道）中的消息，然后才是普通消息，根據(jù)當(dāng)時(shí)壓力，將會(huì)選擇拋棄普通消息。

3.0版本需求：

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

需要支持熱更

更好的廣播性能

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

日志系統(tǒng)

部署腳本

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

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

下面我介紹一下RPC服務(wù)框架。
我們的 RPC 框架是基于 ZeroMQ 的。利用他的里的Dealer和Router 進(jìn)行消息的收發(fā)。
ZeroMQ 自帶自動(dòng)重連和負(fù)載均衡功能，這方面也不用太操心，節(jié)省了開(kāi)發(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ò)較慢的問(wèn)題。

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

△ RPC服務(wù)路由

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

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