1. 金融服務(wù)的核心領(lǐng)域與潛在需求拆解1.1 從“financial-services”這個(gè)標(biāo)題能讀出什么“financial-services”這個(gè)詞本身很寬泛直譯過(guò)來(lái)就是“金融服務(wù)”。但正是這種寬泛給了我們極大的拆解空間。在從業(yè)者的語(yǔ)境里它通常指向一個(gè)完整的業(yè)務(wù)體系或技術(shù)體系而不是單一功能。我拿到這個(gè)標(biāo)題的第一反應(yīng)是它大概率涉及賬戶管理、交易處理、支付結(jié)算、風(fēng)控合規(guī)、數(shù)據(jù)報(bào)表這幾大塊中的至少兩塊。為什么這么判斷因?yàn)槿魏我患艺嬲谧鼋鹑诜?wù)的團(tuán)隊(duì)都不可能只做“記賬”而不碰“對(duì)賬”也不可能只做“支付”而不碰“風(fēng)控”。這是行業(yè)鐵律。從潛在需求來(lái)看搜索這個(gè)詞的人往往處于三種狀態(tài)之一第一種是準(zhǔn)備從零搭建一個(gè)金融服務(wù)模塊的開(kāi)發(fā)者需要知道整體架構(gòu)怎么設(shè)計(jì)第二種是已經(jīng)有一套系統(tǒng)但遇到了性能或合規(guī)瓶頸想找優(yōu)化思路第三種是產(chǎn)品經(jīng)理或業(yè)務(wù)負(fù)責(zé)人想理解金融服務(wù)背后的技術(shù)邏輯以便更好地提需求。這三種人需要的深度不同但共同點(diǎn)是都需要一個(gè)“從業(yè)務(wù)到技術(shù)”的完整映射。我寫(xiě)這篇東西就是想把這三層需求一次性覆蓋掉。1.2 金融服務(wù)系統(tǒng)的典型模塊劃分一個(gè)完整的金融服務(wù)系統(tǒng)不管你是做支付、做信貸、做理財(cái)還是做保險(xiǎn)底層模塊的劃分邏輯是相通的。我把它拆成五個(gè)核心層接入層負(fù)責(zé)接收來(lái)自App、Web、API網(wǎng)關(guān)的請(qǐng)求做初步的鑒權(quán)、限流、參數(shù)校驗(yàn)。這一層的關(guān)鍵是“快”和“穩(wěn)”不能因?yàn)橄掠温桶焉嫌瓮纤?。業(yè)務(wù)邏輯層這是最復(fù)雜的一層包含賬戶體系、交易引擎、計(jì)費(fèi)引擎、產(chǎn)品工廠。賬戶體系要支持多幣種、多賬戶類型交易引擎要保證冪等、順序、一致性計(jì)費(fèi)引擎要能靈活配置費(fèi)率、階梯、優(yōu)惠。資金處理層對(duì)接銀行、第三方支付、清算網(wǎng)絡(luò)。這一層的關(guān)鍵是“對(duì)賬”和“差錯(cuò)處理”因?yàn)橘Y金無(wú)小事一分錢(qián)對(duì)不上就是事故。風(fēng)控與合規(guī)層實(shí)時(shí)反欺詐、反洗錢(qián)、限額限頻、黑名單。這一層往往以“旁路”形式存在但關(guān)鍵時(shí)刻能直接攔截交易。數(shù)據(jù)與報(bào)表層交易流水、賬戶余額、日終結(jié)算、監(jiān)管報(bào)送。這一層對(duì)數(shù)據(jù)準(zhǔn)確性和時(shí)效性要求極高通常需要T0的實(shí)時(shí)報(bào)表和T1的批量報(bào)表并存。這五層不是簡(jiǎn)單的上下級(jí)關(guān)系而是互相穿插。比如風(fēng)控層既要在接入層做初步攔截又要在業(yè)務(wù)邏輯層做深度分析還要在資金處理層做交易后監(jiān)控。理解這種“穿插關(guān)系”是設(shè)計(jì)好金融服務(wù)系統(tǒng)的前提。1.3 為什么選擇“模塊化異步化”作為核心思路我在實(shí)際項(xiàng)目中試過(guò)兩種極端方案一種是單體架構(gòu)所有邏輯寫(xiě)在一個(gè)大服務(wù)里另一種是徹底微服務(wù)化每個(gè)功能獨(dú)立部署。實(shí)測(cè)下來(lái)單體架構(gòu)在初期開(kāi)發(fā)快但到了后期任何一個(gè)小改動(dòng)都可能引發(fā)全鏈路回歸而且擴(kuò)容只能整體擴(kuò)容浪費(fèi)資源。徹底微服務(wù)化則相反開(kāi)發(fā)慢、運(yùn)維復(fù)雜一個(gè)小團(tuán)隊(duì)根本扛不住。所以我現(xiàn)在更傾向于“模塊化異步化”的中間路線。模塊化是指代碼層面按業(yè)務(wù)域嚴(yán)格分包但部署時(shí)可以根據(jù)流量特征合并部署。異步化是指核心交易鏈路盡量用消息隊(duì)列解耦比如支付請(qǐng)求進(jìn)來(lái)后先落庫(kù)再發(fā)消息后續(xù)的記賬、通知、風(fēng)控分析都通過(guò)消息驅(qū)動(dòng)。這樣做的好處是主鏈路響應(yīng)快旁路邏輯不影響主流程而且天然支持削峰填谷。注意異步化不是萬(wàn)能的。涉及資金扣減的核心步驟必須同步完成否則會(huì)出現(xiàn)“錢(qián)扣了但賬沒(méi)記”的災(zāi)難性后果。我的經(jīng)驗(yàn)是資金變動(dòng)同步狀態(tài)通知異步。2. 核心細(xì)節(jié)解析與實(shí)操要點(diǎn)2.1 賬戶體系設(shè)計(jì)從“錢(qián)包”到“子賬戶”的演進(jìn)賬戶體系是金融服務(wù)的基石。我見(jiàn)過(guò)很多團(tuán)隊(duì)一開(kāi)始只設(shè)計(jì)一個(gè)“余額”字段結(jié)果業(yè)務(wù)稍微復(fù)雜一點(diǎn)就撐不住了。比如用戶要同時(shí)管理現(xiàn)金賬戶、積分賬戶、優(yōu)惠券賬戶還要區(qū)分可用余額和凍結(jié)余額。這時(shí)候一個(gè)簡(jiǎn)單的余額字段根本不夠用。我的建議是采用“主子賬戶”模型。主賬戶對(duì)應(yīng)一個(gè)用戶或一個(gè)商戶子賬戶對(duì)應(yīng)不同的資金用途。每個(gè)子賬戶有獨(dú)立的余額、凍結(jié)金額、可用金額?？捎媒痤~ 余額 - 凍結(jié)金額。這個(gè)公式看起來(lái)簡(jiǎn)單但實(shí)現(xiàn)時(shí)要特別注意并發(fā)問(wèn)題。兩個(gè)請(qǐng)求同時(shí)凍結(jié)同一筆資金如果不加鎖就會(huì)出現(xiàn)超額凍結(jié)。-- 賬戶表核心字段示例 CREATE TABLE account ( account_id BIGINT PRIMARY KEY, user_id BIGINT NOT NULL, account_type VARCHAR(32) NOT NULL, -- CASH, POINTS, COUPON balance DECIMAL(20,8) DEFAULT 0, frozen_amount DECIMAL(20,8) DEFAULT 0, version INT DEFAULT 0, -- 樂(lè)觀鎖版本號(hào) created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP, updated_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP );更新余額時(shí)必須帶上版本號(hào)做樂(lè)觀鎖或者用SELECT ... FOR UPDATE做悲觀鎖。樂(lè)觀鎖適合并發(fā)不高的場(chǎng)景悲觀鎖適合并發(fā)高但沖突少的場(chǎng)景。我實(shí)測(cè)下來(lái)日交易量在百萬(wàn)級(jí)以下時(shí)樂(lè)觀鎖完全夠用超過(guò)千萬(wàn)級(jí)建議引入分庫(kù)分表把同一用戶的請(qǐng)求路由到同一個(gè)庫(kù)減少鎖競(jìng)爭(zhēng)。2.2 交易冪等如何保證“同一筆請(qǐng)求只扣一次錢(qián)”冪等是金融交易的生命線。用戶點(diǎn)了一次支付網(wǎng)絡(luò)超時(shí)了他又點(diǎn)了一次系統(tǒng)絕對(duì)不能扣兩次錢(qián)。實(shí)現(xiàn)冪等的常見(jiàn)方案有三種唯一索引法在交易流水表上建一個(gè)唯一索引比如request_id。插入時(shí)如果沖突就說(shuō)明重復(fù)請(qǐng)求直接返回已有結(jié)果。這是最簡(jiǎn)單可靠的方案但要求request_id由客戶端生成且全局唯一。狀態(tài)機(jī)法交易有明確的狀態(tài)流轉(zhuǎn)比如INIT - PROCESSING - SUCCESS/FAIL。每次請(qǐng)求先查狀態(tài)如果已經(jīng)是SUCCESS就直接返回如果是PROCESSING就拒絕或等待。這種方法適合異步交易但狀態(tài)機(jī)的設(shè)計(jì)要非常嚴(yán)謹(jǐn)不能有中間態(tài)遺漏。Token法用戶發(fā)起支付前先申請(qǐng)一個(gè)Token支付時(shí)帶上Token。服務(wù)端消費(fèi)Token消費(fèi)過(guò)的Token不能再用。這種方法適合防止表單重復(fù)提交但Token的存儲(chǔ)和過(guò)期策略要處理好。我一般推薦“唯一索引狀態(tài)機(jī)”組合拳。唯一索引兜底狀態(tài)機(jī)做業(yè)務(wù)邏輯判斷。兩者結(jié)合基本可以杜絕重復(fù)扣款。實(shí)操心得request_id的生成規(guī)則很重要。不要用時(shí)間戳因?yàn)楦卟l(fā)下可能重復(fù)。建議用“業(yè)務(wù)前綴用戶ID隨機(jī)數(shù)時(shí)間戳”的組合或者直接用雪花算法生成全局唯一ID。2.3 對(duì)賬系統(tǒng)資金安全的最后一道防線對(duì)賬是很多團(tuán)隊(duì)容易忽視的環(huán)節(jié)覺(jué)得“我自己的系統(tǒng)沒(méi)問(wèn)題對(duì)什么賬”。但現(xiàn)實(shí)是銀行可能多扣了第三方支付可能少結(jié)了網(wǎng)絡(luò)抖動(dòng)可能導(dǎo)致?tīng)顟B(tài)不同步。沒(méi)有對(duì)賬這些差錯(cuò)永遠(yuǎn)發(fā)現(xiàn)不了。對(duì)賬的核心邏輯是拿我方交易流水和對(duì)方銀行/支付渠道的流水做比對(duì)找出“我方有對(duì)方無(wú)”、“對(duì)方有我方無(wú)”、“金額不一致”三類差異。具體實(shí)現(xiàn)時(shí)要注意幾個(gè)細(xì)節(jié)對(duì)賬文件格式不同渠道的對(duì)賬文件格式千差萬(wàn)別有CSV、定長(zhǎng)文本、XML。建議做一個(gè)統(tǒng)一的解析適配層把不同格式轉(zhuǎn)換成內(nèi)部標(biāo)準(zhǔn)格式。對(duì)賬時(shí)間窗口一般是T1凌晨。但要注意時(shí)區(qū)問(wèn)題跨境交易要特別小心。差錯(cuò)處理發(fā)現(xiàn)差異后不能自動(dòng)修改賬務(wù)必須走人工審核流程。因?yàn)椴町愒蚩赡芎軓?fù)雜自動(dòng)修改可能掩蓋更大的問(wèn)題。# 對(duì)賬核心邏輯偽代碼 def reconcile(local_transactions, channel_transactions): local_dict {t.request_id: t for t in local_transactions} channel_dict {t.request_id: t for t in channel_transactions} only_local set(local_dict.keys()) - set(channel_dict.keys()) only_channel set(channel_dict.keys()) - set(local_dict.keys()) amount_mismatch [] for req_id in set(local_dict.keys()) set(channel_dict.keys()): if local_dict[req_id].amount ! channel_dict[req_id].amount: amount_mismatch.append(req_id) return only_local, only_channel, amount_mismatch對(duì)賬結(jié)果要生成報(bào)表并且要有告警機(jī)制。如果某天的差異率超過(guò)閾值比如0.1%必須立即人工介入。2.4 風(fēng)控規(guī)則引擎讓業(yè)務(wù)人員也能配置規(guī)則風(fēng)控規(guī)則經(jīng)常變?nèi)绻看胃囊?guī)則都要開(kāi)發(fā)改代碼、重新上線那效率太低了。所以需要一個(gè)規(guī)則引擎讓業(yè)務(wù)人員通過(guò)界面配置規(guī)則系統(tǒng)動(dòng)態(tài)加載。規(guī)則引擎的核心是“條件動(dòng)作”。條件可以是“單筆金額10000”、“同一用戶1小時(shí)內(nèi)交易次數(shù)5”、“收款方在黑名單中”。動(dòng)作可以是“拒絕”、“人工審核”、“發(fā)送驗(yàn)證碼”。規(guī)則之間可以有優(yōu)先級(jí)和組合關(guān)系。我試過(guò)用Drools功能強(qiáng)大但學(xué)習(xí)曲線陡峭。后來(lái)改用自研的輕量級(jí)規(guī)則引擎基于JSON配置開(kāi)發(fā)成本低業(yè)務(wù)人員也容易理解。關(guān)鍵是要做好規(guī)則的版本管理和灰度發(fā)布新規(guī)則先在小流量上驗(yàn)證沒(méi)問(wèn)題再全量。注意風(fēng)控規(guī)則不能太嚴(yán)否則會(huì)誤殺正常用戶也不能太松否則形同虛設(shè)。我的經(jīng)驗(yàn)是先松后緊根據(jù)實(shí)際數(shù)據(jù)逐步調(diào)整。上線初期可以只做監(jiān)控不攔截觀察一周后再開(kāi)啟攔截。3. 實(shí)操過(guò)程與核心環(huán)節(jié)實(shí)現(xiàn)3.1 環(huán)境準(zhǔn)備與技術(shù)選型假設(shè)我們要從零搭建一個(gè)金融服務(wù)系統(tǒng)第一步是技術(shù)選型。我的選型原則是成熟優(yōu)先社區(qū)活躍團(tuán)隊(duì)熟悉。不要為了新技術(shù)而新技術(shù)金融系統(tǒng)穩(wěn)定壓倒一切。開(kāi)發(fā)語(yǔ)言Java或Go。Java生態(tài)成熟金融行業(yè)案例多Go性能好并發(fā)模型簡(jiǎn)單。我選Java因?yàn)檎腥巳菀字虚g件支持好。數(shù)據(jù)庫(kù)MySQL做交易庫(kù)PostgreSQL做報(bào)表庫(kù)Redis做緩存和分布式鎖。MySQL要用InnoDB引擎事務(wù)隔離級(jí)別用RR可重復(fù)讀但要注意間隙鎖問(wèn)題。消息隊(duì)列Kafka或RocketMQ。Kafka吞吐量高適合日志和流處理RocketMQ事務(wù)消息支持好適合交易場(chǎng)景。我選RocketMQ因?yàn)樗难舆t消息和事務(wù)消息對(duì)金融場(chǎng)景很友好。服務(wù)框架Spring Boot Spring Cloud Alibaba。Nacos做注冊(cè)中心和配置中心Sentinel做限流熔斷Seata做分布式事務(wù)。部署方式Kubernetes Docker。金融系統(tǒng)對(duì)高可用要求高K8s的滾動(dòng)更新和自動(dòng)擴(kuò)縮容能省很多事。環(huán)境準(zhǔn)備清單組件版本用途備注JDK17運(yùn)行環(huán)境LTS版本穩(wěn)定MySQL8.0交易庫(kù)主從架構(gòu)半同步復(fù)制Redis7.0緩存/鎖哨兵模式至少3節(jié)點(diǎn)RocketMQ5.0消息隊(duì)列主從DLedgerNacos2.2注冊(cè)配置集群模式3節(jié)點(diǎn)Sentinel1.8限流熔斷控制臺(tái)客戶端3.2 核心交易鏈路實(shí)現(xiàn)從請(qǐng)求到記賬一筆支付請(qǐng)求的完整鏈路是這樣的接入層API網(wǎng)關(guān)收到請(qǐng)求做鑒權(quán)驗(yàn)證Token、限流Sentinel、參數(shù)校驗(yàn)金額不能為負(fù)、必填字段不能為空。業(yè)務(wù)層根據(jù)request_id查重如果已存在直接返回。然后開(kāi)啟本地事務(wù)扣減付款方余額增加收款方余額插入交易流水。消息層本地事務(wù)提交后發(fā)送消息到RocketMQ通知下游做記賬、通知、風(fēng)控分析。資金層定時(shí)任務(wù)掃描未完成的交易調(diào)用銀行接口做實(shí)際資金劃轉(zhuǎn)。對(duì)賬層T1日凌晨下載銀行對(duì)賬文件與本地流水比對(duì)。這里的關(guān)鍵是第2步和第3步的配合。如果本地事務(wù)提交了但消息發(fā)送失敗就會(huì)出現(xiàn)“錢(qián)扣了但下游不知道”的問(wèn)題。解決方案是使用RocketMQ的事務(wù)消息先發(fā)送半消息本地事務(wù)執(zhí)行成功后提交消息失敗則回滾消息。如果半消息發(fā)送后本地事務(wù)狀態(tài)未知RocketMQ會(huì)回查本地事務(wù)狀態(tài)。// 事務(wù)消息發(fā)送示例 TransactionMQProducer producer new TransactionMQProducer(pay_producer); producer.setTransactionListener(new TransactionListener() { Override public LocalTransactionState executeLocalTransaction(Message msg, Object arg) { try { // 執(zhí)行本地事務(wù)扣款、記賬 paymentService.processPayment((PaymentRequest) arg); return LocalTransactionState.COMMIT_MESSAGE; } catch (Exception e) { return LocalTransactionState.ROLLBACK_MESSAGE; } } Override public LocalTransactionState checkLocalTransaction(MessageExt msg) { // 回查本地事務(wù)狀態(tài) String requestId msg.getKeys(); PaymentRecord record paymentService.findByRequestId(requestId); if (record null) { return LocalTransactionState.ROLLBACK_MESSAGE; } if (record.getStatus() Status.SUCCESS) { return LocalTransactionState.COMMIT_MESSAGE; } return LocalTransactionState.UNKNOW; } });3.3 參數(shù)計(jì)算費(fèi)率、限額、凍結(jié)金額金融系統(tǒng)里有很多參數(shù)需要計(jì)算我挑三個(gè)最典型的來(lái)說(shuō)。費(fèi)率計(jì)算假設(shè)費(fèi)率為0.6%但有封頂和保底。計(jì)算公式是fee min(max(amount * 0.006, min_fee), max_fee)。比如金額100元費(fèi)率0.6%就是0.6元如果保底0.1元封頂50元那0.6元在范圍內(nèi)最終費(fèi)用0.6元。如果金額10000元0.6%是60元超過(guò)封頂50元最終費(fèi)用50元。這個(gè)計(jì)算看起來(lái)簡(jiǎn)單但要注意金額的精度。金融系統(tǒng)里金額一般用DECIMAL(20,8)不能用FLOAT或DOUBLE因?yàn)楦↑c(diǎn)數(shù)有精度丟失問(wèn)題。限額計(jì)算限額分單筆限額、日累計(jì)限額、月累計(jì)限額。計(jì)算日累計(jì)限額時(shí)要查當(dāng)天所有成功交易的總額。這里有個(gè)坑如果用戶同時(shí)發(fā)起多筆交易每筆都查一次累計(jì)限額可能都通過(guò)但加起來(lái)就超限了。解決方案是用Redis做原子累加每筆交易先INCRBY如果超過(guò)限額就回滾。-- Redis Lua腳本原子累加并檢查限額 local key KEYS[1] local amount tonumber(ARGV[1]) local limit tonumber(ARGV[2]) local current tonumber(redis.call(GET, key) or 0) if current amount limit then return 0 -- 超限 end redis.call(INCRBY, key, amount) redis.call(EXPIRE, key, 86400) -- 當(dāng)天有效 return 1 -- 成功凍結(jié)金額計(jì)算凍結(jié)金額 交易金額 預(yù)估手續(xù)費(fèi)。為什么要加手續(xù)費(fèi)因?yàn)槿绻粌鼋Y(jié)交易金額手續(xù)費(fèi)扣款時(shí)可能余額不足。比如用戶余額100元交易金額100元手續(xù)費(fèi)0.6元。如果只凍結(jié)100元手續(xù)費(fèi)就扣不了。所以凍結(jié)時(shí)要凍結(jié)100.6元。這個(gè)細(xì)節(jié)很多團(tuán)隊(duì)會(huì)忽略導(dǎo)致手續(xù)費(fèi)扣款失敗。3.4 實(shí)操現(xiàn)場(chǎng)記錄一次線上問(wèn)題的排查過(guò)程去年雙十一我們的支付系統(tǒng)突然出現(xiàn)大量“交易超時(shí)”告警。我當(dāng)時(shí)的排查過(guò)程是這樣的第一步看監(jiān)控大盤(pán)。發(fā)現(xiàn)支付接口的P99響應(yīng)時(shí)間從200ms飆升到5s但CPU和內(nèi)存都正常。這說(shuō)明不是資源瓶頸而是某個(gè)下游依賴變慢了。第二步看鏈路追蹤。發(fā)現(xiàn)耗時(shí)集中在“調(diào)用銀行接口”這一步。銀行接口的響應(yīng)時(shí)間從平均300ms變成了3s。聯(lián)系銀行后得知他們那邊也在搞活動(dòng)流量暴漲。第三步看限流配置。發(fā)現(xiàn)我們對(duì)銀行接口的限流閾值設(shè)得太高導(dǎo)致大量請(qǐng)求堆積。于是緊急調(diào)低限流閾值并開(kāi)啟熔斷降級(jí)。對(duì)于超時(shí)的請(qǐng)求先返回“處理中”后續(xù)通過(guò)異步查詢確認(rèn)結(jié)果。第四步事后復(fù)盤(pán)。我們做了三件事一是給銀行接口加了更嚴(yán)格的超時(shí)時(shí)間從5s降到2s二是增加了異步查詢機(jī)制不依賴同步返回三是和銀行建立了容量溝通機(jī)制大促前互相報(bào)備。這次問(wèn)題的教訓(xùn)是金融系統(tǒng)不能假設(shè)下游永遠(yuǎn)可靠。任何外部依賴都要有超時(shí)、重試、熔斷、降級(jí)四件套。而且重試要小心不能盲目重試否則可能造成重復(fù)扣款。我們的做法是只有明確知道請(qǐng)求沒(méi)到達(dá)對(duì)方時(shí)才重試如果對(duì)方可能已處理就走查詢接口確認(rèn)。4. 常見(jiàn)問(wèn)題與排查技巧實(shí)錄4.1 交易類問(wèn)題速查表問(wèn)題現(xiàn)象可能原因排查方法解決方案用戶扣款成功但訂單未更新消息發(fā)送失敗或消費(fèi)失敗查消息隊(duì)列的發(fā)送記錄和消費(fèi)記錄用事務(wù)消息本地消息表兜底同一筆交易扣款兩次冪等失效查request_id是否重復(fù)查唯一索引是否生效加唯一索引用狀態(tài)機(jī)判斷余額出現(xiàn)負(fù)數(shù)并發(fā)扣款未加鎖查數(shù)據(jù)庫(kù)隔離級(jí)別和鎖機(jī)制用樂(lè)觀鎖或悲觀鎖加余額校驗(yàn)對(duì)賬差異率高對(duì)賬文件解析錯(cuò)誤或時(shí)間窗口不對(duì)抽查差異記錄核對(duì)原始文件修正解析邏輯調(diào)整時(shí)間窗口風(fēng)控誤殺率高規(guī)則太嚴(yán)或數(shù)據(jù)不準(zhǔn)查被攔截交易的用戶畫(huà)像調(diào)整規(guī)則閾值增加白名單4.2 并發(fā)問(wèn)題的排查思路并發(fā)問(wèn)題是金融系統(tǒng)最頭疼的問(wèn)題之一。我總結(jié)了一個(gè)排查套路確認(rèn)現(xiàn)象是余額不對(duì)還是交易狀態(tài)不對(duì)還是兩者都不對(duì)。查日志找到出問(wèn)題的交易ID看它的完整日志鏈路。重點(diǎn)關(guān)注加鎖、解鎖、事務(wù)提交、事務(wù)回滾這幾個(gè)節(jié)點(diǎn)。查數(shù)據(jù)庫(kù)看事務(wù)隔離級(jí)別看是否有間隙鎖看唯一索引是否生效。復(fù)現(xiàn)用JMeter或wrk模擬并發(fā)請(qǐng)求看能否復(fù)現(xiàn)。如果能復(fù)現(xiàn)就逐步縮小范圍定位到具體代碼。修復(fù)根據(jù)原因選擇方案。如果是鎖粒度太粗就細(xì)化鎖如果是事務(wù)太大就拆小事務(wù)如果是數(shù)據(jù)庫(kù)隔離級(jí)別問(wèn)題就調(diào)整隔離級(jí)別或改用分布式鎖。實(shí)操心得分布式鎖一定要設(shè)過(guò)期時(shí)間否則一旦持有鎖的節(jié)點(diǎn)宕機(jī)鎖就永遠(yuǎn)釋放不了。但過(guò)期時(shí)間不能太短否則業(yè)務(wù)沒(méi)執(zhí)行完鎖就過(guò)期了。我的經(jīng)驗(yàn)是過(guò)期時(shí)間 業(yè)務(wù)平均耗時(shí) * 3。同時(shí)要加看門(mén)狗機(jī)制業(yè)務(wù)沒(méi)執(zhí)行完就自動(dòng)續(xù)期。4.3 數(shù)據(jù)一致性問(wèn)題的處理金融系統(tǒng)對(duì)數(shù)據(jù)一致性要求極高。我遇到過(guò)幾次數(shù)據(jù)不一致的情況原因各不相同主從延遲寫(xiě)主庫(kù)后立即讀從庫(kù)讀不到最新數(shù)據(jù)。解決方案是“寫(xiě)后讀主”或者用半同步復(fù)制。緩存與數(shù)據(jù)庫(kù)不一致更新數(shù)據(jù)庫(kù)后刪除緩存失敗。解決方案是“先更新數(shù)據(jù)庫(kù)再刪除緩存”并且用消息隊(duì)列做補(bǔ)償刪除。分布式事務(wù)問(wèn)題跨服務(wù)調(diào)用時(shí)一個(gè)服務(wù)成功一個(gè)失敗。解決方案是用Seata的AT模式或TCC模式。AT模式對(duì)代碼侵入小但性能有損耗TCC模式性能好但開(kāi)發(fā)復(fù)雜。我一般推薦“最終一致性”方案核心交易用本地事務(wù)保證強(qiáng)一致跨服務(wù)通信用消息隊(duì)列保證最終一致。這樣既能保證資金安全又能保證系統(tǒng)性能。4.4 合規(guī)與審計(jì)的注意事項(xiàng)金融服務(wù)離不開(kāi)合規(guī)和審計(jì)。我踩過(guò)的坑包括日志留存不夠監(jiān)管要求交易日志至少留存5年。我們一開(kāi)始只留了1年后來(lái)緊急擴(kuò)容。敏感信息未脫敏日志里打印了完整的銀行卡號(hào)被審計(jì)發(fā)現(xiàn)。后來(lái)改成只打印后四位。權(quán)限控制不嚴(yán)開(kāi)發(fā)人員可以隨意查生產(chǎn)數(shù)據(jù)庫(kù)。后來(lái)加了堡壘機(jī)和審批流程。數(shù)據(jù)導(dǎo)出無(wú)記錄有人導(dǎo)出了用戶數(shù)據(jù)但沒(méi)有記錄。后來(lái)加了數(shù)據(jù)導(dǎo)出審計(jì)日志。這些坑看起來(lái)是管理問(wèn)題但技術(shù)手段可以解決大部分。比如日志脫敏可以用Logback的PatternLayout自定義轉(zhuǎn)換器權(quán)限控制可以用Spring Security RBAC數(shù)據(jù)導(dǎo)出可以用數(shù)據(jù)庫(kù)審計(jì)插件。5. 金融服務(wù)系統(tǒng)的擴(kuò)展與演進(jìn)5.1 從單體到微服務(wù)的拆分策略當(dāng)系統(tǒng)發(fā)展到一定規(guī)模單體架構(gòu)會(huì)成為瓶頸。這時(shí)候需要拆分成微服務(wù)。但拆分不是越細(xì)越好我的經(jīng)驗(yàn)是按業(yè)務(wù)域拆不按技術(shù)層拆。比如賬戶服務(wù)、交易服務(wù)、對(duì)賬服務(wù)、風(fēng)控服務(wù)每個(gè)服務(wù)獨(dú)立部署、獨(dú)立數(shù)據(jù)庫(kù)。拆分時(shí)要注意幾個(gè)問(wèn)題分布式事務(wù)跨服務(wù)調(diào)用要用Seata或消息隊(duì)列保證一致性。服務(wù)依賴避免循環(huán)依賴A調(diào)BB又調(diào)A?？梢杂檬录?qū)動(dòng)解耦。數(shù)據(jù)冗余每個(gè)服務(wù)只存自己需要的數(shù)據(jù)不要共享數(shù)據(jù)庫(kù)。接口版本接口要向后兼容新版本上線不能影響老版本調(diào)用方。5.2 高可用與容災(zāi)設(shè)計(jì)金融系統(tǒng)的高可用是硬指標(biāo)。我一般按“同城雙活異地災(zāi)備”來(lái)設(shè)計(jì)同城雙活兩個(gè)機(jī)房同時(shí)提供服務(wù)流量各50%。數(shù)據(jù)庫(kù)用主從半同步復(fù)制保證數(shù)據(jù)不丟。異地災(zāi)備第三個(gè)機(jī)房做冷備或溫備數(shù)據(jù)異步復(fù)制。平時(shí)不承載流量故障時(shí)切換。切換演練每季度做一次切換演練確保切換流程順暢。演練時(shí)要模擬各種故障場(chǎng)景比如機(jī)房斷電、網(wǎng)絡(luò)分區(qū)、數(shù)據(jù)庫(kù)主庫(kù)宕機(jī)。注意切換不是自動(dòng)的一定要有人工確認(rèn)環(huán)節(jié)。因?yàn)樽詣?dòng)切換可能誤判導(dǎo)致不必要的切換。金融系統(tǒng)寧可慢一點(diǎn)也不能切錯(cuò)。5.3 未來(lái)可能的擴(kuò)展方向金融服務(wù)系統(tǒng)做完基礎(chǔ)功能后還可以往幾個(gè)方向擴(kuò)展實(shí)時(shí)風(fēng)控用Flink做流式計(jì)算實(shí)時(shí)分析交易行為發(fā)現(xiàn)異常立即攔截。智能對(duì)賬用機(jī)器學(xué)習(xí)自動(dòng)分類差異原因減少人工審核工作量。開(kāi)放銀行提供API給第三方開(kāi)發(fā)者讓外部應(yīng)用可以調(diào)用金融服務(wù)。區(qū)塊鏈結(jié)算用聯(lián)盟鏈做跨機(jī)構(gòu)結(jié)算提高效率降低成本。這些方向我都在關(guān)注有些已經(jīng)在小范圍試點(diǎn)。比如實(shí)時(shí)風(fēng)控我們用Flink Drools做了一套原型效果不錯(cuò)但規(guī)則維護(hù)成本還比較高。智能對(duì)賬還在調(diào)研階段主要是歷史數(shù)據(jù)不夠模型訓(xùn)練效果一般。我個(gè)人在實(shí)際操作中的體會(huì)是金融服務(wù)系統(tǒng)的核心不是技術(shù)多先進(jìn)而是穩(wěn)定、準(zhǔn)確、可追溯。技術(shù)選型可以保守一點(diǎn)但每個(gè)環(huán)節(jié)都要有兜底方案。寧可上線慢一點(diǎn)也要把對(duì)賬、風(fēng)控、冪等這些基礎(chǔ)打牢。因?yàn)榻鹑谙到y(tǒng)一旦出問(wèn)題就不是簡(jiǎn)單的Bug而是真金白銀的損失。最后再分享一個(gè)小技巧每次上線前一定要做一次“資金全鏈路演練”從用戶下單到資金到賬每個(gè)環(huán)節(jié)都手動(dòng)驗(yàn)證一遍。這個(gè)習(xí)慣幫我避免了好幾次潛在事故。