2
| 本文作者： 周梁偉 | 2016-06-30 18:01 |
雷鋒網(wǎng)按：本文作者周梁偉，現(xiàn)任網(wǎng)易云信IM即時(shí)通訊云服務(wù)器端開發(fā)負(fù)責(zé)人。2011年加入網(wǎng)易，先后擔(dān)任網(wǎng)易后臺(tái)技術(shù)中心與網(wǎng)易大數(shù)據(jù)平臺(tái)資深開發(fā)工程師，目前負(fù)責(zé)即時(shí)通訊領(lǐng)域的產(chǎn)品開發(fā)。
在一般人的理解中，直播聊天室應(yīng)該就是直播畫面旁配一個(gè)聊天窗口，眾多觀看者在里面發(fā)表自己的評(píng)論（如圖1），隨著移動(dòng)互聯(lián)網(wǎng)技術(shù)的發(fā)展和受眾群體的轉(zhuǎn)移，這種簡單的聊天室已經(jīng)滿足不了廣大網(wǎng)民的需求，參與者更加關(guān)注和主播之間的互動(dòng)體驗(yàn)。
圖1：直播聊天室形態(tài)
比如觀眾A平時(shí)就愛網(wǎng)紅視頻直播，進(jìn)直播室就要點(diǎn)亮自己，發(fā)彈幕和主播對(duì)話，高興的時(shí)候要送禮，還要和其他粉絲聊天。觀眾B熱衷投資，對(duì)投資大師們的動(dòng)向分析實(shí)時(shí)關(guān)注，現(xiàn)在大師們開直播了，不僅可以聽取知識(shí)還可以實(shí)時(shí)互動(dòng)，有問題及時(shí)解答。
我們發(fā)現(xiàn)在直播聊天室的互動(dòng)形式已經(jīng)非常多樣化了，常見的像評(píng)論、點(diǎn)亮、彈幕、送禮等（如圖2）。而適用直播聊天室的場景也越來越多，如網(wǎng)紅直播、在線教育、在線游戲、在線金融等，直播的平臺(tái)也從單純的網(wǎng)頁端向移動(dòng)端、網(wǎng)頁端和PC端等多平臺(tái)轉(zhuǎn)移。開發(fā)者通過直播+聊天室實(shí)現(xiàn)了真正的全民互動(dòng)，使舞臺(tái)已經(jīng)不屬于少數(shù)人，人人都能參與其中。
圖2：直播聊天室新形態(tài)
現(xiàn)實(shí)也不總是那么美好。以下這個(gè)畫面（圖3）是不是很熟悉，一打開直播畫面就卡住，幾萬人同時(shí)嗨翻全場，彈幕堆滿屏幕，女主播的臉卡成好幾節(jié)，有的時(shí)候甚至都進(jìn)不去直播間。這樣的直播聊天室體驗(yàn)是不是太差了？
圖3：彈幕卡頓
在討論聊天室設(shè)計(jì)之前，我們先了解下幾種常見的虛擬社群形態(tài)。下面的表格，我們從參與人數(shù)、消息送達(dá)即時(shí)性、離線消息關(guān)注度等維度對(duì)論壇、IM P2P、IM群和聊天室這幾種常見的虛擬社群形態(tài)做了簡單對(duì)比，從這個(gè)對(duì)比可以看到聊天室是一種不同于論壇和群模式的一種虛擬組織。
圖4：常見虛擬社群形態(tài)的對(duì)比
聊天室跟普通的IM群（微信群，QQ群等）相比最大的不同點(diǎn)在于它是一個(gè)比較開放的虛擬組織。我們可以將直播聊天室比喻成一個(gè)廣場，廣場是開放無邊界的，所有的人都可以隨進(jìn)隨出，而群就像一個(gè)房間，是一個(gè)有邊界有容量上限的私密組織，并且進(jìn)入這個(gè)房間需要一定條件，一般是主動(dòng)申請(qǐng)加入或被邀請(qǐng)加入。
聊天室對(duì)比論壇和IM群來說，它既具有了IM群消息即時(shí)送達(dá)的特性又有論壇參與人數(shù)無上限的特性。
就聊天室的實(shí)現(xiàn)來說，目前比較流行的做法是直接在群的架構(gòu)上改造，但是只要是群就有人數(shù)和離線消息的存入上限，聊天室人數(shù)越多，消息分發(fā)的壓力越大，客戶端的用戶體驗(yàn)也會(huì)變差。
跳出之前的思維，我們要實(shí)現(xiàn)一個(gè)聊天室服務(wù)，可能面臨下面這些問題：
客戶端多樣
通信數(shù)據(jù)安全需要保障
網(wǎng)絡(luò)抽風(fēng)/單點(diǎn)故障
用戶量上來了，架構(gòu)撐不住
消息投遞慢
由此，我們提出聊天室服務(wù)需要滿足以下特性：
跨平臺(tái)：新型的應(yīng)用都是能同時(shí)跨多種設(shè)備實(shí)現(xiàn)消息互通的，需要同時(shí)服務(wù)于網(wǎng)頁端，手機(jī)端和桌面端，甚至智能電視等。
數(shù)據(jù)加密：客戶端與服務(wù)器端之間的通信數(shù)據(jù)要避免泄露的風(fēng)險(xiǎn)。
高可用：任何一個(gè)節(jié)點(diǎn)故障都不應(yīng)該引起服務(wù)不可用。
易擴(kuò)展：具有水平擴(kuò)展的特性，對(duì)不同量級(jí)的在線用戶數(shù)都有應(yīng)變的能力。
高并發(fā)低延遲：能支持大量的用戶同時(shí)收發(fā)消息，消息從發(fā)出到送達(dá)所有在線端的延時(shí)在毫秒級(jí)。
那么如何克服那些難點(diǎn)并且搭建一個(gè)符合上述條件的直播聊天室？
開篇闡述了直播各種應(yīng)用場景以及全民互動(dòng)的需求，對(duì)應(yīng)的問題是：一個(gè)熱門直播間的人數(shù)可能達(dá)到幾十萬人，個(gè)人發(fā)消息幾十萬人接收，幾十萬人發(fā)消息幾十萬人接收，這個(gè)流量相當(dāng)驚人，服務(wù)端要如何設(shè)計(jì)才能保證系統(tǒng)流暢？無上限人數(shù)和系統(tǒng)順暢不卡頓，這兩個(gè)條件如何在直播時(shí)同時(shí)滿足？
網(wǎng)易云信在做聊天室服務(wù)時(shí)，將整個(gè)系統(tǒng)分成了：客戶端層、網(wǎng)關(guān)接入層、路由層和業(yè)務(wù)層，來進(jìn)行分別處理。
圖5：設(shè)計(jì)架構(gòu)邏輯
圖6：各分層的具體內(nèi)容
目前的應(yīng)用都存在跨平臺(tái)的需求：iOS、安卓、網(wǎng)頁端，甚至IOT物聯(lián)網(wǎng)設(shè)備，能連多少是多少，多多益善。但是不同開發(fā)平臺(tái)之間的技術(shù)差異性極大，不是所有公司都有這么全的全棧程序猿的；如果團(tuán)隊(duì)開發(fā)的話單就客戶端開發(fā)人員就不是幾個(gè)人可以完成的。
我們?cè)龅竭^一個(gè)創(chuàng)業(yè)團(tuán)隊(duì)，他們想自己實(shí)現(xiàn)TCP長連接的邏輯，iOS開發(fā)的同學(xué)沒日沒夜干了一個(gè)禮拜，終于把第一個(gè)RPC請(qǐng)求調(diào)通了，結(jié)果又在數(shù)據(jù)包壓縮瘦身和加密的坑里爬了大半個(gè)月，好不容易發(fā)了個(gè)demo版出來，結(jié)果發(fā)現(xiàn)移動(dòng)網(wǎng)絡(luò)下各種掉線，最后又不斷優(yōu)化弱網(wǎng)環(huán)境下的自動(dòng)重連機(jī)制，負(fù)責(zé)安卓的同學(xué)則在邊上觀摩了一個(gè)月之后徹底放棄了，因?yàn)樗胘ava重新把iOS同學(xué)的Objective-C代碼再重新實(shí)現(xiàn)一遍，里面有多少坑，能不能爬出來誰也說不準(zhǔn)。而網(wǎng)頁開發(fā)同學(xué)就直接懵了，因?yàn)樗緵]法理解Web上的長連接是什么鬼，調(diào)研半天發(fā)現(xiàn)只能用websocket這種方案，但是這種方案已有的服務(wù)器又根本沒法支持。
所以當(dāng)你想去搭建一個(gè)無上限人數(shù)直播聊天室之前，先想想怎么解決這個(gè)客戶端互通的問題。
所以當(dāng)你想去搭建一個(gè)無上限人數(shù)直播聊天室時(shí)需要先想想怎么解決跨平臺(tái)問題。我們的聊天室服務(wù)SDK需實(shí)現(xiàn)多平臺(tái)覆蓋，對(duì)iOS、Android、Windows和Web等開發(fā)平臺(tái)都要提供原生SDK版本，最大程度上解決開發(fā)者跨平臺(tái)需求的難題，使開發(fā)者能使用自己熟悉的開發(fā)語言和平臺(tái)快速實(shí)現(xiàn)產(chǎn)品功能。
想象一下，我們生活中在手機(jī)（iOS、Android）、平板、電腦、可穿戴設(shè)備上都能實(shí)現(xiàn)看直播時(shí)自由聊天以及互動(dòng)，那是一件多么美好的事情。
圖7：多平臺(tái)互通
SDK層還有一個(gè)重要的工作時(shí)是需要針對(duì)iOS和Android這種移動(dòng)網(wǎng)絡(luò)做弱網(wǎng)絡(luò)優(yōu)化。弱網(wǎng)優(yōu)化有四個(gè)方式：
通過提前喚醒來降低重連過程中的網(wǎng)絡(luò)狀態(tài)切換、DNS解析等帶來的延時(shí)開銷，特別是針對(duì)Android等系統(tǒng)，我們通過維護(hù)后臺(tái)長連接來使手機(jī)與服務(wù)器保存連接活躍狀態(tài)；
通過數(shù)據(jù)包壓縮來降低帶寬的占用，提升請(qǐng)求在網(wǎng)絡(luò)層的傳輸速度；
通過提供邊緣節(jié)點(diǎn)使移動(dòng)客戶端總是能連接到距離最近的最優(yōu)節(jié)點(diǎn)；
通過使用CDN等來提升多媒體資源的上傳下載速度，開發(fā)者無需關(guān)心移動(dòng)網(wǎng)絡(luò)切換時(shí)網(wǎng)絡(luò)斷線重連等問題，提高連接的穩(wěn)定性。
現(xiàn)在移動(dòng)直播越來越火，各類戶外直播也逐漸興起，經(jīng)常會(huì)處在弱網(wǎng)環(huán)境中，有了弱網(wǎng)優(yōu)化的加持，我們?cè)诳粗辈サ臅r(shí)候，也會(huì)更加順暢，無需擔(dān)心看到關(guān)鍵時(shí)刻而黑屏的情況發(fā)生，同時(shí)，還能與其他粉絲一起互動(dòng)聊天。
當(dāng)前的網(wǎng)絡(luò)安全形勢異常復(fù)雜，開發(fā)應(yīng)用時(shí)如果不在通信安全上花心思，那你的用戶就等于在互聯(lián)網(wǎng)上裸奔。開發(fā)者需要針對(duì)不同的平臺(tái)，對(duì)不同的通信技術(shù)實(shí)現(xiàn)可靠的安全方案，避免用戶數(shù)據(jù)在傳輸過程中泄露。在選擇一個(gè)云提供商時(shí)，他們應(yīng)該具備哪些云安全認(rèn)證和標(biāo)準(zhǔn)？是否有匹配具體安全服務(wù)類型的認(rèn)證？其實(shí)安全需求跨度非常廣，涵蓋行業(yè)甚至企業(yè)自己內(nèi)部，但是確有一些共性的需求來保證云安全認(rèn)證和標(biāo)準(zhǔn)的開發(fā)。一些標(biāo)準(zhǔn)很明顯是適用的，比如C-STAR認(rèn)證和ISO27001，都是國際通行的信息安全方面的認(rèn)證體系。
因此在通信安全方面，對(duì)客戶端與服務(wù)器端之間的通信數(shù)據(jù)需進(jìn)行加密處理，加密秘鑰的有效期控制在單次會(huì)話粒度，每次會(huì)話需要通過非對(duì)稱加密算法來協(xié)商本次會(huì)話使用的加密秘鑰，再使用此秘鑰對(duì)請(qǐng)求和響應(yīng)包數(shù)據(jù)做流加密，加密之后的數(shù)據(jù)再對(duì)大請(qǐng)求包做壓縮。 通過這種方式一則幫用戶節(jié)省了網(wǎng)絡(luò)流量，提高數(shù)據(jù)傳輸效率，二則保證了通信數(shù)據(jù)的安全性，規(guī)避數(shù)據(jù)泄露或中間人攻擊等各種安全風(fēng)險(xiǎn)。
安全問題是最最重要的，誰也不希望在看直播、聊天娛樂的時(shí)候被第三方抓取到賬號(hào)或聊天數(shù)據(jù)等隱私信息，所以加密處理是直播聊天室必須要做的，也是為了我們能享受這個(gè)網(wǎng)絡(luò)虛擬環(huán)境在技術(shù)上做的努力。
圖8：數(shù)據(jù)加密
聊天室服務(wù)應(yīng)該具備水平擴(kuò)展的能力，當(dāng)用戶量增長時(shí)隨時(shí)可以通過增加服務(wù)器來擴(kuò)容，而不需要將架構(gòu)推倒重來。
Peter剛進(jìn)入團(tuán)隊(duì)時(shí)跟我們分享了一個(gè)自己的故事，他和幾個(gè)小伙伴之前做了一個(gè)分享周邊美食的App，但是人手緊張啊，想著快速出成效，服務(wù)器簡單搞了幾個(gè)Tomcat，前端弄了Nginx就當(dāng)高可用了，服務(wù)器和客戶端的數(shù)據(jù)通訊就用簡單的http協(xié)議實(shí)現(xiàn)了，開發(fā)速度是真快。iOS和安卓只要在客戶端搞個(gè)http的庫就把數(shù)據(jù)通信的事情搞完了，為了在一個(gè)分享內(nèi)容發(fā)出去之后馬上能被其他人看到，客戶端同學(xué)天真地來了一個(gè)5秒輪詢的邏輯，應(yīng)用一進(jìn)入前臺(tái)就會(huì)定期拉取新內(nèi)容，產(chǎn)品愉快地被推廣出去之后，用戶量幾百人幾千人時(shí)大家都一副很輕松的樣子，但當(dāng)用戶量過萬的時(shí)候就發(fā)現(xiàn)服務(wù)器撐不住了，5秒輪詢的坑開始發(fā)威了。再然后就是競品出來了，用戶體驗(yàn)被完爆，這真是個(gè)悲傷的故事。Peter淚流滿面：“架構(gòu)擴(kuò)展性真的好重要！”
所以無上限人數(shù)聊天室服務(wù)需要具備足夠的彈性，在用戶量級(jí)上來之后能支持快速的擴(kuò)容，不會(huì)因?yàn)榧軜?gòu)的問題需要重構(gòu)。
網(wǎng)關(guān)接入層主要用于客戶端長連接的管理，單個(gè)節(jié)點(diǎn)可以維護(hù)的長連接在十萬量級(jí)。網(wǎng)關(guān)接入層還有一個(gè)重要功能是處理不同SDK的協(xié)議兼容問題，針對(duì)移動(dòng)端和PC端等支持TCP長連接的SDK中我們實(shí)現(xiàn)了私有通訊協(xié)議，針對(duì)Web SDK則提供基于Socket IO的自定義協(xié)議，通過在接入服務(wù)器網(wǎng)關(guān)上對(duì)該協(xié)議進(jìn)行雙向解析轉(zhuǎn)換來保證不同的SDK請(qǐng)求響應(yīng)包格式統(tǒng)一；另外，網(wǎng)關(guān)接入層還要處理數(shù)據(jù)安全邏輯和跨網(wǎng)絡(luò)的高可用邏輯，為此我們提供處于不同網(wǎng)絡(luò)環(huán)境的多個(gè)可用域，當(dāng)單個(gè)可用域出現(xiàn)網(wǎng)絡(luò)故障時(shí)可以自動(dòng)切換到備用域來保證服務(wù)不受影響；網(wǎng)關(guān)接入層還要實(shí)現(xiàn)海量聊天室廣播消息的高效下發(fā)。
任何硬件和軟件都存在故障的可能，我們無法避免應(yīng)用罷工，那就需要隨時(shí)準(zhǔn)備替補(bǔ)上場。
你一定聽說過“藍(lán)翔畢業(yè)生挖斷機(jī)房光纜”這樣的故事，也聽說過天津港爆炸引起IDC機(jī)房受損這樣的真實(shí)事件，當(dāng)這種不可預(yù)測的天災(zāi)人禍降臨的時(shí)候，如果能不影響服務(wù)的話那就更厲害了。所以現(xiàn)在各種云服務(wù)提供商都在提“異地雙活”之類的高可用方案。
更不用提服務(wù)器宕機(jī)之類的這種家常便飯的小故障了，所以在服務(wù)設(shè)計(jì)時(shí)都需要消除可能存在的單點(diǎn)。
路由層承擔(dān)了網(wǎng)關(guān)接入層和業(yè)務(wù)層之間解耦的功能，數(shù)據(jù)包到達(dá)接入層之后通過路由層中轉(zhuǎn)送達(dá)到正確的業(yè)務(wù)節(jié)點(diǎn)。同時(shí)具有負(fù)載均衡和高可用的能力，在單個(gè)業(yè)務(wù)節(jié)點(diǎn)處理能力達(dá)到瓶頸時(shí)能方便快速的擴(kuò)容；路由層使業(yè)務(wù)層擴(kuò)容對(duì)前置網(wǎng)關(guān)層完全透明，當(dāng)一個(gè)網(wǎng)絡(luò)的業(yè)務(wù)集群出現(xiàn)網(wǎng)絡(luò)故障時(shí)，可以切換到備用網(wǎng)絡(luò)，保證服務(wù)可用性。
從業(yè)務(wù)層上來說，聊天室功能上的業(yè)務(wù)節(jié)點(diǎn)主要用于處理收發(fā)聊天室消息，成員進(jìn)出鑒權(quán)等具體的業(yè)務(wù)邏輯，集群內(nèi)有眾多節(jié)點(diǎn)，它們角色相互對(duì)等，單節(jié)點(diǎn)的故障可能會(huì)使集群的業(yè)務(wù)處理能力受影響但不會(huì)引起服務(wù)的中斷，在節(jié)點(diǎn)故障發(fā)生時(shí)可以快速增加新的替代節(jié)點(diǎn)（就是新開服務(wù)器）來恢復(fù)集群的業(yè)務(wù)處理能力，此外業(yè)務(wù)集群有多個(gè)網(wǎng)絡(luò)環(huán)境的熱備（這個(gè)就是上面說的多個(gè)可用域），來應(yīng)對(duì)可能出現(xiàn)的區(qū)域性網(wǎng)絡(luò)故障。
總之，以上的技術(shù)都是在為一個(gè)穩(wěn)定而安全的直播聊天室服務(wù)，沒有以上技術(shù)的加持，這一場主播和觀眾的互動(dòng)聊天大戲是沒有辦法進(jìn)行下去的，更別說全民參與直播、觀看直播了。
技術(shù)的發(fā)展讓用戶體驗(yàn)越來越出色，任何現(xiàn)實(shí)中的難點(diǎn)正在一個(gè)一個(gè)被攻破，技術(shù)人員的責(zé)任也是越來越重大。在直播應(yīng)用如火如荼的今天，各種應(yīng)用都在面臨觀眾人數(shù)的急劇膨脹，產(chǎn)品需求的不斷增加，流量高峰期不期而遇等問題。直播聊天室服務(wù)的穩(wěn)定和高效對(duì)提升應(yīng)用整體的體驗(yàn)至關(guān)重要。
本文為雷鋒網(wǎng)獨(dú)家約稿，轉(zhuǎn)載請(qǐng)聯(lián)系授權(quán)，不得刪改文章內(nèi)容。
雷峰網(wǎng)原創(chuàng)文章，未經(jīng)授權(quán)禁止轉(zhuǎn)載。詳情見轉(zhuǎn)載須知。
