長連接網(wǎng)關技術專題(四)：愛奇藝WebSocket實時推送網(wǎng)關技術實踐
本文由愛奇藝技術團隊原創(chuàng)分享，原題《構建通用WebSocket推送網(wǎng)關的設計與實踐》，有優(yōu)化和改動。
1、引言
叢所周之，HTTP協(xié)議是一種無狀態(tài)、基于TCP的請求/響應模式的協(xié)議，即請求只能由客戶端發(fā)起、由服務端進行響應。在大多數(shù)場景，這種請求/響應的Pull模式可以滿足需求。但在某些情形：例如消息推送（IM中最為常見，比如IM的離線消息推送）、實時通知等應用場景，需要實時將數(shù)據(jù)同步到客戶端，這就要求服務端支持主動Push數(shù)據(jù)的能力。
傳統(tǒng)的Web服務端推送技術歷史悠久，經(jīng)歷了短輪詢、長輪詢等階段的發(fā)展（見《新手入門貼：史上最全Web端即時通訊技術原理詳解》），一定程度上能夠解決問題，但也存在著不足，例如時效性、資源浪費等。HTML5標準帶來的WebSocket規(guī)范基本結束了這一局面，成為目前服務端消息推送技術的主流方案。
在系統(tǒng)中集成WebSocket十分簡單，相關討論與資料很豐富。但如何實現(xiàn)一個通用的WebSocket推送網(wǎng)關尚未有成熟的方案。目前的云服務廠商主要關注iOS和安卓等移動端推送，也缺少對WebSocket的支持。本文分享了愛奇藝基于Netty實現(xiàn)WebSocket長連接實時推送網(wǎng)關時的實踐經(jīng)驗總結。
學習交流：
- 即時通訊/推送技術開發(fā)交流5群：215477170?[推薦]
- 移動端IM開發(fā)入門文章：《新手入門一篇就夠：從零開發(fā)移動端IM》
- 開源IM框架源碼：https://github.com/JackJiang2011/MobileIMSDK
（本文同步發(fā)布于：http://www.52im.net/thread-3539-1-1.html）
2、專題目錄
本文是系列文章的第4篇，總目錄如下：
《長連接網(wǎng)關技術專題(一)：京東京麥的生產(chǎn)級TCP網(wǎng)關技術實踐總結》
《長連接網(wǎng)關技術專題(二)：知乎千萬級并發(fā)的高性能長連接網(wǎng)關技術實踐》
《長連接網(wǎng)關技術專題(三)：手淘億級移動端接入層網(wǎng)關的技術演進之路》
《長連接網(wǎng)關技術專題(四)：愛奇藝WebSocket實時推送網(wǎng)關技術實踐》（* 本文）
其它相關技術文章：
《絕對干貨：基于Netty實現(xiàn)海量接入的推送服務技術要點》
《京東到家基于Netty的WebSocket應用實踐分享》
愛奇藝技術團隊分享的其它文章：
《愛奇藝技術分享：輕松詼諧，講解視頻編解碼技術的過去、現(xiàn)在和將來》
《愛奇藝技術分享：愛奇藝Android客戶端啟動速度優(yōu)化實踐總結》
《愛奇藝移動端網(wǎng)絡優(yōu)化實踐分享：網(wǎng)絡請求成功率優(yōu)化篇》
3、舊方案存在的技術痛點
愛奇藝號是我們內(nèi)容生態(tài)的重要組成，作為前臺系統(tǒng)，對用戶體驗有較高要求，直接影響著創(chuàng)作者的創(chuàng)作熱情。
目前，愛奇藝號多個業(yè)務場景中用到了WebSocket實時推送技術，包括：
1）用戶評論：實時的將評論消息推送到瀏覽器；
2）實名認證：合同簽署前需要對用戶進行實名認證，用戶掃描二維碼后進入第三方的認證頁面，認證完成后異步通知瀏覽器認證的狀態(tài)；
3）活體識別：類似實名認證，當活體識別完成后，異步將結果通知瀏覽器。
在實際的業(yè)務開發(fā)中，我們發(fā)現(xiàn)，WebSocket實時推送技術在使用中存在一些問題。
這些問題是：
1）首先：WebSocket技術棧不統(tǒng)一，既有基于Netty實現(xiàn)的，也有基于Web容器實現(xiàn)的，給開發(fā)和維護帶來困難；
2）其次：WebSocket實現(xiàn)分散在在各個工程中，與業(yè)務系統(tǒng)強耦合，如果有其他業(yè)務需要集成WebSocket，面臨著重復開發(fā)的窘境，浪費成本、效率低下；
3）第三：WebSocket是有狀態(tài)協(xié)議的，客戶端連接服務器時只和集群中一個節(jié)點連接，數(shù)據(jù)傳輸過程中也只與這一節(jié)點通信。WebSocket集群需要解決會話共享的問題。如果只采用單節(jié)點部署，雖然可以避免這一問題，但無法水平擴展支撐更高負載，有單點的風險；
4）最后：缺乏監(jiān)控與報警，雖然可以通過Linux的Socket連接數(shù)大致評估WebSocket長連接數(shù)，但數(shù)字并不準確，也無法得知用戶數(shù)等具有業(yè)務含義的指標數(shù)據(jù)；無法與現(xiàn)有的微服務監(jiān)控整合，實現(xiàn)統(tǒng)一監(jiān)控和報警。
PS：限于篇幅本文不詳細介紹WebSocket技術本身，有興趣可以詳讀《WebSocket從入門到精通，半小時就夠！》。
4、新方案的技術目標
如上節(jié)所示，為了解決舊方案中存在的問題，我們需要實現(xiàn)統(tǒng)一的WebSocket長連接實時推送網(wǎng)關。
這套新的網(wǎng)關需要具備如下特點：
1）集中實現(xiàn)長連接管理和推送能力：統(tǒng)一技術棧，將長連接作為基礎能力沉淀，便于功能迭代和升級維護；
2）與業(yè)務解耦：將業(yè)務邏輯與長連接通信分離，使業(yè)務系統(tǒng)不再關心通信細節(jié)，也避免了重復開發(fā)，浪費研發(fā)成本；
3）使用簡單：提供HTTP推送通道，方便各種開發(fā)語言的接入。業(yè)務系統(tǒng)只需要簡單的調用，就可以實現(xiàn)數(shù)據(jù)推送，提升研發(fā)效率；
4）分布式架構：實現(xiàn)多節(jié)點的集群，支持水平擴展應對業(yè)務增長帶來的挑戰(zhàn)；節(jié)點宕機不影響服務整體可用性，保證高可靠；
5）多端消息同步：允許用戶使用多個瀏覽器或標簽頁同時登陸在線，保證消息同步發(fā)送；
6）多維度監(jiān)控與報警：自定義監(jiān)控指標與現(xiàn)有微服務監(jiān)控系統(tǒng)打通，出現(xiàn)問題時可及時報警，保證服務的穩(wěn)定性。
5、新方案的技術選型
在眾多的WebSocket實現(xiàn)中，從性能、擴展性、社區(qū)支持等方面考慮，最終選擇了Netty。Netty是一個高性能、事件驅動、異步非阻塞的網(wǎng)絡通信框架，在許多知名的開源軟件中被廣泛使用。
PS：如果你對Netty知之甚少，可以詳讀以下兩篇：
《史上最通俗Netty入門長文：基本介紹、環(huán)境搭建、動手實戰(zhàn)》
《新手入門：目前為止最透徹的的Netty高性能原理和框架架構解析》
WebSocket是有狀態(tài)的，無法像直接HTTP以集群方式實現(xiàn)負載均衡，長連接建立后即與服務端某個節(jié)點保持著會話，因此集群下想要得知會話屬于哪個節(jié)點有點困難。
解決以上問題一般有兩種技術方案：
1）一種是使用類似微服務的注冊中心來維護全局的會話映射關系；
2）一種是使用事件廣播由各節(jié)點自行判斷是否持有會話，兩種方案對比如下表所示。
WebSocket集群方案：
綜合考慮實現(xiàn)成本與集群規(guī)模，選擇了輕量級的事件廣播方案。
實現(xiàn)廣播可以選擇基于RocketMQ的消息廣播、基于Redis的Publish/Subscribe、基于ZooKeeper的通知等方案，其優(yōu)缺點對比如下表所示。從吞吐量、實時性、持久化、實現(xiàn)難易等方面考慮，最終選擇了RocketMQ。
廣播的實現(xiàn)方案對比：
6、新方案的實現(xiàn)思路
6.1 系統(tǒng)架構
網(wǎng)關的整體架構如下圖所示：
網(wǎng)關的整體流程如下：
1）客戶端與網(wǎng)關任一節(jié)點握手建立起長連接，節(jié)點將其加入到內(nèi)存維護的長連接隊列?？蛻舳硕〞r向服務端發(fā)送心跳消息，如果超過設定的時間仍沒有收到心跳，則認為客戶端與服務端的長連接已斷開，服務端會關閉連接，清理內(nèi)存中的會話。
2）當業(yè)務系統(tǒng)需要向客戶端推送數(shù)據(jù)時，通過網(wǎng)關提供的HTTP接口將數(shù)據(jù)發(fā)向網(wǎng)關。
3）網(wǎng)關在接收到推送請求后，將消息寫入RocketMQ。
4）網(wǎng)關作為消費者，以廣播模式消費消息，所有節(jié)點都會接收到消息。
5）節(jié)點接收到消息后判斷推送的消息目標是否在自己內(nèi)存中維護的長連接隊列里，如果存在則通過長連接推送數(shù)據(jù)，否則直接忽略。
網(wǎng)關以多節(jié)點方式構成集群，每節(jié)點負責一部分長連接，可實現(xiàn)負載均衡，當面對海量連接時，也可以通過增加節(jié)點的方式分擔壓力，實現(xiàn)水平擴展。
同時，當節(jié)點出現(xiàn)宕機時，客戶端會嘗試重新與其他節(jié)點握手建立長連接，保證服務整體的可用性。
6.2 會話管理
WebSocket長連接建立起來后，會話維護在各節(jié)點的內(nèi)存中。SessionManager組件負責管理會話，內(nèi)部使用了哈希表維護了UID與UserSession的關系。
UserSession代表用戶維度的會話，一個用戶可能會同時建立多個長連接，因此UserSession內(nèi)部同樣使用了一個哈希表維護Channel與ChannelSession的關系。
為了避免用戶無限制的創(chuàng)建長連接，UserSession在內(nèi)部的ChannelSession超過一定數(shù)量后，會將最早建立的ChannelSession關閉，減少服務器資源占用。SessionManager、UserSession、ChannelSession的關系如下圖所示。
SessionManager組件：
6.3 監(jiān)控與報警
為了了解集群建立了多少長連接、包含了多少用戶，網(wǎng)關提供了基本的監(jiān)控與報警能力。
網(wǎng)關接入了Micrometer，將連接數(shù)與用戶數(shù)作為自定義指標暴露，供Prometheus進行采集，實現(xiàn)了與現(xiàn)有的微服務監(jiān)控系統(tǒng)打通。
在Grafana中方便地查看連接數(shù)、用戶數(shù)、JVM、CPU、內(nèi)存等指標數(shù)據(jù)，了解網(wǎng)關當前的服務能力與壓力。報警規(guī)則也可以在Grafana中配置，當數(shù)據(jù)異常時觸發(fā)奇信（內(nèi)部報警平臺）報警。
7、新方案的性能壓測
壓測準備：
1）壓測選擇兩臺配置為4核16G的虛擬機，分別作為服務器和客戶端；
2）壓測時選擇為網(wǎng)關開放了20個端口，同時建立20個客戶端；
3）每個客戶端使用一個服務端端口建立起5萬連接，可以同時創(chuàng)建百萬個連接。
連接數(shù)（百萬級）與內(nèi)存使用情況如下圖所示：
給百萬個長連接同時發(fā)送一條消息，采用單線程發(fā)送，服務器發(fā)送完成的平均耗時在10s左右，如下圖所示。
服務器推送耗時：?
一般同一用戶同時建立的長連接都在個位數(shù)。以10個長連接為例，在并發(fā)數(shù)600、持續(xù)時間120s條件下壓測，推送接口的TPS大約在1600+，如下圖所示。
長連接10、并發(fā)600、持續(xù)時間120s的壓測數(shù)據(jù)：
當前的性能指標已滿足我們的實際業(yè)務場景，可支持未來的業(yè)務增長。
8、新方案的實際應用案例
為了更生動的說明優(yōu)化效果，文章最后，我們也以封面圖添加濾鏡效果為例，介紹一個愛奇藝號使用新WebSocket網(wǎng)關方案的案例。
愛奇藝號自媒體發(fā)表視頻時，可選擇為封面圖添加濾鏡效果，引導用戶提供提供更優(yōu)質的封面。
當用戶選擇一個封面圖后，會提交異步的后臺處理任務。當異步任務處理完成后，通過WebSocket將不同濾鏡效果處理后的圖片返回給瀏覽器，業(yè)務場景如下圖所示。
從研發(fā)效率方面考慮，如果在業(yè)務系統(tǒng)中集成WebSocket，至少需要1-2天的開發(fā)時間。
如果直接使用新的WebSocket網(wǎng)關的推送能力，只需要簡單的接口調用就實現(xiàn)了數(shù)據(jù)推送，開發(fā)時間降低到分鐘級別，研發(fā)效率大大提高。
從運維成本方面考慮，業(yè)務系統(tǒng)不再含有與業(yè)務邏輯無關的通信細節(jié)，代碼的可維護性更強，系統(tǒng)架構變得更加簡單，運維成本大大降低。
9、寫在最后
WebSocket是目前實現(xiàn)服務端推送的主流技術，恰當使用能夠有效提供系統(tǒng)響應能力，提升用戶體驗。通過WebSocket長連接網(wǎng)關可以快速為系統(tǒng)增加數(shù)據(jù)推送能力，有效減少運維成本，提高開發(fā)效率。
長連接網(wǎng)關的價值在于：
1）它封裝了WebSocket通信細節(jié)，與業(yè)務系統(tǒng)解耦，使得長連接網(wǎng)關與業(yè)務系統(tǒng)可獨立優(yōu)化迭代，避免重復開發(fā)，便于開發(fā)與維護；
2）網(wǎng)關提供了簡單易用的HTTP推送通道，支持多種開發(fā)語言接入，便于系統(tǒng)集成和使用；
3）網(wǎng)關采用了分布式架構，可以實現(xiàn)服務的水平擴容、負載均衡與高可用；
4）網(wǎng)關集成了監(jiān)控與報警，當系統(tǒng)異常時能及時預警，保證服務的健康和穩(wěn)定。
目前，新的WebSocket長連接實時網(wǎng)關已在愛奇藝號圖片濾鏡結果通知、MCN電子簽章等多個業(yè)務場景中得到應用。
未來還有許多方面需要探索，例如消息的重發(fā)與ACK、WebSocket二進制數(shù)據(jù)的支持、多租戶的支持等。
附錄：更多相關技術資料
[1] 有關WEB端即時通訊開發(fā)：
《新手入門貼：史上最全Web端即時通訊技術原理詳解》
《Web端即時通訊技術盤點：短輪詢、Comet、Websocket、SSE》
《SSE技術詳解：一種全新的HTML5服務器推送事件技術》
《Comet技術詳解：基于HTTP長連接的Web端實時通信技術》
《新手快速入門：WebSocket簡明教程》
《WebSocket詳解（一）：初步認識WebSocket技術》
《WebSocket詳解（二）：技術原理、代碼演示和應用案例》
《WebSocket詳解（三）：深入WebSocket通信協(xié)議細節(jié)》
《WebSocket詳解（四）：刨根問底HTTP與WebSocket的關系(上篇)》
《WebSocket詳解（五）：刨根問底HTTP與WebSocket的關系(下篇)》
《WebSocket詳解（六）：刨根問底WebSocket與Socket的關系》
《socket.io實現(xiàn)消息推送的一點實踐及思路》
《LinkedIn的Web端即時通訊實踐：實現(xiàn)單機幾十萬條長連接》
《Web端即時通訊技術的發(fā)展與WebSocket、Socket.io的技術實踐》
《Web端即時通訊安全：跨站點WebSocket劫持漏洞詳解(含示例代碼)》
《開源框架Pomelo實踐：搭建Web端高性能分布式IM聊天服務器》
《使用WebSocket和SSE技術實現(xiàn)Web端消息推送》
《詳解Web端通信方式的演進：從Ajax、JSONP 到 SSE、Websocket》
《MobileIMSDK-Web的網(wǎng)絡層框架為何使用的是Socket.io而不是Netty？》
《理論聯(lián)系實際：從零理解WebSocket的通信原理、協(xié)議格式、安全性》
《微信小程序中如何使用WebSocket實現(xiàn)長連接(含完整源碼)》
《八問WebSocket協(xié)議：為你快速解答WebSocket熱門疑問》
《Web端即時通訊實踐干貨：如何讓你的WebSocket斷網(wǎng)重連更快速？》
《WebSocket從入門到精通，半小時就夠！》
《WebSocket硬核入門：200行代碼，教你徒手擼一個WebSocket服務器》
>>?更多同類文章 ……
[2] 有關推送技術的文章：
《一個基于MQTT通信協(xié)議的完整Android推送Demo》
《求教android消息推送：GCM、XMPP、MQTT三種方案的優(yōu)劣》
《移動端實時消息推送技術淺析》
《絕對干貨：基于Netty實現(xiàn)海量接入的推送服務技術要點》
《極光推送系統(tǒng)大規(guī)模高并發(fā)架構的技術實踐分享》
《魅族2500萬長連接的實時消息推送架構的技術實踐分享》
《專訪魅族架構師：海量長連接的實時消息推送系統(tǒng)的心得體會》
《基于WebSocket實現(xiàn)Hybrid移動應用的消息推送實踐(含代碼示例)》
《一個基于長連接的安全可擴展的訂閱/推送服務實現(xiàn)思路》
《實踐分享：如何構建一套高可用的移動端消息推送系統(tǒng)？》
《Go語言構建千萬級在線的高并發(fā)消息推送系統(tǒng)實踐(來自360公司)》
《騰訊信鴿技術分享：百億級實時消息推送的實戰(zhàn)經(jīng)驗》
《百萬在線的美拍直播彈幕系統(tǒng)的實時推送技術實踐之路》
《京東京麥商家開放平臺的消息推送架構演進之路》
《技術干貨：從零開始，教你設計一個百萬級的消息推送系統(tǒng)》
《長連接網(wǎng)關技術專題(四)：愛奇藝WebSocket實時推送網(wǎng)關技術實踐》
>>?更多同類文章 ……
本文已同步發(fā)布于“即時通訊技術圈”公眾號。
▲ 本文在公眾號上的鏈接是：點此進入。同步發(fā)布鏈接是：http://www.52im.net/thread-3539-1-1.html
