近年，不論是正在快速增長的直播，遠程教育以及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
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/38916.html
標籤：其他