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