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通信業、制造業等，在企業業務的運作過程中，往往會受到各種内在或外在因素的影響，嚴重時甚至會導緻中斷業務，而意外的中斷會給企業帶來重大損失。