作者 | Matthew O’Riordan

譯者 | 明知山

策劃 | 丁曉昀

實時數(shù)據(jù)傳遞的興起

我們的日常數(shù)字體驗正在經(jīng)歷一場變革：實時數(shù)據(jù)。

現(xiàn)在，用戶希望應(yīng)用程序或瀏覽器中的頁面無需刷新就能更新狀態(tài)——例如，顯示實時體育比分的應(yīng)用程序或在地圖上跟蹤快遞進(jìn)度的網(wǎng)頁。

我們都已經(jīng)習(xí)慣了即時的數(shù)字體驗，我們理所當(dāng)然地認(rèn)為應(yīng)用程序和網(wǎng)頁可以提供流暢的交互式服務(wù)，沒有延遲。提供無縫實時更新體驗來吸引用戶的組織可以獲得更高的用戶參與度和更多的頁面停留時間，還有潛在的再次訪問和業(yè)務(wù)上的好處。如果沒有無縫的實時更新，用戶體驗就會顯得過時，并有失去市場份額的風(fēng)險。

本文通過示例對一些最常見的實時用戶體驗進(jìn)行了比較，討論了支持實時更新的事件驅(qū)動架構(gòu)，并介紹了常見的技術(shù)選項。

據(jù)估計，到 2025 年，全球30%的消費數(shù)據(jù)將來自實時信息交換，因為預(yù)計將有 1500 億臺設(shè)備連接并創(chuàng)建實時數(shù)據(jù)。隨著企業(yè)尋求相對于競爭對手的運營優(yōu)勢，它們開始關(guān)注實時體驗。在最近的一項調(diào)查中，一些 IT 行業(yè)的領(lǐng)先者告訴 IDC，在有助于實現(xiàn)實時決策的技術(shù)上投入是當(dāng)務(wù)之急。

實時的定義

人類平均眨眼時間為 100 毫秒，平均反應(yīng)時間約為 250 毫秒。因此，在 250 毫秒以內(nèi)發(fā)生的任何事情都被認(rèn)為是“實時”的。

操作系統(tǒng)對硬件有不同的要求，“硬實時”的內(nèi)核承諾延遲小于 5 毫秒。另一個要求低延遲的領(lǐng)域是多人游戲，它要求延遲低于 50 毫秒。在本文中，我們要討論的實時是一種符合人類對“瞬時”理解的實時。

常見的實時用戶體驗

實時體驗

許多人都熟悉這種實時體驗——根據(jù)內(nèi)容或數(shù)據(jù)的變化，實時數(shù)據(jù)從源向用戶單向傳遞。

這類例子包括：

• 在線購物網(wǎng)站，顯示商品庫存數(shù)量或商品存放在其他用戶購物籃中的數(shù)量；
• 作為對銀行帳戶活動的反映，即時更新銀行應(yīng)用程序；
• 將體育和新聞更新發(fā)送到應(yīng)用程序或網(wǎng)頁上。

實時體驗的例子：Reddit

Reddit 是全球訪問量最大的 20 個網(wǎng)站之一，它最近推出的實時更新功能表明，在與 Facebook 等其他在線社區(qū)的競爭中，實時體驗具有重要的戰(zhàn)略意義。Reddit App 用戶現(xiàn)在可以看到其他 Reddit 用戶的活動，比如當(dāng)其他 Reddit 用戶在閱讀同一篇文章或輸入回復(fù)時會顯示動畫和提示。除此之外，還有其他的一些實時功能。

共享的實時體驗

當(dāng)實時數(shù)據(jù)雙向流動時，就形成了共享的實時體驗。打字聊天消息的傳遞就是一個典型的例子。其他的例子還包括民意調(diào)查、測驗和問答，例如在 Twitch 流媒體直播中，參與者可以與主持人互動。

共享的實時體驗示例：Mentimeter

Mentimeter可以作為直播的一個補(bǔ)充環(huán)節(jié)，可用于進(jìn)行民意調(diào)查或測驗。例如，主持人可以問觀眾：“你們最喜歡的曼達(dá)洛人角色是哪一個？”參與者可以打開一個短 URL，并進(jìn)行在線投票，他們的回答會被實時可視化，并在直播中顯示。

協(xié)作體驗

協(xié)作體驗類似于共享的實時體驗，但通常使用點對點通信，用戶可以實時編輯共享的狀態(tài)和數(shù)據(jù)。一個典型的例子是我們在遠(yuǎn)程工作中使用的協(xié)作生產(chǎn)力工具，如 Figma、Google Docs 或 Miro。

協(xié)作體驗示例：Figma

Figma是一個協(xié)作設(shè)計工具，允許多個用戶同時處理一個文件。它被稱為“設(shè)計協(xié)作的分水嶺”和設(shè)計軟件的變革者。

用戶可以直接共享 Figma 文件的鏈接，不需要下載或發(fā)送文件，也不需要離線編輯和合并修改。對于文檔、電子表格和演示文稿的協(xié)作來說，這些已經(jīng)相對標(biāo)準(zhǔn)化了，但對于復(fù)雜的設(shè)計軟件來說，這是一種新的工作方式。

對于許多組織（無論是現(xiàn)有的頭部公司還是挑戰(zhàn)者）來說，被Adobe以破紀(jì)錄的200億美元收購的 Figma 是一個有趣的案例。共享的實時和協(xié)作體驗是未來趨勢，沒有實時功能的產(chǎn)品需要找到一種方法來引入這些功能。

通常，當(dāng)我們講到實時體驗時，我們想到的是速度和延遲，但實時交互的根本在于架構(gòu)。

基于事件驅(qū)動的實時架構(gòu)

對于一個成功的實時解決方案，你需要考慮采用事件驅(qū)動模型。在事件驅(qū)動模型中，事件表示可能觸發(fā)客戶端（或事件消費者）執(zhí)行某些操作的變更，例如更新 UI。事件將作為消息通過事件通道傳遞給消費者。事件生成器負(fù)責(zé)傳遞反映數(shù)據(jù)或狀態(tài)實時變化的事件。

事件驅(qū)動系統(tǒng)的典型模式是“發(fā)布和訂閱”。當(dāng)狀態(tài)發(fā)生變化時，事件生產(chǎn)者（發(fā)布者）發(fā)送事件消息，事件訂閱者可以消費這些消息，并做出響應(yīng)時執(zhí)行業(yè)務(wù)邏輯。

用于實時解決方案的協(xié)議

在事件驅(qū)動架構(gòu)中，事件消費者需要能夠異步地接收更新?？晒┻x擇的協(xié)議包括：

• HTTP長輪詢——服務(wù)器保持客戶端連接處于打開狀態(tài)，在新數(shù)據(jù)可用或連接超時時發(fā)送響應(yīng)。
• WebSocket——通過持久 TCP 連接提供雙向、全雙工通信通道，開銷要比半雙工替代方案（如 HTTP 長輪詢）低得多。
• MQTT——用于在 CPU 功率或電池壽命有限的設(shè)備（如物聯(lián)網(wǎng)設(shè)備）之間傳輸數(shù)據(jù)的首選協(xié)議。
• SSE——用于事件驅(qū)動數(shù)據(jù)流的輕量級開放協(xié)議（僅訂閱）。

WebSocket 可以說是使用最為廣泛的支持實時用戶體驗的協(xié)議。WebSocket 于 2011 年實現(xiàn)標(biāo)準(zhǔn)化（RFC 6455），它是建立在TCP/IP協(xié)議棧之上的一個薄傳輸層。

WebSocket 的出現(xiàn)標(biāo)志著 Web 開發(fā)的一個轉(zhuǎn)折點。WebSocket 連接是為事件驅(qū)動架構(gòu)而設(shè)計的，并針對最小化開銷和延遲進(jìn)行了優(yōu)化，它通過持久的單套接字連接實現(xiàn)了客戶端和服務(wù)器之間的雙向全雙工通信，并盡可能接近原始的 TCP 通信層。

與HTTP相比，WebSocket 連接提高了效率，可伸縮性更好。WebSocket 協(xié)議是基于推送的，因此一旦有事件發(fā)生，連接的客戶端就會收到更新。

用于事件驅(qū)動系統(tǒng)的 WebSocket

我們有幾種方法可以將 WebSocket 集成到我們的技術(shù)棧中。

第一種方法是從頭開始構(gòu)建一個基于 WebSocket 的消息傳遞解決方案，并根據(jù)需要對其進(jìn)行定制。例如，DAZN 使用 WebSocket 協(xié)議設(shè)計了一個自定義解決方案，用于向數(shù)百萬用戶廣播消息。

另一種方法是使用 WebSocket 開源項目作為消息傳遞層的主干。Socket.IO是一個基于原始 WebSocket 構(gòu)建的框架，提供了額外的功能，比如支持回退、自動重連和發(fā)布/訂閱消息（房間）。一種常見的方法是結(jié)合使用 Socket.IO 和Redis Pub/Sub，在不同的進(jìn)程或服務(wù)器上運行多個 Socket.IO 實例，并在節(jié)點之間傳遞事件。

然而，這種方法仍然存在一些限制，例如缺乏消息排序、有限的原生安全性和單區(qū)域可用性設(shè)計。因此，要在生產(chǎn)環(huán)境中大規(guī)模使用Socket.IO仍然存在很大的挑戰(zhàn)。

為實時數(shù)據(jù)構(gòu)建 WebSocket 解決方案所面臨的挑戰(zhàn)

上面描述的兩種 WebSockets 集成方式都存在工程方面的挑戰(zhàn)，可能會影響項目成本和交付期限。從表面上看，構(gòu)建 WebSocket 解決方案就是從添加接收實時更新的功能開始。然而，隨著功能的演進(jìn)，基本的實時體驗會延伸出共享實時體驗和協(xié)作功能等額外需求。

為這些實時體驗構(gòu)建和維護(hù)一個專有的 WebSocket 解決方案可能極具挑戰(zhàn)性。支撐解決方案的基礎(chǔ)設(shè)施必須穩(wěn)定可靠，需要有經(jīng)驗的工程師來構(gòu)建和維護(hù)。開發(fā)團(tuán)隊可能會更關(guān)注實時需求方面的東西，而不是增強(qiáng)核心產(chǎn)品的特性，并面臨可伸縮性和彈性、延遲、容錯以及數(shù)據(jù)完整性和連接管理等工程挑戰(zhàn)。

可伸縮性和彈性

為了能夠可靠地處理數(shù)百萬個并發(fā) WebSocket 連接，解決方案需要具備可伸縮性，這是一項復(fù)雜且耗時的工作，需要專門的工程資源、大量的基礎(chǔ)設(shè)施成本和時間。

水平伸縮帶來了更復(fù)雜的架構(gòu)、負(fù)載均衡、路由以及基礎(chǔ)設(shè)施和維護(hù)成本的增加，這些還只是其中的一部分挑戰(zhàn)。

為了能夠成功地處理規(guī)模不可預(yù)測的 WebSocket 連接，解決方案還需要具備彈性，讓系統(tǒng)能夠自動添加更多的服務(wù)器，有足夠的容量來處理潛在的流量高峰。

延遲

網(wǎng)絡(luò)延遲是大規(guī)模分布式系統(tǒng)中的一個關(guān)鍵因素。延遲隨著距離的增加而增加，因此為了保持較低的網(wǎng)絡(luò)延遲，建議借助托管數(shù)據(jù)中心和邊緣加速點讓數(shù)據(jù)盡可能地靠近用戶。良好的用戶體驗還需要盡量減少延遲抖動。

容錯

要讓系統(tǒng)具備容錯能力，必須要有服務(wù)實例甚至數(shù)據(jù)中心冗余。這意味著至少要將基礎(chǔ)設(shè)施分布到同一地區(qū)的多個可用性區(qū)域，甚至分布到多個地區(qū)。這涉及大量的工程和 DevOps 工作以及與基礎(chǔ)設(shè)施相關(guān)的成本。

數(shù)據(jù)完整性和連接管理

事件驅(qū)動架構(gòu)依賴了事件消息序列，要求沒有消息丟失或沒有的無序消息。

如果用戶設(shè)備斷電或網(wǎng)絡(luò)出了問題，則可能導(dǎo)致連接中斷。當(dāng)用戶重新連接時，需要從斷開連接的點繼續(xù)處理事件。系統(tǒng)需要在不重復(fù)已處理消息的情況下傳遞遺漏的消息。整個過程必須是完全無縫的。

所以還需要解決一些復(fù)雜的工程問題，以保證消息排序和精確一次語義所需的數(shù)據(jù)完整性。

DIY 的困境

一些組織試圖盡早發(fā)布產(chǎn)品，將這些困難的問題留到以后解決。但是，如果產(chǎn)品無法滿足它創(chuàng)造出來的需求，那么迅速進(jìn)入市場并獲得早期成功可能會弄巧成拙。

另一種選擇是盡早進(jìn)行伸縮性設(shè)計，并為未來的增長建立可持續(xù)的架構(gòu)。但這種方法可能會導(dǎo)致延遲進(jìn)入市場，成為競爭對手的可乘之機(jī)。另一個常見的問題是，最初的設(shè)計會在產(chǎn)品獲得足夠的市場反饋以了解其發(fā)展方向之前就已經(jīng)在產(chǎn)品中加入了重大的限制。

無服務(wù)器 WebSocket 的優(yōu)勢

一個可行的解決方案是將構(gòu)建業(yè)務(wù)關(guān)鍵型實時平臺的復(fù)雜性轉(zhuǎn)移到專門的云服務(wù)上。全托管的無服務(wù)器 WebSocket 解決方案為基于事件驅(qū)動的消息傳遞提供了基礎(chǔ)設(shè)施，它將底層基礎(chǔ)設(shè)施變成了商品。用戶使用提供者服務(wù)發(fā)送/接收低延遲消息，并專注于構(gòu)建業(yè)務(wù)邏輯來處理實時更新。

將 WebSocket 技術(shù)與無服務(wù)器模型結(jié)合起來有幾個好處：

• 無需維護(hù)基礎(chǔ)設(shè)施——構(gòu)建專有的 WebSocket 基礎(chǔ)設(shè)施既耗時又耗費資源。無服務(wù)器 WebSocket 提供商減輕了管理實時基礎(chǔ)設(shè)施的負(fù)擔(dān)。
• 降低運營成本——大多數(shù)無服務(wù)器 WebSocket 提供商都提供按使用付費的定價模型。這比預(yù)先租用或購買固定數(shù)量的服務(wù)器容量更具成本效益，后者通常會存在大量未充分使用或空閑的時間。
• 可伸縮性和可用性——無服務(wù)器 WebSocket 架構(gòu)在設(shè)計上是可伸縮的。使用無服務(wù)器基礎(chǔ)設(shè)施構(gòu)建的應(yīng)用程序可能會遇到很大其波動的流量，需要基礎(chǔ)設(shè)施能夠自動伸縮以處理不可預(yù)測且快速變化的并發(fā) WebSocket 連接。
• 降低延遲——在無服務(wù)器模型中，應(yīng)用程序并不是托管在原始的服務(wù)器上。這意味著，根據(jù)無服務(wù)器 WebSocket 基礎(chǔ)設(shè)施提供商的設(shè)置，無服務(wù)器應(yīng)用程序可能會在全球多個地區(qū)和邊緣位置的用戶附近運行，從而提高了性能并降低了延遲。

無服務(wù)器 WebSocket 解決方案

一些云供應(yīng)商提供了無服務(wù)器 WebSocket 解決方案，如AWS AppSync和AWS API Gateway、Cloudflare Workers、Google Cloud Run和Azure Web PubSub。然而，這些解決方案并沒有提供一個完整的端到端解決方案來處理最常見的場景，具體例子見DAZN對AWS AppSync和AWS API Gateway的評測。

一些平臺，如Ably和Pusher，致力于幫助組織應(yīng)對在采用無服務(wù)器 WebSocket 事件驅(qū)動架構(gòu)時面臨的挑戰(zhàn)，并添加了額外的功能來解決常見的痛點。

例如，它們很少只使用一個通用的協(xié)議，因為不同的協(xié)議可以更好地實現(xiàn)某些目的。Ably 提供了多種協(xié)議，如 WebSocket、MQTT、SSE 和 HTTP，并且還擴(kuò)展了原始協(xié)議之外的功能，如設(shè)備狀態(tài)、流歷史、通道回流和處理連接突然斷開。

采用供應(yīng)商提供的端到端無服務(wù)器 WebSocket 平臺有很多好處，因為它們可以應(yīng)對處理大規(guī)模實時數(shù)據(jù)時所面臨的挑戰(zhàn)，讓工程團(tuán)隊可以專注于核心產(chǎn)品創(chuàng)新，不需要操心與實時基礎(chǔ)設(shè)施相關(guān)的問題。

總結(jié)

實時體驗由實時、事件驅(qū)動的 API 提供支撐，可以滿足現(xiàn)代終端用戶的需求。

穩(wěn)定的低延遲、數(shù)據(jù)完整性（順序和傳遞保證)、容錯、可用性和可伸縮性是實時系統(tǒng)的基礎(chǔ)，并不是每個組織都有能力處理好構(gòu)建可靠和不間斷體驗的復(fù)雜性。

新一代提供無服務(wù)器 WebSocket 的 PaaS 可以促進(jìn)架構(gòu)、構(gòu)建、交付和維護(hù)解決方案的過程，讓用戶更加滿意，并使產(chǎn)品更具競爭力，無需花費高成本自行開發(fā)解決方案。

作者簡介：

Matthew O'Riordan 是 Ably（無服務(wù)器 WebSocket 提供商）的首席執(zhí)行官和聯(lián)合創(chuàng)始人。他已經(jīng)做了 20 多年的軟件工程師，其中有很多時間在擔(dān)任 CTO。他從在 20 世紀(jì) 90 年代中期開始從事商業(yè)互聯(lián)網(wǎng)方面的工作，當(dāng)時 IE 3 和網(wǎng)景還在你爭我搶。他喜歡寫代碼，同時，作為初創(chuàng)企業(yè)家，擴(kuò)大業(yè)務(wù)所面臨的挑戰(zhàn)是他前進(jìn)的動力。Matthew 之前曾創(chuàng)辦過兩家科技公司，并成功退出。

原文鏈接：

https://www.infoq.com/articles/serverless-websockets-realtime-messaging/

相關(guān)閱讀：

WebSocket 原理淺析與實現(xiàn)簡單聊天

構(gòu)建通用WebSocket推送網(wǎng)關(guān)的設(shè)計與實踐

Serverless實戰(zhàn)：利用云函數(shù) API網(wǎng)關(guān)實現(xiàn)Websocket聊天工具

本文轉(zhuǎn)載來源：

https://www.infoq.cn/article/9C7u99NSGaKvx9jeA4lw