搭建websocket消息推送服務，必須要考慮的幾個問題

近年，不論是正在快速增長的直播，遠端教育以及IM聊天場景，還是在正常企業級系統中用到的系統提醒，對websocket的需求越來越大，對websocket的要求也越來越高。從早期對websocket的應用僅限于少部分功能和IM等特殊場景，逐漸發展為追求支援高并發，百萬、千萬級每秒通訊的高可用websocket服務。

面對各種新場景對websocket功能和性能越來越高的需求，不同的團隊有不同的選擇，有的直接使用由專業團隊開發的成熟穩定的第三方websocket服務，有些則選擇自建websocket服務。

作為一個具有多年websocket開發經驗的老程式猿，經曆了GoEasy企業級websocket服務從無到有，從小到大的過程，此文是根據過去幾年在GoEasy開發過程中踩過的坑，以及為衆多開發團隊提供websocket服務、與衆多開發者交流中的總結的一些經驗和體會。

這次主要從搭建websocket服務的基本功能和特性方面做一些分享，下次有機會再從建構一個高可用websocket時要面對的高并發，海量消息，叢集容災，橫向擴充，以及自動化運維等方面進更多的分享。

以下幾點是個人認為在建構websocket服務時必須要考慮的一些技術特性以及能顯著提高使用者體驗的功能，供各位同學參考：

1.建立心跳機制

心跳機制幾乎是所有網絡程式設計的第一步，經常容易被新手忽略。因為在websocket長連接配接中，用戶端和服務端并不會一直通信，如果雙方長期沒有溝通則都不清楚彼此目前狀态，是以需要發送一段很小的封包告訴對方“我還活着”。另外還有兩個目的：

服務端檢測到某個用戶端遲遲沒有心跳過來可以主動關閉通道，讓它下線；

用戶端檢測到某個服務端遲遲沒有響應心跳也能重連擷取一個新的連接配接。

2.建立具有良好相容性的用戶端SDK

雖說現在主流浏覽器都支援websocket，但在編碼中還是會遇到浏覽器相容性問題，而且通過websocket通信的用戶端早已不僅限于各種web浏覽器，還包括越來越多的APP，小程式。是以就要求建構的websocket服務必須能夠很友好的支援各種用戶端。最好的方式就是建構一個能夠相容所有主流浏覽器、小程式和APP，以及uni-app、vue、react-native等目前常見的各種前端架構的用戶端SDK，這樣不論公司的各個項目使用什麼樣的前端技術，都能夠快速的內建websocket服務。

3.斷網自動重連和消息補發機制

移動網際網路時代，終端使用者所處的網絡環境多樣且複雜，如使用者進出電梯，出入地下室或地鐵等網絡不穩定的場所，或其他原因導緻的網絡不穩定都是很常見的場景。是以，一個可靠的websocket服務必須具備完善的斷網自動重連機制。確定斷網後，網絡一旦恢複，能第一時間自動重建立立長連接配接，并且能夠立即補發在網絡不穩定期間發送的消息。

4.離線消息

基礎的Websocket通訊從技術上來說，消息送達的前提條件就是建立起一個長連接配接，沒有建立網絡連接配接就來讨論通訊那是耍流氓。但是從使用者的角度上來說，随手關閉浏覽器，或者将小程式、APP程序直接殺掉而導緻網絡連接配接斷開的情況是随時都在發生的。然後我們下意識的期待，就是我下次打開浏覽器通路網頁，或者打開APP時，能夠收到使用者離開系統期間的所有資訊。從技術上這是一個跟websocket沒有多大關系的需求，但實際上卻是websocket服務不可或缺的基本特性，也是一個能夠極大提升使用者體驗的功能。

5.上下線提醒，用戶端線上清單

掌握目前系統有哪些使用者線上，捕捉使用者上下線事件，是搭建一個企業級websocket服務，必不可少的特性，尤其是開發IM和遊戲類産品。

6.支援曆史消息查詢

websocket服務，某種意義也是屬于一個消息系統，對于曆史消息的查詢需求，是無法繞開的話題。比如IM系統中常見的曆史消息，是以在websocket服務内部實作一個高速，可靠的消息隊列機制來支援websocket服務實作曆史消息的查詢就是一個必須的工作。

7.消息的壓縮機制

不論是為了保證消息通訊的速度和實時性，還是為了節約流量和帶寬費用，或者是出于提高網卡的使用效率和增加系統的吞吐量，在通訊過程中對消息進行必要的壓縮都是必不可少的。

除了需要考慮以上七點以外，筆者認為，還有幾個問題也是很值得初學者積極關注的：

1.緩存和持久化

選擇合适的消息緩存機制，是企業級websocket服務保證性能必須要考慮的問題。

2.異步調用

要支援大量消息通訊的高性能系統，必然推薦異步調用。若設計為同步調用，調用方就需要一直等待被調用方完成。如果一層一層的同步調用下去，所有的調用方需要相同的等待時間，調用方的資源會被大量的浪費。更糟糕的是一旦被調用方出問題，其他調用就會出現多米諾骨牌效應跟着出問題，導緻故障蔓延。收到請求立即傳回結果，然後再異步執行，不僅可以增加系統的吞吐量，最大的好處是讓服務之間的解耦更為徹底。

3.獨立于業務和标準化

盡管在一個web項目中可以同時存在正常http服務和websocket服務，尤其對性能要求不高的單應用web系統，這種方式更簡單，更便于維護。但對于性能和可用性高的企業級系統或者網際網路平台，更好的方式，是将websocket服務作為一個單獨的微服務來進行設計，避免和正常的http服務搶占資源，導緻系統性能不可控，同時也更便于橫向擴充。

一個設計良好的企業級websocket服務應該是一個獨立于業務系統、标準化的單獨存在的技術性微服務，能夠作為公司基礎架構的一部分為公司的所有項目提供通訊服務。

4.幂等性和重複消息的過濾

所謂幂等性，就是一次和多次請求一個接口都應該具有同樣的後果。為什麼需要？對每個接口的調用都會有三種可能的結果：成功，失敗和逾時。對最後一種的原因很多可能是網絡丢包，可能請求沒有到達，也有可能傳回沒有收到。于是在對接口的調用時往往都會有重試機制，但重試機制很容易導緻消息的重複發送，從使用者層面這往往是不可接受的，是以在接口的設計時，我們就需要考慮接口的幂等性，確定同一條消息發送一次和十次都不回導緻消息的重複到達。

5.支援QoS 服務品質分級

其實對于上一點消息重複的問題，行業已經有了解決方案和标準規範，對于消息到達率和重複，常用的手段就是通過消息确認的方式來確定消息到達，要求越高，意味着确認機制越複雜，成本越高。為了在成本和到達率之間有很好的平衡，通常對消息系統的服務品質（QoS）分為以下三個級别 ：

• QoS 0(At most once)：“最多發一次”，意味着發送就可以了，不需要确認機制，發送了即可，适用于要求不高的場景，可以接受一定的不到達率，成本最低。
• QoS 1(At least once)：“至少發一次”，意味着發送方必須明确收到接收方的确認信号，否則就會反複發，每條消息至少需要兩次通信來确認到達，可以接受一些消息被重發，但成本不高 。
• QoS 2(Exactly once)：“確定隻發一次”，意味着每條消息隻能到達一次，且不允許重複到達，為了達到這個目标就需要雙方至少通訊三次，成本最高。

一個完善的websocket服務面對不同的應用場景，應該能夠支援選擇不同等級的QoS，在成本和服務品質之間取得平衡。

最後

雖然websocket已經廣泛的應用于各種系統和平台，但如果要搭建一個滿足企業級或者大型網際網路平台的可靠、安全穩定的websocket服務，對于沒有經驗的同學，在具體的技術實踐過程依然是有不少的坑要踩。

對websocket服務有較高要求，選擇成熟可靠的第三方websocket服務其實也是一個成本更低和高效的選擇。GoEasy作為國内領先的第三方websocket消息平台，已經穩定運作了5年時間，支援千萬級消息并發，除了相容所有常見的浏覽器以外，同時也相容uni-app，各種小程式，以及vue、react-native等常見的前端架構。

希望本文能為初次搭建websocket服務的同學在思路上有所幫助和參考，也歡迎各位前輩多多批評指正，同時也希望未來有機會就更多的技術與大家進行交流。

GoEasy官網：

https://www.goeasy.io/