搭建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官網：www.goeasy.io 微信：GoEasySupport