網易雲信「三板斧」,實現千萬級高並發

2020-12-22 中國網科學頻道

中國網際網路信息中心第38次《中國網際網路發展狀況統計報告》的統計數據顯示,2016年6月中國即時通信用戶規模達6.42億人,網民使用率為90.4%。另一方面,文化部文化市場司行業數據監測點最新統計顯示,2016年上半年,我國網絡文化市場整體營收達1017.2億元,網絡直播市場是爆發最快的領域,同比增長209.3%。其中演藝秀場用戶達到2.5億人,遊戲直播用戶達到2億人。在網際網路+時代,消息量級的大幅上升,消息形式的多元化。給IM雲服務平臺帶來了非常大的挑戰。如何應對更大數量級的高並發消息量,並能夠真正保障IM服務的穩定和快速,成為各IM雲平臺的重中之重。 

(圖片來源於網絡)

在12月2日於北京國際會議中心舉辦的ArchSummit全球架構師峰會上,網易雲信首席架構師周梁偉就針對這一話題,進行了題為《網易IM雲服務架構設計與實踐》的主題演講。其中,周梁偉先生重點分享了網易雲信在連接層的「三板斧」優化是如何在保證穩定快速的情況下實現支持千萬級高並發消息量的,引發了現場參會者和行業人士的極大關注和思考。

連接層是奠定雲信穩定性的基石

演講中,周梁偉先生反覆強調消息的到達率和及時性。他認為,對於任何一個IM應用而言,這都是一條不容有失的生命線。尤其是對於移動端IM雲服務,在無法迴避弱網環境的種種複雜問題情況下,還要考慮到聊天室等應用在高並發狀況下的嚴苛考驗。周梁偉說:「消息快速到達的前提是客戶端和伺服器之間保持了穩定的快速的連接,所以連接層可以理解為奠定雲信服務穩定性的基石。」

連接層優化之板斧一:通過邊緣節點優化網絡拓撲

據他介紹,網易雲信在其智慧雲IM架構中的連接層,進行了三大管理優化措施。第一,通過邊緣節點優化網絡拓撲。區域性網絡問題是任何一個應用或者服務都會面臨的問題,特別是對IM這類對於網絡質量特別敏感的服務。網易雲信通過部署區域性的邊緣加速節點的方式來優化網絡拓撲,譬如他們目前在海外,像美國,歐洲,中東和東南亞等很多國家和地區提供了這類邊緣加速節點,加速節點和數據中心之間再通過專線等優質網絡做互通,將整個用戶鏈路中的關鍵路徑替換成IDC之間的網絡線路,從而大幅提升連接的穩定性和速度。通過優化,客戶端到IDC中心的速度從之前的500ms以上銳減至200ms,實現提速60%。同時,消息丟失率也從之前的20%以上降低到0%。

連接層優化之板斧二:場景化的消息分發機制提升吞吐率

第二是通過場景化的消息分發機制提升吞吐率。IM點對點的消息分發模式非常依賴用戶的在線狀態。在消息分發過程中,一次在線狀態的查詢假定需要10ms,如果有100人發送消息,僅查詢在線狀態的開銷就要1秒鐘,並且這個時間開銷還會隨著消息接收人數的增加而成倍增加,再加上中間消息包的網絡分發開銷,這個消息處理的時間很快就會到達瓶頸。在聊天室場景下,這個問題就會變得尤為突出。網易雲信針對這種特殊的消息分發場景實現了一種消息分發的廣播模式。假定一個100萬人的聊天室,所有用戶分布在10個連接節點上,一條廣播消息在分發過程中只需要查詢一次在線狀態,並給每個Link分發一個廣播包,到最終用戶端的消息包由Link節點做內存拆包和下發,並且不同的節點之間可以完全並行處理。這種方式的消息分發使一個百萬量級的消息分發任務可以在秒級處理時間之內完成,對消息接收者來說也能有效控制消息到達的延時情況。

連接層優化之板斧三:集群化解決單節點性能瓶頸

第三個優化是通過集群化解決單節點性能瓶頸。周梁偉詳細介紹說,通過組建集群來對業務處理能力做水平擴展是雲信常用的一種方法。雲信最初在設計針對Web瀏覽器的長連接伺服器時,由於伺服器既需要處理SSL編解碼,又要做請求包的格式轉換,又要做長連接的管理,這直接導致了伺服器性能很快達到瓶頸。特別是在用戶側的連接有比較頻繁的重建的場景下,大部分的CPU資源都花在了SSL握手過程中。面對這個問題,網易雲信使用nginx作為前端代理,並把SSL的處理過程移到了nginx上,並使用性能較好的伺服器來做nginx代理服務,而在後端WebLink上直接使用http協議,極大提升了後端節點的處理能力。通過這種代理方式,在4核8G的虛擬機上,單個節點的承載能力從1萬連接數飆升至10萬。

從2015年10月上線就主打「真正穩定的IM雲服務」的網易雲信,至今已成功接入超過15萬APP開發者,覆蓋用戶達到驚人的5億以上。在網絡和區域上面覆蓋了196個國家,567個地區,並保證100%的送達率。除此之外,還獲得了國內即時通訊雲服務領域的首個CSA-STAR和ISO27001認證,並已擁有56項認證專利。雖然目前IM雲服務已呈現出多元化的發展趨勢,用戶和開發者對於IM服務提出碎片化、個性化和場景化的需求,但作為生存基石的穩定、快速、高並發的強化,反而更加重要。就如同武林高手過招,招式再花哨,沒有足夠深厚的內功,很難在大浪淘沙之後留存下來。通過周梁偉的分享,我們不僅看到了網易雲信在整體分層架構上的大智慧,還通過連接層的「三板斧」優化,了解了雲信是如何穩定快速的支持千萬級高並發消息量的。周梁偉先生的分享不但有助於引發國內各IM雲服務平臺對深化內功的重視和反思,而且這種分享精神對於面對挑戰的同行業者的集思廣益和共同進步,有著極具正能量的引導意義。

了解更多,請點擊http://www.netease.im/

關於網易雲信:

網易雲信是網易公司集16年IM經驗打造的即時通訊雲服務(PaaS),是網易雲第一個開放給市場的雲服務產品。開發者通過集成客戶端SDK和雲端OPEN API,即可快速實現強大的IM功能,作為PaaS服務模式的網易雲信全面支持Android、iOS、Web、PC等多平臺。除了應對傳統開發者的各項IM基本功能外,網易雲信還提供了高級通訊功能,包括實時音視頻、互動直播、教學白板、專線電話、簡訊、專屬雲在內的獨家功能以及更多其他服務。網易雲信滿足包括遊戲、協同辦公、在線醫療、在線客服、在線教育、娛樂、諮詢、生活服務、物流、旅遊、金融等各行業各種產品的即時通訊服務需求。

相關焦點

  • 網易雲信亮相WOT, 「IM+連麥互動直播」雲服務
    網易雲信側重於通過"雲服務"解決網際網路產品研發、運營等層面的痛點,幫助一鍵搭建即時通訊功能,而非提供主機、雲儲存等基礎設施,並以場景化、功能性雲服務迎合越來越多樣的開發者需求。眾多獨家功能,包括教學白板、專屬伺服器、語言識別、專線電話、原創貼圖表情、UI組件、多端登錄等契合了產品研發的具體使用場景,深受開發者好評。
  • 發展五年後,網易雲信衝擊融合通信頭把交椅
    以10月份成立整整五年的網易雲信為例,從最初的即時通訊基礎能力開始,該平臺已經擴展出即時通訊、音視頻相關的十餘種功能,服務了百萬開發者,完成了10000億條消息的發送、8億+SDK用戶和全球196個國家或地區的覆蓋,實現了日活3億的突破。
  • 網易雲信:IM雲平臺發力網際網路下半場
    在產品開發節奏加速和IM技術難度大的雙重作用下,能同時做到穩定、高並發、高可用是移動IM雲服務平臺的關鍵,而對此,網易雲信已經潛心研究了16年。連接層管理優化,支持千萬級高並發在點對點通信之外,IM更大的場景還在於群體並發溝通。
  • 網易雲信聯手配音秀,打造語音聊天室互動新體驗
    作為配音秀多年的技術合作夥伴,網易雲信為其提供了基於音視頻通話和IM即時通訊的多人語音聊天室解決方案,為配音秀用戶打造了穩定、流暢、清晰的音頻社交互動體驗。在配音秀語音聊天室的背後,是網易雲信多年持續、穩定的IM和音視頻技術支持。雲信多人語音聊天室解決方案為配音秀量身定製音頻+文本實時互動服務。
  • 網易雲信首推音樂教學解決方案
    所以唱歌教學這個場景,對音質的要求是非常高的。針對該痛點,網易雲信在音視頻通話中推出了高清音樂模式,針對唱歌教學場景做了深度優化,以滿足該場景用戶的音質需求。唱歌教學這個場景下,無論學生和老師都需要通過對照曲譜來教學,雲信可通過教學白板這個功能實現曲譜功能,老師可以通過上傳WORD或者PDF曲譜文件後,使用雲信文檔轉碼的功能將文件轉成圖片後實現譜曲功能。
  • 推進產學研創新發展 網易雲信與杭州電子科技大學計算機學院達成合作
    為了促進高等教育人才培養目標的實現和相關企業的生產技術進步,更好地利用高校與企業在人才資源、科學研究、生產實踐及商業運用等方面的各自優勢,網易雲信與杭州電子科技大學計算機學院達成戰略合作。12月31日,雙方在杭州網易大廈正式舉行了戰略合作揭牌儀式,宣布成立網易雲信——杭州電子科技大學計算機學院產學研合作基地,旨在以雙方的特色產品和優勢學科為基礎,結合國家產業結構調整升級的實際需要,開展學生聯合培養、科研開發合作等工作,在提升專業人才培養的同時提升網易雲信的音視頻創新能力。
  • 求職戰"疫" | 網易雲信攜手濱江區人力社保局實現「無接觸」招聘
    通過"零接觸雲招聘"系統,有1127位線上投遞簡歷的應聘者實現了與31家企業招聘人員的線上視頻面試。其中357人,成功取得了企業方"高合作意向"的面試評價。突如其來的疫情,讓我們的城市按下暫停鍵,使眾多行業受到波及。隨著春季招聘的需求日漸緊迫,而疫情的肆虐,卻攔住了大家出行的腳步。諸多用人單位招聘需求受到影響,應聘者著急找工作卻只能待在家中葛優躺。
  • to B的網易智企緣何要to H?
    規模龐大的中小企業,對於數位化轉型的需求愈發迫切,2B被看做中國下一個萬億級的市場。11月28日,網易智企舉辦網易創新企業大會,一方面整合旗下網易七魚、網易定位、網易互客三大產品線,發布網易雲商新品牌;一方面,網易雲信也發布了新一代音視頻技術架構和系列新產品、解決方案。雲商主打商業,雲信主打技術,組成了其未來兩大業務板塊及戰略。
  • 網易雲信流媒體首席架構師:新一代音視頻技術架構如何構建?
    網易雲信新一代音視頻架構升級新一代音視頻融合通信系統架構首先看一下網易雲信在新一代音視頻融合通信服務端系統的整體架構圖。為了進一步提升高音質的效果,我們基於線上真實用戶數據,打造了自動化的線上問題診斷分析工具,並利用機型的雲端適配和無參考打分體系,通過真實數據反饋不斷打磨高音質的效果;視頻引擎:雲信自研的 NE264 和 NEVC 視頻編碼器,壓縮效果和速度相比開源編碼器有很大提高;同時雲信實現了高性能的
  • 弘成教育啟動「三板斧」保服務方案,力求保障用戶使用流暢度
    疫情出現後,弘成教育迅速成立疫情應對小組,並制定了疫情期間兩大方案:免費開放方案和「三板斧」保服務方案。針對「停課不停學、不停教」的號召,弘成教育依託近20年的高校服務經驗,免費開放「弘成雲課堂」,為全國高校、教育機構、學生、職業人員、社會學員提供7000多門課程資源。
  • 「高並發」億級流量場景下如何實現分布式限流?
    可以採用Redis+Lua技術實現,通過這種技術可以實現高並發和高性能的限流。Lua是一種輕量小巧的腳本程式語言,用標準的C語言編寫的開源腳本,其設計的目的是為了嵌入到應用程式中,為應用程式提供靈活的擴展和定製功能。
  • 高並發的核心技術 - 冪等的實現方案
    更複雜的操作冪等保證是利用唯一交易號(流水號)實現. 我的理解:冪等就是一個操作,不論執行多少次,產生的效果和返回的結果都是一樣的 三、技術方案 1. 查詢操作 查詢一次和查詢多次,在數據不變的情況下,查詢結果是一樣的。
  • 網易雲信攜手小天才電話手錶 打造視頻通話體驗的行業標杆
    如何通過各種方式實現一對一或者一對多的實時視頻對話功能?如何通過安全而又穩定的網絡傳輸能力確保家長隨時可見,提升兒童在社交過程中的互動體驗感?對於以家長為核心的用戶群體而言,他們需要精準地獲取孩子的位置、周邊環境等信息,並且需要在嘈雜的環境中保證與孩子之間的視頻互動的完整性和有效性,如視頻通話時長要在10分鐘左右、通話音量不能太小等。
  • 網易:潔癖是對我們的誤解
    刻板印象中,網易嚴選、網易雲音樂是網易典型的」美好產品「,似乎更具小眾風格。那網易是不是一家「小而美」的公司呢?或者說,網易有沒有潔癖? 阮良很直接地反駁:潔癖是對我們的誤解。相比之下,網易就顯得有點不那麼「著急」。入局:ToB慢半拍網易雖從2015年也開始布局企業服務,但從組織架構上,直到2019年才正式成立了智慧企業事業部,目前有網易雲信、網易企業郵箱、網易七魚、網易定位、網易互客這五大系列產品。
  • 網易雲信質量數據監控臺重磅發布 助開發者快速排查故障
    如果有可視化的界面,將大大降低溝通成本針對問題反饋流程中的種種難題,網易雲信推出質量數據監控臺,幫助跟蹤用戶的IM消息收發、音視頻通話質量、直播流質量信息,提供端到端、可視化的自助排查工具。發送端上行網絡丟包高;2. 發送端CPU佔用高,無法及時處理3. 接收端CPU佔用高,無法及時處理4.
  • 關於高並發,我想告訴你這些!
    這篇文章,我想結合自己的高並發項目經驗,系統性地總結下高並發需要掌握的知識和實踐思路,希望對你有所幫助。內容分成以下3個部分:高並發意味著大流量,需要運用技術手段抵抗流量的衝擊,這些手段好比操作流量,能讓流量更平穩地被系統所處理,帶給用戶更好的體驗。我們常見的高並發場景有:淘寶的雙11、春運時的搶票、微博大V的熱點新聞等。
  • 網易企業郵箱發布全新slogan「安全穩定 連通世界」
    網易企業郵箱深知這一點,此次slogan升級,堅持保留「安全穩定」,並放在最重要的位置。作為行業領頭羊,網易企業郵箱是這麼承諾的,也是這麼堅守的,從基礎架構到前端應用再到系統運維,每一個環節都用黑科技強力加持:郵件伺服器部署於國家骨幹網點數據中心,架設千萬元災備級冗餘配置,高強度備份機制,防止數據丟失。
  • Oppo百萬級高並發mongodb集群性能數十倍提升優化實踐
    同時整點有大量推送,因此整點並發會更高,mongodb默認的一個請求一個線程這種模式將會嚴重影響系統負載,該默認配置不適合高並發的讀寫應用場景。Mongodb默認網絡線程模型不適合高並發讀寫原因如下:1. 在高並發的情況下,瞬間就會創建大量的線程,例如線上的這個集群,連接數會瞬間增加到 1 萬左右,也就是作業系統需要瞬間創建 1 萬個線程,這樣系統load負載就會很高。2.
  • 高並發編程系列:ConcurrentHashMap的實現原理(JDK1.7和JDK1.8)
    ConcurrentHashMap避免了對全局加鎖改成了局部加鎖操作,這樣就極大地提高了並發環境下的操作速度,由於ConcurrentHashMap在JDK1.7和1.8中的實現非常不同,接下來我們談談JDK在1.7和1.8中的區別。