1.直播聊天室的形式和應用場景
在一般人的理解中，直播聊天室應該就是直播畫面旁邊配一個聊天窗口，眾多觀看者在
裡面發表自己的評論（如圖1）。Oh, NO！這樣的場景是不是太Low啦！隨著互聯網技術和消費者群體的轉移，這種簡單的聊天室根本就滿足不瞭廣大網民的需求。比如小明平時就愛網紅視頻直播，來瞭就點亮自己，視頻彈幕自己想對網紅說的話，高興的時候要送禮，還要和粉絲積極互動。小軍熱衷投資，對投資大師們的動向分析實時關註，現在大師們開直播啦，不僅可以聽取知識還可以實時互動，有問題及時解答，完美！能滿足他們的要求麼？
答案是當然！發展到現在，直播聊天室的展現形態已經多樣化：評論，點亮，彈幕，送禮熱你選（如圖2），是不是美美噠？而使用直播聊天室的場景也越來越多，網紅直播，在線教育，金融等，使用直播聊天室也從網站端轉移到移動端，讓直播+聊天室實現瞭全民真正的互動，舞臺已經不屬於少數人，人人都能參與其中！
圖1：傳統聊天室形態
圖2：直播聊天室新形態
2.直播聊天室的技術難點
欣賞完瞭圖2美美的圖片，給大傢看一個立馬毀三觀的場景。以下這個畫面（圖3）是不是很熟悉，善良的你打開直播畫面就卡住，幾萬人同時high翻全場的時候，你的彈幕卡成鬼畜視頻，女主播的臉卡成好幾節，卡到你懷疑網速、電腦配置、瀏覽器、懷疑你自己的人品為止。這樣的聊天室客戶體驗是不是太差瞭？怎麼會這樣呢？說好的美圖2呢？
圖3：直播卡頓
回到正題，開篇闡述瞭直播各種應用場景，全民互動，對應的問題是：一個熱門直播間人數可能達到幾十萬人，個人發消息幾十萬人接收，幾十萬人發消息幾十萬人接收，這個流量相當驚人，服務端要如何設計才能保證系統流暢？無上限人數&系統順暢不卡頓，這兩個條件如何在直播時同時滿足？即如何才能成功搭建一個完美的視頻直播系統？
在討論聊天室之前，我們先瞭解下幾種常見的虛擬社群形態。下表從參與人數、消息送達即時性、離線消息關註度等維度對論壇、IM P2P、IM群和聊天室這幾種常見的虛擬社群形態做瞭簡單對比，從這個對比可以看到聊天室是一種不同於論壇和群模式一種虛擬組織，聊天室的架構需要跳出傳統思維來設計。
圖4：常見虛擬社群形態的對比
聊天室跟普通的IM群（微信群，QQ群等）相比最大的不同點在於它是一個比較開放的虛擬組織。我們可以將聊天室比喻成一個廣場，廣場是開放無邊界的，所有的人都可以隨進隨出，而群就像一個房間，是一個有邊界有容量上限的私密組織，並且進入這個房間需要一定條件，一般是主動申請加入或被邀請加入。聊天室對比BBS論壇這種虛擬組織來說，它既具有瞭IM群消息即時送達的特性又有論壇參與人數無上限的特性。
聊天室目前比較流行的做法說都是建立在群的架構上，但是隻要是群就有人數和離線消息的存入上限，所以您看到的圖2就不足為奇，聊天室人數越多現象更嚴重，這裡請大傢自行腦補下看電視滿屏雪花點的感受。
問題來瞭，那跳出群框架就好瞭啊，如此簡單。Oh,No！還真不是你想跳就能跳，下面我們來看看搭建無上線聊天室的難點在哪裡？
圖5：聊天室搭建技術難點
首先第一個難點是客戶端多樣性：
目前的應用都存在跨平臺的需求，iOS、安卓和PC端，網頁端，甚至IOT物聯網設備，能連多少是多少，多多益善；但是不同開發平臺之間的技術差異性極大，不是所有公司都有這麼全的全棧程序猿的；如果團隊開發的話單就客戶端開發人員就不是幾個人可以完成的。
圖6：客戶端多樣性
我們曾遇到過一個創業團隊，他們想自己實現TCP長連接的邏輯，iOS開發的同學沒日沒夜幹瞭一個禮拜，終於把第一個RPC請求調通瞭，結果又在數據包壓縮瘦身和加密的坑裡爬瞭大半個月，好不容易發瞭個demo版出來，結果發現移動網絡下各種掉線，最後又不斷優化弱網環境下的自動重連機制，負責安卓的同學則在邊上觀摩瞭一個月之後徹底放棄瞭，因為他要用java重新把iOS同學的Objective-C代碼再重新實現一遍，裡面有多少坑，能不能爬出來說也說不準；而網頁開發同學就直接懵瞭，因為他根本沒法理解Web上的長連接是什麼鬼，調研半天發現隻能用websocket這種方案，但是這種方案已有的服務器又根本沒法支持。
其次，要考慮到數據安全的保證
當前的網絡安全形勢異常復雜，開發應用時如果不在通信安全上花心思，那你的用戶就是在互聯網上裸奔；開發者需要針對不同的平臺，不同的通信技術實現可靠的安全方案，避免用戶數據在傳輸過程中泄露。在選擇一個雲提供商時，他們應該具備哪些雲安全認證和標準?是否有匹配具體安全服務類型的認證?其實安全需求跨度非常廣，涵蓋行業甚至企業自己內部，但是確有一些共性的需求來保證雲安全認證和標準的開發。一些標準很明顯是適用的，比如C-STAR認證和ISO27001，都是國際通行的信息安全方面的認證體系。
第三，還需要配備跨機房網絡級的高可用方案
當機房網絡出現故障時把責任推給市政施工隊或者“網絡抽風”已經不流行瞭，用戶需要的是故障無感知。
同時，還需要所有環節的單點故障排除
任何硬件和軟件都存在故障的可能，我們無法避免應用罷工，那就需要隨時準備替補上場。
你一定聽說過“藍翔畢業生挖斷機房光纜”這樣的故事吧，也聽說過天津港爆（bao）炸（zha）引起IDC機房受損這樣的真實事件吧，當這種不可預測的天災人禍降臨的時候，如果能不影響服務的話那就更厲害瞭，所以現在服務提供方都在提“異地雙活”之類的高可用方案。更不用提服務器宕機之類的這種傢常便飯的小故障瞭，所以在服務的設計時都需要消除可能存在的單點。
然後需要能應對任何用戶量級的需求
架構級做到水平擴展的能力，當用戶量增長時隨時可以通過堆服務器來解決，而不是將架構推倒重來。
網易雲信新同事Peter剛進入團隊時跟我們分享瞭一個自己的故事，他和幾個小夥伴之前做瞭一個分享周邊美食的App，但是人手緊張啊，想著快速出成效，服務器簡單搞瞭幾個Tomcat，前端弄瞭Nginx就當高可用瞭，服務器和客戶端的數據通訊就簡單的http協議實現瞭，開發速度是真快！iOS和安卓隻要在客戶端搞個http的庫就把數據通信的事情搞完瞭；為瞭在一個分享內容發出去之後馬上能被其他人看到，客戶端同學天真地來瞭一個5秒輪詢的邏輯，產品愉快地被推廣出去之後，用戶量幾百人幾千人時大傢都一副很輕松的樣子，但當用戶量過萬的時候就發現服務器撐不住瞭，5秒輪詢的坑開始發威瞭。再然後就是競品出來瞭，用戶體驗被完爆，最後Peter就來網易雲信瞭，這真是個悲傷的故事。Peter淚流滿面地說：架構擴展性真的好重要！
架構必需要具備足夠的彈性，
在用戶量級上來之後能支持快速的水平擴展，不會因為架構的問題需要重構；
最後就是消息投遞速度，絕對影響用戶體驗
聊天室對消息的即時性要求非常高，同一條消息在投遞給不同成員時需要在毫秒級內完成，如果消息投遞慢瞭容易造成消息時間線錯亂，使聊天室裡的人無法理解上下文場景。
3.無上限不卡頓聊天室架構應具備的條件
看瞭上述描述，是不是覺得很難很復雜哇，那我來總結下這樣的聊天室架構應該具備哪些條件吧！
跨平臺：新型的應用都是能同時跨多種設備實現消息互通的，比如網頁端，手機端和桌面端，甚至智能電視等；
數據加密：客戶端與服務器端之間的通信數據要避免泄露的風險；
高可用：任何一個節點故障都不應該引起服務不可用；
易擴展：具有水平擴展的特性，對不同量級的在線用戶數都有應變的能力；
高並發低延遲：能支持大量的用戶同時收發消息，消息從發出到送達所有在線端的延時在毫秒級；
4.無上限不卡頓聊天室，雲信是如何做到的？
這裡可以分享一下網易雲信是如何搭建設計架構的：我們是分瞭客戶端層、網關接入層、路由層、業務層進行分別處理。
在客戶端層重點解決跨平臺問題，SDK實現瞭多平臺覆蓋，對iOS、Android、Windows和Web等開發平臺都提供瞭原生SDK版本，最大程度上解決瞭開發者跨平臺需求的難題，使開發者能使用自己熟悉的開發語言和平臺快速實現產品功能。此外我們對iOS和Android這種移動網絡做瞭弱網絡優化，開發者無需關心移動網絡切換時網絡斷線重連等問題，提高瞭連接的穩定性。在通信安全方面，對客戶端與服務器端之間的通信數據都做瞭加密壓縮處理，一則幫用戶節省瞭網絡流量，提高數據傳輸效率，二則保證瞭通信數據的安全性，規避數據泄露或中間人攻擊等各種安全風險。
然後就是網關接入層面，網關接入層主要用於客戶端長連接的管理，單個節點可以維護的長連接在十萬量級。網關接入層還有一個重要功能是處理不同SDK的協議兼容問題，比如Web端使用的WebSocket協議和iOS端使用的基於TCP的私有協議是不一樣的，這類客戶端與服務器在數據通信協議上的差異需要通過接入網關做協議轉換；另外，我們的網關接入層還要處理數據安全邏輯和跨網絡的高可用邏輯(誰知道哪天網線會被藍翔的畢業生挖斷呢?)；最後是廣播消息的高效下行分發，網關接入節點需要將收到的廣播消息分發到本節點上維護的客戶端。
路由層，路由層承擔瞭網關接入層和業務層之間解耦的功能，數據包到達接入層之後通過路由層中轉送達到正確的業務節點，同時具有負載均衡和高可用的能力，在單個業務節點處理能力達到瓶頸時能方便快速的擴容；路由層使業務層擴容對前置網關層完全透明，當一個網絡的業務集群出現網絡故障時，可以切換到備用網絡，保證服務可用性。
最後從業務層上來說，我們聊天室功能上的業務節點主要用於處理收發聊天室消息，成員進出鑒權等具體的業務邏輯，集群內有眾多節點，它們角色相互對等，單節點的故障可能會使集群的業務處理能力受影響但不會引起服務的中斷，在節點故障發生時可以快速增加新的替代節點來恢復集群的業務處理能力；此外業務集群有多個網絡環境的熱備，以應對可能出現的區域性網絡故障。
5.使用網易雲信聊天室的原因
創業，時間是你最大的成本
技術發展到現在已經不流行重復造輪子瞭，因為輪子的結構越來越復雜，功能性和非功能性的指標要求越來越高；而我們的用戶卻不會再等我們瞭。當我們還在畫輪子的圖紙的時候，競爭對手可能已經把車子都造好，在路上跑瞭。雖然我們不是非得自己造輪子，但是瞭解如何完成一個完美的輪子的制作過程和質量標準卻是非常有必要的，這也是之前談這麼多的原因。比如要做互聯網視頻直播，要選一傢靠譜的CDN廠商，不靠譜的CDN服務對小產品開發團隊就是一個災難，其次找一個靠譜的技術團隊，如何在行業窗口爆發期去迅速找到一批專業的技術高手，是每個創業團隊面臨的問題。
就像近幾年大數據技術非常流行，如果你對這個領域有所瞭解你就會發現幾乎所有公司都在使用已有的平臺，或者直接使用，或者在上面做二次改造，原因無非就是上面說的幾點。現在你遇到的也是同樣的問題，聊天室這種功能在最近兩年又火瞭起來，主要還是視頻直播業務的大規模擴張；能借用目前已有的平臺或工具來實現產品需求是最快捷的路徑，創業團隊需要關註的是怎樣以最快的速度抓住用戶。造個好輪子不容易，為什麼不用現成的？
我們為您的安全保駕護航
如前文所述，數據安全需求跨度非常廣，涵蓋行業甚至企業自己內部，但是確有一些共性的需求來保證雲安全認證和標準的開發。一些標準很明顯是適用的，比如C-STAR認證和ISO27001，都是國際通行的信息安全方面的認證體系。而網易雲信是國內首批通過ISO22301認證的雲服務商。
ISO 22301是第一份以業務連續管理(Business Continuity Management，簡稱BCM)為主題的國際標準，提供瞭一種完整通用的BCM方法論，讓企業能夠達到國際上公認的最佳實踐。該認證適用於所有行業中的大、中、小型公有及私有組織，並且特別適用於處於高風險和高度監管環境下的行業，例如金融業、IT通信業、制造業等，在企業業務的運行過程中，往往會受到各種內在或外在因素的影響，嚴重時甚至會導致中斷業務，而意外的中斷會給企業帶來重大損失。
