作者：王豫寧(顏冉)
RTMS是 Real Time Message Service 的縮寫，基於幀同步的思想，我們實現了一套實時網路通訊方案，服務端只轉發訊息，不做任何邏輯處理，專門適用於對實時性和互動性有很高要求的業務場景。
在實現上，RTMS 在服務端通過提供SDK的形式與業務伺服器整合部署在一起，減少了東西向的流量轉發，不依賴外部儲存服務(如分散式快取,資料庫)等，純記憶體計算，提供底層的業務網路能力。通過簡化設計，大大提高了實時性和穩定性。
業務背景
為提升使用者活躍度和黏性，目前支付寶存在很多如螞蟻森林，螞蟻莊園，芭芭農場這樣的互動產品。在往年618和雙11大促期間，有疊貓貓的互動產品，前年開始的新春五福，又新增了打年獸的玩法等等。但是目前支付寶端內的互動產品的互動性還不夠強，使用者與使用者之間無法同時競技，互動性和參與感偏低。
在五福走過的第7年，新春五福這個大IP也急需新的玩法創新來進一步吸引使用者。通過調查發現，使用者對五福活動新增“互動，PK，對戰”的呼聲也很高。RTMS的網路技術能力和五福產品團隊設計的聯機版打年獸玩法需求非常契合，在2022新春五福活動中發揮了重要作用，穩定支撐活動順利進行。
業務痛點
1、多人實時互動業務場景，處理複雜，實時性差
服務端通常是分散式無狀態的微服務架構，客戶端請求會經過負載均衡，隨機的落到一臺業務伺服器上進行處理。在多人實時互動場景中，同一個互動“房間”的多個使用者請求被隨機路由到不同伺服器後，為了維護獲取“房間”的狀態，互動服務提供方不得不依賴分散式快取或者集中式的資料庫進行資料的儲存和交換。
同時，為了將處理的結果訊息傳送到客戶端，還需要依賴中心化的訊息核心服務來傳送。由於客戶端長連線分佈在不同的伺服器上，訊息核心需要通過分散式快取來管理連線資訊，為推送時任意訊息核心伺服器都能夠找到特定使用者的長連線所在伺服器。此外訊息核心原本的設計是要保證即使客戶端網路不線上也能夠最終推送到客戶端，所以訊息核心會把每一條訊息都持久化到資料庫。
可以看出，基於傳統的網路通訊解決方案，業務處理非常複雜，需要多次訪問分散式快取和資料庫，服務端內部的東西向流量和請求也比較多，增加了處理複雜度和耗時。雖然保證了訊息到達的可靠性，卻無法滿足互動場景中高頻、實時的訴求。
2、大規模隨機使用者訊息訂閱場景，處理複雜，耗時冗長
在支付寶目前的股票業務場景中，股票標的眾多，在開市交易期間，每個股票標的每分每秒的資料都在不斷的發生變化，訊息量巨大。使用者在檢視股票行情時，也會經常不斷的切換正在檢視的股票標的。每天會有上百萬使用者同時在檢視不同股票標的資訊。如何將頻繁變化的股票行情資料，準確快速的推送到所有客戶端上，是一個難題。
服務端需要實時感知並維護使用者和股票標的之間的一對多關係，這個工作非常複雜和麻煩。在有訊息產生的時候，需要通過訊息核心的服務，遍歷使用者列表，將相同的訊息逐個傳送給所有客戶端。對於熱門標的來說，批量完整呼叫一次都很費時。隨著使用者規模的不斷攀升，這樣的呼叫方式越來越重，逐漸無法支撐業務的發展。
設計方案
仔細思考這些新的業務形態的訴求，我們重新設計了新的南北向的實時訊息推送方案RTMS，通過定向路由、訂閱釋出機制、放棄訊息持久化、去中心化等新的思路滿足了業務對於高實時性、快速大規模擴散的需求。
去中心化&去持久化
和中心化的訊息核心不同，RTMS完全使用去中心化的方案，連線管理、上行訊息路由投遞、下行訊息的擴散分發通過SDK的方式和業務服務同機部署，減少了業務服務和訊息核心之間的東西向流量。
此外，這些場景對於訊息的實時性要求高，也意味著對收到客戶端離線期間產生的訊息的訴求下降，因此我們在設計中去掉了服務端對訊息的持久化。高頻的訊息不再持久化不僅提高了整個鏈路的實時性，也規避了巨大的儲存壓力。
雙向通訊
RTMS的雙向通訊能力，可以使客戶端傳送上行請求和服務端處理結果推送到客戶端直接在同一條鏈路上完成，鏈路更加簡化，程式設計模型更加統一。
上行訊息
上行訊息，是指客戶端傳送訊息到服務端。上行訊息首先會投遞到使用者自己的上行訊息佇列中，然後再通過上行訊息佇列繫結的巡檢任務，非同步投遞到指定的傳送目標。
下行訊息
下行訊息，是指服務端傳送到客戶端的訊息。Meeting訊息和Topic訊息首先投遞到其本身的訊息佇列中，然後通過巡檢任務，非同步的將訊息投遞到使用者的下行訊息佇列。使用者下行訊息佇列也各自有一個巡檢任務，再非同步的將訊息推送到客戶端。
定向路由
通過定向路由，我們把邏輯上屬於一個“房間”的使用者的長連線路由到同一臺伺服器上的RTMS SDK進行處理。
服務端通過一定的機制，生成一個 Token，這個 Token 代表了一臺特定伺服器的基本資訊。不同的客戶端，在建立長連線時可以指定這個 Token，負載均衡器識別這個 Token ，把具有相同 Token 的連線路由到同一臺伺服器上。從而屬於一個“房間”的使用者的業務邏輯可以集中在單臺伺服器上處理，降低業務處理複雜度，避免使用集中式的儲存，提高訊息實時性。
訂閱釋出模式
RTMS除了提供基礎的按指定使用者推送訊息的模式外，還提供了 Meeting 和 Topic 兩種推送模式，來適應不同的訊息擴散場景。
Meeting模式
Meeting是對業務上一個“房間”例項的抽象，例如一局聯機版打年獸可以對應一個Meeting，局內的所有使用者都共同加入到一個Meeting中。一個Meeting僅會在單臺伺服器上，因此Meeting內所有使用者的上行和下行訊息，都可以集中在單臺伺服器上處理。
Topic模式
Topic是對一類相關訊息的抽象，例如一個股票標的可以對應一個Topic，使用者可以訂閱某個股票標的的Topic，產生一個訂閱關係。
通過叢集擴散能力，業務服務端僅需呼叫介面一次，RTMS通過訊息佇列中介軟體將訊息擴散到服務端所有的機器上，進而每臺伺服器再按照Topic的訂閱關係將訊息分別擴散到所有客戶端。
總結&展望
在訊息推送以及端到端的網路通訊領域，RTMS提供的程式設計模型和設計思路給了業務一種新的選擇。在對實時性、互動性有較高要求的場景上，RTMS能夠為業務提供重要的價值，降低處理複雜度，使業務更加聚焦於業務本身。
為進一步提高訊息的實時性和大規模擴散能力，RTMS將向MESH化的方向繼續探索，通過就近接入，邊緣部署等方式，進一步縮短鏈路，提升使用者體驗。
關注【阿里巴巴移動技術】，阿里前沿移動乾貨&實踐給你思考！