一、問題背景

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

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

當(dāng)前架構(gòu)圖如下：

圖片

二、問題分析和整體思路

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

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

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

三、解決方案

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

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

一個(gè)典型的 Websocket 握手請(qǐng)求如下：

1.客戶端請(qǐng)求

圖片

2.服務(wù)器回應(yīng)

圖片

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

圖片

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

圖片

改造后架構(gòu)圖如下：

圖片

四、核心實(shí)現(xiàn)

基于spring boot建立websocket連接

圖片

基于spring boot接收 websocket消息

圖片

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

圖片

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

圖片

圖片

圖片

Nginx反向代理配置：

五、性能測(cè)試

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

圖片

給10萬(wàn)個(gè)長(zhǎng)連接同時(shí)發(fā)送一條消息，采用單線程發(fā)送，服務(wù)器發(fā)送完成的平均耗時(shí)在10s左右，如圖所示。

圖片

當(dāng)前的性能指標(biāo)已滿足智慧門診的實(shí)際業(yè)務(wù)場(chǎng)景，可支持未來(lái)的業(yè)務(wù)增長(zhǎng)。

六、產(chǎn)品效果

圖片

七、問題和展望

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

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