SpringBoot生產(chǎn)級WebSocket集群實踐，支持10萬連接！
1、問題背景
智慧門診系統(tǒng)旨在從一定程度上解決患者面臨的三長一短（掛號、看病、取藥時間長，醫(yī)生問診時間短）的問題。實現(xiàn)“診前、診中、診后”實時智能一體化，整合完善醫(yī)院工作流程。圍繞門診看病的各個環(huán)節(jié)，讓患者全程手機(jī)有提醒，讓患者少排隊、少跑腿、看病更簡單，獲得全流程的陪伴服務(wù)從而有效提升就醫(yī)體驗。
系統(tǒng)通過接收醫(yī)院第三方系統(tǒng)推送的門診數(shù)據(jù)，再結(jié)合業(yè)務(wù)服務(wù)處理后主動推送到前端，從而實時的將數(shù)據(jù)同步給患者手機(jī)。之所以沒有采用傳統(tǒng)的前端輪訓(xùn)方案，主要是在當(dāng)前業(yè)務(wù)場景下存在時效性不足，資源浪費等問題。但與此同時也有代價的，相比于Http的無狀態(tài)通信，服務(wù)端主動推送是有狀態(tài)協(xié)議的，客戶端連接服務(wù)器時只和集群中一個節(jié)點連接，數(shù)據(jù)傳輸過程中也只與這一節(jié)點通信，在集群多臺服務(wù)器環(huán)境下，我們就出現(xiàn)了服務(wù)端部分消息推送丟失的現(xiàn)象。
當(dāng)前架構(gòu)圖如下：
圖片
2、問題分析和整體思路
客戶端和服務(wù)端每次建立連接時候，會創(chuàng)建有狀態(tài)的會話Session，服務(wù)器得保存維持連接的Session。客戶端每次只能和集群服務(wù)器其中的一個服務(wù)器連接，后續(xù)也是和該服務(wù)器進(jìn)行數(shù)據(jù)傳輸。因此集群的問題，應(yīng)該考慮Session的問題，客戶端成功連接服務(wù)器之后，其他服務(wù)器也知道客戶端連接成功。
可以使用Nginx負(fù)載均衡的ip hash算法，客戶端每次都是請求同一個服務(wù)器，客戶端的session都保存在該服務(wù)器上，而后續(xù)請求都是請求該服務(wù)器，都能獲取到session，就不存在分布式session問題了。websocket相對http來說，可以由服務(wù)端主動推動消息給客戶端，如果接收消息的服務(wù)端和發(fā)送消息消息的服務(wù)端不是同一個服務(wù)端，發(fā)送消息的服務(wù)端無法找到接收消息對應(yīng)的session，即兩個session不處于同一個服務(wù)端，也就無法推送消息。
解決問題的方法是將所有消息的發(fā)送方和接收方都處于同一個服務(wù)器下，而消息發(fā)送方和接收方都是不確定的，顯然是無法實現(xiàn)的。將消息的發(fā)送方和接收方都處于同一個服務(wù)器下才能發(fā)送消息，那么可以轉(zhuǎn)換一下思路，可以將消息以消息廣播的方式通知給所有的服務(wù)器，可以使用消息中間件發(fā)布訂閱模式，消息脫離了服務(wù)器的限制，通過發(fā)送到中間件，再發(fā)送給訂閱的服務(wù)器，類似廣播一樣，只要訂閱了消息，都能接收到消息的通知。
3、解決方案
WebSocket協(xié)議是基于TCP的一種新的網(wǎng)絡(luò)協(xié)議，是一個應(yīng)用層協(xié)議，是 HTML5 提供的一種在單個 TCP 連接上進(jìn)行全雙工通訊的協(xié)議，與 TCP 一樣，客戶端和服務(wù)器都可以隨時向?qū)Ψ桨l(fā)送數(shù)據(jù)，而不用像 HTTP請求 - 應(yīng)答”通信模式。于是，服務(wù)器就可以變得更加“主動”了。一旦后臺有新的數(shù)據(jù)，就可以立即“推送”給客戶端，不需要客戶端輪詢，“實時通信”的效率也就提高了。
瀏覽器是一個“沙盒”環(huán)境，有很多的限制，不允許建立 TCP 連接收發(fā)數(shù)據(jù)，而WebSocket利用了 HTTP 本身的“協(xié)議升級”特性，“偽裝”成 HTTP，這樣就能繞過瀏覽器沙盒、與服務(wù)器直接建立“TCP 連接”，獲得更多的自由。
一個典型的 Websocket 握手請求如下：
- 客戶端請求
圖片
- 服務(wù)器回應(yīng)
圖片
WebSocket是有狀態(tài)的，無法像直接HTTP以集群方式實現(xiàn)負(fù)載均衡，長連接建立后即與服務(wù)端某個節(jié)點保持著會話，因此集群下想要得知會話屬于哪個節(jié)點，有兩種方案，一種是使用類似微服務(wù)的注冊中心來維護(hù)全局的會話映射關(guān)系，一種是使用事件廣播由各節(jié)點自行判斷是否持有會話，兩種方案對比如表所示。
圖片
綜合考慮實現(xiàn)成本與集群規(guī)模，選擇了輕量級的事件廣播方案。實現(xiàn)廣播可以選擇基于RocketMQ的消息廣播、基于Redis的Publish/Subscribe、基于服務(wù)的通知等方案，其優(yōu)缺點對比如表所示。從實時性、實現(xiàn)難易等方面考慮，同時對于持久化高可靠級別并沒有太高要求，最終選擇了Redis。
圖片
改造后架構(gòu)圖如下：
圖片
4、核心實現(xiàn)
基于spring boot建立websocket連接
圖片
基于spring boot接收 websocket消息
圖片
基于spring boot發(fā)布和訂閱Redis消息
圖片
vue前端websocket建立連接、心跳檢測、發(fā)送消息、消息訂閱等
圖片
圖片
圖片
Nginx反向代理配置
圖片
5、性能測試
性能壓測選擇兩臺配置為2核16G的虛擬機(jī)，分別作為服務(wù)器和客戶端。壓測時選擇為網(wǎng)關(guān)開放了5個端口，同時建立5個客戶端，每個客戶端使用一個服務(wù)端端口建立起2萬連接，可以同時創(chuàng)建10萬個連接。連接數(shù)與內(nèi)存使用情況如圖所示。
圖片
給10萬個長連接同時發(fā)送一條消息，采用單線程發(fā)送，服務(wù)器發(fā)送完成的平均耗時在10s左右，如圖所示。
圖片
當(dāng)前的性能指標(biāo)已滿足智慧門診的實際業(yè)務(wù)場景，可支持未來的業(yè)務(wù)增長。
6、產(chǎn)品效果
圖片
7、問題和展望
當(dāng)前WebSocket實現(xiàn)分散在在各個服務(wù)中，與業(yè)務(wù)系統(tǒng)強(qiáng)耦合，如果有其他業(yè)務(wù)需要集成WebSocket，面臨著重復(fù)開發(fā)的窘境，浪費成本、效率低下。后續(xù)建議在網(wǎng)關(guān)中擴(kuò)展統(tǒng)一集成管理websocket，能夠具備以下特點：
- 集中實現(xiàn)長連接管理和推送能力。統(tǒng)一技術(shù)棧，將長連接作為基礎(chǔ)能力沉淀，便于功能迭代和升級維護(hù)。
- 與業(yè)務(wù)解耦。將業(yè)務(wù)邏輯與長連接通信分離，使業(yè)務(wù)系統(tǒng)不再關(guān)心通信細(xì)節(jié)，也避免了重復(fù)開發(fā)，浪費研發(fā)成本。
- 使用簡單。提供HTTP推送通道，方便各種開發(fā)語言的接入。業(yè)務(wù)系統(tǒng)只需要簡單的調(diào)用，就可以實現(xiàn)數(shù)據(jù)推送，提升研發(fā)效率。
- 分布式架構(gòu)。實現(xiàn)多節(jié)點的集群，支持水平擴(kuò)展應(yīng)對業(yè)務(wù)增長帶來的挑戰(zhàn)；節(jié)點宕機(jī)不影響服務(wù)整體可用性，保證高可靠。
- 多端消息同步。允許用戶使用多個瀏覽器或標(biāo)簽頁同時登陸在線，保證消息同步發(fā)送。
- 多維度監(jiān)控與報警。自定義監(jiān)控指標(biāo)與現(xiàn)有微服務(wù)監(jiān)控系統(tǒng)打通，出現(xiàn)問題時可及時報警，保證服務(wù)的穩(wěn)定性。
