馬蜂窩支付中心架構演進

爲了更好地支持交易業務的快速發展，馬蜂窩支付中心從最初只支持基礎支付和退款的「刀耕火種」階段，經歷了架構調整的「刮骨療傷」階段，完成了到實現綜合產品平臺形態的「沉澱蓄力」階段的演進。

目前，馬蜂窩支付中心集成了包括基礎訂單、收銀臺、路由管理、支付通道、清算覈對、報表統計等多種能力，爲馬蜂窩度假（平臺、定製）、交通（機票、火車票、用車）、酒店（開放平臺、代理商）等近 20 條業務線提供服務。本文將圍繞支付中心總體演變過程當中不一樣階段的核心部分進行簡要介紹。

1、支付中心 1.0

初期爲快速響應業務的支付、退款以及一些基礎需求，支付中心主要負責接入支付通道（支付寶、微信、連連等），由各業務線分別實現收銀臺，而後調用支付中心進行支付。業務系統、支付中心和第三方通道的交互流程圖以下：

各系統交互流程爲：

1. 業務線將訂單信息封裝後請求到支付中心
2. 支付中心對訂單信息簡要處理後增長支付信息請求到第三方支付通道
3. 第三方支付通道將支付結果異步回調到支付中心
4. 支付中心將第三方響應的數據簡易處理後同步通知到各業務系統
5. 業務系統進行邏輯處理、用戶通知及頁面跳轉等

業務發展初期，業務量較小，交易場景也比較單一，這樣的設計能夠快速響應業務需求，實現功能。但當業務複雜性不斷提升，接入的業務也愈來愈多時，該架構就顯得力不從心了。各業務線須要重複開發一些功能，而且支付中心不具有總體管控能力，開發維護成本愈來愈大。主要的問題包括：

• 維護成本高：各業務線需單獨維護收銀臺，調用支付系統完成支付，需分別保證冪等、安全等問題
• 容災能力差：全部功能集中在一個大模塊裏，某個功能出問題，直接影響所有
• 結構不合理：架構單一，不能知足複雜業務場景
• 系統職責亂：收銀臺維護了收款方式及部分業務路由，缺少統一的管控

爲了兼顧對快速發展中的業務的需求響應和系統的高可用性，保證線上服務的質量，咱們快速進行了架構調整，開始了向支付中心 2.0 的演進。

2、支付中心 2.0

2.0 架構將各業務的公共交易、支付、財務等沉澱到支付中心，並主要解決了如下三個主要問題：

• 創建基礎訂單、支付、財務統一體系，抽象和封裝公共處理邏輯，造成統一的基礎服務，下降業務的接入成本及重複研發成本；
• 構建安全、穩定、可擴展的系統，爲業務的快速發展和創新需求提供基礎支撐，解決業務「快」和支付「穩」之間的矛盾；
• 沉澱核心交易數據，同時爲用戶、商家、財務提供大數據支撐。

2.1 核心能力

支付中心 2.0 是整個交易系統快速發展的重要時段。在此過程當中，不只要進行架構的升級，還要保證服務的穩定。

目前支付中心對業務提供的主要能力包括：

• 平臺支付：用戶可使用微信、支付寶等第三方平臺來完成支付
• 快捷支付：用戶提供銀行卡信息，進行便捷支付
• 協議支付：用戶完成受權後，能夠在不打斷用戶體驗的場景下進行便捷支付
• 信用支付：用戶能夠選擇花唄等分期產品進行透支支付
• 境外支付：用戶能夠選擇境外支付通道完成境外產品的購買
• 線下支付：用戶能夠選擇 ToB 通道完成特定場景的支付

針對馬蜂窩業務的特色，目前支持的核心交易場景包括：

• 支付和退款：適用於普通商品的購買及退款
• 拆分支付：適用於限額或金額較大場景
• 合單支付：適用於保險等分帳到不一樣收款帳號的場景

2.2 架構設計

演進過程當中，首先是對相對獨立，同時做爲統一體系基礎的網關進行模塊化。支付網關對外抽象出支付、退款、查詢這些標準請求，而後在網關基礎上逐步梳理各支付通道，並逐步抽取出基礎訂單模塊，解耦業務功能與支付功能，同時可支持複雜的業務場景。目前的系統功能總體架構以下：

如圖所示，從架構上主要分爲三個層次：

• **產品層：**組合核心層提供的支付能力，對終端用戶提供收銀臺、對運營財務人員提供運營財務系統
• **核心層：**支付中心核心模塊，包括基礎訂單、支付路由、支付通道等
• **支撐層：**用來支撐整個系統的基礎設施，包括監控報警、日誌、消息隊列等

2.2.1 產品層

產品層主要包含消費者可見的收銀臺、支付管理後臺和財務覈算、對帳的財會系統。本文重點介紹收銀臺的設計思路。

收銀臺

收銀臺包含 H5 收銀臺和 PC 收銀臺兩部分：

移動端：

PC端：

如上圖所示，收銀臺主要由三部分組成：訂單基本信息（含訂單號及支付金額）、訂單詳情（含日期信息、商品信息及基礎信息）、支付方式（平臺支付、信用支付等）。

因爲收銀臺是整個支付中心面向用戶的惟一入口，用戶體驗及安全性相當重要。爲同時支持業務個性化和用戶的一致性體驗，收銀臺主要是經過定製化和配置化的方式實現。對業務同窗來說接入也很是簡單，僅需經過訂單號跳轉至收銀臺頁面，後續流程均由支付中心完成。

用戶下單後到達收銀臺頁面，收銀臺經過訂單所屬業務線、支付金額、是否合單等信息，展現可用的支付通道。同時風控系統會從商品、訂單、用戶行爲等維度進行監控，屏蔽高風險的支付渠道。支付渠道出現故障時可在收銀臺暫停展現。

（1）定製化

• 爲支持統一收銀臺下各業務線不一樣模式、不一樣展現的特性，使用工廠類繼承的模式實現各業務數據及展現樣式。
• 收銀臺主要屬性分爲展現模塊和通道路由，其中重複及默認功能的模塊由抽象類用模板的方式實現，子類使用默認方法或者重寫父類方法便可達到自定義的實現。
• 收銀臺展現實現類已經實現了一套默認的收銀臺，其中包含大多數必須的組件（如倒計時，頭部定製，訂單詳情等）。
• 通常狀況下，各個業務線僅需簡單添加特定的實現類，便可生成一個清晰又豐富的頁面

（2）配置化

收銀臺的配置化主要根據各業務的屬性（業務類型、品類等）對後續操做作必定的流程處理配置化，好比：

• 基於後端路由對收銀臺展現層作不一樣的處理，用戶看到的可支持的通道列表（微信、支付寶等），以及排序置頂打標記等
• 知足不一樣場景、不一樣業務在同一種支付方式下收款到不一樣的收款帳號
• 根據場景不一樣，走不一樣的結算方式，以及結算渠道等

2.2.2 核心層

支付中心中的核心模塊，包括基礎訂單、支付路由、支付通道等。

基礎訂單

基礎訂單系統是鏈接交易業務線、支付中心和結算系統的橋樑，實現了業務和支付結算解耦。主要涵蓋了業務建立訂單、關單、支付、退款、回調通知等 API 模塊。基礎數據支持普通支付、合單支付、拆分支付、保險支付等多種場景的支付功能，各個系統的交互流程以下：

目前基礎訂單系統可支持以下兩種特殊場景：

（1）一訂單 VS 多商品

建立一個基礎訂單能夠包含 N 個商品（商品信息包含商品名稱、商品 ID、單價、數量、折扣等，訂單信息包含用戶 UID、手機號、支付金額、訂單折扣等彙總基礎信息），N 個商品對應 M 個業務子訂單 (M≦N)，全部業務子訂單的業務類型若同樣則爲普通模式，不然爲搭售模式；每一個業務訂單對應一個對帳單元（支付成功後會將支付信息同步給對帳系統），一訂單 VS 多商品的創單模式基本支持目前全部場景，包括將來可能的購物車模式。

（2）一訂單 VS 多支付單

普通訂單用戶選擇支付寶、微信等渠道會生成一個支付單；當金額超過 5000 元時能夠選擇拆分訂單金額支付，此時會生成多個支付單；若是下單勾選保險就會走第三方合單支付，會生成兩個支付單；同時拆分支付也會致使用戶部分支付或者超額支付，監控會針對異常支付狀況進行自動退款；大金額訂單有 10% 以上的轉換率提高, 一訂單 VS 多支付單模型更好的支持了馬蜂窩的支付場景。

通道路由管理

通道路由主要包含兩方面，一個是業務側須要控制支付通道，一個是支付側須要選擇支付帳戶。

（1）支付帳戶管理

支付建立訂單和處理回調等流程中，須要根據業務類型、支付方式和支付通道肯定支付帳號，早期版本這個對應關係是經過配置文件維護的。一個業務類型對應多個配置項，每新增一個業務須要增長多個配置，並且隨着更多支付通道的接入，新增業務須要配置的信息也愈來愈多，不易維護。

通過優化，把現有的配置對應關係放到數據庫中，數據表由業務類型、支付方式、支付通道惟一肯定一個收款帳號，支付帳號的具體參數信息仍是放在文件配置中。建立訂單時根據業務類型、支付方式、支付通道查詢收款帳號，把帳號信息記錄到支付訂單數據表，回調時直接從訂單表查詢支付帳號。

（2）支付通道管理

目前對接了支付寶、支付寶國際、微信、京東支付、applepay、連連支付、銀聯 2B 等第三方通道，每個通道下有多個支付產品。第三方通道的接口形式差別很大，可是都提供下單、退款、查詢、支付通知、帳單下載等標準功能。支付中心對這些支付通道作了一次封裝，用一個抽象類做爲基類，使用模版方法設計模式，在基類中定義了一個標準流程，具體的實如今通道各自的實現類中。客戶類只須要關心基類的公共方法，和具體通道無關。

2.2.3 支撐層

支撐層包含監控報警、日誌管理、加簽驗籤、配置管理、消息總線等模塊。其中日誌使用 ELK 進行收集管理，系統配置採用公司自研的分佈式配置中心進行管理，消息總線也是使用公司二次封裝的 RabbitMQ 進行消息分發及消費。

因爲支付系統對可用性有極高要求以及支付數據的敏感性，支付中心獨立實現了監控報警系統，下面將詳細描述該監控報警系統的功能及設計思路。

監控系統

爲保證監控的實時性及有效性，監控依賴的資源如數據庫必須和業務庫要進行隔離（避免雞蛋放在同一個籃子裏）。支付監控系統涵蓋了 API 監控、 服務性能監控、數據庫監控等，可以提供統一的報警、分析和故障排除能力。從異常數據採集到故障問題主動發現及穩定性趨勢分析，爲支付體系優化提供數據支撐。

（1）監控後臺

後臺主要包含監控用戶管理以及監控項建立管理，用戶能夠根據需求對應的監控項目，可配置的參數涵蓋 API 請求地址、請求方式、可用性、正確性、 響應時間等性能數據以及報警方式和策略；詳細配置以下圖：

接口監控能夠針對固定 host IP 綁定以及設置超時時間，監控請求支持 GET、POST 兩種方式，POST 方式能夠設置固定請求參數輔助，監控頻率支持分鐘、秒兩種級別配置；響應數據模塊能夠校驗 HTTP code 是否異常，配置響應數據類型，比較檢測返回 key 值，針對 DB 監控還能夠設置 DB 查詢超時時間；報警模塊目前支持短信和郵件兩種方式，能夠設置最小、最大報警閾值，超過最大閾值每隔最大報警數會觸發一次報警，規避了故障期間短信轟炸問題。

（2）監控核心

爲了實現最快監控頻率 10 秒，同時能夠支持成千上萬的監控項並行運行，支付監控採用了多進程管理的方式。父進程建立指定數量的子進程，每一個子進程完成固定數量的監控任務退出任務，此時父進程實時監控子進程狀態並建立新的子進程執行任務；父進程還能夠接受外部信號完成服務重啓以及中止，流程以下：

（3）監控報警

執行監控項會根據監控配置進行接口請求以及返回數據分析處理，而後經過 Redis 計數方式按報警策略進行報警通知。平常監控短信示例：

2.3 實踐經驗

（1）數據一致性

上文提到，咱們採用模塊化的方式來解耦業務功能與支付功能。在這個過程當中，每引入一個模塊就會涉及到系統交互問題，所以最核心的即是數據一致性問題。針對數據一致性問題須要引入事務，實時、延遲校驗以及補償機制保證數據的最終一致性。從架構看是很清晰的，可是對於整個改造過程是艱難的，猶如給飛行的飛機更換髮動機，因此咱們也把這個過程形容爲一個刮骨療傷的階段。

（2）穩定性

支付服務都是由第三方支付通道提供的，支付通道存在不穩定性。好比用戶用支付寶支付了一筆訂單，因爲各類緣由，支付中心沒有收到支付成功的通知，用戶又用微信再次付款，致使重複支付。

爲了解決這個問題，支付中心採用定時掃描的策略，主動發現重複支付單並自動執行退款，不須要人工參與。退款流程中，退款單須要通過申請、審覈、調用退款接口等流程，在調接口環節，可能會發生失敗。調用失敗的退款單，會根據退避算法發起重試，逐漸加大重試間隔，直到次數超過限制。失敗單數量超過閾值、或者有訂單處於失敗時間超過閾值時會觸發報警。自動處理不了的退款單能夠人工檢測，或線下退款。

3、總結 & 展望

目前，馬蜂窩支付中心已經具有支持多業務、多場景、多支付方式的能力，但想要實現一個真正意義上「百花齊放」的平臺，還有不少地方須要改進和完善。

即將到來的支付中心 3.0 將以微服務的思想把單體應用按照業務進行解耦，會逐漸從一個高耦合的單一系統演變爲衆多子系統組成的高併發、高可用、支持更多交易支付場景的分佈式系統。微服務化拆分後，在系統結構上將更加清晰，但對於總體系統的開發管理和維護也將帶來更大的挑戰。

伴隨馬蜂窩「內容+交易」的戰略升級，支付中心也會探索更多的支付方式和能力，持續爲各業務線賦能。

本文做者：馬蜂窩電商支付結算團隊。

（馬蜂窩技術原創內容，轉載務必註明出處保存文末二維碼圖片，謝謝配合。）