前言

在數字化浪潮席卷的當下，業務的高效運營與創新發展離不開強大的技術支撐。對于各類線上業務而言，交易系統作為連接用戶與服務的關鍵樞紐，其成熟度與完整性直接決定了業務的競爭力。一套卓越的交易系統，不僅是業務流程的數字化載體，更是提升運營效率、優化用戶體驗、推動業務創新的核心驅動力。大會員業務精心打造的交易系統，正是這樣一個集高效、靈活、穩定于一身的強大平臺，它以模塊化的架構、先進的技術組件和完善的功能體系，為業務的持續增長和生態的繁榮發展奠定了堅實基礎。

系統架構全景洞察

大會員交易系統采用模塊化設計理念，將復雜的交易流程拆解為交易、訂單、簽約、商品及清結算等多個核心模塊。這些模塊既相互獨立又緊密協同，共同驅動著整個交易鏈路的順暢運轉，構建起一個高效、靈活且易于維護的系統架構，確保系統能夠快速響應業務需求的變化，為業務的創新發展提供有力支持。

因我們本身所屬業務的特性，所以設計的交易系統可能跟傳統電商的交易系統不同，更適配虛擬物品相關的業務。

核心流程深度解析

交易系統的核心流程從用戶下單的那一刻開始啟動，訂單作為貫穿始終的關鍵紐帶，串聯起支付、履約、退款等各個環節。在這個過程中，訂單系統負責維護交易狀態、管理交易生命周期，與商品系統、支付系統、營銷系統以及清結算系統緊密配合，共同完成整個交易流程。每一個環節都經過精心設計和嚴格把控，確保交易的順利進行和數據的安全可靠。

架構設計實踐

系統架構圖

圖片

核心流程示例

交易系統的核心流程始于用戶下單，訂單貫穿支付、履約、退款等環節。訂單系統負責維護交易狀態和生命周期，與商品系統、支付系統、營銷系統、清結算系統協同完成整個交易的流程。

圖片

核心技術組件說明

交易配置

1.業務身份管理

業務身份管理為每個業務分配唯一 ID，該 ID 在整個訂單、支付和結算鏈路中貫穿始終，為每個業務頒發了一張專屬 “身份證”，憑借這一 ID，不同業務的數據得以相互隔離且可精準追蹤，有力保障了業務管理的清晰性和數據的完整性。

2.支付中樞配置

支持靈活選擇支付渠道和優先級，能夠根據業務需求和用戶偏好，快速切換和調整支付渠道順序。

同時，通過管理支付協議模板，實現前端展示與不同支付需求的快速適配。

3.風險控制

通過風控控制通過主動防御（如黑名單）和智能攔截機制（如惡意退款），識別并阻止異常交易，保障支付安全。

訂單服務

訂單服務涵蓋交易流程編排、業務數據管理和交易數據安全。它維護訂單從創建到完結的全生命周期，通過狀態機模式管理訂單狀態流轉，支持超時取消和自動確認等規則。訂單系統提供實時數據查詢和業務指標分析，借助分布式事務保障數據一致性，通過分級隔離的熔斷降級機制應對流量洪峰，建立自動化對賬體系防控資金風險。

1. 交易流程編排

交易場景中，訂單的生命周期分為：

• 訂單創建：即用戶觸發購買后生成新的訂單
• 用戶支付：按照商品價格營銷策略計算的支付相應金額
• 訂單履約：購買的商品（權益）的下發
• 訂單完結：交易完成后訂單完成
• 訂單退款：出現退款，訂單需要退回支付金額，商品（權益）觸發回收
• 訂單關單：支付失敗關單，超時關閉訂單，用戶取消關閉訂單

訂單系統負責維護上述生命周期，通過狀態機模式流轉訂單狀態，并且支持訂單的超時取消合自動確認等規則，配合上下游其他系統提供完整的訂單服務。

2. 業務數據管理

訂單提供了完成的交易數據管理能力，提供了實時的訂單數據查詢服務，以及業務的數據指標的分析。

3. 交易數據安全

• 通過分布式事務保障數據一致性
• 實施分級隔離的熔斷降級機制抵御流量洪峰
• 建立自動化對賬體系防控資金風險

4.訂單事件驅動的狀態機引擎

訂單的狀態管理采用了事件驅動有限狀態機的設計模式，通過事件訂閱訂單的狀態流轉：

圖片

簽約服務

負責訂閱類業務的簽約管理，例如包月充電業務，可以為業務提供連續包月的簽約對接能力，為付費業務提供更多的運營方案。

1.簽約及續費處理流程

用戶下簽約單后，訂單會觸發簽約系統執行簽約邏輯，向支付中心創建簽約單，并維護簽約狀態

圖片

2.可擴展的簽約服務設計

對于簽約的業務，需要定時的完成續約、扣款、解約以及用戶的簽約狀態維護簽約系統。

簽約系統可分業務、分片的定時完成自動化的續約、扣款、和解約，以及用戶的簽約狀態的維護。

抽象出簽約和扣款接口，接入的訂閱類業務只需實現業務邏輯即可接入簽約續費能力。

圖片

3.簽約數據一致性處理

簽解約流程設計遵循冪等性原則，同時，通過上下游數據對賬，確保簽約數據與訂單、支付渠道的續費信息保持高度一致，保障簽約數據的準確性和完整性。

商品系統

商品系統解決了交易系統中“買什么”的能力，交易系統中的具體交易實體我們稱為“商品”，實際表現上單個商品就是一個SKU，用戶下單購買的實體則是一個具體的SKU，歸于同一個組的商品集合為一個SPU

1.商品信息展示與管理

商品系統是平臺展示商品信息的核心模塊，負責存儲和呈現商品的基本屬性、圖片、描述、規格參數等內容，提供了商品以及商品屬性的配置能力，為消費者提供全面的商品認知，幫助其做出購買決策。

2.交易基礎支撐

在整個交易流程中，商品系統為訂單生成、支付結算、庫存管理等環節提供關鍵數據支持。準確的商品價格、庫存數量等信息是保障交易順利進行的基礎，直接影響到訂單的有效性和消費者的體驗。

3.營銷活動支持

商品系統與營銷系統緊密配合，實現各種促銷活動的配置和執行。通過對商品進行折扣、滿減、贈品等活動設置，激發消費者的購買欲望，提高商品銷量和平臺銷售額。

4.定制化的商品配置

商品除了基礎的屬性規則等配置，應對虛擬物品的不確定性，以及內部各業務的差異性，實現了定制屬性規則，以及適配我們的交易系統的商品特殊綁定的交易規則，清分規則，結算規則配置。

清結算系統

正常的交易流程走完之后，用戶視角下，消費流程已經完結；清結算則是業務視角下的后續流程，售賣的商品被用戶購買之后，平臺需要對收益進行結算，并對商品的供應商或者擁有者進行分成，清結算系統是大會員交易系統中負責處理交易完成后資金分配和結算的關鍵模塊，它確保了平臺和各方合作伙伴在交易中的收益能夠準確、及時地進行計算和分發。

清分系統：交易?額按預定?例拆解，為結算做準備。每筆交易的收益將根據協議分配到相應的分成?。

結算系統：清分數據準備完畢后，結算系統根據結算周期，計算每個分成?的應得?額，并將資?轉?相應賬戶。

這里以一個簡化的例子快速解釋一下清結算的概念。

按照上圖描述，一筆消費完成之后，會先由清分將消費分為多方的分成，再由結算按照結算周期進行計算，并且按照對應的打款方式將收益轉移到對應的分成方的賬戶中。

了解了清結算的基礎概念之后，下面來具體聊一下我們是如何實現整個清分-結算的流程的。

1.清分系統

• 清分系統支持多種數據源接入，不同的業務數據通過標準化的數據接口和數據解析，將各類數據源的數據轉化為系統可識別和處理的格式，為后續的清分計算提供統一的數據基礎。例如，它可以同時接入大會員業務、裝扮業務等不同業務板塊的交易數據，并將其進行整合處理。
• 清分規則支持高度個性化的配置，以滿足不同業務場景和合作模式的需求。通過配置清分執行器鏈表，系統能夠按照特定順序對業務數據進行精確的清分計算。清分執行器是實現清分規則的核心組件，它可以根據業務需求進行定制開發。例如，在涉及多方分成的場景中，清分執行器可以根據不同的分成比例、優先級等規則，對交易金額進行準確的拆分。

清分執行器實現

圖片

通過實現不同的清分策略可以配置各種不同的清分執行器，來滿足不同的業務分成訴求。

整體清分流程

圖片

在進行清分時，系統首先會獲取需要清分的交易數據，這些數據可能來自于交易系統的實時推送，也可能是定時從數據庫中獲取的批量數據。然后，根據預設的清分規則匹配相應的清分執行器。匹配成功后，運行清分執行器對數據進行計算，計算過程中會考慮到各種因素，如不同業務的分成比例、是否有運營獎懲等。計算完成后，得到清分結果并將其落庫存儲，以便后續結算系統使用。在這個過程中，系統會對每一步操作進行記錄和監控，確保清分過程的準確性和可追溯性。

2.結算系統

結算系統結算系統通過訂閱清分數據，即可實現結算指定分成方的分成的匯總結算：

• 結算系統支持到了最小時間粒度為天，最小實體粒度為SPU的結算
• 接入了裝扮&收藏集&充電+和單片充電多個業務的結算
• 商品SPU緯度或者mid緯度可通過結算規則的綁定對公或者對私結算方式
• 通過對私結算和財務系統滿足的業務的對公&對私打款，實現了合作方的打款流程線上化

圖片

前端

統一營收支付SDK

這是連接用戶與交易系統的重要橋梁，集成了通用支付業務的各項功能。它提供支付全流程服務，包括根據商品信息和用戶選擇生成訂單、調用支付渠道接口發起支付請求、通過輪詢實時獲取支付結果以及處理支付超時、失敗等異常情況。同時，封裝了通用 UI 組件庫，包含商品信息展示、商品數量選擇、支付渠道選擇、支付協議確認、支付按鈕等模塊。業務方可以根據自身需求，靈活組合這些模塊，定制個性化的支付面板，也可以直接使用現成的通用支付面板，快速接入支付功能。

活動類業務可通過配置實現全鏈路接入；定制業務可通過模塊化、插件化開發適配不同需求。

圖片

圖片

圖片

圖片

支付sdk分層設計架構圖：

圖片

支付SDK：收斂通用支付業務，提供支付鏈路全流程SDK

• 訂單創建：根據商品信息和用戶選擇生成訂單。
• 支付發起：調用支付渠道接口發起支付請求。
• 輪詢支付結果：通過輪詢實時獲取支付結果，確保支付狀態同步。
• 異常處理：處理支付超時、失敗等異常情況，提供友好的用戶提示。

通用 Headless UI 組件庫：商品信息展示、商品數量選擇、支付渠道選擇、支付協議確認、支付按鈕等模塊。

開箱即用的解決方案：可以結合業務需求， 靈活組合支付模塊，實現面板的完全定制，也可以使用開箱即用的通用支付面板。

業務接入

活動類新業務接入

交易系統0開發量全鏈路通過配置，客戶端適配sdk后，可實現全流程的商品展示，下單支付，發放業務權益

已有其他業務接入

1. 業務適配評估階段

異構系統兼容性分析

需對存量業務進行全量接口掃描（如訂單創建、支付回調、權益發放），識別與標準交易協議差異點（如字段缺失、異步流程阻塞）

數據模型映射改造

新老系統數據兼容，歷史數據差異清洗處理

2. 前端支付面板適配

通用支付面板適用場景：適用于對支付面板UI樣式無深度定制需求的場景。

• 接入方式：通過npm包 @bilibili/ogv-basic-cashier 快速接入。
• 核心能力：

a.靈活配置：支持通過配置動態開啟或關閉部分支付面板功能。

b.主題化支持：內置多套通用主題，可輕松切換，滿足不同場景的視覺需求。

• 推薦場景：適合追求快速接入、功能標準化且無需復雜UI定制的項目。
• 定制支付面板適用場景：當通用支付面板無法滿足個性化需求時，可選擇定制支付面板。
• 接入方式：基于原子化的 headless UI 組件庫，自由組合面板視圖。
• 核心能力：

a.高度定制化：支持深度定制UI樣式與業務邏輯，滿足個性化需求。

b.支付邏輯解耦：開發者只需專注于UI設計與交互，底層支付邏輯由系統自動處理。

• 推薦場景：適合需要高度定制化UI或特殊業務邏輯的項目。
• 特殊支付流程
• 適用場景：當通用和定制支付面板均無法滿足需求時，可選擇特殊支付流程。
• 接入方式：通過npm包 @bilibili/ogv-quick-pay 接入，直接調用底層支付鏈路。
• 核心能力：

a.底層鏈路開放：提供底層支付能力，支持完全自定義支付流程。

b.極致靈活性：開發者可完全掌控支付邏輯，適配復雜或特殊業務場景。

• 推薦場景：適合需要完全自定義支付流程或處理特殊支付邏輯的項目。

3. 服務端遷移技術難點

核心鏈路灰度策略

• 入口灰度隔離，保證一單請求只會走單一鏈路
• 采用四層灰度機制：功能開關 → 白名單放量 → 比例灰度 → 全量切換
• 訂單數據兼容方案：新老系統并行處理，通過分布式鎖確保冪等性
• 訂單下游業務支持2個系統的數據兼容處理
• 離線數倉數據底表兼容，各類數據統計、BI報表

業務系統兼容適配

• 交易相關交互接口的兼容實現
• 訂單數據的兼容處理

總結

一致性、穩定性

1.數據庫事務控制

• 通過數據庫事務機制，確保數據操作具備原子性、一致性、隔離性和持久性，保障系統數據的完整性和準確性。交易中多表操作由事務管理，異常時回滾避免數據錯誤。

2.分布式鎖機制

• 在分布式系統環境下，采用分布式鎖機制，防止多進程或線程同時操作同一數據，避免數據沖突和不一致。如在高并發訂單處理場景中保障訂單狀態更新準確。

3.冪等性設計

• 系統遵循冪等性原則，多次執行同一操作結果相同，避免因網絡問題或重復提交導致數據錯誤和重復操作，如支付場景中防止重復扣款。

4.對賬系統

• 建立自動化對賬體系，定期核對訂單數據，及時發現和處理數據不一致問題，防控資金風險，確保訂單準確性和安全性。

5.超時異常補償任務

• 針對系統異常，設計補償任務機制，減少異常對業務和用戶的影響。如系統故障導致履約失敗時，為用戶退還費用或提供補償。

6.分級的限流策略

• 根據不同付費場景，對請求進行隔離，為不同業務方配置限流保護，確保系統在高流量下穩定運行。

展望

系統架構優化：

持續優化系統架構，采用更先進的技術架構和設計理念，提高系統的性能、擴展性和可維護性。

創新業務模式：

結合市場需求和技術發展趨勢，探索創新業務模式和產品服務，滿足業務多樣化的需求。

構建生態系統：

構建開放、共享、協同的交易生態系統，整合上下游資源，實現各方協同發展和價值共創。

本文全面呈現了大會員交易系統的建設情況，涵蓋架構設計、核心模塊實現、穩定性保障，為同類系統建設提供部分參考。