1、問題背景

智慧門診系統(tǒng)旨在從一定程度上解決患者面臨的三長一短（掛號、看病、取藥時間長，醫(yī)生問診時間短）的問題。實現(xiàn)“診前、診中、診后”實時智能一體化，整合完善醫(yī)院工作流程。圍繞門診看病的各個環(huán)節(jié)，讓患者全程手機有提醒，讓患者少排隊、少跑腿、看病更簡單，獲得全流程的陪伴服務從而有效提升就醫(yī)體驗。

系統(tǒng)通過接收醫(yī)院第三方系統(tǒng)推送的門診數(shù)據(jù)，再結合業(yè)務服務處理后主動推送到前端，從而實時的將數(shù)據(jù)同步給患者手機。之所以沒有采用傳統(tǒng)的前端輪訓方案，主要是在當前業(yè)務場景下存在時效性不足，資源浪費等問題。但與此同時也有代價的，相比于Http的無狀態(tài)通信，服務端主動推送是有狀態(tài)協(xié)議的，客戶端連接服務器時只和集群中一個節(jié)點連接，數(shù)據(jù)傳輸過程中也只與這一節(jié)點通信，在集群多臺服務器環(huán)境下，我們就出現(xiàn)了服務端部分消息推送丟失的現(xiàn)象。

當前架構圖如下：

圖片

2、問題分析和整體思路

客戶端和服務端每次建立連接時候，會創(chuàng)建有狀態(tài)的會話Session，服務器得保存維持連接的Session?？蛻舳嗣看沃荒芎图悍掌髌渲械囊粋€服務器連接，后續(xù)也是和該服務器進行數(shù)據(jù)傳輸。因此集群的問題，應該考慮Session的問題，客戶端成功連接服務器之后，其他服務器也知道客戶端連接成功。

可以使用Nginx負載均衡的ip hash算法，客戶端每次都是請求同一個服務器，客戶端的session都保存在該服務器上，而后續(xù)請求都是請求該服務器，都能獲取到session，就不存在分布式session問題了。websocket相對http來說，可以由服務端主動推動消息給客戶端，如果接收消息的服務端和發(fā)送消息消息的服務端不是同一個服務端，發(fā)送消息的服務端無法找到接收消息對應的session，即兩個session不處于同一個服務端，也就無法推送消息。

解決問題的方法是將所有消息的發(fā)送方和接收方都處于同一個服務器下，而消息發(fā)送方和接收方都是不確定的，顯然是無法實現(xiàn)的。將消息的發(fā)送方和接收方都處于同一個服務器下才能發(fā)送消息，那么可以轉(zhuǎn)換一下思路，可以將消息以消息廣播的方式通知給所有的服務器，可以使用消息中間件發(fā)布訂閱模式，消息脫離了服務器的限制，通過發(fā)送到中間件，再發(fā)送給訂閱的服務器，類似廣播一樣，只要訂閱了消息，都能接收到消息的通知。

3、解決方案

WebSocket協(xié)議是基于TCP的一種新的網(wǎng)絡協(xié)議，是一個應用層協(xié)議，是 HTML5 提供的一種在單個 TCP 連接上進行全雙工通訊的協(xié)議，與 TCP 一樣，客戶端和服務器都可以隨時向?qū)Ψ桨l(fā)送數(shù)據(jù)，而不用像 HTTP請求 - 應答”通信模式。于是，服務器就可以變得更加“主動”了。一旦后臺有新的數(shù)據(jù)，就可以立即“推送”給客戶端，不需要客戶端輪詢，“實時通信”的效率也就提高了。

瀏覽器是一個“沙盒”環(huán)境，有很多的限制，不允許建立 TCP 連接收發(fā)數(shù)據(jù)，而WebSocket利用了 HTTP 本身的“協(xié)議升級”特性，“偽裝”成 HTTP，這樣就能繞過瀏覽器沙盒、與服務器直接建立“TCP 連接”，獲得更多的自由。

一個典型的 Websocket 握手請求如下：

客戶端請求

圖片

服務器回應

圖片

WebSocket是有狀態(tài)的，無法像直接HTTP以集群方式實現(xiàn)負載均衡，長連接建立后即與服務端某個節(jié)點保持著會話，因此集群下想要得知會話屬于哪個節(jié)點，有兩種方案，一種是使用類似微服務的注冊中心來維護全局的會話映射關系，一種是使用事件廣播由各節(jié)點自行判斷是否持有會話，兩種方案對比如表所示。

圖片

綜合考慮實現(xiàn)成本與集群規(guī)模，選擇了輕量級的事件廣播方案。實現(xiàn)廣播可以選擇基于RocketMQ的消息廣播、基于Redis的Publish/Subscribe、基于服務的通知等方案，其優(yōu)缺點對比如表所示。從實時性、實現(xiàn)難易等方面考慮，同時對于持久化高可靠級別并沒有太高要求，最終選擇了Redis。

圖片

改造后架構圖如下：

圖片

3、核心實現(xiàn)

基于spring boot建立websocket連接

圖片

基于spring boot接收 websocket消息

圖片

基于spring boot發(fā)布和訂閱Redis消息

圖片

vue前端websocket建立連接、心跳檢測、發(fā)送消息、消息訂閱等

圖片

圖片

圖片

Nginx反向代理配置

圖片

4、性能測試

性能壓測選擇兩臺配置為2核16G的虛擬機，分別作為服務器和客戶端。壓測時選擇為網(wǎng)關開放了5個端口，同時建立5個客戶端，每個客戶端使用一個服務端端口建立起2萬連接，可以同時創(chuàng)建10萬個連接。連接數(shù)與內(nèi)存使用情況如圖所示。

圖片

給10萬個長連接同時發(fā)送一條消息，采用單線程發(fā)送，服務器發(fā)送完成的平均耗時在10s左右，如圖所示。

圖片

當前的性能指標已滿足智慧門診的實際業(yè)務場景，可支持未來的業(yè)務增長。

5、產(chǎn)品效果

圖片

6、問題和展望

當前WebSocket實現(xiàn)分散在在各個服務中，與業(yè)務系統(tǒng)強耦合，如果有其他業(yè)務需要集成WebSocket，面臨著重復開發(fā)的窘境，浪費成本、效率低下。后續(xù)建議在網(wǎng)關中擴展統(tǒng)一集成管理websocket，能夠具備以下特點：

• 集中實現(xiàn)長連接管理和推送能力。統(tǒng)一技術棧，將長連接作為基礎能力沉淀，便于功能迭代和升級維護。
• 與業(yè)務解耦。將業(yè)務邏輯與長連接通信分離，使業(yè)務系統(tǒng)不再關心通信細節(jié)，也避免了重復開發(fā)，浪費研發(fā)成本。
• 使用簡單。提供HTTP推送通道，方便各種開發(fā)語言的接入。業(yè)務系統(tǒng)只需要簡單的調(diào)用，就可以實現(xiàn)數(shù)據(jù)推送，提升研發(fā)效率。
• 分布式架構。實現(xiàn)多節(jié)點的集群，支持水平擴展應對業(yè)務增長帶來的挑戰(zhàn)；節(jié)點宕機不影響服務整體可用性，保證高可靠。
• 多端消息同步。允許用戶使用多個瀏覽器或標簽頁同時登陸在線，保證消息同步發(fā)送。
• 多維度監(jiān)控與報警。自定義監(jiān)控指標與現(xiàn)有微服務監(jiān)控系統(tǒng)打通，出現(xiàn)問題時可及時報警，保證服務的穩(wěn)定性。