概述

支付系統(tǒng)是連接消費(fèi)者、商家（或平臺(tái)）和金融機(jī)構(gòu)的橋梁，管理支付數(shù)據(jù)，調(diào)用第三方支付平臺(tái)接口，記錄支付信息（對(duì)應(yīng)訂單號(hào)，支付金額等），金額對(duì)賬等功能，根據(jù)不同公司對(duì)于支付業(yè)務(wù)的定位不同大概有幾個(gè)階段：第一階段：支付作為一個(gè)（封閉）的、獨(dú)立的應(yīng)用系統(tǒng)，為各系統(tǒng)提供支付功能支持。一般來(lái)說(shuō)，這個(gè)系統(tǒng)僅限于為公司內(nèi)部的業(yè)務(wù)提供支付支持，并且和業(yè)務(wù)緊密耦合。第二階段：支付作為一個(gè)開發(fā)的系統(tǒng)，為公司內(nèi)外部系統(tǒng)、各種業(yè)務(wù)提供支付服務(wù)，支付服務(wù)本身應(yīng)該是和具體的業(yè)務(wù)解耦合。

?

? ? ? 支付是電商系統(tǒng)中核心

我們先來(lái)看一下用戶完成一次購(gòu)物需要進(jìn)行那些操作：

通常消費(fèi)者在手機(jī)APP或者網(wǎng)站都會(huì)涉及到支付相關(guān)的業(yè)務(wù)場(chǎng)景，用戶只需要簡(jiǎn)單點(diǎn)擊支付按鈕輸入支付密碼，就可以完成整個(gè)支付過(guò)程，那么我就和大家一起來(lái)看看一個(gè)完整的支付系統(tǒng)有什么功能組成和設(shè)計(jì)時(shí)需要考慮那些問題。

?

01

支付系統(tǒng)的作用

從上圖中我們可以看出真實(shí)的資金流向。首先當(dāng)用戶產(chǎn)生支付行為時(shí)，資金從用戶端流向支付系統(tǒng)，退款時(shí)則相反，從支付系統(tǒng)回流至用戶端。因此在整個(gè)交易過(guò)程中用戶端與支付系統(tǒng)是雙向資金的流動(dòng)方式。對(duì)于支付系統(tǒng)而言，資金有進(jìn)有出。從支付系統(tǒng)到商戶端就比較簡(jiǎn)單了，在清算完成后支付系統(tǒng)負(fù)責(zé)將代收的資金結(jié)算給商戶，通常結(jié)算的操作可以在線上來(lái)完成（采用支付公司代付接口或者銀企直連接口來(lái)完成），也可以由公司財(cái)務(wù)通過(guò)線下手工轉(zhuǎn)賬的方式來(lái)完成，因此這種資金流動(dòng)的方式是單向的。出于資金安全考慮，大多數(shù)公司通常這部分采用線下方式實(shí)現(xiàn)。

真實(shí)的資金流由支付公司按照約定期限（通常 T+1 ）結(jié)算到平臺(tái)公司對(duì)公賬戶中，然后再由平臺(tái)公司再按照交易明細(xì)進(jìn)行二次清算后結(jié)算給對(duì)應(yīng)的商戶。

?

支付系統(tǒng)

一個(gè)支付系統(tǒng)需要由哪些功能模塊組成

?

01

完整的支付系統(tǒng)包括如下功能：

應(yīng)用管理: 同時(shí)支持公司多個(gè)業(yè)務(wù)系統(tǒng)對(duì)接。

商戶管理: 支持商戶入駐，商戶需要向平臺(tái)方提供相關(guān)的資料備案。

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

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

支付交易: 生成預(yù)支付訂單、提供退款服務(wù)。

對(duì)賬管理: 實(shí)現(xiàn)支付系統(tǒng)的交易數(shù)據(jù)與第三方支付渠道交易明細(xì)的自動(dòng)核對(duì)（通常T+1），確保交易數(shù)據(jù)的準(zhǔn)確性和一致性。

清算管理: 計(jì)算收款交易中商戶的應(yīng)收與支付系統(tǒng)收益。

結(jié)算管理: 根據(jù)清算結(jié)果，將資金劃撥至商戶對(duì)應(yīng)的資金帳戶中。

02

核心流程

支付系統(tǒng)有幾個(gè)關(guān)鍵的核心流程：支付流程、對(duì)賬流程、結(jié)算流程

支付流程

支付流程說(shuō)明

用戶在商城選購(gòu)商品并發(fā)起支付請(qǐng)求；

商城將支付訂單通過(guò)B2C網(wǎng)關(guān)收款接口傳送至支付網(wǎng)關(guān)；

用戶選擇網(wǎng)銀支付及銀行，支付平臺(tái)將訂單轉(zhuǎn)送至指定銀行網(wǎng)關(guān)界面；

用戶支付完成，銀行處理結(jié)果并向平臺(tái)返回處理結(jié)果；

支付平臺(tái)接收處理結(jié)果，落地處理并向商戶返回結(jié)果；

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

一般而言支付系統(tǒng)會(huì)給商戶設(shè)置有“可用余額”賬戶、“待結(jié)算”賬戶；系統(tǒng)在接收到銀行返回支付成功信息會(huì)進(jìn)行落地處理，一方面更改對(duì)應(yīng)訂單狀態(tài)，另一方面在商戶待結(jié)算賬戶記入一筆金額；該筆金額，系統(tǒng)會(huì)根據(jù)結(jié)算周期從待結(jié)算賬戶--->“可用余額”賬戶。

退款流程說(shuō)明

用戶在商戶平臺(tái)發(fā)起退款申請(qǐng)，商戶核實(shí)退款信息及申請(qǐng)；

商戶登錄支付平臺(tái)賬戶/或者通過(guò)支付公司提供的退款接口向支付平臺(tái)發(fā)起退款；

支付系統(tǒng)會(huì)對(duì)退款信息校驗(yàn)（退款訂單對(duì)應(yīng)的原訂單是否支付成功？退款金額是否少于等于原訂單金額？），校驗(yàn)商戶賬戶余額是否充足等；校驗(yàn)不通過(guò)，則無(wú)法退款；

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

對(duì)于收單金額未結(jié)算，還在“待結(jié)算”賬戶的訂單，如果出現(xiàn)退款情況，業(yè)務(wù)流程和上述流程差不多，只是從待結(jié)算賬戶進(jìn)行扣款。

對(duì)賬流程

說(shuō)明

? ? ? ? 對(duì)賬，我們一般稱為勾兌，支付系統(tǒng)的對(duì)賬，包含著兩個(gè)層面：

支付系統(tǒng)內(nèi)部間的對(duì)賬，支付系統(tǒng)一般是分布式的，整個(gè)支付系統(tǒng)被拆分成了多個(gè)子系統(tǒng)，如交易系統(tǒng)、賬戶系統(tǒng)、會(huì)計(jì)系統(tǒng)、賬戶系統(tǒng)，每個(gè)子系統(tǒng)在處理各自的業(yè)務(wù)，系統(tǒng)間的對(duì)賬，就是以上系統(tǒng)的核對(duì)，用于修正內(nèi)部系統(tǒng)的數(shù)據(jù)不一致。

支付系統(tǒng)與渠道的對(duì)賬，這里的渠道泛指所有為支付系統(tǒng)提供代收付業(yè)務(wù)的渠道，如：第三方支付公司、銀行、清算中心、網(wǎng)聯(lián)、銀聯(lián)等。

支付系統(tǒng)與渠道間的對(duì)賬

系統(tǒng)間的對(duì)賬比較好理解，這里主要講支付系統(tǒng)與渠道間的對(duì)賬。支付系統(tǒng)與渠道間的對(duì)賬，又包含2個(gè)維度：

信息流勾對(duì)：即業(yè)務(wù)對(duì)賬／交易對(duì)賬，主要是就收單交易的支付信息與銀行提供的信息流文件進(jìn)行勾兌。信息流的勾地能發(fā)現(xiàn)支付系統(tǒng)與銀行系統(tǒng)間的掉單、兩邊由于系統(tǒng)間的原因?qū)е碌耐还P交易支付金額不一致（可能性很小）或者支付狀態(tài)不一致。信息流勾兌一般用來(lái)恢復(fù)掉單數(shù)據(jù)，可通過(guò)補(bǔ)單或者具體系統(tǒng)問題排查解決。

資金流勾對(duì)：即資金對(duì)賬，主要就收單交易的支付信息與銀行提供的資金流信息進(jìn)行勾兌。資金流的勾兌能發(fā)現(xiàn)支付系統(tǒng)在銀行的帳戶資金實(shí)際發(fā)生的變動(dòng)與應(yīng)該發(fā)生的變動(dòng)的差異，比如長(zhǎng)款（銀行多結(jié)算給支付系統(tǒng)）和短款（銀行少結(jié)算給支付系統(tǒng)）。

說(shuō)了這么多，就出現(xiàn)來(lái)4個(gè)對(duì)賬文件，支付系統(tǒng)信息流文件、支付系統(tǒng)資金流文件、銀行信息流文件、銀行資金流文件。業(yè)務(wù)對(duì)賬（勾兌）就是支付系統(tǒng)的信息流文件與銀行的信息流文件勾兌，資金對(duì)賬即支付系統(tǒng)的資金流文件與銀行的資金流文件勾兌。

核對(duì)的差異處理

1、信息流勾對(duì)的差異處理

• 支付系統(tǒng)信息流沒有，而銀行有的差異，可能是因?yàn)橹Ц断到y(tǒng)交易數(shù)據(jù)的丟失、銀行的掉單，如果是銀行的掉單，由支付公司的運(yùn)營(yíng)登錄銀行網(wǎng)銀確認(rèn)后，做補(bǔ)單處理，并將差異表中該記錄核銷。

• 支付系統(tǒng)信息流有，而銀行沒有的差異，此種情況一般不會(huì)發(fā)生，因?yàn)橹Ц断到y(tǒng)所有的交易數(shù)據(jù)都是取銀行返回狀態(tài)的數(shù)據(jù)。

2、資金流勾對(duì)對(duì)差異處理

• 支付系統(tǒng)資金流沒有，而銀行有的差異。可能原因如下：1、銀行日切晚與支付系統(tǒng)核心賬務(wù)系統(tǒng)；2、支付系統(tǒng)賬務(wù)核心系統(tǒng)與其他系統(tǒng)間的掉單。一旦出現(xiàn)，則會(huì)出現(xiàn)長(zhǎng)款（即銀行不應(yīng)該結(jié)算而實(shí)際結(jié)算）的現(xiàn)象，對(duì)于因日切導(dǎo)致的差異，在第二天的對(duì)賬中系統(tǒng)會(huì)對(duì)平，其他原因的，需要技術(shù)排查。

• 支付系統(tǒng)資金流有，而銀行沒有的差異，可能是因?yàn)殂y行日切早于支付系統(tǒng)的核心賬務(wù)系統(tǒng)，一旦出現(xiàn)，會(huì)出現(xiàn)短款（銀行應(yīng)結(jié)算而實(shí)際未結(jié)算）的現(xiàn)象，銀行日切導(dǎo)致段差異，會(huì)在下一天與銀行的勾對(duì)中，將此筆差異勾對(duì)上，如果是非日切導(dǎo)致的原因，就需要找銀行追款了。

總結(jié)就是，業(yè)務(wù)對(duì)賬，即信息流對(duì)賬，支付系統(tǒng)的交易流水與銀行的交易流水間核對(duì)，保障支付交易完整入賬。資金對(duì)賬，即資金流對(duì)賬，支付系統(tǒng)的入賬流水與銀行的結(jié)算流水間核對(duì)，保障銀行入賬流水與實(shí)際入賬資金的匹配。

?

結(jié)算流程

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

03

關(guān)鍵表設(shè)計(jì)

04

支付系統(tǒng)要點(diǎn)

在支付系統(tǒng)中，支付網(wǎng)關(guān)和支付渠道的對(duì)接是最繁瑣重要的功能之一，其中支付網(wǎng)關(guān)是對(duì)外提供服務(wù)的接口，所有需要渠道支持的資金操作都需要通過(guò)網(wǎng)關(guān)分發(fā)到對(duì)應(yīng)的渠道模塊上。一旦定型，后續(xù)就很少，也很難調(diào)整。而支付渠道模塊是接收網(wǎng)關(guān)的請(qǐng)求，調(diào)用渠道接口執(zhí)行真正的資金操作。每個(gè)渠道的接口，傳輸方式都不盡相同，所以在這里，支付網(wǎng)關(guān)相對(duì)于支付渠道模塊的作用，類似設(shè)計(jì)模式中的wrapper，封裝各個(gè)渠道的差異，對(duì)網(wǎng)關(guān)呈現(xiàn)統(tǒng)一的接口。而網(wǎng)關(guān)的功能是為業(yè)務(wù)提供通用接口，一些和渠道交互的公共操作，也會(huì)放置到網(wǎng)關(guān)中。

支付系統(tǒng)對(duì)其他系統(tǒng)，特別是交易系統(tǒng)，提供的支付服務(wù)包括簽約，支付，退款，充值，轉(zhuǎn)帳，解約等。有些地方還會(huì)額外提供簽約并支付的接口，用于支持在支付過(guò)程中綁卡。 每個(gè)服務(wù)實(shí)現(xiàn)的流程也是基本類似，包括下單，取消訂單，退單，查單等操作。每個(gè)操作實(shí)現(xiàn)，都包括參數(shù)校驗(yàn)，支付路由，生成訂單，風(fēng)險(xiǎn)評(píng)估，調(diào)用渠道服務(wù)，更新訂單和發(fā)送消息這7步，對(duì)于一些比較復(fù)雜的渠道服務(wù)，還會(huì)涉及到異步同通知處理的步驟。

01

網(wǎng)關(guān)前置

支付網(wǎng)關(guān)前置是對(duì)接業(yè)務(wù)系統(tǒng)，為其提供支付服務(wù)的模塊。它是所有支付服務(wù)接口的集成前置，將不同支付渠道提供的接口通過(guò)統(tǒng)一的方式呈現(xiàn)給業(yè)務(wù)方。這樣接入方就只需要對(duì)接支付網(wǎng)關(guān)，增加和調(diào)整支付渠道對(duì)業(yè)務(wù)方是透明的。 支付網(wǎng)關(guān)前置的設(shè)計(jì)對(duì)整個(gè)支付系統(tǒng)的穩(wěn)定性、功能、性能以及其他非功能性需求有著直接的影響。

在支付網(wǎng)關(guān)中需要完成大量的操作，為了保證性能，這些操作都盡量異步化來(lái)處理。支付網(wǎng)關(guān)前置應(yīng)保持穩(wěn)定，盡量減少系統(tǒng)重啟等操作對(duì)業(yè)務(wù)方的影響。支付網(wǎng)關(guān)也避免不了升級(jí)和重啟。這可通過(guò)基于Nginx的LBS(Load Balance System)網(wǎng)關(guān)來(lái)解決。LBS在這里有兩個(gè)作用： 一個(gè)是實(shí)現(xiàn)負(fù)載均衡，一個(gè)是隔離支付網(wǎng)關(guān)重啟對(duì)調(diào)用的影響。 支付網(wǎng)關(guān)也采用多臺(tái)機(jī)器分布式部署，重啟時(shí)，每個(gè)服務(wù)器逐個(gè)啟動(dòng)。某臺(tái)服務(wù)器重啟時(shí)，首先從LBS系統(tǒng)中取消注冊(cè)，重啟完成后，再重新注冊(cè)到LBS上。這個(gè)過(guò)程對(duì)調(diào)用方是無(wú)感知的。

為了避免接口受攻擊，在安全上，還得要求業(yè)務(wù)方通過(guò)HTTPS來(lái)訪問接口，并提供防篡改機(jī)制。防篡改則通過(guò)接口參數(shù)簽名來(lái)處理。現(xiàn)在主流的簽名是對(duì)接口參數(shù)按照參數(shù)名稱排序后，做加密和散列，參考微信的簽名規(guī)范。

02

參數(shù)校驗(yàn)

• 所有的支付操作，都需要對(duì)輸入執(zhí)行參數(shù)校驗(yàn)，避免接口受到攻擊。

• 驗(yàn)證輸入?yún)?shù)中各字段的有效性驗(yàn)證，比如用戶ID,商戶ID,價(jià)格，返回地址等參數(shù)。

• 驗(yàn)證賬戶狀態(tài)。交易主體、交易對(duì)手等賬戶的狀態(tài)是處于可交易的狀態(tài)。

• 驗(yàn)證訂單：如果涉及到預(yù)單，還需要驗(yàn)證訂單號(hào)的有效性，訂單狀態(tài)是未支付。為了避免用戶緩存某個(gè)URL地址，還需要校驗(yàn)下單時(shí)間和支付時(shí)間是否超過(guò)預(yù)定的間隔。

• 驗(yàn)證簽名。簽名也是為了防止支付接口被偽造。 一般簽名是使用分發(fā)給商戶的key來(lái)對(duì)輸入?yún)?shù)拼接成的字符串做MD5 Hash或者RSA加密，然后作為一個(gè)參數(shù)隨其他參數(shù)一起提交到服務(wù)器端。

03

路由選擇

根據(jù)用戶選擇的支付方式確定用來(lái)完成該操作的合適的支付渠道。用戶指定的支付方式不一定是最終的執(zhí)行支付的渠道。比如用戶選擇通過(guò)工行信用卡來(lái)執(zhí)行支付，但是我們沒有實(shí)現(xiàn)和工行的對(duì)接，而是可以通過(guò)第三方支付，比如支付寶、微信支付、易寶支付，或者銀聯(lián)來(lái)完成。那如何選擇合適的支付渠道，就通過(guò)支付路由來(lái)實(shí)現(xiàn)。支付路由會(huì)綜合考慮收費(fèi)、渠道的可用性等因素來(lái)選擇最優(yōu)方案

04

風(fēng)險(xiǎn)評(píng)估

檢查本次交易是否有風(fēng)險(xiǎn)。風(fēng)控接口返回三種結(jié)果：阻斷交易、增強(qiáng)驗(yàn)證和放行交易。

• 阻斷交易，說(shuō)明該交易是高風(fēng)險(xiǎn)的，需要終止，不執(zhí)行第5個(gè)步驟；

• 增強(qiáng)驗(yàn)證，說(shuō)明該交易有一定的風(fēng)險(xiǎn)，需要確認(rèn)下是不是用戶本人在操作。這可以通過(guò)發(fā)送短信驗(yàn)證碼或者其他可以驗(yàn)證用戶身份的方式來(lái)做校驗(yàn)，驗(yàn)證通過(guò)后，可以繼續(xù)執(zhí)行該交易。

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

05

發(fā)送消息

通過(guò)消息來(lái)通知相關(guān)系統(tǒng)關(guān)于訂單的變更。風(fēng)控，信用BI等，都需要依賴這數(shù)據(jù)做準(zhǔn)實(shí)時(shí)計(jì)算。

06

更新訂單

對(duì)于同步返回的結(jié)果，需要在主線程中更新訂單的狀態(tài)，標(biāo)記是支付成功還是失敗。對(duì)于異步返回的渠道，需要在異步程序中處理。

07

異步通知

其中涉及到調(diào)用遠(yuǎn)程接口，其延遲不可控。如果調(diào)用方一直阻塞等待，很容易超時(shí)。引入異步通知機(jī)制，可以讓調(diào)用方在主線程中盡快返回，通過(guò)異步線程來(lái)得到支付結(jié)果。對(duì)于通過(guò)異步來(lái)獲取支付結(jié)果的渠道接口，也需要對(duì)應(yīng)的在異步通知中將結(jié)果返回給調(diào)用方。 異步通知需要調(diào)用方提供一個(gè)回調(diào)地址，一般以http或者h(yuǎn)ttps的方式。這就有技術(shù)風(fēng)險(xiǎn)，如果調(diào)用失敗，還需要重試。而重試不能過(guò)于頻繁，需要逐步拉大每一次重試的時(shí)間間隔。 在異步處理程序中，訂單根據(jù)處理結(jié)果變更狀態(tài)后，也要發(fā)消息通知相關(guān)系統(tǒng)。

08

生成交易訂單

將訂單信息持久化到數(shù)據(jù)庫(kù)中。當(dāng)訪問壓力大的時(shí)候，數(shù)據(jù)庫(kù)寫入會(huì)成為一個(gè)瓶頸。

09

交易流水和記賬

每一筆交易都需要記錄流水，并登記到個(gè)人和機(jī)構(gòu)的分戶賬戶上，統(tǒng)計(jì)和分析也需要根據(jù)交易流水來(lái)更新相關(guān)數(shù)據(jù)。 而個(gè)人和機(jī)構(gòu)賬戶總額更新、交易流水記錄以及庫(kù)存的處理，更是需要事務(wù)處理機(jī)制的支持。 從性能角度， 可以弱化了事務(wù)處理的要求，采用消息機(jī)制來(lái)異步化和交易相關(guān)的數(shù)據(jù)處理。

• 在支付網(wǎng)關(guān)前置的主流程中，僅記錄交易流水，即將當(dāng)前的請(qǐng)求保存到數(shù)據(jù)庫(kù)中。

• 完成數(shù)據(jù)記錄后，發(fā)送MQ出來(lái)，記賬、統(tǒng)計(jì)、分析，都是接收MQ來(lái)完成數(shù)據(jù)處理。

• 涉及到本地資金支付，比如錢包支付，會(huì)需要分布式事務(wù)處理，扣減賬號(hào)余額，記賬，扣減庫(kù)存等，每個(gè)操作失敗，都要回滾。阿里有很不錯(cuò)的分享，這里不詳細(xì)描述。

• 當(dāng)交易量上來(lái)后，需要考慮交易表的分表分庫(kù)的事情。分表分庫(kù)有兩個(gè)策略，按照流水號(hào)或者交易主體id來(lái)走。后者可以支持按用戶來(lái)獲取交易記錄。我們用的是前者。后者可以走elastic，確保數(shù)據(jù)庫(kù)專用。風(fēng)控，信用和統(tǒng)計(jì)所需要的數(shù)據(jù)，通過(guò)MQ同步到歷史庫(kù)里面。作為支付系統(tǒng)最有價(jià)值的數(shù)據(jù)，在存儲(chǔ)上做到專庫(kù)專用，無(wú)可厚非，畢竟存儲(chǔ)成本還是廉價(jià)的。

10

支付路由

支付路由是一個(gè)復(fù)雜的話題。對(duì)支付系統(tǒng)來(lái)說(shuō)，能支持的支付方式越多越好，不能由于支付方式的不支持?jǐn)嗔素?cái)路。現(xiàn)實(shí)中的支付方式多得難以置信。用戶隨時(shí)甩出一張你聽都沒聽說(shuō)過(guò)的卡。如果一個(gè)銀行卡只有幾個(gè)用戶在用，那針對(duì)這個(gè)卡開發(fā)個(gè)對(duì)接有點(diǎn)得不嘗失。現(xiàn)在第三方支付的爆發(fā)，確實(shí)給開發(fā)支付系統(tǒng)省了不少事。但是公司不可能只對(duì)接一個(gè)第三方支付，如果這個(gè)渠道出問題了，或者鬧矛盾了，把鏈接給掐了，老板還不欲哭無(wú)淚。總之，得對(duì)接多個(gè)渠道。對(duì)于交易量大的銀行，還得考慮直聯(lián)。

11

渠道接入

對(duì)于支付渠道，首先考慮的是接入哪些渠道。要對(duì)接的渠道按優(yōu)先級(jí)有：

• 第三方支付，對(duì)大部分應(yīng)用來(lái)說(shuō)，支付寶和微信支付都是必須的，一般來(lái)說(shuō)，這兩者可以占到90%以上的交易量。用戶不需要綁卡，授權(quán)后直接支付就行。各種平臺(tái)都支持，性能和穩(wěn)定性都不錯(cuò)。對(duì)于一些特殊業(yè)務(wù)，比如游戲，企業(yè)支付，可以查看一些專用的第三方支付平臺(tái)。

• 銀聯(lián)，它的存在，極大方便了和銀行的對(duì)接。和第三方支付主要不同在兩個(gè)地方一是需要綁卡，也就是用戶先把卡號(hào)，手機(jī)，身份證號(hào)提供出來(lái)。這一步會(huì)折損不少用戶。綁卡后，以后的支付操作就簡(jiǎn)單了，用戶只需要輸入密碼就行。手機(jī)客戶端不需要像第三方支付那樣安裝SDK，都在服務(wù)器端完成。當(dāng)然，這是針對(duì)快捷支付。網(wǎng)銀支付還是挺麻煩的。銀聯(lián)接入也需要ADSS認(rèn)證。

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

• 手機(jī)支付：比如蘋果的In-App支付， 三星支付、華為支付等， 這些支付僅針對(duì)特定的手機(jī)型號(hào)， 支持NFC等，根據(jù)業(yè)務(wù)需要也可以接入。

總結(jié)

支付系統(tǒng)是一個(gè)繁雜的系統(tǒng)，其中涉及了各種錯(cuò)綜復(fù)雜的業(yè)務(wù)流程，以上只是簡(jiǎn)單介紹了支付系統(tǒng)我們能看見的一些問題和設(shè)計(jì)，還有后續(xù)的系統(tǒng)保障沒有寫出來(lái)，沒寫出來(lái)的才是關(guān)鍵部分，比如：支付系統(tǒng)監(jiān)控（業(yè)務(wù)監(jiān)控分類、渠道監(jiān)控、商戶監(jiān)控、賬戶監(jiān)控）文章只是引子，?架構(gòu)不是靜態(tài)的，而是動(dòng)態(tài)演化的。只有能夠不斷應(yīng)對(duì)環(huán)境變化的系統(tǒng)，才是有生命力的系統(tǒng)。所以即使你掌握了以上所有的業(yè)務(wù)細(xì)節(jié)，仍然需要演化式思維，在設(shè)計(jì)的同時(shí)，借助反饋和進(jìn)化的力量推動(dòng)架構(gòu)的持續(xù)演進(jìn)。

?

作者介紹：

?

山哥談支付系統(tǒng)

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

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

支付系統(tǒng)如何進(jìn)行分布式改造

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

?

?

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

更多關(guān)于傳統(tǒng)架構(gòu)與分布式架構(gòu)對(duì)比請(qǐng)參考《集中式架構(gòu)與分布式架構(gòu)比較》

分布式架構(gòu)在容量、性能、穩(wěn)定性、成本方面都具有巨大的優(yōu)勢(shì)。在高可用方面，核心思想之一是“解決一切單點(diǎn)”，單點(diǎn)容易出現(xiàn)故障，性能方面也可能成為瓶頸，因此需要將單點(diǎn)改造拆分成多個(gè)點(diǎn)。垂直拆分能更清晰化模塊劃分，區(qū)分治理，水平切分能解決大數(shù)據(jù)量性能瓶頸問題，分布式改造主要是將這兩者結(jié)合起來(lái)，對(duì)傳統(tǒng)架構(gòu)進(jìn)行全面的改造。

分布式改造之垂直拆分

垂直拆分就是將原來(lái)一個(gè)整體的系統(tǒng)按業(yè)務(wù)模塊拆分成多個(gè)系統(tǒng)，系統(tǒng)內(nèi)部數(shù)據(jù)是自包含的，不會(huì)與別的系統(tǒng)共用數(shù)據(jù)庫(kù)，系統(tǒng)與系統(tǒng)之間的交互通過(guò)暴露和調(diào)用服務(wù)來(lái)實(shí)現(xiàn)。那么如何按照業(yè)務(wù)來(lái)拆分呢？

為了方便理解，首先我們來(lái)看一下一筆支付過(guò)程是如何進(jìn)行的：

• 商戶發(fā)起收單請(qǐng)求，經(jīng)過(guò) API 網(wǎng)關(guān)，調(diào)到產(chǎn)品層的“在線收單”產(chǎn)品

• 調(diào)用收銀臺(tái)選擇支付方式，也可能直接進(jìn)入支付環(huán)節(jié)，創(chuàng)建交易流水

• 進(jìn)行支付處理，通過(guò)金融交換從銀行扣客戶帳，記錄帳務(wù)流水，入商戶帳，記錄賬務(wù)流水

• 對(duì)交易按照費(fèi)率進(jìn)行收費(fèi)，記錄收費(fèi)的帳務(wù)流水。此時(shí)會(huì)異步觸發(fā)營(yíng)銷和風(fēng)控策略

• 日終會(huì)異步進(jìn)行會(huì)計(jì)記帳（也有同步記會(huì)計(jì)帳的）、業(yè)會(huì)核對(duì)、清結(jié)算和對(duì)帳處理

從這個(gè)過(guò)程可以大概推演出支付系統(tǒng)的一般應(yīng)用架構(gòu)：

圖：支付系統(tǒng)的應(yīng)用架構(gòu)

應(yīng)用架構(gòu)定義一個(gè)大型軟件系統(tǒng)由哪些應(yīng)用子系統(tǒng)構(gòu)成，以及應(yīng)用之間是如何分工和協(xié)作的。好的應(yīng)用架構(gòu)抽象合理、協(xié)作有序、易于擴(kuò)展、能夠復(fù)用。有了這個(gè)應(yīng)用架構(gòu)，我們就可以非常清晰的根據(jù)應(yīng)用架構(gòu)劃分的子系統(tǒng)來(lái)進(jìn)行垂直拆分。

從架構(gòu)上來(lái)說(shuō)，分為四層：

?

圖：支付系統(tǒng)的分層

?

渠道層：商戶和客戶的交易請(qǐng)求的入口。一般會(huì)劃分以下系統(tǒng)：商戶網(wǎng)站、用戶網(wǎng)站、無(wú)線接入、API 網(wǎng)關(guān)。

產(chǎn)品層：通過(guò)基礎(chǔ)服務(wù)層提供的服務(wù)組裝成具體業(yè)務(wù)場(chǎng)景功能，對(duì)客戶、商戶運(yùn)營(yíng)等人員提供服務(wù)。一般會(huì)把服務(wù)商戶的功能劃分為商戶域，服務(wù) C 端用戶的劃分為用戶域。可以按照這兩個(gè)域拆分成兩個(gè)子系統(tǒng)，也可以更進(jìn)一步根據(jù)不同產(chǎn)品特性再拆分，比如商戶域中的收單產(chǎn)品、虛擬產(chǎn)品、垂直行業(yè)產(chǎn)品。

公共服務(wù)層：將各個(gè)產(chǎn)品都需要使用的些服務(wù)抽像成公共服務(wù)。一般會(huì)劃分：收銀臺(tái)、交易支付、計(jì)費(fèi)等系統(tǒng)。比如說(shuō)產(chǎn)品層可以通過(guò)組裝各種交易類型和收費(fèi)規(guī)則形成不同的產(chǎn)品。

基礎(chǔ)業(yè)務(wù)層：支付系統(tǒng)的核心，資金和客戶信息的處理都在這里。一般會(huì)劃分三大子系統(tǒng)：帳務(wù)核心、會(huì)計(jì)核心、會(huì)員核心。

其它支撐系統(tǒng)：

網(wǎng)關(guān)：負(fù)責(zé)與銀行、銀聯(lián)等金融機(jī)構(gòu)進(jìn)行資金交換，與外部合作伙伴接入，如渠道拓展商、行業(yè)客戶等。一般劃分：銀行接入網(wǎng)關(guān)和合作伙伴接入網(wǎng)關(guān)。

運(yùn)營(yíng)支撐：貫穿于四個(gè)層的是運(yùn)營(yíng)支撐域：一般會(huì)劃分運(yùn)營(yíng)支撐、安全、風(fēng)控、營(yíng)銷子系統(tǒng)。

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

分布式改造之水平拆分

前面講的垂直拆分只是把系統(tǒng)按業(yè)務(wù)模塊劃分到不同的子系統(tǒng)，數(shù)據(jù)庫(kù)也分到了不同系統(tǒng)，但沒有解決單表大數(shù)據(jù)量的問題，而水平切分就是要把一個(gè)表按照某種規(guī)則把數(shù)據(jù)劃分到不同表或數(shù)據(jù)庫(kù)里。簡(jiǎn)單的說(shuō)就是做分庫(kù)分表。

在做分庫(kù)分表之前我們需對(duì)數(shù)據(jù)模型進(jìn)行分類，分為“流水型數(shù)據(jù)”、“狀態(tài)型數(shù)據(jù)”和“配置型數(shù)據(jù)”。

• 流水型數(shù)據(jù)：像流水一樣不斷增長(zhǎng)的數(shù)據(jù)，各條數(shù)據(jù)間是獨(dú)立的。如支付訂單、交易流水、帳務(wù)流水（入帳/出帳）、會(huì)計(jì)流水等。

• 狀態(tài)型數(shù)據(jù)：代表一個(gè)對(duì)象當(dāng)前的狀態(tài)的數(shù)據(jù)。如會(huì)員信息、客戶信息、帳戶信息、會(huì)計(jì)帳。

為什么有會(huì)員信息還有客戶信息？會(huì)員往往是注冊(cè)在支付平臺(tái)的用戶，一個(gè)人可以注冊(cè)多個(gè)會(huì)員，但是一個(gè)自然人只可能有一個(gè)客戶信息，一個(gè)會(huì)員通過(guò)實(shí)名認(rèn)證后就關(guān)聯(lián)上了客戶信息。無(wú)論一個(gè)客戶注冊(cè)多少個(gè)會(huì)員，實(shí)名認(rèn)證后都只有一個(gè)客戶信息。

• 配置型數(shù)據(jù)：系統(tǒng)中用作為配置的數(shù)據(jù)。如產(chǎn)品、手續(xù)費(fèi)率、分支機(jī)構(gòu)信息、支付路由規(guī)則、會(huì)計(jì)科目等。

?

流水型數(shù)據(jù)會(huì)不斷產(chǎn)生，且各條數(shù)據(jù)間是獨(dú)立的，天然適合進(jìn)行分庫(kù)分表。

狀態(tài)型數(shù)據(jù)讀寫比相當(dāng)，每一次寫操作必須基于前一個(gè)正確的狀態(tài)，可以評(píng)估一下數(shù)據(jù)量的大小，數(shù)據(jù)量如果大或者要實(shí)現(xiàn)單元化架構(gòu)，也需要進(jìn)行分庫(kù)分表，提高并發(fā)處理能力，同時(shí)方便隔離故障影響。

配置型數(shù)據(jù)，讀多寫少，強(qiáng)依賴讀，弱依賴寫，不要求嚴(yán)格的讀一致性，且配置型數(shù)據(jù)一般數(shù)據(jù)量不會(huì)很大，不需要進(jìn)行分庫(kù)分表設(shè)計(jì)。但是業(yè)務(wù)處理中往往又需要用到，傳統(tǒng)架構(gòu)的老系統(tǒng)可能使用了一些關(guān)聯(lián)表操作，關(guān)聯(lián)到了配置數(shù)據(jù)，分庫(kù)后其它數(shù)據(jù)與配置不在一個(gè)庫(kù)，不能進(jìn)行關(guān)聯(lián)表操作，由于配置型數(shù)據(jù)不要求嚴(yán)格的讀一致性的特點(diǎn)，可以將配置型數(shù)據(jù)加載到分布式緩存里，由業(yè)務(wù)代碼來(lái)做“join”。

那么分庫(kù)分表按照什么規(guī)則來(lái)拆分呢？通常不會(huì)按實(shí)體 id 進(jìn)行 hash 取模的方式來(lái)拆分。因?yàn)橄Ｍ粋€(gè)用戶的數(shù)據(jù)能夠在同一個(gè)數(shù)據(jù)庫(kù)中，盡量避免產(chǎn)生分布式事務(wù)。業(yè)界普遍的做法是通過(guò)用戶維度來(lái)進(jìn)行拆分。由于不同實(shí)體 id 的值不同，且不能保證每個(gè)實(shí)體和請(qǐng)求中都包含用戶 id，所以簡(jiǎn)單的用實(shí)體 id 或用戶 id 進(jìn)行 hash 取模將不能保證同一個(gè)用戶的數(shù)據(jù)都落在同一個(gè)分片。

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

下面是一個(gè)參考的 id 生成規(guī)則示例：

所以數(shù)據(jù)水平拆分除了需要一個(gè)強(qiáng)大的分庫(kù)分表數(shù)據(jù)訪問中間件，還需要一個(gè)分布式序列生成器。當(dāng)然這個(gè)生成器也可以是集成在分庫(kù)分表數(shù)據(jù)訪問中間件中的一個(gè)功能。

那么如果一筆交易涉及多個(gè)用戶按誰(shuí)的 id 來(lái)拆分呢？比如一筆轉(zhuǎn)賬或支付，涉及轉(zhuǎn)出方/轉(zhuǎn)入方或支付方/收款商戶。這種情況一般可以按資金轉(zhuǎn)出方來(lái)拆分。

分布式改造后帶來(lái)的問題如何應(yīng)對(duì)

?

分布式事務(wù)產(chǎn)生

由于按用戶維度進(jìn)行了分庫(kù)分表，可能存在跨數(shù)據(jù)庫(kù)的事務(wù)，比如說(shuō)，轉(zhuǎn)賬交易中轉(zhuǎn)出方和轉(zhuǎn)入方的賬戶不在同一個(gè)數(shù)據(jù)庫(kù)中，這就產(chǎn)生了分布式事務(wù)。通常不會(huì)用 XA 協(xié)議來(lái)解決，因?yàn)?XA 協(xié)議鎖資源性能太差，通常是通過(guò) TCC 柔性事務(wù)來(lái)解決。具體可以參見進(jìn)階閱讀《分布式事務(wù)綜述》。

跨表查詢?nèi)绾谓鉀Q

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

還可以通過(guò)異構(gòu)索引來(lái)查詢和做 OLAP 分析，異構(gòu)索引就是將數(shù)據(jù)同步到 ElasticSearch，利用 ES 的強(qiáng)大索引能力來(lái)做查詢和分析，為了使業(yè)務(wù)更容易使用，可以利用數(shù)據(jù)訪問代理層來(lái)屏蔽底層是路由到數(shù)據(jù)庫(kù)還是路由到 ES。

如何進(jìn)行數(shù)據(jù)同步

企業(yè)都有做大數(shù)據(jù)分析的需求，需要將數(shù)據(jù)同步大數(shù)據(jù)平臺(tái)，如 Hadoop。分庫(kù)分表之后，數(shù)據(jù)同步會(huì)比較復(fù)雜，畢竟之前是單表同步到 Hadoop 比較簡(jiǎn)單，但是 100 張表同步到 Hadoop 里會(huì)復(fù)雜一些。這時(shí)就需要設(shè)計(jì)一套專門的數(shù)據(jù)模型管理平臺(tái)，數(shù)據(jù)模型、分庫(kù)分表規(guī)則等由這個(gè)平臺(tái)來(lái)管理，當(dāng)需要使用數(shù)據(jù)的時(shí)候通過(guò)（應(yīng)用/邏輯表）維度訂閱數(shù)據(jù)即可，不用單獨(dú)訂閱物理表。不僅是數(shù)據(jù)同步，凡是有業(yè)務(wù)需要用到各種數(shù)據(jù)，都可以通過(guò)這個(gè)平臺(tái)來(lái)訂閱，幫助企業(yè)數(shù)據(jù)業(yè)務(wù)快速發(fā)展。

分庫(kù)分表后批處理任務(wù)怎么處理

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

前面提到各條流水?dāng)?shù)據(jù)之間沒有關(guān)聯(lián)的，完全可以并發(fā)的進(jìn)行處理，每個(gè) Server 撈取一個(gè)分片的數(shù)據(jù)進(jìn)行處理。那么就需要有一個(gè)很好的調(diào)度系統(tǒng)來(lái)協(xié)調(diào)，可以采用三層調(diào)度的方式。

圖：三層調(diào)度示意圖

• 第一層 split：把任務(wù)按照分片規(guī)則拆分成多個(gè) Load 任務(wù)，并發(fā)送到集群中的 Server 去執(zhí)行。

• 第二層 load：每個(gè) load 任務(wù)撈取一個(gè)分片的數(shù)據(jù)，逐條創(chuàng)建 execute 任務(wù)，并發(fā)送到集群中的 Server 去執(zhí)行。注意：撈取數(shù)據(jù)要進(jìn)行流量控制以免數(shù)據(jù)量太大把集群打滿。

• 第三層 execute：執(zhí)行具體的一條數(shù)據(jù)的邏輯。

三層架構(gòu)并不是說(shuō)一定都需要三層，可以根據(jù)業(yè)務(wù)邏輯來(lái)定制只有兩層也可以。

如何進(jìn)行數(shù)據(jù)擴(kuò)容

通常可以采用“預(yù)分配”的方式來(lái)做，即一開始就按一個(gè)比較長(zhǎng)期的容量來(lái)規(guī)劃分片數(shù)，比如百庫(kù)百表。但實(shí)際上一開始并沒有這么大的量，所以實(shí)際只有兩個(gè)數(shù)據(jù)庫(kù) Server，在這兩個(gè) Server 上分別建 50 個(gè) schema，邏輯上仍然是 100 個(gè)分庫(kù)，物理上只有 2 個(gè)數(shù)據(jù)庫(kù) Server。當(dāng)容量不夠的時(shí)候，為了保證數(shù)據(jù)的均衡，通常會(huì)采用成倍擴(kuò)容的方式，再加兩臺(tái)數(shù)據(jù)庫(kù) Server，然后分別遷移 25 個(gè) schema 到這兩個(gè)數(shù)據(jù)庫(kù) Server 上，數(shù)據(jù)也搬過(guò)來(lái)。由于數(shù)據(jù)同步有延時(shí)，全量數(shù)據(jù)同步完成后，兩邊的 schema 都禁寫，待增量數(shù)據(jù)同步完成后打開新的 schema 寫，會(huì)產(chǎn)生短暫的部分用戶交易失敗，重試一下即可，在低峰期做遷移，產(chǎn)生小范圍失敗一般是可以接受的。由于邏輯分片數(shù)沒有變化，擴(kuò)容成本比較低。通常不會(huì)用改變分片規(guī)則的方式來(lái)擴(kuò)容，因?yàn)楦淖兎制?guī)則需要進(jìn)行數(shù)據(jù)重新分布，成本和風(fēng)險(xiǎn)巨大。

如何進(jìn)行容災(zāi)

• 同城容災(zāi)：通常可以同城多機(jī)房部署應(yīng)用，數(shù)據(jù)庫(kù)只有一個(gè)機(jī)房處于 Active 狀態(tài)，所有機(jī)房的應(yīng)用都連這個(gè)機(jī)房的數(shù)據(jù)庫(kù)，另一個(gè)機(jī)房的數(shù)據(jù)庫(kù)為備庫(kù)，進(jìn)行主備復(fù)制，當(dāng)備機(jī)房發(fā)生災(zāi)難時(shí)業(yè)務(wù)不會(huì)中斷，但業(yè)務(wù)會(huì)跌一半，當(dāng)主機(jī)房發(fā)生災(zāi)難時(shí)，數(shù)據(jù)庫(kù)切換備庫(kù)，會(huì)有短暫的業(yè)務(wù)中斷。

• 異地冷備：應(yīng)用也是異地多機(jī)房部署，由于異地網(wǎng)絡(luò)延時(shí)不可忽略，異地備機(jī)房是處于 standby 狀態(tài)，正常是沒有流量的，冷備機(jī)房采用數(shù)據(jù)庫(kù)主備同步的方式同步數(shù)據(jù)，這種方式災(zāi)備切換時(shí)間長(zhǎng)，成本投入高。

• 異地多活：應(yīng)用采用異地多機(jī)房單元化部署架構(gòu)，每個(gè)機(jī)房的應(yīng)用都是可以提供服務(wù)的，單元內(nèi)是自包含部署全量應(yīng)用，每個(gè)單元服務(wù)多個(gè)分片的用戶，單元化架構(gòu)可以參考《素描單元化》。由于異地網(wǎng)絡(luò)延時(shí)是不可忽略的，數(shù)據(jù)層的容災(zāi)方案也是分“流水型”、“狀態(tài)型”、“配置型”數(shù)據(jù)采用不同的容災(zāi)策略。具體可參考《分布式系統(tǒng)數(shù)據(jù)層設(shè)計(jì)模式》。

?

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

分布式改造后整個(gè)系統(tǒng)架構(gòu)已經(jīng)是服務(wù)化了，原來(lái)通常可以通過(guò)查本地日志來(lái)定位問題。但現(xiàn)在一個(gè)交易由若干個(gè)系統(tǒng)協(xié)同完成，我們需要一套分布式鏈路跟蹤系統(tǒng)或 APM（應(yīng)用性能管理）系統(tǒng)來(lái)協(xié)助我們看清整個(gè)系統(tǒng)的全貌，分析排查問題。那么如何進(jìn)行分布式鏈路跟蹤呢？可以通過(guò) OpenTracing 標(biāo)準(zhǔn)對(duì)整個(gè)分布式架構(gòu)中的中間件和應(yīng)用進(jìn)行埋點(diǎn)或自動(dòng)植入探針實(shí)現(xiàn)。

總 ?結(jié)

分布式架構(gòu)有著海量、成本、穩(wěn)定、速度的優(yōu)勢(shì)，但它也不是銀彈，分布式改造是一個(gè)較為復(fù)雜的工程，既需要熟悉業(yè)務(wù)，能夠設(shè)計(jì)出整個(gè)系統(tǒng)的業(yè)務(wù)架構(gòu)，按照業(yè)務(wù)架構(gòu)來(lái)進(jìn)行垂直拆分，又需要熟悉數(shù)據(jù)模型，區(qū)分“流水型”、“狀態(tài)型”、“配置型”數(shù)據(jù)，根據(jù)不同類型數(shù)據(jù)的特點(diǎn)將它他按用戶維度進(jìn)行拆分，還需要熟悉分布式中間件的運(yùn)用。分布式中間件在整個(gè)分布式架構(gòu)中起著至關(guān)重要的作用，將技術(shù)構(gòu)架與業(yè)務(wù)結(jié)合起來(lái)。螞蟻金服通過(guò)多年金融級(jí)架構(gòu)的演進(jìn)，經(jīng)過(guò)多年雙十一大促的驗(yàn)證，已經(jīng)形成了一套業(yè)界領(lǐng)先的金融級(jí)分布式架構(gòu)，請(qǐng)參考《金融級(jí)分布式交易的技術(shù)路徑》。

?

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

從0到1實(shí)現(xiàn)一套聚合支付系統(tǒng)

?

大家好，我是來(lái)自盒子科技研發(fā)部支付線劉恒，目前主要是負(fù)責(zé)公司的一個(gè)聚合支付系統(tǒng)的研發(fā)工作。今天主要是講一下我們聚合支付系統(tǒng)從2016年年初到現(xiàn)在技術(shù)演變。

?

首先我會(huì)從那三個(gè)方向，第一是聚合支付的介紹，聚合支付在我們公司它承擔(dān)一個(gè)什么樣的地位，第二是在我們公司有什么樣的使用場(chǎng)景。第三是從公司開始做聚合支付最開始的版本是什么樣子的，在這個(gè)版本之上，我們做了什么樣的優(yōu)化，然后到了現(xiàn)在發(fā)展成什么樣的架構(gòu)。

?

01

?

聚合支付的介紹

_____

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

?

它主要是針對(duì)一個(gè)微小商戶進(jìn)行一個(gè)收款工具，讓商家他那邊會(huì)有一個(gè)好噠商戶通，第一個(gè)可以實(shí)時(shí)的收聽語(yǔ)音報(bào)告，當(dāng)前用戶付款多少錢，第二個(gè)就是他可以去實(shí)時(shí)查看賬單，了解當(dāng)天的營(yíng)業(yè)額。

?

?

?

還有一個(gè)產(chǎn)品就是我們公司的一個(gè)pos機(jī)。這個(gè)主要是一款生態(tài)pos，它里面不僅繼承了我們一個(gè)我們這個(gè)具備支付系統(tǒng)提供的服務(wù)，就比如微信支付寶，它們還集成了一個(gè)刷卡的功能，就是磁條卡芯片卡，還有各種支付方式。

?

這次我們講的聚合支付，只是涉及到交易流，不涉及到資金流，資金流是其他項(xiàng)目組負(fù)責(zé)。

?

02

?

1.0系統(tǒng)

_____

?

好，進(jìn)入項(xiàng)目背景。

?

第一個(gè)就是工期短，基本上所有的項(xiàng)目都會(huì)遇到，天天都在趕工程。

?

?

我們是從2016年過(guò)年前一周，然后忽然被拉入一個(gè)群，說(shuō)是有個(gè)項(xiàng)目要做一做，當(dāng)時(shí)老大讓一周上線，

?

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

?

第三個(gè)就是人員的缺乏，因?yàn)楫?dāng)時(shí)就做系統(tǒng)研發(fā)，只有我和另外一個(gè)新同事。

?

就在這種背景下，我們就搭建了第一套系統(tǒng)架構(gòu)，即虛線圈住的，我負(fù)責(zé)交易前置，同事負(fù)責(zé)交易網(wǎng)關(guān)，當(dāng)時(shí)就直接操作DB沒有做任何的其他的優(yōu)化。

?

?

?

當(dāng)時(shí)就做這樣一個(gè)簡(jiǎn)單的架構(gòu)，第一個(gè)開發(fā)比較快，直接拿需求進(jìn)行改代碼，方便測(cè)試以及上線。當(dāng)時(shí)是2016年3月份4月份就上線了，也很快。后來(lái)就是在經(jīng)過(guò)了三四個(gè)月交易量比較猛增的情況下，就發(fā)現(xiàn)這個(gè)系統(tǒng)感覺各種瓶頸就出來(lái)了。

?

?

??渠道的隔離，因?yàn)楫?dāng)時(shí)對(duì)接了幾個(gè)渠道，特別渠道不穩(wěn)定的話，比如資源不可用、網(wǎng)絡(luò)問題，導(dǎo)致超時(shí)，這樣就會(huì)把所有渠道交易全部影響，造成級(jí)聯(lián)反應(yīng)，導(dǎo)致整個(gè)服務(wù)交易鏈路不可用，影響比較嚴(yán)重。周末別人都可以在家好好休息，但是我們支付研發(fā)不行，每天都是隨時(shí)關(guān)注手機(jī)，因?yàn)檎f(shuō)不定哪個(gè)渠道就出問題了，立馬要處理。而且系統(tǒng)哪邊掛了之后立馬要趕緊聯(lián)系。所以說(shuō)這個(gè)渠道隔離放在第一位首要的。

?

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

?

??動(dòng)態(tài)擴(kuò)容。因?yàn)榫酆现Ц逗芏嘟灰锥际钱惒降?#xff0c;用戶下單時(shí)，我們會(huì)立即返回就下單成功，或者下單失敗，但是這個(gè)交易有沒有消費(fèi)成功，我們需要設(shè)置定時(shí)的任務(wù)去查詢最終付款結(jié)果。

?

定時(shí)調(diào)度，它需要定時(shí)、定點(diǎn)、定量的去拉取一批訂單進(jìn)行處理，如果拉取的數(shù)據(jù)太多，內(nèi)存直接爆了，拉取太少，有很多交易得不到執(zhí)行。在分布式環(huán)境如何充分提升并發(fā)的前提下充分使用機(jī)器的資源變得越來(lái)越緊迫。

?

??配置分散，傳統(tǒng)方式是將配置文件存放在每一個(gè)節(jié)點(diǎn)，每次升級(jí)都需要運(yùn)維手動(dòng)改。風(fēng)險(xiǎn)較高而且相當(dāng)不好維護(hù)。

?

?

03

?

2.0系統(tǒng)

_____

在這個(gè)前提下，我們開始著手設(shè)計(jì)2.0。當(dāng)初有幾個(gè)大的方向：

?

?

??穩(wěn)定：支付系統(tǒng)的根基

??支付體驗(yàn)：用戶使用支付功能時(shí)感知零延遲

??低耦合：模塊之間減少依賴，需求變動(dòng)風(fēng)險(xiǎn)控制在最小范圍

?

在這個(gè)過(guò)程中也是試了很多種方案，要么程序復(fù)雜，你寫完的話可能只有自己懂，后續(xù)不好維護(hù)；要么性能跟不上去。所以我們也嘗試了各種方案，最后演變?yōu)槿缦孪到y(tǒng)架構(gòu)。

?

?

首先將服務(wù)劃分為三條線，上面綠色的，和中間那個(gè)紅色的和最下面一條橙色的。綠色的就是我們把交易核心、交易網(wǎng)關(guān)獨(dú)立出來(lái)。任務(wù)作業(yè)和那個(gè)查詢網(wǎng)關(guān)獨(dú)立部署。這兩條業(yè)務(wù)線通過(guò)MQ進(jìn)行解耦，然后我們?cè)侏?dú)立查詢服務(wù)，對(duì)前端業(yè)務(wù)僅僅提供一個(gè)流水查詢功能而已。

?

業(yè)務(wù)流程如下：

?

業(yè)務(wù)發(fā)起一筆消費(fèi)，首先進(jìn)入支付核心初始化流水、風(fēng)控風(fēng)險(xiǎn)識(shí)別、渠道路由、渠道網(wǎng)關(guān)報(bào)文組裝、上送、渠道應(yīng)答。異步交易發(fā)送消息至MQ集群，任務(wù)作業(yè)監(jiān)聽消息，put緩存，定時(shí)任務(wù)拉取進(jìn)行狀態(tài)查詢，業(yè)務(wù)方通過(guò)查詢服務(wù)查看該筆交易支付狀態(tài)

?

?

前置優(yōu)化水平方向

?

?

??接入層：將共性的接口統(tǒng)一。比如說(shuō)下單，所有的業(yè)務(wù)，不管微信支付，還有其他的全部歸為下單，具體的業(yè)務(wù)，通過(guò)一個(gè)serviceId參數(shù)進(jìn)行識(shí)別

?

??服務(wù)層：共性邏輯，也就是核心邏輯全部抽離出來(lái)，然后進(jìn)行統(tǒng)一下沉，作為底層服務(wù)，上層業(yè)務(wù)全部通過(guò)serviceId配置化實(shí)現(xiàn)，這樣的話盡量去少改動(dòng)核心業(yè)務(wù)邏輯。

?

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

?

?

前置優(yōu)化垂直拆分：

?

?

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

?

??任務(wù)作業(yè)：將處理中的交易進(jìn)行狀態(tài)同步，和核心交易通過(guò)消息解耦

?

??查詢服務(wù)：僅僅是對(duì)公司內(nèi)部提供一個(gè)交易狀態(tài)的查詢功能

?

?

?

?

任務(wù)作業(yè)內(nèi)部查詢策略設(shè)計(jì)為兩個(gè)隊(duì)列、一個(gè)批處理

?

??內(nèi)存隊(duì)列：基于DelayQueue設(shè)計(jì)的延遲隊(duì)列，通過(guò)制定算法策略，就是比如說(shuō)延遲十秒、間隔五秒，或者是很多銀行使用2的N次方進(jìn)行查詢。

?

該隊(duì)列主要是針對(duì)單筆交易執(zhí)行快速狀態(tài)同步,提升用戶體驗(yàn)。

?

??緩存隊(duì)列：基于我們公司Codis緩存集群，結(jié)合分布式調(diào)度框架Elastic-Job設(shè)計(jì)。主要是針對(duì)狀態(tài)延遲的訂單，進(jìn)行批量狀態(tài)同步

?

??DB批處理：也是結(jié)合Elastic-Job設(shè)計(jì)，主要是提供人工干預(yù)的入口，當(dāng)渠道延遲比較長(zhǎng)、或者渠道異常的情況下，執(zhí)行批量狀態(tài)同步

?

?

分片策略：

?

?

??任務(wù)分片：目的在于把一個(gè)任務(wù)分散到不同的機(jī)器上運(yùn)行，既可以解決單機(jī)計(jì)算能力上限的問題，也能降低部分任務(wù)失敗對(duì)整體系統(tǒng)的影響。elastic-job并不直接提供數(shù)據(jù)處理的功能，框架只會(huì)將分片項(xiàng)分配各個(gè)運(yùn)行中的作業(yè)服務(wù)器（其實(shí)是Job實(shí)例，部署在一臺(tái)機(jī)器上的多個(gè)Job實(shí)例也能分片），

?

PS：開發(fā)者需要自行處理分片項(xiàng)與真實(shí)數(shù)據(jù)的對(duì)應(yīng)關(guān)系。框架也預(yù)置了一些分片策略：平均分配算法策略，作業(yè)名哈希值奇偶數(shù)算法策略，輪轉(zhuǎn)分片策略。同時(shí)也提供了自定義分片策略的接口。

?

??數(shù)據(jù)分片：訂單號(hào)取模存儲(chǔ)（zset）

?

?

數(shù)據(jù)結(jié)構(gòu)：

?

??有序集合（zset）：按照分片邏輯，將訂單號(hào)取模，存放至對(duì)應(yīng)的隊(duì)列中

?

??string：交易明細(xì)序列化存儲(chǔ)

?

設(shè)計(jì)思路：

?

?

1.?MQ消費(fèi)者（作業(yè)節(jié)點(diǎn)），接收到消息后，將數(shù)據(jù)存放在緩存

?

2.?作業(yè)節(jié)點(diǎn)根據(jù)分片項(xiàng)、score范圍，定時(shí)從對(duì)應(yīng)的緩存隊(duì)列中獲取指定數(shù)量的訂單號(hào)

?

3.?業(yè)務(wù)循環(huán)處理，根據(jù)訂單號(hào)再去緩存中獲取對(duì)應(yīng)的詳細(xì)信息

?

4.?執(zhí)行查詢邏輯

?

注意事項(xiàng)：

zset元素?cái)?shù)據(jù)過(guò)期，需要業(yè)務(wù)自己處理，可以單獨(dú)建立檢測(cè)機(jī)制，也可以每次執(zhí)行業(yè)務(wù)時(shí)執(zhí)行判斷，過(guò)期則移除，不然集合會(huì)越來(lái)越大。

?

?

??渠道隔離：在高并發(fā)訪問下，系統(tǒng)所依賴的渠道穩(wěn)定性對(duì)系統(tǒng)的影響非常大，依賴有很多不可控的因素，比如網(wǎng)絡(luò)連接變慢，資源突然繁忙，暫時(shí)不可用，我們選在知名的容錯(cuò)開源框架Hystrix，隔離方案選擇thread。

?

??查詢網(wǎng)關(guān)：在交易系統(tǒng)中，查詢業(yè)務(wù)量一般時(shí)支付業(yè)務(wù)的6倍，甚至更高，這樣對(duì)查詢服務(wù)性能就會(huì)有更高的要求。減少對(duì)核心交易影響，提升穩(wěn)定性。

?

通道商戶緩存：通道信息（機(jī)構(gòu)號(hào)、商戶號(hào)、密鑰等）屬于靜態(tài)信息，在初次使用時(shí)存放至分布式緩存系統(tǒng)中（設(shè)置有效期，防止僵尸數(shù)據(jù)），同時(shí)增加手動(dòng)修改的入口，方便人工干預(yù)。

?

?

??千里之堤毀于蟻穴：我們用容錯(cuò)的方式就是讓這種蟻穴不要變大，在依賴的服務(wù)不可用時(shí)，服務(wù)調(diào)用方應(yīng)該通過(guò)一些技術(shù)手段，向上提供有損服務(wù)，保證業(yè)務(wù)柔性可用。

?

??線程池資源隔離：Java的Servlet容器，無(wú)論是Tomcat還是Jetty都是多線程模型，都用Worker線程來(lái)處理請(qǐng)求。當(dāng)業(yè)務(wù)請(qǐng)求打滿Worker線程的最大值之后，剩余請(qǐng)求會(huì)被放到等待隊(duì)列（或者拒絕掉），如果等待隊(duì)列也塞滿之后，那這臺(tái)Web Server就會(huì)拒絕服務(wù)。

?

如果你的服務(wù)是QPS較高的服務(wù)，那基本上這種場(chǎng)景下，你的服務(wù)也會(huì)跟著被拖垮。假如上游服務(wù)也沒有設(shè)置合理的超時(shí)時(shí)間，故障就會(huì)擴(kuò)散。這種故障逐級(jí)放大的過(guò)程，就是服務(wù)雪崩效應(yīng)。

?

我們采用容錯(cuò)框架Hystrix來(lái)解決此問題。通過(guò)Hystrix命令模式，將每個(gè)類型的業(yè)務(wù)請(qǐng)求封裝成對(duì)應(yīng)的命令請(qǐng)求。每個(gè)命令請(qǐng)求對(duì)應(yīng)一個(gè)線程池，創(chuàng)建好的線程池是被放入到ConcurrentHashMap中。

?

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

?

?

Hystrix線程監(jiān)控

?

實(shí)時(shí)展示當(dāng)前各個(gè)業(yè)務(wù)線程池資源使用情況，研發(fā)人員可以以此為參考，確定資源是否夠用、是否需要升級(jí)機(jī)器資源等。

?

?

2.0之后我們是全面對(duì)接我們公司監(jiān)控平臺(tái)，主要從以下幾點(diǎn)進(jìn)行監(jiān)控：

?

?

??節(jié)點(diǎn)耗時(shí)監(jiān)控：如說(shuō)哪個(gè)時(shí)間點(diǎn)、哪個(gè)節(jié)點(diǎn)耗時(shí)比較慢，通過(guò)百分比的形式，可以比較直觀的看出問題。

?

??成功率的監(jiān)控：折線圖定時(shí)刷新數(shù)據(jù)，將各個(gè)時(shí)間點(diǎn)的交易記錄數(shù)、成功筆數(shù)、失敗筆數(shù)進(jìn)行匯總計(jì)算，渠道接口異常時(shí)可以第一時(shí)間發(fā)出告警

?

??應(yīng)答碼監(jiān)控：應(yīng)答碼TOP排行榜，方便研發(fā)分析數(shù)據(jù)，提前將問題通知給渠道，減少后續(xù)可能出現(xiàn)更大的問題；部分應(yīng)答碼重點(diǎn)監(jiān)控，通過(guò)設(shè)定告警閥值，超過(guò)閥值短信及電話告警，研發(fā)第一時(shí)間接入處理，減少可能造成的損失。

?

??郵件巡檢報(bào)告：用于第二天研發(fā)進(jìn)行數(shù)據(jù)分析。

?

?

以上就是盒子科技聚合支付系統(tǒng)演變的大致過(guò)程，在 2017年的到現(xiàn)在沒有出現(xiàn)任何技術(shù)故障和業(yè)務(wù)故障，沒有造成一筆長(zhǎng)款、短款的出現(xiàn)，系統(tǒng)具備良好的伸縮性，能夠保證公司近兩年業(yè)務(wù)的快速發(fā)展。

?

04

?

下一步需要做什么

_____

那么在系統(tǒng)穩(wěn)定的基礎(chǔ)之上，下一步我們還需要做哪些事情呢？

?

?

??全鏈路的監(jiān)控：我們現(xiàn)在鏈路監(jiān)控只是從前端到后端有一個(gè)請(qǐng)求的跟蹤號(hào)，但是這個(gè)都分散在我們業(yè)務(wù)日志里面的。所以說(shuō)我們下一步就準(zhǔn)備做一個(gè)全鏈路的監(jiān)控，就相當(dāng)于把每一個(gè)每筆交易，它具體在哪個(gè)時(shí)間點(diǎn)在哪個(gè)機(jī)器上，然后在哪個(gè)渠道，然后它狀態(tài)做的什么變更，做一個(gè)完整的記錄，通過(guò)一個(gè)可視化的界面提供出來(lái)，方便客服、運(yùn)營(yíng)等其他協(xié)作部門使用。

?

?

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

?

??動(dòng)態(tài)分片：主要包括數(shù)據(jù)分片、任務(wù)分片，業(yè)務(wù)量持續(xù)倍數(shù)增長(zhǎng)的情況，各個(gè)環(huán)節(jié)的分片策略如何做到自動(dòng)化實(shí)現(xiàn)，充分使用各個(gè)機(jī)器的性能。（本文完）

?

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

?

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

金融級(jí)分布式交易的技術(shù)路徑

移動(dòng)互聯(lián)網(wǎng)、大數(shù)據(jù)與云計(jì)算作為新的基礎(chǔ)設(shè)施，催生了新的互聯(lián)網(wǎng)經(jīng)濟(jì)，也正在推動(dòng)各行各業(yè)的升級(jí)。在過(guò)去十多年中，金融服務(wù)飛速發(fā)展，移動(dòng)支付支撐了零售業(yè)線上線下的變革，基于大數(shù)據(jù)的信貸服務(wù)支持了無(wú)數(shù)小微企業(yè)的創(chuàng)業(yè)創(chuàng)新，老百姓可以隨時(shí)隨地享受曾經(jīng)高門檻的理財(cái)、保險(xiǎn)等金融服務(wù)。以普惠服務(wù)為目標(biāo)、數(shù)據(jù)與技術(shù)驅(qū)動(dòng)、新型信用體系為基礎(chǔ)的新金融已經(jīng)成為新經(jīng)濟(jì)的基石。

?

伴隨著螞蟻金服在新金融領(lǐng)域的探索，螞蟻金服技術(shù)團(tuán)隊(duì)也在金融技術(shù)與架構(gòu)領(lǐng)域不斷開拓。從?2005?年每秒處理?1?筆交易到?2015?年雙十一每秒處理?8.59?萬(wàn)筆交易，從單一的支付到覆蓋微貸、理財(cái)、保險(xiǎn)、信用、銀行等，通過(guò)十多年的探索與實(shí)踐，我們形成了一套包含金融級(jí)分布式交易、分布式大數(shù)據(jù)分析與決策等在內(nèi)的完整架構(gòu)與技術(shù)體系。

?

在本文中，我們將與大家交流金融級(jí)分布式交易相關(guān)的實(shí)踐與體會(huì)。

?

金融級(jí)系統(tǒng)的關(guān)鍵目標(biāo)

?

如果將建造系統(tǒng)比作蓋樓的話，建一個(gè)常規(guī)的系統(tǒng)要先立穩(wěn)四根柱子：高可用、安全、性能、成本。但要建一個(gè)移動(dòng)互聯(lián)網(wǎng)時(shí)代的金融級(jí)大廈，除了上述四根柱子需要更加牢固，還需要加上兩根柱子：資金安全與數(shù)據(jù)質(zhì)量。這六根柱子，是我們?cè)诩軜?gòu)螞蟻金服的每一個(gè)系統(tǒng)時(shí)的首要目標(biāo)。

?

具體來(lái)說(shuō)，我們對(duì)一個(gè)金融級(jí)系統(tǒng)有以下關(guān)鍵目標(biāo)：

?

高可用：具備?99.99%?以上的高可用性。系統(tǒng)能夠容忍各種軟硬件設(shè)施的故障，可以在服務(wù)不中斷的情況下進(jìn)行升級(jí)，在嚴(yán)苛的應(yīng)用場(chǎng)景下保證承諾的服務(wù)質(zhì)量，容忍各種人為失誤。對(duì)于關(guān)鍵系統(tǒng)，還需要具備異地容災(zāi)能力。

?

安全：具備多層次檢測(cè)、感知與防御各類安全攻擊的能力。系統(tǒng)有能力實(shí)時(shí)、精細(xì)地分析系統(tǒng)行為與數(shù)據(jù)流發(fā)現(xiàn)異常，必要時(shí)可以快速調(diào)集資源阻斷大規(guī)模、有組織的攻擊。

?

性能：對(duì)于實(shí)時(shí)交易業(yè)務(wù)，要求極快的響應(yīng)時(shí)間與極高并發(fā)能力。對(duì)于批量業(yè)務(wù)，要求極大的吞吐量。尤其重要的是，系統(tǒng)必須具備很強(qiáng)的可伸縮性與彈性，在需要時(shí)可以快速調(diào)集資源應(yīng)對(duì)突發(fā)的業(yè)務(wù)量。

?

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

?

資金安全：這是金融級(jí)系統(tǒng)與常規(guī)系統(tǒng)的一個(gè)關(guān)鍵差異。要做到資金處理絕對(duì)不出差錯(cuò)，需要交易與數(shù)據(jù)具備強(qiáng)一致性，需要在任何故障場(chǎng)景數(shù)據(jù)不丟不錯(cuò)，需要具備準(zhǔn)實(shí)時(shí)的交易資金核對(duì)能力，需要在異常場(chǎng)景下有精細(xì)化熔斷與快速恢復(fù)能力。

?

數(shù)據(jù)質(zhì)量：數(shù)據(jù)質(zhì)量是金融服務(wù)質(zhì)量的基礎(chǔ)。數(shù)據(jù)從采集、生成、流轉(zhuǎn)、存儲(chǔ)、計(jì)算、使用需要經(jīng)歷很多環(huán)節(jié)，要確保經(jīng)過(guò)這么多環(huán)節(jié)后，數(shù)據(jù)依然是準(zhǔn)確、完整和及時(shí)的，需要系統(tǒng)具備全鏈路的數(shù)據(jù)質(zhì)量管控與治理能力。

?

金融交易系統(tǒng)是否可以走分布式路線？如何基于分布式的思想與技術(shù)達(dá)到以上?6?個(gè)關(guān)鍵目標(biāo)？接下來(lái)，我們就以螞蟻金服的實(shí)踐為基礎(chǔ)，分享對(duì)這個(gè)問題的觀點(diǎn)。

?

分布式金融交易架構(gòu)與技術(shù)

?

?

1

強(qiáng)一致的微服務(wù)：微交易架構(gòu)

?

微服務(wù)是一種廣泛應(yīng)用的分布式架構(gòu)。通過(guò)將系統(tǒng)分解為單一職責(zé)、高內(nèi)聚、松耦合、獨(dú)立部署、自主運(yùn)行的“微“服務(wù)，可以極大提升系統(tǒng)的靈活性與擴(kuò)展能力。但由于每一個(gè)微服務(wù)是自包含的數(shù)據(jù)與計(jì)算單元，當(dāng)一個(gè)有嚴(yán)格一致性要求的交易，被分布在很多節(jié)點(diǎn)上執(zhí)行時(shí)，如何保證數(shù)據(jù)與服務(wù)處理達(dá)到金融級(jí)的強(qiáng)一致性，成為一個(gè)難題。盡管可以用支持分布式事務(wù)的數(shù)據(jù)庫(kù)或數(shù)據(jù)中間件來(lái)保證數(shù)據(jù)分布時(shí)的一致性，但解決不了當(dāng)服務(wù)分布時(shí)的一致性問題。由于分布式事務(wù)對(duì)資源加鎖的時(shí)間長(zhǎng)、粒度大，也制約了系統(tǒng)的可伸縮性與高可用性。

?

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

?

從?2008?年初上線至今，微交易架構(gòu)已經(jīng)應(yīng)用到螞蟻金服的各種金融業(yè)務(wù)場(chǎng)景，經(jīng)歷過(guò)歷次大促高峰考驗(yàn)，證明這套架構(gòu)與技術(shù)的可行性。

?

2

請(qǐng)金融級(jí)分布式數(shù)據(jù)庫(kù): OceanBase

?

目前，主要商業(yè)數(shù)據(jù)庫(kù)本質(zhì)上是單機(jī)系統(tǒng)，其容量、性能和可靠性均依賴于單個(gè)或少量高性能服務(wù)器與高可靠存儲(chǔ)的組合，成本高昂且擴(kuò)展困難。盡管通過(guò)運(yùn)用微交易架構(gòu)，可以將對(duì)數(shù)據(jù)操作的壓力分拆多個(gè)數(shù)據(jù)庫(kù)，解決了水平可擴(kuò)展的問題，但數(shù)據(jù)庫(kù)本身的性能、成本與可靠性依然是一個(gè)難點(diǎn)。因此，阿里巴巴與螞蟻金服從?2010?年起，開始研發(fā)專門的金融級(jí)分布式數(shù)據(jù)庫(kù)?OceanBase。

?

OceanBase?在以下幾個(gè)方面，對(duì)傳統(tǒng)數(shù)據(jù)庫(kù)架構(gòu)進(jìn)行了突破：

?

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

?

強(qiáng)一致：經(jīng)典的主庫(kù)+備庫(kù)方式的數(shù)據(jù)庫(kù)，很難兼具高可用與強(qiáng)一致能力。為了解決這個(gè)問題，OceanBase?使用多數(shù)據(jù)副本（>=3）投票協(xié)議，對(duì)于每個(gè)寫事務(wù)，OceanBase?只有在事務(wù)日志（redo log）到達(dá)超過(guò)半數(shù)服務(wù)器后，才應(yīng)答客戶。這樣當(dāng)少數(shù)服務(wù)器（例如?3?臺(tái)中的?1?臺(tái)，或者?5?臺(tái)中的?2?臺(tái)）異常時(shí)，剩下的服務(wù)器至少有一臺(tái)有事務(wù)日志，保證了數(shù)據(jù)庫(kù)不因?yàn)樯贁?shù)服務(wù)器故障而導(dǎo)致數(shù)據(jù)丟失；

?

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

?

目前?OceanBase?已經(jīng)穩(wěn)定支撐了支付寶的核心交易、支付與賬務(wù)，支撐了網(wǎng)商銀行的核心系統(tǒng)，經(jīng)歷了多次“雙十一”的考驗(yàn)，形成了跨機(jī)房、跨區(qū)域部署的高可用架構(gòu)，并在日常運(yùn)行、應(yīng)急演練和容災(zāi)切換中發(fā)揮了重要作用。

?

3

異地多活與容災(zāi):?單元化架構(gòu)

?

“兩地三中心”是一種在金融系統(tǒng)中廣泛應(yīng)用的跨數(shù)據(jù)中心擴(kuò)展與跨地區(qū)容災(zāi)部署模式，但也存在一些問題：在擴(kuò)展能力上，由于跨地區(qū)的備份中心不承載核心業(yè)務(wù)，不能解決核心業(yè)務(wù)跨地區(qū)擴(kuò)展的問題；在成本上，災(zāi)備系統(tǒng)僅在容災(zāi)時(shí)使用，資源利用率低，成本較高；在容災(zāi)能力上，由于災(zāi)備系統(tǒng)冷備等待，容災(zāi)時(shí)可用性低，切換風(fēng)險(xiǎn)較大。

?

因此，螞蟻金服沒有選擇“兩地三中心”部署模式，而是實(shí)現(xiàn)了異地多活與容災(zāi)模式。異地多活與容災(zāi)架構(gòu)的基礎(chǔ)是對(duì)系統(tǒng)進(jìn)行單元化。每一個(gè)單元可以認(rèn)為是一個(gè)縮小規(guī)模的、包含從接入網(wǎng)關(guān)、應(yīng)用服務(wù)到數(shù)據(jù)存儲(chǔ)的全功能系統(tǒng)。每個(gè)單元負(fù)責(zé)一定比例的數(shù)據(jù)與用戶訪問。單元有以下關(guān)鍵特性：

?

自包含性：比如用戶的一次賬戶充值交易，涉及到的所有計(jì)算與數(shù)據(jù)都在一個(gè)單元內(nèi)完成；

?

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

?

故障獨(dú)立性：一個(gè)單元內(nèi)的故障，不會(huì)傳播到其它單元；

?

容災(zāi)性：單元之間相互備份，確保每個(gè)單元在同城和異地都有可在故障期間進(jìn)行接管的單元。數(shù)據(jù)在單元間的備份方式，我們以?OceanBase?提供的多地多中心強(qiáng)一致方案為主。

?

通過(guò)單元化架構(gòu)，能夠?qū)⒁粋€(gè)大規(guī)模系統(tǒng)分拆成許多個(gè)相對(duì)獨(dú)立的小規(guī)模系統(tǒng)，每一個(gè)單元系統(tǒng)可以部署到任何地區(qū)的數(shù)據(jù)中心，從而實(shí)現(xiàn)了靈活的異地多數(shù)據(jù)中心部署模式。系統(tǒng)的主要伸縮模式變成單元的增減，但一個(gè)單元內(nèi)部的規(guī)模與復(fù)雜性不變，降低了系統(tǒng)的復(fù)雜性。單元之間的故障隔離，降低了軟硬件故障的影響面。“活”的單元和跨單元的快速切換能力，使同城異地的容災(zāi)處理更為簡(jiǎn)單高效。

?

目前，螞蟻金服的核心系統(tǒng)已經(jīng)分布在上海、深圳、杭州等多個(gè)城市的多個(gè)數(shù)據(jù)中心，核心交易流量分布在各個(gè)數(shù)據(jù)中心，并且可以進(jìn)行調(diào)度與切換。通過(guò)異地多活，系統(tǒng)可以在全國(guó)范圍內(nèi)任意擴(kuò)展，服務(wù)器資源得到了充分利用，提升了系統(tǒng)應(yīng)對(duì)地區(qū)級(jí)災(zāi)難的能力。

?

4

按需伸縮：彈性混合云架構(gòu)

?

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

?

我們解決這個(gè)問題的方法是，活動(dòng)前，在云計(jì)算平臺(tái)上快速申請(qǐng)資源，構(gòu)建新的單元，部署應(yīng)用與數(shù)據(jù)庫(kù)。然后將流量與數(shù)據(jù)“彈出”到新的單元，快速提升系統(tǒng)容量。當(dāng)活動(dòng)結(jié)束后，再將流量與數(shù)據(jù)“彈回”，釋放云計(jì)算平臺(tái)上的資源。通過(guò)這種方式，可以大大降低資源采購(gòu)與運(yùn)行成本。

?

彈性操作，需要在流量、數(shù)據(jù)與資源之間協(xié)調(diào)一致地操作，尤其是有狀態(tài)的數(shù)據(jù)的彈性操作是最困難的，需要不中斷業(yè)務(wù)，也需要保證數(shù)據(jù)的一致性。這些操作如果依靠運(yùn)維人員人工執(zhí)行會(huì)十分復(fù)雜低效，需要架構(gòu)、中間件與管控系統(tǒng)的支持。

?

彈性混合云架構(gòu)與技術(shù)在實(shí)踐中有以下一些關(guān)鍵點(diǎn)：

1.?通過(guò)統(tǒng)一資源調(diào)度，靈活地申請(qǐng)與分配計(jì)算、存儲(chǔ)與網(wǎng)絡(luò)資源，創(chuàng)建單元，快速部署數(shù)據(jù)庫(kù)、中間件與應(yīng)用；

2.?通過(guò)中間件，將應(yīng)用與基礎(chǔ)設(shè)施充分解耦，無(wú)論流量、數(shù)據(jù)與資源如何分布，應(yīng)用系統(tǒng)不需要改變；

3.?通過(guò)分布式架構(gòu)與數(shù)據(jù)規(guī)范，以及中間件支持，保證所有請(qǐng)求、服務(wù)、數(shù)據(jù)、消息等都有全局唯一的?ID?和一致的?ID?編碼規(guī)則。根據(jù)?ID，從接入網(wǎng)關(guān)、服務(wù)中間件、消息中間件、數(shù)據(jù)中間件等都能夠正確地路由服務(wù)請(qǐng)求與數(shù)據(jù)訪問；

4.?通過(guò)統(tǒng)一管控平臺(tái)，將高層的彈性操作，翻譯成各個(gè)組件的部署與配置指令，并且統(tǒng)一調(diào)度執(zhí)行，使操作協(xié)調(diào)一致、精準(zhǔn)高效。

?

基于彈性混合云架構(gòu)，2015?年雙十一，支付寶有?10%?的支付流量運(yùn)行在阿里云計(jì)算平臺(tái)上。2016?年雙十一，我們計(jì)劃將?50%?的高峰期支付流量運(yùn)行在阿里云計(jì)算平臺(tái)上，帶來(lái)成本的極大優(yōu)化。

?

未來(lái)展望與期待

?

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

?

未來(lái)，螞蟻金服依然會(huì)在金融級(jí)分布式架構(gòu)與技術(shù)方面深耕與拓荒。在這一領(lǐng)域，我們給自己提出兩個(gè)新的重大命題：

?

1.?如何處理每秒?1?億筆交易：萬(wàn)物互聯(lián)時(shí)代，無(wú)處不在的交易終端和無(wú)數(shù)新的交易場(chǎng)景，會(huì)繼續(xù)帶來(lái)金融交易量的指數(shù)型增長(zhǎng)。什么樣的架構(gòu)與技術(shù)，可以處理萬(wàn)物互聯(lián)時(shí)代的天量交易，是需要未雨綢繆去攻堅(jiān)與突破的；

?

2.?將金融級(jí)分布式架構(gòu)與技術(shù)變成“普惠”的云計(jì)算服務(wù)，為千千萬(wàn)萬(wàn)金融服務(wù)機(jī)構(gòu)服務(wù)。為了實(shí)現(xiàn)這個(gè)目標(biāo)，螞蟻金服和阿里云共同提出了“螞云計(jì)劃”，共建新一代的金融云平臺(tái)，未來(lái)服務(wù)全球?5?萬(wàn)家金融機(jī)構(gòu)，共創(chuàng)全球化的普惠金融。

?

中國(guó)已經(jīng)在金融服務(wù)創(chuàng)新上處于世界領(lǐng)先，新金融需要新技術(shù)作為底盤與引擎，這是中國(guó)金融技術(shù)的挑戰(zhàn)與機(jī)遇。螞蟻金服期待與中國(guó)金融業(yè)的專家一起，共同創(chuàng)造未來(lái)的新金融技術(shù)，為世界技術(shù)做出更多中國(guó)的貢獻(xiàn)。

?

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

?

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

1.異地多活與容災(zāi):?單元化架構(gòu)

2.布式改造是一個(gè)較為復(fù)雜的工程，既需要熟悉業(yè)務(wù)，能夠設(shè)計(jì)出整個(gè)系統(tǒng)的業(yè)務(wù)架構(gòu)，按照業(yè)務(wù)架構(gòu)來(lái)進(jìn)行垂直拆分，又需要熟悉數(shù)據(jù)模型，區(qū)分“流水型”、“狀態(tài)型”、“配置型”數(shù)據(jù)，根據(jù)不同類型數(shù)據(jù)的特點(diǎn)將它他按用戶維度進(jìn)行拆分，還需要熟悉分布式中間件的運(yùn)用。

3.以上只是簡(jiǎn)單介紹了支付系統(tǒng)我們能看見的一些問題和設(shè)計(jì)，還有后續(xù)的系統(tǒng)保障沒有寫出來(lái)，沒寫出來(lái)的才是關(guān)鍵部分，比如：支付系統(tǒng)監(jiān)控（業(yè)務(wù)監(jiān)控分類、渠道監(jiān)控、商戶監(jiān)控、賬戶監(jiān)控）文章只是引子，?架構(gòu)不是靜態(tài)的，而是動(dòng)態(tài)演化的。只有能夠不斷應(yīng)對(duì)環(huán)境變化的系統(tǒng)，才是有生命力的系統(tǒng)。所以即使你掌握了以上所有的業(yè)務(wù)細(xì)節(jié)，仍然需要演化式思維，在設(shè)計(jì)的同時(shí)，借助反饋和進(jìn)化的力量推動(dòng)架構(gòu)的持續(xù)演進(jìn)。

4.從0到1實(shí)現(xiàn)一套聚合支付系統(tǒng)。對(duì)外的商業(yè)系統(tǒng)。

5.第一層 split：把任務(wù)按照分片規(guī)則拆分成多個(gè) Load 任務(wù)，并發(fā)送到集群中的 Server 去執(zhí)行。

第二層 load：每個(gè) load 任務(wù)撈取一個(gè)分片的數(shù)據(jù)，逐條創(chuàng)建 execute 任務(wù)，并發(fā)送到集群中的 Server 去執(zhí)行。注意：撈取數(shù)據(jù)要進(jìn)行流量控制以免數(shù)據(jù)量太大把集群打滿。

第三層 execute：執(zhí)行具體的一條數(shù)據(jù)的邏輯。

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。