為了更好地支持交易業(yè)務(wù)的快速發(fā)展，馬蜂窩支付中心從最初只支持基礎(chǔ)支付和退款的「刀耕火種」階段，經(jīng)歷了架構(gòu)調(diào)整的「刮骨療傷」階段，完成了到實(shí)現(xiàn)綜合產(chǎn)品平臺形態(tài)的「沉淀蓄力」階段的演進(jìn)。
目前，馬蜂窩支付中心集成了包括基礎(chǔ)訂單、收銀臺、路由管理、支付通道、清算核對、報表統(tǒng)計等多種能力，為馬蜂窩度假（平臺、定制）、交通（機(jī)票、火車票、用車）、酒店（開放平臺、代理商）等近 20 條業(yè)務(wù)線提供服務(wù)。本文將圍繞支付中心整體演變過程中不同階段的核心部分進(jìn)行簡要介紹。
支付中心
1.0
初期為快速響應(yīng)業(yè)務(wù)的支付、退款以及一些基礎(chǔ)需求，支付中心主要負(fù)責(zé)接入支付通道（支付寶、微信、連連等），由各業(yè)務(wù)線分別實(shí)現(xiàn)收銀臺，然后調(diào)用支付中心進(jìn)行支付。業(yè)務(wù)系統(tǒng)、支付中心和第三方通道的交互流程圖如下：
各系統(tǒng)交互流程為：
業(yè)務(wù)線將訂單信息封裝后請求到支付中心
支付中心對訂單信息簡要處理后增加支付信息請求到第三方支付通道
第三方支付通道將支付結(jié)果異步回調(diào)到支付中心
支付中心將第三方響應(yīng)的數(shù)據(jù)簡易處理后同步通知到各業(yè)務(wù)系統(tǒng)
業(yè)務(wù)系統(tǒng)進(jìn)行邏輯處理、用戶通知及頁面跳轉(zhuǎn)等
業(yè)務(wù)發(fā)展初期，業(yè)務(wù)量較小，交易場景也比較單一，這樣的設(shè)計可以快速響應(yīng)業(yè)務(wù)需求，實(shí)現(xiàn)功能。但當(dāng)業(yè)務(wù)復(fù)雜性不斷提高，接入的業(yè)務(wù)也越來越多時，該架構(gòu)就顯得力不從心了。各業(yè)務(wù)線需要重復(fù)開發(fā)一些功能，并且支付中心不具備整體管控能力，開發(fā)維護(hù)成本越來越大。主要的問題包括：
維護(hù)成本高：各業(yè)務(wù)線需單獨(dú)維護(hù)收銀臺，調(diào)用支付系統(tǒng)完成支付，需分別保證冪等、安全等問題
容災(zāi)能力差：所有功能集中在一個大模塊里，某個功能出問題，直接影響全部
結(jié)構(gòu)不合理：架構(gòu)單一，不能滿足復(fù)雜業(yè)務(wù)場景
系統(tǒng)職責(zé)亂：收銀臺維護(hù)了收款方式及部分業(yè)務(wù)路由，缺乏統(tǒng)一的管控
為了兼顧對快速發(fā)展中的業(yè)務(wù)的需求響應(yīng)和系統(tǒng)的高可用性，保證線上服務(wù)的質(zhì)量，我們快速進(jìn)行了架構(gòu)調(diào)整，開始了向支付中心 2.0 的演進(jìn)。
支付中心
2.0
2.0 架構(gòu)將各業(yè)務(wù)的公共交易、支付、財務(wù)等沉淀到支付中心，并主要解決了以下三個主要問題：
建立基礎(chǔ)訂單、支付、財務(wù)統(tǒng)一體系，抽象和封裝公共處理邏輯，形成統(tǒng)一的基礎(chǔ)服務(wù)，降低業(yè)務(wù)的接入成本及重復(fù)研發(fā)成本；
構(gòu)建安全、穩(wěn)定、可擴(kuò)展的系統(tǒng)，為業(yè)務(wù)的快速發(fā)展和創(chuàng)新需求提供基礎(chǔ)支撐，解決業(yè)務(wù)「快」和支付「穩(wěn)」之間的矛盾；
沉淀核心交易數(shù)據(jù)，同時為用戶、商家、財務(wù)提供大數(shù)據(jù)支撐。
2.1 核心能力
支付中心 2.0 是整個交易系統(tǒng)快速發(fā)展的重要時段。在此過程中，不僅要進(jìn)行架構(gòu)的升級，還要保證服務(wù)的穩(wěn)定。
目前支付中心對業(yè)務(wù)提供的主要能力包括：
平臺支付：用戶可以使用微信、支付寶等第三方平臺來完成支付
快捷支付：用戶提供銀行卡信息，進(jìn)行便捷支付
協(xié)議支付：用戶完成授權(quán)后，可以在不打斷用戶體驗(yàn)的場景下進(jìn)行便捷支付
信用支付：用戶可以選擇花唄等分期產(chǎn)品進(jìn)行透支支付
境外支付：用戶可以選擇境外支付通道完成境外產(chǎn)品的購買
線下支付：用戶可以選擇ToB通道完成特定場景的支付
針對馬蜂窩業(yè)務(wù)的特點(diǎn)，目前支持的核心交易場景包括：
支付和退款：適用于普通商品的購買及退款
拆分支付：適用于限額或金額較大場景
合單支付：適用于保險等分賬到不同收款賬號的場景
2.2 架構(gòu)設(shè)計
演進(jìn)過程中，首先是對相對獨(dú)立，同時作為統(tǒng)一體系基礎(chǔ)的網(wǎng)關(guān)進(jìn)行模塊化。支付網(wǎng)關(guān)對外抽象出支付、退款、查詢這些標(biāo)準(zhǔn)請求，然后在網(wǎng)關(guān)基礎(chǔ)上逐步梳理各支付通道，并逐步抽取出基礎(chǔ)訂單模塊，解耦業(yè)務(wù)功能與支付功能，同時可支持復(fù)雜的業(yè)務(wù)場景。目前的系統(tǒng)功能整體架構(gòu)如下：
如圖所示，從架構(gòu)上主要分為三個層次：
產(chǎn)品層：組合核心層提供的支付能力，對終端用戶提供收銀臺、對運(yùn)營財務(wù)人員提供運(yùn)營財務(wù)系統(tǒng)
核心層：支付中心核心模塊，包括基礎(chǔ)訂單、支付路由、支付通道等
支撐層：用來支撐整個系統(tǒng)的基礎(chǔ)設(shè)施，包括監(jiān)控報警、日志、消息隊(duì)列等
2.2.1 產(chǎn)品層
產(chǎn)品層主要包含消費(fèi)者可見的收銀臺、支付管理后臺和財務(wù)核算、對賬的財會系統(tǒng)。本文重點(diǎn)介紹收銀臺的設(shè)計思路。
收銀臺
收銀臺包含 H5 收銀臺和 PC 收銀臺兩部分：
移動端：
PC 端：
如上圖所示，收銀臺主要由三部分組成：訂單基本信息（含訂單號及支付金額）、訂單詳情（含日期信息、商品信息及基礎(chǔ)信息）、支付方式（平臺支付、信用支付等）。
由于收銀臺是整個支付中心面向用戶的唯一入口，用戶體驗(yàn)及安全性至關(guān)重要。為同時支持業(yè)務(wù)個性化和用戶的一致性體驗(yàn)，收銀臺主要是通過定制化和配置化的方式實(shí)現(xiàn)。對業(yè)務(wù)同學(xué)來講接入也非常簡單，僅需通過訂單號跳轉(zhuǎn)至收銀臺頁面，后續(xù)流程均由支付中心完成。
用戶下單后到達(dá)收銀臺頁面，收銀臺通過訂單所屬業(yè)務(wù)線、支付金額、是否合單等信息，展示可用的支付通道。同時風(fēng)控系統(tǒng)會從商品、訂單、用戶行為等維度進(jìn)行監(jiān)控，屏蔽高風(fēng)險的支付渠道。支付渠道出現(xiàn)故障時可在收銀臺暫停展示。
（1）定制化
為支持統(tǒng)一收銀臺下各業(yè)務(wù)線不同模式、不同展示的特性，使用工廠類繼承的模式實(shí)現(xiàn)各業(yè)務(wù)數(shù)據(jù)及展示樣式。
收銀臺主要屬性分為展示模塊和通道路由，其中重復(fù)及默認(rèn)功能的模塊由抽象類用模板的方式實(shí)現(xiàn)，子類使用默認(rèn)方法或者重寫父類方法即可達(dá)到自定義的實(shí)現(xiàn)。
收銀臺展示實(shí)現(xiàn)類已經(jīng)實(shí)現(xiàn)了一套默認(rèn)的收銀臺，其中包含大多數(shù)必須的組件（如倒計時，頭部定制，訂單詳情等）。
一般情況下，各個業(yè)務(wù)線僅需簡單添加特定的實(shí)現(xiàn)類，即可生成一個清晰又豐富的頁面
（2）配置化
收銀臺的配置化主要根據(jù)各業(yè)務(wù)的屬性（業(yè)務(wù)類型、品類等）對后續(xù)操作做一定的流程處理配置化，比如：
基于后端路由對收銀臺展示層做不同的處理，用戶看到的可支持的通道列表（微信、支付寶等），以及排序置頂打標(biāo)記等
滿足不同場景、不同業(yè)務(wù)在同一種支付方式下收款到不同的收款賬號
根據(jù)場景不同，走不同的結(jié)算方式，以及結(jié)算渠道等
2.2.2 核心層
支付中心中的核心模塊，包括基礎(chǔ)訂單、支付路由、支付通道等。
基礎(chǔ)訂單
基礎(chǔ)訂單系統(tǒng)是連接交易業(yè)務(wù)線、支付中心和結(jié)算系統(tǒng)的橋梁，實(shí)現(xiàn)了業(yè)務(wù)和支付結(jié)算解耦。主要涵蓋了業(yè)務(wù)創(chuàng)建訂單、關(guān)單、支付、退款、回調(diào)通知等 API 模塊?；A(chǔ)數(shù)據(jù)支持普通支付、合單支付、拆分支付、保險支付等多種場景的支付功能，各個系統(tǒng)的交互流程如下：
目前基礎(chǔ)訂單系統(tǒng)可支持如下兩種特殊場景：
（1）一訂單 VS 多商品
創(chuàng)建一個基礎(chǔ)訂單可以包含 N 個商品（商品信息包含商品名稱、商品 ID、單價、數(shù)量、折扣等，訂單信息包含用戶 UID、手機(jī)號、支付金額、訂單折扣等匯總基礎(chǔ)信息），N 個商品對應(yīng) M 個業(yè)務(wù)子訂單 (M≦N)，所有業(yè)務(wù)子訂單的業(yè)務(wù)類型若一樣則為普通模式，否則為搭售模式；每個業(yè)務(wù)訂單對應(yīng)一個對賬單元（支付成功后會將支付信息同步給對賬系統(tǒng)），一訂單 VS 多商品的創(chuàng)單模式基本支持目前所有場景，包括未來可能的購物車模式。
（2）一訂單 VS 多支付單
普通訂單用戶選擇支付寶、微信等渠道會生成一個支付單；當(dāng)金額超過 5000 元時可以選擇拆分訂單金額支付，此時會生成多個支付單；如果下單勾選保險就會走第三方合單支付，會生成兩個支付單；同時拆分支付也會導(dǎo)致用戶部分支付或者超額支付，監(jiān)控會針對異常支付情況進(jìn)行自動退款；大金額訂單有 10% 以上的轉(zhuǎn)換率提升, 一訂單 VS 多支付單模型更好的支持了馬蜂窩的支付場景。
通道路由管理
通道路由主要包含兩方面，一個是業(yè)務(wù)側(cè)需要控制支付通道，一個是支付側(cè)需要選擇支付賬戶。
（1）支付賬戶管理
支付創(chuàng)建訂單和處理回調(diào)等流程中，需要根據(jù)業(yè)務(wù)類型、支付方式和支付通道確定支付賬號，早期版本這個對應(yīng)關(guān)系是通過配置文件維護(hù)的。一個業(yè)務(wù)類型對應(yīng)多個配置項(xiàng)，每新增一個業(yè)務(wù)需要增加多個配置，而且隨著更多支付通道的接入，新增業(yè)務(wù)需要配置的信息也越來越多，不易維護(hù)。
經(jīng)過優(yōu)化，把現(xiàn)有的配置對應(yīng)關(guān)系放到數(shù)據(jù)庫中，數(shù)據(jù)表由業(yè)務(wù)類型、支付方式、支付通道唯一確定一個收款賬號，支付賬號的具體參數(shù)信息還是放在文件配置中。創(chuàng)建訂單時根據(jù)業(yè)務(wù)類型、支付方式、支付通道查詢收款賬號，把賬號信息記錄到支付訂單數(shù)據(jù)表，回調(diào)時直接從訂單表查詢支付賬號。
（2）支付通道管理
目前對接了支付寶、支付寶國際、微信、京東支付、applepay、連連支付、銀聯(lián) 2B 等第三方通道，每一個通道下有多個支付產(chǎn)品。第三方通道的接口形式差異很大，但是都提供下單、退款、查詢、支付通知、賬單下載等標(biāo)準(zhǔn)功能。支付中心對這些支付通道做了一次封裝，用一個抽象類作為基類，使用模版方法設(shè)計模式，在基類中定義了一個標(biāo)準(zhǔn)流程，具體的實(shí)現(xiàn)在通道各自的實(shí)現(xiàn)類中。客戶類只需要關(guān)心基類的公共方法，和具體通道無關(guān)。
2.2.3 支撐層
支撐層包含監(jiān)控報警、日志管理、加簽驗(yàn)簽、配置管理、消息總線等模塊。其中日志使用 ELK 進(jìn)行收集管理，系統(tǒng)配置采用公司自研的分布式配置中心進(jìn)行管理，消息總線也是使用公司二次封裝的 RabbitMQ 進(jìn)行消息分發(fā)及消費(fèi)。
由于支付系統(tǒng)對可用性有極高要求以及支付數(shù)據(jù)的敏感性，支付中心獨(dú)立實(shí)現(xiàn)了監(jiān)控報警系統(tǒng)，下面將詳細(xì)描述該監(jiān)控報警系統(tǒng)的功能及設(shè)計思路。
監(jiān)控系統(tǒng)
為保證監(jiān)控的實(shí)時性及有效性，監(jiān)控依賴的資源如數(shù)據(jù)庫必須和業(yè)務(wù)庫要進(jìn)行隔離（避免雞蛋放在同一個籃子里）。支付監(jiān)控系統(tǒng)涵蓋了 API 監(jiān)控、 服務(wù)性能監(jiān)控、數(shù)據(jù)庫監(jiān)控等，能夠提供統(tǒng)一的報警、分析和故障排除能力。從異常數(shù)據(jù)采集到故障問題主動發(fā)現(xiàn)及穩(wěn)定性趨勢分析，為支付體系優(yōu)化提供數(shù)據(jù)支撐。
（1）監(jiān)控后臺
后臺主要包含監(jiān)控用戶管理以及監(jiān)控項(xiàng)創(chuàng)建管理，用戶可以根據(jù)需求對應(yīng)的監(jiān)控項(xiàng)目，可配置的參數(shù)涵蓋 API 請求地址、請求方式、可用性、正確性、 響應(yīng)時間等性能數(shù)據(jù)以及報警方式和策略；詳細(xì)配置如下圖：
接口監(jiān)控可以針對固定 host IP 綁定以及設(shè)置超時時間，監(jiān)控請求支持 GET、POST 兩種方式，POST 方式可以設(shè)置固定請求參數(shù)輔助，監(jiān)控頻率支持分鐘、秒兩種級別配置；響應(yīng)數(shù)據(jù)模塊可以校驗(yàn) HTTP code 是否異常，配置響應(yīng)數(shù)據(jù)類型，比較檢測返回 key 值，針對 DB 監(jiān)控還可以設(shè)置 DB 查詢超時時間；報警模塊目前支持短信和郵件兩種方式，可以設(shè)置最小、最大報警閾值，超過最大閾值每隔最大報警數(shù)會觸發(fā)一次報警，規(guī)避了故障期間短信轟炸問題。
（2）監(jiān)控核心
為了實(shí)現(xiàn)最快監(jiān)控頻率 10 秒，同時可以支持成千上萬的監(jiān)控項(xiàng)并行運(yùn)行，支付監(jiān)控采用了多進(jìn)程管理的方式。父進(jìn)程創(chuàng)建指定數(shù)量的子進(jìn)程，每個子進(jìn)程完成固定數(shù)量的監(jiān)控任務(wù)退出任務(wù)，此時父進(jìn)程實(shí)時監(jiān)控子進(jìn)程狀態(tài)并創(chuàng)建新的子進(jìn)程執(zhí)行任務(wù)；父進(jìn)程還可以接受外部信號完成服務(wù)重啟以及停止，流程如下：
（3）監(jiān)控報警
執(zhí)行監(jiān)控項(xiàng)會根據(jù)監(jiān)控配置進(jìn)行接口請求以及返回數(shù)據(jù)分析處理，然后通過 Redis 計數(shù)方式按報警策略進(jìn)行報警通知。日常監(jiān)控短信示例：
2.3 實(shí)踐經(jīng)驗(yàn)
（1）數(shù)據(jù)一致性
上文提到，我們采用模塊化的方式來解耦業(yè)務(wù)功能與支付功能。在這個過程中，每引入一個模塊就會涉及到系統(tǒng)交互問題，因此最核心的便是數(shù)據(jù)一致性問題。針對數(shù)據(jù)一致性問題需要引入事務(wù)，實(shí)時、延遲校驗(yàn)以及補(bǔ)償機(jī)制保證數(shù)據(jù)的最終一致性。從架構(gòu)看是很清晰的，但是對于整個改造過程是艱難的，猶如給飛行的飛機(jī)更換發(fā)動機(jī)，所以我們也把這個過程形容為一個刮骨療傷的階段。
（2）穩(wěn)定性
支付服務(wù)都是由第三方支付通道提供的，支付通道存在不穩(wěn)定性。比如用戶用支付寶支付了一筆訂單，由于各種原因，支付中心沒有收到支付成功的通知，用戶又用微信再次付款，導(dǎo)致重復(fù)支付。
為了解決這個問題，支付中心采用定時掃描的策略，主動發(fā)現(xiàn)重復(fù)支付單并自動執(zhí)行退款，不需要人工參與。退款流程中，退款單需要經(jīng)過申請、審核、調(diào)用退款接口等流程，在調(diào)接口環(huán)節(jié)，可能會發(fā)生失敗。調(diào)用失敗的退款單，會根據(jù)退避算法發(fā)起重試，逐漸加大重試間隔，直到次數(shù)超過限制。失敗單數(shù)量超過閾值、或者有訂單處于失敗時間超過閾值時會觸發(fā)報警。自動處理不了的退款單可以人工檢測，或線下退款。
總結(jié) &
展望
目前，馬蜂窩支付中心已經(jīng)具備支持多業(yè)務(wù)、多場景、多支付方式的能力，但想要實(shí)現(xiàn)一個真正意義上「百花齊放」的平臺，還有很多地方需要改進(jìn)和完善。
即將到來的支付中心 3.0 將以微服務(wù)的思想把單體應(yīng)用按照業(yè)務(wù)進(jìn)行解耦，會逐漸從一個高耦合的單一系統(tǒng)演變?yōu)楸姸嘧酉到y(tǒng)組成的高并發(fā)、高可用、支持更多交易支付場景的分布式系統(tǒng)。微服務(wù)化拆分后，在系統(tǒng)結(jié)構(gòu)上將更加清晰，但對于整體系統(tǒng)的開發(fā)管理和維護(hù)也將帶來更大的挑戰(zhàn)。
伴隨馬蜂窩「內(nèi)容+交易」的戰(zhàn)略升級，支付中心也會探索更多的支付方式和能力，持續(xù)為各業(yè)務(wù)線賦能。
本文作者：馬蜂窩電商支付結(jié)算團(tuán)隊(duì)。
擴(kuò)展閱讀：馬蜂窩大交通業(yè)務(wù)監(jiān)控報警系統(tǒng)架構(gòu)設(shè)計與實(shí)現(xiàn)、馬蜂窩實(shí)時計算平臺演進(jìn)之路
版權(quán)申明：內(nèi)容來源網(wǎng)絡(luò)，版權(quán)歸原創(chuàng)者所有。除非無法確認(rèn)，我們都會標(biāo)明作者及出處，如有侵權(quán)煩請告知，我們會立即刪除并表示歉意。謝謝。
