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