概述

支付系統是連接消費者、商家（或平臺）和金融機構的橋梁，管理支付數據，調用第三方支付平臺接口，記錄支付信息（對應訂單號，支付金額等），金額對賬等功能，根據不同公司對于支付業務的定位不同大概有幾個階段：第一階段：支付作為一個（封閉）的、獨立的應用系統，為各系統提供支付功能支持。一般來說，這個系統僅限于為公司內部的業務提供支付支持，并且和業務緊密耦合。第二階段：支付作為一個開發的系統，為公司內外部系統、各種業務提供支付服務，支付服務本身應該是和具體的業務解耦合。

?

? ? ? 支付是電商系統中核心

我們先來看一下用戶完成一次購物需要進行那些操作：

通常消費者在手機APP或者網站都會涉及到支付相關的業務場景，用戶只需要簡單點擊支付按鈕輸入支付密碼，就可以完成整個支付過程，那么我就和大家一起來看看一個完整的支付系統有什么功能組成和設計時需要考慮那些問題。

?

01

支付系統的作用

從上圖中我們可以看出真實的資金流向。首先當用戶產生支付行為時，資金從用戶端流向支付系統，退款時則相反，從支付系統回流至用戶端。因此在整個交易過程中用戶端與支付系統是雙向資金的流動方式。對于支付系統而言，資金有進有出。從支付系統到商戶端就比較簡單了，在清算完成后支付系統負責將代收的資金結算給商戶，通常結算的操作可以在線上來完成（采用支付公司代付接口或者銀企直連接口來完成），也可以由公司財務通過線下手工轉賬的方式來完成，因此這種資金流動的方式是單向的。出于資金安全考慮，大多數公司通常這部分采用線下方式實現。

真實的資金流由支付公司按照約定期限（通常 T+1 ）結算到平臺公司對公賬戶中，然后再由平臺公司再按照交易明細進行二次清算后結算給對應的商戶。

?

支付系統

一個支付系統需要由哪些功能模塊組成

?

01

完整的支付系統包括如下功能：

應用管理: 同時支持公司多個業務系統對接。

商戶管理: 支持商戶入駐，商戶需要向平臺方提供相關的資料備案。

渠道管理: 支持微信、支付寶、銀聯、京東支付等多種渠道。

賬戶管理: 渠道賬戶管理，支持共享賬戶（個人商戶）及自有賬戶。

支付交易: 生成預支付訂單、提供退款服務。

對賬管理: 實現支付系統的交易數據與第三方支付渠道交易明細的自動核對（通常T+1），確保交易數據的準確性和一致性。

清算管理: 計算收款交易中商戶的應收與支付系統收益。

結算管理: 根據清算結果，將資金劃撥至商戶對應的資金帳戶中。

02

核心流程

支付系統有幾個關鍵的核心流程：支付流程、對賬流程、結算流程

支付流程

支付流程說明

用戶在商城選購商品并發起支付請求；

商城將支付訂單通過B2C網關收款接口傳送至支付網關；

用戶選擇網銀支付及銀行，支付平臺將訂單轉送至指定銀行網關界面；

用戶支付完成，銀行處理結果并向平臺返回處理結果；

支付平臺接收處理結果，落地處理并向商戶返回結果；

商城接收到支付公司返回結果，落地處理（更改訂單狀態）并通知用戶。

一般而言支付系統會給商戶設置有“可用余額”賬戶、“待結算”賬戶；系統在接收到銀行返回支付成功信息會進行落地處理，一方面更改對應訂單狀態，另一方面在商戶待結算賬戶記入一筆金額；該筆金額，系統會根據結算周期從待結算賬戶--->“可用余額”賬戶。

退款流程說明

用戶在商戶平臺發起退款申請，商戶核實退款信息及申請；

商戶登錄支付平臺賬戶/或者通過支付公司提供的退款接口向支付平臺發起退款；

支付系統會對退款信息校驗（退款訂單對應的原訂單是否支付成功？退款金額是否少于等于原訂單金額？），校驗商戶賬戶余額是否充足等；校驗不通過，則無法退款；

支付系統在商戶可用余額賬戶扣除金額，并將退款訂單發送至銀行，銀行完成退款操作。注意：對于網關收款的訂單退款，各銀行要求不一，有些銀行提供的退款接口要求原訂單有效期在90或180天，有些銀行不提供退款接口；針對超期或者不支持接口退款的訂單，支付公司通過代付通道完成退款操作。

對于收單金額未結算，還在“待結算”賬戶的訂單，如果出現退款情況，業務流程和上述流程差不多，只是從待結算賬戶進行扣款。

對賬流程

說明

? ? ? ? 對賬，我們一般稱為勾兌，支付系統的對賬，包含著兩個層面：

支付系統內部間的對賬，支付系統一般是分布式的，整個支付系統被拆分成了多個子系統，如交易系統、賬戶系統、會計系統、賬戶系統，每個子系統在處理各自的業務，系統間的對賬，就是以上系統的核對，用于修正內部系統的數據不一致。

支付系統與渠道的對賬，這里的渠道泛指所有為支付系統提供代收付業務的渠道，如：第三方支付公司、銀行、清算中心、網聯、銀聯等。

支付系統與渠道間的對賬

系統間的對賬比較好理解，這里主要講支付系統與渠道間的對賬。支付系統與渠道間的對賬，又包含2個維度：

信息流勾對：即業務對賬／交易對賬，主要是就收單交易的支付信息與銀行提供的信息流文件進行勾兌。信息流的勾地能發現支付系統與銀行系統間的掉單、兩邊由于系統間的原因導致的同一筆交易支付金額不一致（可能性很小）或者支付狀態不一致。信息流勾兌一般用來恢復掉單數據，可通過補單或者具體系統問題排查解決。

資金流勾對：即資金對賬，主要就收單交易的支付信息與銀行提供的資金流信息進行勾兌。資金流的勾兌能發現支付系統在銀行的帳戶資金實際發生的變動與應該發生的變動的差異，比如長款（銀行多結算給支付系統）和短款（銀行少結算給支付系統）。

說了這么多，就出現來4個對賬文件，支付系統信息流文件、支付系統資金流文件、銀行信息流文件、銀行資金流文件。業務對賬（勾兌）就是支付系統的信息流文件與銀行的信息流文件勾兌，資金對賬即支付系統的資金流文件與銀行的資金流文件勾兌。

核對的差異處理

1、信息流勾對的差異處理

• 支付系統信息流沒有，而銀行有的差異，可能是因為支付系統交易數據的丟失、銀行的掉單，如果是銀行的掉單，由支付公司的運營登錄銀行網銀確認后，做補單處理，并將差異表中該記錄核銷。

• 支付系統信息流有，而銀行沒有的差異，此種情況一般不會發生，因為支付系統所有的交易數據都是取銀行返回狀態的數據。

2、資金流勾對對差異處理

• 支付系統資金流沒有，而銀行有的差異。可能原因如下：1、銀行日切晚與支付系統核心賬務系統；2、支付系統賬務核心系統與其他系統間的掉單。一旦出現，則會出現長款（即銀行不應該結算而實際結算）的現象，對于因日切導致的差異，在第二天的對賬中系統會對平，其他原因的，需要技術排查。

• 支付系統資金流有，而銀行沒有的差異，可能是因為銀行日切早于支付系統的核心賬務系統，一旦出現，會出現短款（銀行應結算而實際未結算）的現象，銀行日切導致段差異，會在下一天與銀行的勾對中，將此筆差異勾對上，如果是非日切導致的原因，就需要找銀行追款了。

總結就是，業務對賬，即信息流對賬，支付系統的交易流水與銀行的交易流水間核對，保障支付交易完整入賬。資金對賬，即資金流對賬，支付系統的入賬流水與銀行的結算流水間核對，保障銀行入賬流水與實際入賬資金的匹配。

?

結算流程

在清結算部分，系統按照設定好的清結算規則自動將錢款結算給商戶。完善的運營會計體系幫助財務進行精細化核算，提高財務效率。與支付渠道自動進行對賬，確保賬務正確，在異常情況下能及時定位問題并處理。系統更是能對商戶進行個性化的費率配置或賬期配置，方便靈活。系統的價值不僅體現在支付清結算方面，同時更是提升了運營管理效率。支付清結算系統可以有效幫助運營、財務、開發以及管理人員。對于運營人員，系統可幫助處理平臺的運營工作，包括各類支付管理，商戶、會員管理，營銷活動的數據統計等，全面提高運營效率。針對財務人員，可以協助完成資金對賬、會計處理，出入款管理，賬務差錯處理等，大部分工作由系統自動處理，減少人工處理，提高資金處理效率。一套靈活便捷的配置后臺供開發人員快速調整系統以適應新的業務，并能方便對系統進行維護，如渠道接入、費率配置、賬期調整等，提高開發效率。系統提供資金流轉過程中各個環節的數據，能夠從各個維度進行核算和分析，形成對管理人員的決策支持，從而提高決策效率。

03

關鍵表設計

04

支付系統要點

在支付系統中，支付網關和支付渠道的對接是最繁瑣重要的功能之一，其中支付網關是對外提供服務的接口，所有需要渠道支持的資金操作都需要通過網關分發到對應的渠道模塊上。一旦定型，后續就很少，也很難調整。而支付渠道模塊是接收網關的請求，調用渠道接口執行真正的資金操作。每個渠道的接口，傳輸方式都不盡相同，所以在這里，支付網關相對于支付渠道模塊的作用，類似設計模式中的wrapper，封裝各個渠道的差異，對網關呈現統一的接口。而網關的功能是為業務提供通用接口，一些和渠道交互的公共操作，也會放置到網關中。

支付系統對其他系統，特別是交易系統，提供的支付服務包括簽約，支付，退款，充值，轉帳，解約等。有些地方還會額外提供簽約并支付的接口，用于支持在支付過程中綁卡。 每個服務實現的流程也是基本類似，包括下單，取消訂單，退單，查單等操作。每個操作實現，都包括參數校驗，支付路由，生成訂單，風險評估，調用渠道服務，更新訂單和發送消息這7步，對于一些比較復雜的渠道服務，還會涉及到異步同通知處理的步驟。

01

網關前置

支付網關前置是對接業務系統，為其提供支付服務的模塊。它是所有支付服務接口的集成前置，將不同支付渠道提供的接口通過統一的方式呈現給業務方。這樣接入方就只需要對接支付網關，增加和調整支付渠道對業務方是透明的。 支付網關前置的設計對整個支付系統的穩定性、功能、性能以及其他非功能性需求有著直接的影響。

在支付網關中需要完成大量的操作，為了保證性能，這些操作都盡量異步化來處理。支付網關前置應保持穩定，盡量減少系統重啟等操作對業務方的影響。支付網關也避免不了升級和重啟。這可通過基于Nginx的LBS(Load Balance System)網關來解決。LBS在這里有兩個作用： 一個是實現負載均衡，一個是隔離支付網關重啟對調用的影響。 支付網關也采用多臺機器分布式部署，重啟時，每個服務器逐個啟動。某臺服務器重啟時，首先從LBS系統中取消注冊，重啟完成后，再重新注冊到LBS上。這個過程對調用方是無感知的。

為了避免接口受攻擊，在安全上，還得要求業務方通過HTTPS來訪問接口，并提供防篡改機制。防篡改則通過接口參數簽名來處理?，F在主流的簽名是對接口參數按照參數名稱排序后，做加密和散列，參考微信的簽名規范。

02

參數校驗

• 所有的支付操作，都需要對輸入執行參數校驗，避免接口受到攻擊。

• 驗證輸入參數中各字段的有效性驗證，比如用戶ID,商戶ID,價格，返回地址等參數。

• 驗證賬戶狀態。交易主體、交易對手等賬戶的狀態是處于可交易的狀態。

• 驗證訂單：如果涉及到預單，還需要驗證訂單號的有效性，訂單狀態是未支付。為了避免用戶緩存某個URL地址，還需要校驗下單時間和支付時間是否超過預定的間隔。

• 驗證簽名。簽名也是為了防止支付接口被偽造。 一般簽名是使用分發給商戶的key來對輸入參數拼接成的字符串做MD5 Hash或者RSA加密，然后作為一個參數隨其他參數一起提交到服務器端。

03

路由選擇

根據用戶選擇的支付方式確定用來完成該操作的合適的支付渠道。用戶指定的支付方式不一定是最終的執行支付的渠道。比如用戶選擇通過工行信用卡來執行支付，但是我們沒有實現和工行的對接，而是可以通過第三方支付，比如支付寶、微信支付、易寶支付，或者銀聯來完成。那如何選擇合適的支付渠道，就通過支付路由來實現。支付路由會綜合考慮收費、渠道的可用性等因素來選擇最優方案

04

風險評估

檢查本次交易是否有風險。風控接口返回三種結果：阻斷交易、增強驗證和放行交易。

• 阻斷交易，說明該交易是高風險的，需要終止，不執行第5個步驟；

• 增強驗證，說明該交易有一定的風險，需要確認下是不是用戶本人在操作。這可以通過發送短信驗證碼或者其他可以驗證用戶身份的方式來做校驗，驗證通過后，可以繼續執行該交易。

• 放行交易，即本次交易是安全的，可以繼續往下走。

05

發送消息

通過消息來通知相關系統關于訂單的變更。風控，信用BI等，都需要依賴這數據做準實時計算。

06

更新訂單

對于同步返回的結果，需要在主線程中更新訂單的狀態，標記是支付成功還是失敗。對于異步返回的渠道，需要在異步程序中處理。

07

異步通知

其中涉及到調用遠程接口，其延遲不可控。如果調用方一直阻塞等待，很容易超時。引入異步通知機制，可以讓調用方在主線程中盡快返回，通過異步線程來得到支付結果。對于通過異步來獲取支付結果的渠道接口，也需要對應的在異步通知中將結果返回給調用方。 異步通知需要調用方提供一個回調地址，一般以http或者https的方式。這就有技術風險，如果調用失敗，還需要重試。而重試不能過于頻繁，需要逐步拉大每一次重試的時間間隔。 在異步處理程序中，訂單根據處理結果變更狀態后，也要發消息通知相關系統。

08

生成交易訂單

將訂單信息持久化到數據庫中。當訪問壓力大的時候，數據庫寫入會成為一個瓶頸。

09

交易流水和記賬

每一筆交易都需要記錄流水，并登記到個人和機構的分戶賬戶上，統計和分析也需要根據交易流水來更新相關數據。 而個人和機構賬戶總額更新、交易流水記錄以及庫存的處理，更是需要事務處理機制的支持。 從性能角度， 可以弱化了事務處理的要求，采用消息機制來異步化和交易相關的數據處理。

• 在支付網關前置的主流程中，僅記錄交易流水，即將當前的請求保存到數據庫中。

• 完成數據記錄后，發送MQ出來，記賬、統計、分析，都是接收MQ來完成數據處理。

• 涉及到本地資金支付，比如錢包支付，會需要分布式事務處理，扣減賬號余額，記賬，扣減庫存等，每個操作失敗，都要回滾。阿里有很不錯的分享，這里不詳細描述。

• 當交易量上來后，需要考慮交易表的分表分庫的事情。分表分庫有兩個策略，按照流水號或者交易主體id來走。后者可以支持按用戶來獲取交易記錄。我們用的是前者。后者可以走elastic，確保數據庫專用。風控，信用和統計所需要的數據，通過MQ同步到歷史庫里面。作為支付系統最有價值的數據，在存儲上做到專庫專用，無可厚非，畢竟存儲成本還是廉價的。

10

支付路由

支付路由是一個復雜的話題。對支付系統來說，能支持的支付方式越多越好，不能由于支付方式的不支持斷了財路?，F實中的支付方式多得難以置信。用戶隨時甩出一張你聽都沒聽說過的卡。如果一個銀行卡只有幾個用戶在用，那針對這個卡開發個對接有點得不嘗失。現在第三方支付的爆發，確實給開發支付系統省了不少事。但是公司不可能只對接一個第三方支付，如果這個渠道出問題了，或者鬧矛盾了，把鏈接給掐了，老板還不欲哭無淚。總之，得對接多個渠道。對于交易量大的銀行，還得考慮直聯。

11

渠道接入

對于支付渠道，首先考慮的是接入哪些渠道。要對接的渠道按優先級有：

• 第三方支付，對大部分應用來說，支付寶和微信支付都是必須的，一般來說，這兩者可以占到90%以上的交易量。用戶不需要綁卡，授權后直接支付就行。各種平臺都支持，性能和穩定性都不錯。對于一些特殊業務，比如游戲，企業支付，可以查看一些專用的第三方支付平臺。

• 銀聯，它的存在，極大方便了和銀行的對接。和第三方支付主要不同在兩個地方一是需要綁卡，也就是用戶先把卡號，手機，身份證號提供出來。這一步會折損不少用戶。綁卡后，以后的支付操作就簡單了，用戶只需要輸入密碼就行。手機客戶端不需要像第三方支付那樣安裝SDK，都在服務器端完成。當然，這是針對快捷支付。網銀支付還是挺麻煩的。銀聯接入也需要ADSS認證。

• 銀行：2018年2月9日銀監會公布了最新權威數字：一共【4549家】開發性金融機構1家：國家開發銀行；政策性銀行2家：進出口銀行、農業發展銀行；5大國有銀行：工、建、農、中、交；郵儲銀行1家；全國性股份制商業銀行12家：招行、中信、興業、民生、浦發、光大、廣發、華夏、平安、浙商、渤海、恒豐；金融資產管理公司4家：信達、華融、長城、東方四大AMC；城商行134家；住房儲蓄銀行1家；民營銀行17家，如網商銀行；農商行1262家；農村合作銀行33家；農村信用社965家；村鎮銀行1562家；貸款公司13家；農村資金互助社48家；外資法人銀行39家；信托公司68家；金融租賃公司69家；企業集團財務公司247家；汽車金融公司25家；消費金融公司22家；貨幣經紀公司5家；其他金融機構14家。一般對接一個銀行預計有3周左右的工作量，大部分銀行需要專線接入，費用和帶寬有關，一年也得幾萬費用。不同銀行對接入環境有不同要求，這也是成本。

• 手機支付：比如蘋果的In-App支付， 三星支付、華為支付等， 這些支付僅針對特定的手機型號， 支持NFC等，根據業務需要也可以接入。

總結

支付系統是一個繁雜的系統，其中涉及了各種錯綜復雜的業務流程，以上只是簡單介紹了支付系統我們能看見的一些問題和設計，還有后續的系統保障沒有寫出來，沒寫出來的才是關鍵部分，比如：支付系統監控（業務監控分類、渠道監控、商戶監控、賬戶監控）文章只是引子，?架構不是靜態的，而是動態演化的。只有能夠不斷應對環境變化的系統，才是有生命力的系統。所以即使你掌握了以上所有的業務細節，仍然需要演化式思維，在設計的同時，借助反饋和進化的力量推動架構的持續演進。

?

作者介紹：

?

山哥談支付系統

https://mp.weixin.qq.com/s?__biz=MzIxMzEzMjM5NQ==&mid=2651030233&idx=1&sn=c8c4f3b1c175b1a9178ff9ebc0e90f9f&chksm=8c4c57ddbb3bdecb9795124d8acbba61ddb2fd7d3a053498ba8c44e1f9aa9466399e21bdbb1f&mpshare=1&scene=1&srcid=0919spPSof3y9C9uYIzbg2Vs#rd

============================

支付系統如何進行分布式改造

https://mp.weixin.qq.com/s?__biz=MzIxMzEzMjM5NQ==&mid=2651029688&idx=1&sn=3d65387868fab10ec6e5634b5128945e&chksm=8c4c55bcbb3bdcaa14ddea4edf060508e45e93eb1ab1fc3b9fa83281e7b61fbe04bb2a708b90&mpshare=1&scene=1&srcid=091987YFedQUrEj6PGq0prU8#rd

?

?

隨著近年來移動支付的興起 ，如條碼支付、聲波支付、NFC 近場支付等，隨之還產生了聚合支付把多種支付方式聚合在一起，方便人們的使用，移動支付已經滲透到我們生活的每一個角落，不帶錢包出門已經沒有任何阻礙。這就給傳統的支付系統提出了新的挑戰，用戶量激增，系統容量和性能跟不上了，傳統的架構往往以 IOE 技術為主，采用 scale up 方式以更強的硬件提升系統性能和容量，擴容成本將是巨大的。支付機構是持牌機構都是受監管的，對系統穩定性有強要求，傳統架構下往往都會用冷備的方式來進行容災，意味著又要投入一倍的成本，由于數據庫主備復制的延時，必須等到數據同步完成才可以切換，容災切換時間長。進行分布式改造已經刻不容緩。

更多關于傳統架構與分布式架構對比請參考《集中式架構與分布式架構比較》

分布式架構在容量、性能、穩定性、成本方面都具有巨大的優勢。在高可用方面，核心思想之一是“解決一切單點”，單點容易出現故障，性能方面也可能成為瓶頸，因此需要將單點改造拆分成多個點。垂直拆分能更清晰化模塊劃分，區分治理，水平切分能解決大數據量性能瓶頸問題，分布式改造主要是將這兩者結合起來，對傳統架構進行全面的改造。

分布式改造之垂直拆分

垂直拆分就是將原來一個整體的系統按業務模塊拆分成多個系統，系統內部數據是自包含的，不會與別的系統共用數據庫，系統與系統之間的交互通過暴露和調用服務來實現。那么如何按照業務來拆分呢？

為了方便理解，首先我們來看一下一筆支付過程是如何進行的：

• 商戶發起收單請求，經過 API 網關，調到產品層的“在線收單”產品

• 調用收銀臺選擇支付方式，也可能直接進入支付環節，創建交易流水

• 進行支付處理，通過金融交換從銀行扣客戶帳，記錄帳務流水，入商戶帳，記錄賬務流水

• 對交易按照費率進行收費，記錄收費的帳務流水。此時會異步觸發營銷和風控策略

• 日終會異步進行會計記帳（也有同步記會計帳的）、業會核對、清結算和對帳處理

從這個過程可以大概推演出支付系統的一般應用架構：

圖：支付系統的應用架構

應用架構定義一個大型軟件系統由哪些應用子系統構成，以及應用之間是如何分工和協作的。好的應用架構抽象合理、協作有序、易于擴展、能夠復用。有了這個應用架構，我們就可以非常清晰的根據應用架構劃分的子系統來進行垂直拆分。

從架構上來說，分為四層：

?

圖：支付系統的分層

?

渠道層：商戶和客戶的交易請求的入口。一般會劃分以下系統：商戶網站、用戶網站、無線接入、API 網關。

產品層：通過基礎服務層提供的服務組裝成具體業務場景功能，對客戶、商戶運營等人員提供服務。一般會把服務商戶的功能劃分為商戶域，服務 C 端用戶的劃分為用戶域。可以按照這兩個域拆分成兩個子系統，也可以更進一步根據不同產品特性再拆分，比如商戶域中的收單產品、虛擬產品、垂直行業產品。

公共服務層：將各個產品都需要使用的些服務抽像成公共服務。一般會劃分：收銀臺、交易支付、計費等系統。比如說產品層可以通過組裝各種交易類型和收費規則形成不同的產品。

基礎業務層：支付系統的核心，資金和客戶信息的處理都在這里。一般會劃分三大子系統：帳務核心、會計核心、會員核心。

其它支撐系統：

網關：負責與銀行、銀聯等金融機構進行資金交換，與外部合作伙伴接入，如渠道拓展商、行業客戶等。一般劃分：銀行接入網關和合作伙伴接入網關。

運營支撐：貫穿于四個層的是運營支撐域：一般會劃分運營支撐、安全、風控、營銷子系統。

垂直拆分本質上是服務化改造，除了上面講的按業務拆分，還需要一套分布式服務框架的支撐。

分布式改造之水平拆分

前面講的垂直拆分只是把系統按業務模塊劃分到不同的子系統，數據庫也分到了不同系統，但沒有解決單表大數據量的問題，而水平切分就是要把一個表按照某種規則把數據劃分到不同表或數據庫里。簡單的說就是做分庫分表。

在做分庫分表之前我們需對數據模型進行分類，分為“流水型數據”、“狀態型數據”和“配置型數據”。

• 流水型數據：像流水一樣不斷增長的數據，各條數據間是獨立的。如支付訂單、交易流水、帳務流水（入帳/出帳）、會計流水等。

• 狀態型數據：代表一個對象當前的狀態的數據。如會員信息、客戶信息、帳戶信息、會計帳。

為什么有會員信息還有客戶信息？會員往往是注冊在支付平臺的用戶，一個人可以注冊多個會員，但是一個自然人只可能有一個客戶信息，一個會員通過實名認證后就關聯上了客戶信息。無論一個客戶注冊多少個會員，實名認證后都只有一個客戶信息。

• 配置型數據：系統中用作為配置的數據。如產品、手續費率、分支機構信息、支付路由規則、會計科目等。

?

流水型數據會不斷產生，且各條數據間是獨立的，天然適合進行分庫分表。

狀態型數據讀寫比相當，每一次寫操作必須基于前一個正確的狀態，可以評估一下數據量的大小，數據量如果大或者要實現單元化架構，也需要進行分庫分表，提高并發處理能力，同時方便隔離故障影響。

配置型數據，讀多寫少，強依賴讀，弱依賴寫，不要求嚴格的讀一致性，且配置型數據一般數據量不會很大，不需要進行分庫分表設計。但是業務處理中往往又需要用到，傳統架構的老系統可能使用了一些關聯表操作，關聯到了配置數據，分庫后其它數據與配置不在一個庫，不能進行關聯表操作，由于配置型數據不要求嚴格的讀一致性的特點，可以將配置型數據加載到分布式緩存里，由業務代碼來做“join”。

那么分庫分表按照什么規則來拆分呢？通常不會按實體 id 進行 hash 取模的方式來拆分。因為希望同一個用戶的數據能夠在同一個數據庫中，盡量避免產生分布式事務。業界普遍的做法是通過用戶維度來進行拆分。由于不同實體 id 的值不同，且不能保證每個實體和請求中都包含用戶 id，所以簡單的用實體 id 或用戶 id 進行 hash 取模將不能保證同一個用戶的數據都落在同一個分片。

一種推薦做法是，在用戶創建的時候給該用戶隨機或一定規則（如地區）生成一個兩位的分片號 00~99（兩位意味著可以分成百庫百表，通常夠用了），那么在生成與該用戶相關的所有實體的 id 的時候，都約定把這個分片號拼接到這個 id 中。在分布式數據訪問框架中進行路由選擇時，就可以取 id 中的分片號進行路由，而不依賴于用戶 id。且在排查問題的時候也非常方便定位數據的存儲位置。

下面是一個參考的 id 生成規則示例：

所以數據水平拆分除了需要一個強大的分庫分表數據訪問中間件，還需要一個分布式序列生成器。當然這個生成器也可以是集成在分庫分表數據訪問中間件中的一個功能。

那么如果一筆交易涉及多個用戶按誰的 id 來拆分呢？比如一筆轉賬或支付，涉及轉出方/轉入方或支付方/收款商戶。這種情況一般可以按資金轉出方來拆分。

分布式改造后帶來的問題如何應對

?

分布式事務產生

由于按用戶維度進行了分庫分表，可能存在跨數據庫的事務，比如說，轉賬交易中轉出方和轉入方的賬戶不在同一個數據庫中，這就產生了分布式事務。通常不會用 XA 協議來解決，因為 XA 協議鎖資源性能太差，通常是通過 TCC 柔性事務來解決。具體可以參見進階閱讀《分布式事務綜述》。

跨表查詢如何解決

由于分庫分表后，不能進行跨庫的連表查詢，原來的一些很常見的查詢操作變得很麻煩。對于不是以用戶為維度的匯總查詢也非常麻煩。比如說支付交易流水是按發起方用戶（支付方）進行拆分的，用戶需要查詢自己的賬單很容易。但是商戶要查詢賬單就比較麻煩了，要去所有的庫里遍歷、匯總、分頁。也非常耗系統資源。所以一般會做一些數據冗余，例如專門實現一個賬單系統，通過消息隊列異步將用戶的交易流水同步過來，T+1 跑批再按商戶維度進行拆分，并生成商戶賬單。查詢帳單都從帳單系統中查詢。

還可以通過異構索引來查詢和做 OLAP 分析，異構索引就是將數據同步到 ElasticSearch，利用 ES 的強大索引能力來做查詢和分析，為了使業務更容易使用，可以利用數據訪問代理層來屏蔽底層是路由到數據庫還是路由到 ES。

如何進行數據同步

企業都有做大數據分析的需求，需要將數據同步大數據平臺，如 Hadoop。分庫分表之后，數據同步會比較復雜，畢竟之前是單表同步到 Hadoop 比較簡單，但是 100 張表同步到 Hadoop 里會復雜一些。這時就需要設計一套專門的數據模型管理平臺，數據模型、分庫分表規則等由這個平臺來管理，當需要使用數據的時候通過（應用/邏輯表）維度訂閱數據即可，不用單獨訂閱物理表。不僅是數據同步，凡是有業務需要用到各種數據，都可以通過這個平臺來訂閱，幫助企業數據業務快速發展。

分庫分表后批處理任務怎么處理

批處理任務，比如有日終對賬、清算、生成賬單等，原來在一個數據庫中的時候，由一個應用 Server 去數據庫中撈取流水就可以了。但是分庫分表后流水都落在很多庫里，一個 Server 去每個庫里遍歷顯然不是一個很好的辦法，且不能充分利用機器資源，提高批處理效率，甚至由于處理的數據量太大在日終低峰期內根本無法完成任務。

前面提到各條流水數據之間沒有關聯的，完全可以并發的進行處理，每個 Server 撈取一個分片的數據進行處理。那么就需要有一個很好的調度系統來協調，可以采用三層調度的方式。

圖：三層調度示意圖

• 第一層 split：把任務按照分片規則拆分成多個 Load 任務，并發送到集群中的 Server 去執行。

• 第二層 load：每個 load 任務撈取一個分片的數據，逐條創建 execute 任務，并發送到集群中的 Server 去執行。注意：撈取數據要進行流量控制以免數據量太大把集群打滿。

• 第三層 execute：執行具體的一條數據的邏輯。

三層架構并不是說一定都需要三層，可以根據業務邏輯來定制只有兩層也可以。

如何進行數據擴容

通?？梢圆捎谩邦A分配”的方式來做，即一開始就按一個比較長期的容量來規劃分片數，比如百庫百表。但實際上一開始并沒有這么大的量，所以實際只有兩個數據庫 Server，在這兩個 Server 上分別建 50 個 schema，邏輯上仍然是 100 個分庫，物理上只有 2 個數據庫 Server。當容量不夠的時候，為了保證數據的均衡，通常會采用成倍擴容的方式，再加兩臺數據庫 Server，然后分別遷移 25 個 schema 到這兩個數據庫 Server 上，數據也搬過來。由于數據同步有延時，全量數據同步完成后，兩邊的 schema 都禁寫，待增量數據同步完成后打開新的 schema 寫，會產生短暫的部分用戶交易失敗，重試一下即可，在低峰期做遷移，產生小范圍失敗一般是可以接受的。由于邏輯分片數沒有變化，擴容成本比較低。通常不會用改變分片規則的方式來擴容，因為改變分片規則需要進行數據重新分布，成本和風險巨大。

如何進行容災

• 同城容災：通常可以同城多機房部署應用，數據庫只有一個機房處于 Active 狀態，所有機房的應用都連這個機房的數據庫，另一個機房的數據庫為備庫，進行主備復制，當備機房發生災難時業務不會中斷，但業務會跌一半，當主機房發生災難時，數據庫切換備庫，會有短暫的業務中斷。

• 異地冷備：應用也是異地多機房部署，由于異地網絡延時不可忽略，異地備機房是處于 standby 狀態，正常是沒有流量的，冷備機房采用數據庫主備同步的方式同步數據，這種方式災備切換時間長，成本投入高。

• 異地多活：應用采用異地多機房單元化部署架構，每個機房的應用都是可以提供服務的，單元內是自包含部署全量應用，每個單元服務多個分片的用戶，單元化架構可以參考《素描單元化》。由于異地網絡延時是不可忽略的，數據層的容災方案也是分“流水型”、“狀態型”、“配置型”數據采用不同的容災策略。具體可參考《分布式系統數據層設計模式》。

?

如何更好的排查和分析問題

分布式改造后整個系統架構已經是服務化了，原來通?？梢酝ㄟ^查本地日志來定位問題。但現在一個交易由若干個系統協同完成，我們需要一套分布式鏈路跟蹤系統或 APM（應用性能管理）系統來協助我們看清整個系統的全貌，分析排查問題。那么如何進行分布式鏈路跟蹤呢？可以通過 OpenTracing 標準對整個分布式架構中的中間件和應用進行埋點或自動植入探針實現。

總 ?結

分布式架構有著海量、成本、穩定、速度的優勢，但它也不是銀彈，分布式改造是一個較為復雜的工程，既需要熟悉業務，能夠設計出整個系統的業務架構，按照業務架構來進行垂直拆分，又需要熟悉數據模型，區分“流水型”、“狀態型”、“配置型”數據，根據不同類型數據的特點將它他按用戶維度進行拆分，還需要熟悉分布式中間件的運用。分布式中間件在整個分布式架構中起著至關重要的作用，將技術構架與業務結合起來。螞蟻金服通過多年金融級架構的演進，經過多年雙十一大促的驗證，已經形成了一套業界領先的金融級分布式架構，請參考《金融級分布式交易的技術路徑》。

?

=====================================

從0到1實現一套聚合支付系統

?

大家好，我是來自盒子科技研發部支付線劉恒，目前主要是負責公司的一個聚合支付系統的研發工作。今天主要是講一下我們聚合支付系統從2016年年初到現在技術演變。

?

首先我會從那三個方向，第一是聚合支付的介紹，聚合支付在我們公司它承擔一個什么樣的地位，第二是在我們公司有什么樣的使用場景。第三是從公司開始做聚合支付最開始的版本是什么樣子的，在這個版本之上，我們做了什么樣的優化，然后到了現在發展成什么樣的架構。

?

01

?

聚合支付的介紹

_____

首先從第一個主題講什么是聚合支付，聚合支付主要是就是一個將所有的第三方支付，通過借助形式融合在一起，相當于對接一個支付接口，就可以使用各種支付的場景，就比如說各位有可能去那種超市便利店去買東西，貼著一個碼，碼上有什么微信支付，支付寶支付，還有一個京東QQ各種支付。然后我們公司也有一個，就是一個好噠，相當于這個用戶就是圖上兩個男生，然后掃橙色的那個二維碼，所以我們公司做了一個好噠立牌。

?

它主要是針對一個微小商戶進行一個收款工具，讓商家他那邊會有一個好噠商戶通，第一個可以實時的收聽語音報告，當前用戶付款多少錢，第二個就是他可以去實時查看賬單，了解當天的營業額。

?

?

?

還有一個產品就是我們公司的一個pos機。這個主要是一款生態pos，它里面不僅繼承了我們一個我們這個具備支付系統提供的服務，就比如微信支付寶，它們還集成了一個刷卡的功能，就是磁條卡芯片卡，還有各種支付方式。

?

這次我們講的聚合支付，只是涉及到交易流，不涉及到資金流，資金流是其他項目組負責。

?

02

?

1.0系統

_____

?

好，進入項目背景。

?

第一個就是工期短，基本上所有的項目都會遇到，天天都在趕工程。

?

?

我們是從2016年過年前一周，然后忽然被拉入一個群，說是有個項目要做一做，當時老大讓一周上線，

?

第二是業務不熟。不知道聚合支付到底做什么事情，它的支付流程是什么樣的？雖然說之前做過支付相關業務，但是每個公司支付業務是完全不一樣的。當時做微信支付寶，微信APP ID是什么東西還不知道，所以說就在這種情況下開始著手，還有就是一個當時的交易量，當時的交易量是只有前端的一兩個產品在使用，每天的交易筆數也很小，就幾千筆。

?

第三個就是人員的缺乏，因為當時就做系統研發，只有我和另外一個新同事。

?

就在這種背景下，我們就搭建了第一套系統架構，即虛線圈住的，我負責交易前置，同事負責交易網關，當時就直接操作DB沒有做任何的其他的優化。

?

?

?

當時就做這樣一個簡單的架構，第一個開發比較快，直接拿需求進行改代碼，方便測試以及上線。當時是2016年3月份4月份就上線了，也很快。后來就是在經過了三四個月交易量比較猛增的情況下，就發現這個系統感覺各種瓶頸就出來了。

?

?

??渠道的隔離，因為當時對接了幾個渠道，特別渠道不穩定的話，比如資源不可用、網絡問題，導致超時，這樣就會把所有渠道交易全部影響，造成級聯反應，導致整個服務交易鏈路不可用，影響比較嚴重。周末別人都可以在家好好休息，但是我們支付研發不行，每天都是隨時關注手機，因為說不定哪個渠道就出問題了，立馬要處理。而且系統哪邊掛了之后立馬要趕緊聯系。所以說這個渠道隔離放在第一位首要的。

?

??接口膨脹，特別涉及到某些相似的業務，就比如說那個消費、撤銷、退款接口，就每個業務類型都有這幾個接口，隨著業務的發展，也不好維護，開發每次來個需求都要去考慮，到底是改哪個接口，要不要都改。

?

??動態擴容。因為聚合支付很多交易都是異步的，用戶下單時，我們會立即返回就下單成功，或者下單失敗，但是這個交易有沒有消費成功，我們需要設置定時的任務去查詢最終付款結果。

?

定時調度，它需要定時、定點、定量的去拉取一批訂單進行處理，如果拉取的數據太多，內存直接爆了，拉取太少，有很多交易得不到執行。在分布式環境如何充分提升并發的前提下充分使用機器的資源變得越來越緊迫。

?

??配置分散，傳統方式是將配置文件存放在每一個節點，每次升級都需要運維手動改。風險較高而且相當不好維護。

?

?

03

?

2.0系統

_____

在這個前提下，我們開始著手設計2.0。當初有幾個大的方向：

?

?

??穩定：支付系統的根基

??支付體驗：用戶使用支付功能時感知零延遲

??低耦合：模塊之間減少依賴，需求變動風險控制在最小范圍

?

在這個過程中也是試了很多種方案，要么程序復雜，你寫完的話可能只有自己懂，后續不好維護；要么性能跟不上去。所以我們也嘗試了各種方案，最后演變為如下系統架構。

?

?

首先將服務劃分為三條線，上面綠色的，和中間那個紅色的和最下面一條橙色的。綠色的就是我們把交易核心、交易網關獨立出來。任務作業和那個查詢網關獨立部署。這兩條業務線通過MQ進行解耦，然后我們再獨立查詢服務，對前端業務僅僅提供一個流水查詢功能而已。

?

業務流程如下：

?

業務發起一筆消費，首先進入支付核心初始化流水、風控風險識別、渠道路由、渠道網關報文組裝、上送、渠道應答。異步交易發送消息至MQ集群，任務作業監聽消息，put緩存，定時任務拉取進行狀態查詢，業務方通過查詢服務查看該筆交易支付狀態

?

?

前置優化水平方向

?

?

??接入層：將共性的接口統一。比如說下單，所有的業務，不管微信支付，還有其他的全部歸為下單，具體的業務，通過一個serviceId參數進行識別

?

??服務層：共性邏輯，也就是核心邏輯全部抽離出來，然后進行統一下沉，作為底層服務，上層業務全部通過serviceId配置化實現，這樣的話盡量去少改動核心業務邏輯。

?

??緩存層：隨著交易量的增長，特別是在第一代的時候，里面很多業務查詢都是直接操作DB了，對DB有很大的性能影響。所以我們就是在DB之上將所有消費交易信息全部緩存，后續所有的操作查詢和更新全部操作緩存層主要為了提升了服務的性能。

?

?

前置優化垂直拆分：

?

?

??核心交易：負責交易的核心鏈路，用戶感知最明顯。比如支付失敗，用戶立馬能知道，立馬就會投訴或者打電話給客服，該模塊也包含退款等業務。

?

??任務作業：將處理中的交易進行狀態同步，和核心交易通過消息解耦

?

??查詢服務：僅僅是對公司內部提供一個交易狀態的查詢功能

?

?

?

?

任務作業內部查詢策略設計為兩個隊列、一個批處理

?

??內存隊列：基于DelayQueue設計的延遲隊列，通過制定算法策略，就是比如說延遲十秒、間隔五秒，或者是很多銀行使用2的N次方進行查詢。

?

該隊列主要是針對單筆交易執行快速狀態同步,提升用戶體驗。

?

??緩存隊列：基于我們公司Codis緩存集群，結合分布式調度框架Elastic-Job設計。主要是針對狀態延遲的訂單，進行批量狀態同步

?

??DB批處理：也是結合Elastic-Job設計，主要是提供人工干預的入口，當渠道延遲比較長、或者渠道異常的情況下，執行批量狀態同步

?

?

分片策略：

?

?

??任務分片：目的在于把一個任務分散到不同的機器上運行，既可以解決單機計算能力上限的問題，也能降低部分任務失敗對整體系統的影響。elastic-job并不直接提供數據處理的功能，框架只會將分片項分配各個運行中的作業服務器（其實是Job實例，部署在一臺機器上的多個Job實例也能分片），

?

PS：開發者需要自行處理分片項與真實數據的對應關系?？蚣芤差A置了一些分片策略：平均分配算法策略，作業名哈希值奇偶數算法策略，輪轉分片策略。同時也提供了自定義分片策略的接口。

?

??數據分片：訂單號取模存儲（zset）

?

?

數據結構：

?

??有序集合（zset）：按照分片邏輯，將訂單號取模，存放至對應的隊列中

?

??string：交易明細序列化存儲

?

設計思路：

?

?

1.?MQ消費者（作業節點），接收到消息后，將數據存放在緩存

?

2.?作業節點根據分片項、score范圍，定時從對應的緩存隊列中獲取指定數量的訂單號

?

3.?業務循環處理，根據訂單號再去緩存中獲取對應的詳細信息

?

4.?執行查詢邏輯

?

注意事項：

zset元素數據過期，需要業務自己處理，可以單獨建立檢測機制，也可以每次執行業務時執行判斷，過期則移除，不然集合會越來越大。

?

?

??渠道隔離：在高并發訪問下，系統所依賴的渠道穩定性對系統的影響非常大，依賴有很多不可控的因素，比如網絡連接變慢，資源突然繁忙，暫時不可用，我們選在知名的容錯開源框架Hystrix，隔離方案選擇thread。

?

??查詢網關：在交易系統中，查詢業務量一般時支付業務的6倍，甚至更高，這樣對查詢服務性能就會有更高的要求。減少對核心交易影響，提升穩定性。

?

通道商戶緩存：通道信息（機構號、商戶號、密鑰等）屬于靜態信息，在初次使用時存放至分布式緩存系統中（設置有效期，防止僵尸數據），同時增加手動修改的入口，方便人工干預。

?

?

??千里之堤毀于蟻穴：我們用容錯的方式就是讓這種蟻穴不要變大，在依賴的服務不可用時，服務調用方應該通過一些技術手段，向上提供有損服務，保證業務柔性可用。

?

??線程池資源隔離：Java的Servlet容器，無論是Tomcat還是Jetty都是多線程模型，都用Worker線程來處理請求。當業務請求打滿Worker線程的最大值之后，剩余請求會被放到等待隊列（或者拒絕掉），如果等待隊列也塞滿之后，那這臺Web Server就會拒絕服務。

?

如果你的服務是QPS較高的服務，那基本上這種場景下，你的服務也會跟著被拖垮。假如上游服務也沒有設置合理的超時時間，故障就會擴散。這種故障逐級放大的過程，就是服務雪崩效應。

?

我們采用容錯框架Hystrix來解決此問題。通過Hystrix命令模式，將每個類型的業務請求封裝成對應的命令請求。每個命令請求對應一個線程池，創建好的線程池是被放入到ConcurrentHashMap中。

?

注意：盡管線程池提供了線程隔離，也必須要有超時設置，不能無限制的阻塞以致于線程池一直飽和。

?

?

Hystrix線程監控

?

實時展示當前各個業務線程池資源使用情況，研發人員可以以此為參考，確定資源是否夠用、是否需要升級機器資源等。

?

?

2.0之后我們是全面對接我們公司監控平臺，主要從以下幾點進行監控：

?

?

??節點耗時監控：如說哪個時間點、哪個節點耗時比較慢，通過百分比的形式，可以比較直觀的看出問題。

?

??成功率的監控：折線圖定時刷新數據，將各個時間點的交易記錄數、成功筆數、失敗筆數進行匯總計算，渠道接口異常時可以第一時間發出告警

?

??應答碼監控：應答碼TOP排行榜，方便研發分析數據，提前將問題通知給渠道，減少后續可能出現更大的問題；部分應答碼重點監控，通過設定告警閥值，超過閥值短信及電話告警，研發第一時間接入處理，減少可能造成的損失。

?

??郵件巡檢報告：用于第二天研發進行數據分析。

?

?

以上就是盒子科技聚合支付系統演變的大致過程，在 2017年的到現在沒有出現任何技術故障和業務故障，沒有造成一筆長款、短款的出現，系統具備良好的伸縮性，能夠保證公司近兩年業務的快速發展。

?

04

?

下一步需要做什么

_____

那么在系統穩定的基礎之上，下一步我們還需要做哪些事情呢？

?

?

??全鏈路的監控：我們現在鏈路監控只是從前端到后端有一個請求的跟蹤號，但是這個都分散在我們業務日志里面的。所以說我們下一步就準備做一個全鏈路的監控，就相當于把每一個每筆交易，它具體在哪個時間點在哪個機器上，然后在哪個渠道，然后它狀態做的什么變更，做一個完整的記錄，通過一個可視化的界面提供出來，方便客服、運營等其他協作部門使用。

?

?

??智能路由：遇到渠道異常、臨時停用渠道等等情況下，需要將用戶切換至其他渠道，目前都是人工通過拉取數據手工操作的，所以下一步我們就想如何讓我們的路由更加智能。

?

??動態分片：主要包括數據分片、任務分片，業務量持續倍數增長的情況，各個環節的分片策略如何做到自動化實現，充分使用各個機器的性能。（本文完）

?

https://mp.weixin.qq.com/s?__biz=MzIxMzEzMjM5NQ==&mid=2651030198&idx=1&sn=056a70449a9c7bc3771220cc52dc29dd&chksm=8c4c57b2bb3bdea4fde10bc1f489bf55ce0d99c0d681d168287fefa43e6457170c95d6f1cc35&mpshare=1&scene=1&srcid=0911D3xt3Cf5t0vbhnbuiPVN#rd

?

================================

金融級分布式交易的技術路徑

移動互聯網、大數據與云計算作為新的基礎設施，催生了新的互聯網經濟，也正在推動各行各業的升級。在過去十多年中，金融服務飛速發展，移動支付支撐了零售業線上線下的變革，基于大數據的信貸服務支持了無數小微企業的創業創新，老百姓可以隨時隨地享受曾經高門檻的理財、保險等金融服務。以普惠服務為目標、數據與技術驅動、新型信用體系為基礎的新金融已經成為新經濟的基石。

?

伴隨著螞蟻金服在新金融領域的探索，螞蟻金服技術團隊也在金融技術與架構領域不斷開拓。從?2005?年每秒處理?1?筆交易到?2015?年雙十一每秒處理?8.59?萬筆交易，從單一的支付到覆蓋微貸、理財、保險、信用、銀行等，通過十多年的探索與實踐，我們形成了一套包含金融級分布式交易、分布式大數據分析與決策等在內的完整架構與技術體系。

?

在本文中，我們將與大家交流金融級分布式交易相關的實踐與體會。

?

金融級系統的關鍵目標

?

如果將建造系統比作蓋樓的話，建一個常規的系統要先立穩四根柱子：高可用、安全、性能、成本。但要建一個移動互聯網時代的金融級大廈，除了上述四根柱子需要更加牢固，還需要加上兩根柱子：資金安全與數據質量。這六根柱子，是我們在架構螞蟻金服的每一個系統時的首要目標。

?

具體來說，我們對一個金融級系統有以下關鍵目標：

?

高可用：具備?99.99%?以上的高可用性。系統能夠容忍各種軟硬件設施的故障，可以在服務不中斷的情況下進行升級，在嚴苛的應用場景下保證承諾的服務質量，容忍各種人為失誤。對于關鍵系統，還需要具備異地容災能力。

?

安全：具備多層次檢測、感知與防御各類安全攻擊的能力。系統有能力實時、精細地分析系統行為與數據流發現異常，必要時可以快速調集資源阻斷大規模、有組織的攻擊。

?

性能：對于實時交易業務，要求極快的響應時間與極高并發能力。對于批量業務，要求極大的吞吐量。尤其重要的是，系統必須具備很強的可伸縮性與彈性，在需要時可以快速調集資源應對突發的業務量。

?

成本：在滿足高可用、安全與性能的前提下，成本是一個重要約束。我們將單筆交易的平均處理成本（月交易總筆數/月成本）、以及峰值交易的處理成本（每提升?1000?交易?TPS?需要追加的成本）作為兩個關鍵指標去持續優化。除了必須在基礎軟硬件與系統關鍵鏈路上做極致的優化外，靈活的資源調度與按需伸縮能力是優化成本的關鍵。

?

資金安全：這是金融級系統與常規系統的一個關鍵差異。要做到資金處理絕對不出差錯，需要交易與數據具備強一致性，需要在任何故障場景數據不丟不錯，需要具備準實時的交易資金核對能力，需要在異常場景下有精細化熔斷與快速恢復能力。

?

數據質量：數據質量是金融服務質量的基礎。數據從采集、生成、流轉、存儲、計算、使用需要經歷很多環節，要確保經過這么多環節后，數據依然是準確、完整和及時的，需要系統具備全鏈路的數據質量管控與治理能力。

?

金融交易系統是否可以走分布式路線？如何基于分布式的思想與技術達到以上?6?個關鍵目標？接下來，我們就以螞蟻金服的實踐為基礎，分享對這個問題的觀點。

?

分布式金融交易架構與技術

?

?

1

強一致的微服務：微交易架構

?

微服務是一種廣泛應用的分布式架構。通過將系統分解為單一職責、高內聚、松耦合、獨立部署、自主運行的“微“服務，可以極大提升系統的靈活性與擴展能力。但由于每一個微服務是自包含的數據與計算單元，當一個有嚴格一致性要求的交易，被分布在很多節點上執行時，如何保證數據與服務處理達到金融級的強一致性，成為一個難題。盡管可以用支持分布式事務的數據庫或數據中間件來保證數據分布時的一致性，但解決不了當服務分布時的一致性問題。由于分布式事務對資源加鎖的時間長、粒度大，也制約了系統的可伸縮性與高可用性。

?

為了解決這個難題，我們提出一種使微服務具備強一致性的微交易架構。在這種架構中，涉及到交易操作的微服務具備事務屬性。一個微交易提供三種操作TCC（Try-Confirm-Cancel），其中?Try?操作負責業務檢查與資源預留，Confirm?操作負責實際操作，Cancel?操作負責釋放預留的資源。一次完整的交易由一系列微交易的?Try?操作組成，如果所有的?Try?操作都成功，最終由微交易框架來統一Confirm，否則統一?Cancel，從而實現了類似經典兩階段提交協議（2PC）的強一致性。但不同于?2PC，微交易架構力求高效與可伸縮。TCC?三個操作都是基于本地事務的短事務，Try?操作只預留必須的業務資源，比如一筆交易涉及10元錢，僅預留賬戶中的?10?元錢，而不是鎖定整個賬戶，TCC?協議在提交時，也沒有單獨的?Prepare?階段，將提交協議的成本降到最低。

?

從?2008?年初上線至今，微交易架構已經應用到螞蟻金服的各種金融業務場景，經歷過歷次大促高峰考驗，證明這套架構與技術的可行性。

?

2

請金融級分布式數據庫: OceanBase

?

目前，主要商業數據庫本質上是單機系統，其容量、性能和可靠性均依賴于單個或少量高性能服務器與高可靠存儲的組合，成本高昂且擴展困難。盡管通過運用微交易架構，可以將對數據操作的壓力分拆多個數據庫，解決了水平可擴展的問題，但數據庫本身的性能、成本與可靠性依然是一個難點。因此，阿里巴巴與螞蟻金服從?2010?年起，開始研發專門的金融級分布式數據庫?OceanBase。

?

OceanBase?在以下幾個方面，對傳統數據庫架構進行了突破：

?

高性能：數據庫的一個顯著特征是總數量比較大，但每天變化(增刪改)的數據只是總數據量的很小一部分。因此?OceanBase?將數據劃分為基線數據和修改增量?；€數據即數據庫在某個時間點的一個快照，存放在每臺?OceanBase?服務器的硬盤中，修改增量即快照點之后的增刪改數據，相對比較小，通常存放在每臺?OceanBase?服務器的內存中。通過這種方式，使得增刪改操作基本都在內存中進行，從而獲得接近內存數據庫的事務處理性能；

?

強一致：經典的主庫+備庫方式的數據庫，很難兼具高可用與強一致能力。為了解決這個問題，OceanBase?使用多數據副本（>=3）投票協議，對于每個寫事務，OceanBase?只有在事務日志（redo log）到達超過半數服務器后，才應答客戶。這樣當少數服務器（例如?3?臺中的?1?臺，或者?5?臺中的?2?臺）異常時，剩下的服務器至少有一臺有事務日志，保證了數據庫不因為少數服務器故障而導致數據丟失；

?

高可用：關鍵業務的數據庫必須達到?99.999%?的可用性，服務器故障、機房或網絡故障都不能導致數據庫不可用。OceanBase?通常由分布于多個機房（3?個或以上）的機群組成，每個機群有完整數據，其中一個機群作為主庫對外提供讀寫服務，其余機群作為備庫，接收主庫的事務日志和回放日志。當主庫故障時，剩下的機群會立刻自動發起投票選舉，選出新的主庫，新主庫從其他機群獲得可能存在的最新事務日志并回放，完成后對外提供服務。

?

目前?OceanBase?已經穩定支撐了支付寶的核心交易、支付與賬務，支撐了網商銀行的核心系統，經歷了多次“雙十一”的考驗，形成了跨機房、跨區域部署的高可用架構，并在日常運行、應急演練和容災切換中發揮了重要作用。

?

3

異地多活與容災:?單元化架構

?

“兩地三中心”是一種在金融系統中廣泛應用的跨數據中心擴展與跨地區容災部署模式，但也存在一些問題：在擴展能力上，由于跨地區的備份中心不承載核心業務，不能解決核心業務跨地區擴展的問題；在成本上，災備系統僅在容災時使用，資源利用率低，成本較高；在容災能力上，由于災備系統冷備等待，容災時可用性低，切換風險較大。

?

因此，螞蟻金服沒有選擇“兩地三中心”部署模式，而是實現了異地多活與容災模式。異地多活與容災架構的基礎是對系統進行單元化。每一個單元可以認為是一個縮小規模的、包含從接入網關、應用服務到數據存儲的全功能系統。每個單元負責一定比例的數據與用戶訪問。單元有以下關鍵特性：

?

自包含性：比如用戶的一次賬戶充值交易，涉及到的所有計算與數據都在一個單元內完成；

?

松耦合性：跨單元之間只能進行服務調用，不能直接訪問數據庫或其它存儲。對于一些必須跨單元的交易處理，比如分屬于兩個不同單元的用戶之間的轉賬交易，跨單元的服務調用次數盡可能少，在業務與用戶體驗允許的情況下盡量異步處理。這樣，即使兩個單元之間相距上千公里，也可以容忍跨單元的訪問時延；

?

故障獨立性：一個單元內的故障，不會傳播到其它單元；

?

容災性：單元之間相互備份，確保每個單元在同城和異地都有可在故障期間進行接管的單元。數據在單元間的備份方式，我們以?OceanBase?提供的多地多中心強一致方案為主。

?

通過單元化架構，能夠將一個大規模系統分拆成許多個相對獨立的小規模系統，每一個單元系統可以部署到任何地區的數據中心，從而實現了靈活的異地多數據中心部署模式。系統的主要伸縮模式變成單元的增減，但一個單元內部的規模與復雜性不變，降低了系統的復雜性。單元之間的故障隔離，降低了軟硬件故障的影響面?！盎睢钡膯卧涂鐔卧目焖偾袚Q能力，使同城異地的容災處理更為簡單高效。

?

目前，螞蟻金服的核心系統已經分布在上海、深圳、杭州等多個城市的多個數據中心，核心交易流量分布在各個數據中心，并且可以進行調度與切換。通過異地多活，系統可以在全國范圍內任意擴展，服務器資源得到了充分利用，提升了系統應對地區級災難的能力。

?

4

按需伸縮：彈性混合云架構

?

每年，支付寶系統都要應對雙十一、新春紅包等活動的極高交易量。盡管單元化架構讓我們具備應對峰值的能力，但要降低高峰期的資源投入，系統還需要具備按需伸縮的能力。

?

我們解決這個問題的方法是，活動前，在云計算平臺上快速申請資源，構建新的單元，部署應用與數據庫。然后將流量與數據“彈出”到新的單元，快速提升系統容量。當活動結束后，再將流量與數據“彈回”，釋放云計算平臺上的資源。通過這種方式，可以大大降低資源采購與運行成本。

?

彈性操作，需要在流量、數據與資源之間協調一致地操作，尤其是有狀態的數據的彈性操作是最困難的，需要不中斷業務，也需要保證數據的一致性。這些操作如果依靠運維人員人工執行會十分復雜低效，需要架構、中間件與管控系統的支持。

?

彈性混合云架構與技術在實踐中有以下一些關鍵點：

1.?通過統一資源調度，靈活地申請與分配計算、存儲與網絡資源，創建單元，快速部署數據庫、中間件與應用；

2.?通過中間件，將應用與基礎設施充分解耦，無論流量、數據與資源如何分布，應用系統不需要改變；

3.?通過分布式架構與數據規范，以及中間件支持，保證所有請求、服務、數據、消息等都有全局唯一的?ID?和一致的?ID?編碼規則。根據?ID，從接入網關、服務中間件、消息中間件、數據中間件等都能夠正確地路由服務請求與數據訪問；

4.?通過統一管控平臺，將高層的彈性操作，翻譯成各個組件的部署與配置指令，并且統一調度執行，使操作協調一致、精準高效。

?

基于彈性混合云架構，2015?年雙十一，支付寶有?10%?的支付流量運行在阿里云計算平臺上。2016?年雙十一，我們計劃將?50%?的高峰期支付流量運行在阿里云計算平臺上，帶來成本的極大優化。

?

未來展望與期待

?

螞蟻金服的實踐證明了在金融級中間件、數據庫和云計算平臺的支持下，分布式架構可以完全勝任復雜、高要求的金融級交易，并且給出了一種可供參考的技術架構與實施路線。

?

未來，螞蟻金服依然會在金融級分布式架構與技術方面深耕與拓荒。在這一領域，我們給自己提出兩個新的重大命題：

?

1.?如何處理每秒?1?億筆交易：萬物互聯時代，無處不在的交易終端和無數新的交易場景，會繼續帶來金融交易量的指數型增長。什么樣的架構與技術，可以處理萬物互聯時代的天量交易，是需要未雨綢繆去攻堅與突破的；

?

2.?將金融級分布式架構與技術變成“普惠”的云計算服務，為千千萬萬金融服務機構服務。為了實現這個目標，螞蟻金服和阿里云共同提出了“螞云計劃”，共建新一代的金融云平臺，未來服務全球?5?萬家金融機構，共創全球化的普惠金融。

?

中國已經在金融服務創新上處于世界領先，新金融需要新技術作為底盤與引擎，這是中國金融技術的挑戰與機遇。螞蟻金服期待與中國金融業的專家一起，共同創造未來的新金融技術，為世界技術做出更多中國的貢獻。

?

https://mp.weixin.qq.com/s?__biz=MzUzMzU5Mjc1Nw==&mid=2247483825&idx=1&sn=4b4f4e45fa653b88bd8a0370de125e36&chksm=faa0ee6bcdd7677d58e1deefb5500a53b4c77947a61fc47abd6c830e6a2496de12586fce9a16&mpshare=1&scene=1&srcid=0919itY6mEUVZwgUfjYssEzA#rd

?

========================

1.異地多活與容災:?單元化架構

2.布式改造是一個較為復雜的工程，既需要熟悉業務，能夠設計出整個系統的業務架構，按照業務架構來進行垂直拆分，又需要熟悉數據模型，區分“流水型”、“狀態型”、“配置型”數據，根據不同類型數據的特點將它他按用戶維度進行拆分，還需要熟悉分布式中間件的運用。

3.以上只是簡單介紹了支付系統我們能看見的一些問題和設計，還有后續的系統保障沒有寫出來，沒寫出來的才是關鍵部分，比如：支付系統監控（業務監控分類、渠道監控、商戶監控、賬戶監控）文章只是引子，?架構不是靜態的，而是動態演化的。只有能夠不斷應對環境變化的系統，才是有生命力的系統。所以即使你掌握了以上所有的業務細節，仍然需要演化式思維，在設計的同時，借助反饋和進化的力量推動架構的持續演進。

4.從0到1實現一套聚合支付系統。對外的商業系統。

5.第一層 split：把任務按照分片規則拆分成多個 Load 任務，并發送到集群中的 Server 去執行。

第二層 load：每個 load 任務撈取一個分片的數據，逐條創建 execute 任務，并發送到集群中的 Server 去執行。注意：撈取數據要進行流量控制以免數據量太大把集群打滿。

第三層 execute：執行具體的一條數據的邏輯。

總結

以上是生活随笔為你收集整理的支付系统的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。