NextRPC : RPC多段返回的創新和探索

阿里巴巴移動技術發表於2022-03-18
Trpc

作者：吳欣蔚(蓄昂)

NextRPC 是對 RPC 請求模式的創新和探索，它可以像多級火箭一樣，返回 Payload 多段資料，從不同的網路通道請求/應答多段返回，最終完成業務場景交付。裡面的“Next”有雙關的意思：

  1. 核心的區別於傳統 RPC，請求的特點是讓請求響應以流式多段返回給客戶端，在流式的語義裡面資料不停地通過 Next -> Next -> Next 的模式來響應；
  2. Next 有下一代的意思，NextRPC 是傳統單響應的下一代 RPC 模式。

目前，NextRPC 已經在手淘的部分交易場景上線，如：下單換購業務在2021年4月初上線，經歷9.9、11.11兩次大促，業務模式已經穩定。在2021年的雙十一大促中，通過 NextRPC 鏈路給業務整體帶來超過5%的 uv 轉化提升，在多商品中選擇一個最優商品透出的場景下，uv 轉化提升達25%以上。

業務背景

在一些交易核心鏈路如 購物車、訂單 等場景，期望引入導購鏈路的推薦演算法，基於店鋪維度針對單品、多品SKU、跨店場景進行個性化推薦，推出如“順手買一件”的個性化推薦產品 或 其他優惠資訊的透出，提升uv轉化率。

問題與挑戰

當 核心交易場景 遇上 個性化推薦 ，交易 和 導購 的場景碰撞，會產生以下新的問題：

  • 使用者體驗的衝突：個性化推薦演算法服務RT高，不滿足核心交易鏈路對RT的要求；
  • 服務質量的衝突：引入個性化推薦，會使得交易鏈路的下游系統變得更加複雜，對系統的穩定性帶來新的挑戰；同時，導購鏈路的「個性化推薦業務」容忍部分不確定性（如請求超時/失敗），而「核心交易鏈路」則對穩定性和確定性要求極高，每一次的失敗可能都會錯失交易；
  • 機器資源的衝突：交易、導購 的多地部署結構不一樣，機器容量和分佈存在差異化。

上述的這些問題，引出了新的技術挑戰：如何在一次請求中同時支援對「使用者體驗」、「服務質量」、「資源」要求不一樣的多個業務支撐系統。

技術選型

1、RPC模式分析

以下針對五種常見的RPC模型展開對比分析：

2、請求處理模型分析

請求處理模型主要分析 序列處理、並行處理兩種模型。

  • 序列處理：資料的依賴深度決定了整體可優化的最小rt；
  • 並行處理：通過並行化（併發度n），來將對應層次上的rt降低為原來的 max(RTn)。

3、NextRPC的多段返回模式

NextRPC結合了 單請求非同步推送資料流 的RPC模式和 並行處理 的請求處理模型，解決了新的業務場景帶來的挑戰：

  • 單請求非同步推送資料流：

-可以將 核心業務邏輯 和 非核心業務邏輯 解耦，保證核心資料同步響應，非核心資料非同步響應，解決服務質量問題；

-交易鏈路、導購鏈路邏輯解耦，內部跨應用呼叫，解決機器資源問題；

  • 並行處理：

-業務邏輯可並行化處理，節省序列等待時間，解決交易鏈路使用者體驗問題。

NextRPC架構

1、客戶端架構

技術架構

  • 網路層，抹平Mtop/Accs通道，對業務透明；
  • 資料整流層，控制 單個請求多個返回的時序（其中非同步副返回包含了非同步的業務資料流）；
  • 資料編排層，控制 多請求間 非同步資料的合併。

資料流和多例項

  • 一個頁面支援多個 NextRPC 例項，多頁面可建立多個 NextRPC 例項；
  • 一個 NextRPC 例項可進行多個不同請求，接收不同的副響應推送。

2、服務端架構

技術架構

請求過程詳解

  1. 客戶端發起主請求；
  2. 服務端接收到客戶端主請求，執行業務邏輯的同時，通過訊息中介軟體傳送副請求資訊（注：AttachedRequestEmitter 通過訊息中介軟體，將非核心依賴解耦出去），所有業務邏輯執行完成後，副請求也都傳送完成；
  3. 返回客戶端主響應，主響應包含副請求元資訊；

  4. 副請求接收端通過訊息中介軟體消費副請求訊息，並呼叫業務處理器AttachedRequestProcessor，業務處理完成後，返回nextrpc-sdk副請求處理結果；

    1. 副響應通過訊息推送通道下發給客戶端
    2. 客戶端監聽指定的訊息推送通道，收到副響應資料後，渲染上屏。

異常情況處理

  1. 副請求編排，一個主請求多個副響應的場景下，客戶端如何知道總共有多少個副請求？

由於服務端業務呼叫 NextRPC SDK 傳送副請求，SDK 是知道自己被呼叫了多少次的，所以這個資訊由 SDK 來統計並儲存，SDK 內部維護一個副請求元資訊，包括總數、副請求業務資訊，業務每呼叫一次 SDK 傳送副請求，SDK 累加累加總數，主響應結束時，同時下發副請求總個數。

  1. 副請求處理，不同業務吞吐量不一樣，多個業務之間如何隔離確保互不影響？

業務之間通過訊息中介軟體的不同 Topic 或者 不同的 Tag 進行隔離，每個 Topic 或 Tag 使用單獨執行緒池消費。

  1. 訊息過期、重複如何處理？

副請求通過訊息中介軟體傳送，當副請求接收端收到訊息時，訊息存在過期、重複的情況，SDK 提供訊息的元資訊（包括時間戳、唯一標識）

訊息過期：SDK 內部可

訊息重複：需要由業務程式碼根據請求的唯一標識來實現冪等。

3、技術指標

NextRPC作為一種單請求多響應的RPC模式，按請求階段劃分，衡量服務質量的技術指標可以分為 3 種：

  • 主請求成功率：主請求被成功處理的比例。主請求的成功與否，決定著後續的流程能否繼續進行，也是衡量NextRPC服務質量的最基本指標；
  • 副請求成功率：副請求從發起到被處理成功的比例，用於衡量副請求的服務質量；
  • 副響應到達率：在主請求成功的基礎之上，從副請求的發起、接收、處理，再到端上裝置成功接收到副響應，是NextRPC多響應服務質量的核心衡量指標。配合上請求的超時配置，還可以進一步衡量 1s、3s、5s 到達率。

不同的請求階段會有不同的技術指標，可以用於客戶端、服務端服務質量分析，各個階段產出的指標如下圖所示：

總結與展望

雙11是阿里巴巴的超級工程，2021年是雙11的第十三個年頭，立足過去12年的技術與商業創新，是一個新輪迴的開始。

我們從追求更高到追求更好，技術也在探索這個過程，圍繞消費體驗不降級這個目標，我們在核心交易鏈路上做出大膽的技術嘗試，追求交易確定性和體驗的同時，提供更好、更有質量的服務滿足消費者，並且可以賦能商家提升運營能力。

後續，我們也將繼續嘗試落地更多業務場景，藉助NextRPC為業務的創新助力！

我們招聘啦！

歡迎加入淘寶移動技術中臺，團隊成員大牛雲集，有阿里移動中介軟體的創始人員、鷹眼全鏈路追蹤平臺核心成員、更有一群熱愛技術，期望用技術推動業務的小夥伴。

淘寶移動技術中臺，推進淘系（淘寶、天貓等）架構升級，致力於為淘系、整個集團提供基礎核心能力、產品與解決方案：

  1. 業務高可用的解決方案與核心能力（應用高可用：為業務提供自適應限流、隔離與熔斷的柔性高可用解決方案，站點高可用：故障自愈、多機房與異地容災與快速切流恢復）；
  2. 新一代的業務研發模式FaaS（一站式函式研發Gaia平臺）；
  3. 下一代網路協議QUIC實現與落地；
  4. 移動中介軟體（API閘道器MTop、域名排程AMDC、訊息/推送、檔案上傳AUS、移動配置推送Orange 等等）。

期待一起參與加入淘系基礎平臺的建設~

簡歷投至方式 ：zebin.xuzb@alibaba-inc.com

關注【阿里巴巴移動技術】微信公眾號，每週 3 篇移動技術實踐&乾貨給你思考！

相關文章