1. 项目背景为什么我们要拆出一个独立的金融服务模块我参与的这个项目内部代号叫 financial-services。说白了就是把一家公司散落在各个业务系统里的资金相关逻辑全部收进一个独立系统里集中管理。如果你正在做交易中台、支付系统、账务系统或者已经被对账、重复扣款、渠道切换这些事折腾得够呛这篇文章值得你耐心看完。下面讲的每一段都是我们在这个项目里真实踩坑之后的总结不是什么教科书式的理想方案。金融类项目最先要回答的问题是这个模块到底管什么。我们的答案非常克制——不做账本不做信贷核心只管一件事让所有涉及用户资金流转的操作包括余额支付、渠道扣款、退款、账单查询和对账都从业务系统里剥离出来由一个模块集中控制。这个决定当时在团队里引发了不少争论反对的声音主要有两类一类觉得项目太敏感资金数据挪窝风险大另一类觉得公司已经有那么多开源支付框架直接集成不是更省事。但等我们把前期排查报告摆上桌面争论就自动停止了。因为原来的账确实已经对不上了。1.1 账务逻辑散落带来的三座大山我们当时面对的问题可以归纳成三座大山。第一座是账对不平每一条产品线都有自己的一套余额和账单财务部每个月靠人工拉 Excel 做对账一次要耗掉好几天而且经常对完仍有长短款。第二座是差错定位难同一个用户订单在订单服务里显示支付成功在支付单服务里显示处理中在渠道侧却显示失败。三个表各记各的谁都不敢说自己是对的。第三座是行为不一致订单服务能直接调渠道扣款营销服务也能直接调连客服系统都有一根处理“异常退费”的通道。每个服务都觉得自己在做一个合法动作但整体上没有任何人说得清一笔钱到底经过了多少节点。这三座大山叠加在一起造成的直接后果是业务侧上线新功能时只要涉及钱都要先拉上支付、财务、客服的人开一轮评审会而且评审会开完仍然不敢拍板。因为谁也不知道改了一处余额逻辑另一处还在偷偷扣钱的旧逻辑会不会跳出来捣乱。1.2 一个需求要改七个系统的触发点真正让我们下决心立项的是一个看起来很普通的需求部分退款。这个需求本身不难难的是它要改七个系统——订单、售后、客服、财务、渠道网关、运营后台、用户账单。我们做评估时发现每个系统都有自己的退款状态定义有的叫“退款成功”有的叫“已退回”有的叫“处理完成”但触发的条件和余额恢复的逻辑完全不一样。改完这个需求之后还要继续维护它每一个新渠道接入都意味着所有业务线再各改一遍。这种结构不管你怎么打补丁成本只会越滚越高。于是在那次需求评审会上我们提了一个多少有点大胆的提案把资金相关的逻辑全部收口到 financial-services 里让业务系统只表达交易意图不碰余额、不写流水、不直接对接渠道。提案通过的原因也很现实渠道统一、对账自动化和资金差错可追溯已经是公司财务和运营部门憋了很久的诉求。技术上的重构困难反而成了最后需要解决的问题。1.3 项目定位成为唯一的资金事实来源项目定位一句话就能说清楚成为全公司唯一的资金事实来源。所有业务线查余额、查支付状态、查账单都必须以 financial-services 的返回为准资金流经的每一步都能在这里找到记录。这听起来像个庞大的“核心系统”但我们刻意把范围控制得很小业务复杂度可以留给你们我不关心你卖的是课程还是实物商品我只负责管好钱。想清楚这一点之后后面所有设计都会顺很多。因为“唯一事实来源”意味着我们不能只做一个支付网关还要管好账户、账单、对账、退款、渠道连接并且保证任何一条资金记录都可以被审计。它是业务系统和外部渠道之间的翻译层同时也是资金安全的守门员。2. 模块边界与核心能力设计先搞清楚哪些必须自己做拆模块之前我们花了整整两周时间做边界梳理。很多人一上来就画微服务架构图问要不要上 Kafka、要不要上分布式事务这些当然重要但都不如先把边界定清楚。边界不清楚后面写多少代码都是给自己埋雷。2.1 边界划分原则我们最后沉淀下来三条硬性规则。第一条动钱的必须走 financial-services余额扣减、支付、退款、出款一律不允许业务系统自行处理。第二条业务系统只传交易意图比如下单时传入“我要支付订单 OID”而不是自己先算好余额再去调用接口。第三条查询可以共享写操作必须收敛查余额可以走共享接口但任何写操作都必须经过统一入口。这三条规则看起来简单但执行时最大的阻力不是技术而是让存量业务系统不再继续偷偷改余额。我们为此做了一个比较彻底的动作把旧系统里所有直接 update 余额的入口全部收回逐个业务线上线检查。排查时还真发现了几个隐藏多年的“野接口”甚至连负责维护的同事都忘了它们还在跑。2.2 六大能力域与数据分层边界划好之后我们按能力把系统拆成六个域支付域、账户域、账单域、对账域、退款域、渠道网关域。支付域负责受理支付请求、生成支付单、驱动支付状态机账户域负责余额变动和账户记录账单域负责消费账单的生成与查询对账域拉取各渠道账单做差异处理退款域管理逆向资金流渠道网关域统一封装第三方支付和银行渠道。六个域之间通过内部事件通信尽量避免服务之间直接互相调用到绕不开。数据模型上我们坚持四层分离业务订单、支付单、渠道流水、账单各是一张独立的表。业务订单由业务系统自己管financial-services 只处理支付单支付单记录一次完整的支付请求及其状态渠道流水记录和外部渠道每一次交互的原始结果账单则面向用户展示。这样分层的好处是任何一层出了问题都不会污染其他层的语义。渠道流水甚至可能由于渠道回溯而发生变更但我们仍然保留原始记录再用追加记录表达变更而不是覆盖。2.3 异步化的设计取舍最开始我们的方案是全同步的用户点击支付订单服务同步调支付服务支付服务同步调渠道网关渠道网关同步等渠道返回。这种方案理解起来最简单但第一次压测就翻车了。同步链路越长最慢的一个环节会拖死整条链路。我们后来做了一个关键调整把资金动作拆成“受理”和“处理”两个阶段。用户提交支付后接口只负责校验权限、生成支付单、返回受理成功真正的扣款放到异步任务里执行结果通过回调或者主动查单返回给调用方。这么做的代价是业务复杂度增加但换来了吞吐量和容错能力。同步模式下一个渠道 3 秒超时整个调用链就傻等 3 秒异步模式下渠道慢了只会影响那笔对应的订单系统整体仍然可以继续受理新请求。我们选择异步还有一个核心原因支付业务永远允许最终一致只要保证状态最终可解释、可校验就行。为了不让异步消息丢失我们在本地建了一张任务表业务操作和任务写入放在同一个数据库事务里再由后台任务定时补偿基本做到了既不丢单也不重复入账。3. 支付与账务链路的实现细节幂等、对账、状态机进入具体实现之后最能区分一个金融系统靠不靠谱的不是用了什么新技术而是幂等、状态机、对账这三件事做到什么程度。我把它们单独拿出来说因为这三件事任何一个出问题都会直接表现为资金差错。3.1 三层幂等设计我们做了三层幂等。第一层是业务请求幂等所有调用方必须传一个全局唯一的 request_id同一笔请求重复提交不会产生重复扣款。第二层是支付单幂等同一笔业务订单只能生成一张有效的支付单防止业务方换一个场景又来建一笔。第三层是渠道流水幂等最终落到渠道侧的每一笔扣款都以渠道返回的流水号为唯一键重复回调不会重复入账。幂等的实现方式我强烈建议在数据库层做唯一索引而不是只依赖 Redis 锁。Redis 锁在分布式环境下有超时、误删、并发穿透这些边界问题当作前置过滤没问题但最终兜底一定要靠唯一索引。我们建表时直接带上唯一键比如下面这种方式CREATE TABLE pay_order ( id BIGINT PRIMARY KEY AUTO_INCREMENT, biz_order_no VARCHAR(64) NOT NULL, request_id VARCHAR(64) NOT NULL, pay_no VARCHAR(64) NOT NULL, status TINYINT NOT NULL, -- 其余字段略 UNIQUE KEY uk_request_id (request_id), UNIQUE KEY uk_pay_no (pay_no), UNIQUE KEY uk_biz_order_no (biz_order_no) );这样就算同一个请求被重放了十次数据库也会拒掉后面九次顶多报一个唯一键冲突你把它当成成功的幂等结果处理即可。我们在实践中还发现唯一键冲突不要直接暴露给调用方统一转成“请求已受理”的语义否则上游会以为系统报错反而触发不必要的重试风暴。3.2 支付单状态机的落地支付单的状态我们一开始没有管得很严结果出了不少非法跳变问题。后来我们把状态机显式建模状态只有六种待支付、支付中、成功、关闭、退款中、退款成功。每个状态的变化都必须走规定路径比如只有“待支付”可以到“支付中”“支付中”可以到“成功”或“关闭”“成功”可以到“退款中”“退款中”可以到“退款成功”。代码里任何一处更新状态的地方都要经过状态机校验不允许随意直接 update status。当前状态允许流转到说明待支付支付中、关闭用户发起支付后进入支付中超时未付可关闭支付中成功、关闭关闭需要经过人工确认或超时逻辑成功退款中有逆向资金需求时进入退款中退款成功、成功退款失败时回到成功状态保留可重试能力关闭无终态不允许再被拉起退款成功无终态资金逆向已完成每次状态变化都会写一条状态变更流水记录变化前状态、变化后状态、触发人和幂等键。这既是为了排查问题也是审计的基本要求。任何资金数据都不能覆盖历史只能通过追加状态来完成变更。3.3 对账体系的搭建对账这件事我们做了两层。第一层是渠道对账每天把渠道侧返回的账单和我们的支付单逐笔比对找出我单方成功、渠道单方成功、金额不一致这些差异。第二层是内部对账把账户余额变动跟账单流水做一致性核对确保记账没有漏记、重记。批量跑完对出差异只是第一步真正费力的是差异处理闭环。我们将差异单自动发起重查重查失败进入人工池由运营和财务处理每张差异单都有状态处理过程全程留痕。这套流程跑顺之后财务那边原先一周做一次对账的节奏变成了每天自动完成人工只需要处理异常池。我们自己定的目标是所有差异单必须在 24 小时内完成重查或人工处理如果某天差异池超过 20 张值班负责人的第一优先级是清池子而不是开新功能。4. 安全合规与数据保护金融系统的命门金融系统的命门不在功能在安全。动钱的系统一旦出现数据泄漏或者越权操作可能比功能故障严重得多。所以我们在安全上花的力气不比业务功能少。4.1 敏感数据加密与日志脱敏银行卡号、身份证号、手机号这类字段我们全部用 AES-256-GCM 加密后落库。选 GCM 模式是因为它自带随机初始向量和附加认证数据密文一旦被篡改或者被挪到其他环境解密时会直接失败这比单纯的 ECB 模式强太多。密钥统一由 KMS 管理代码里只保存密钥 ID不保存明文密钥解密动作发生在内存中落日志之前再脱敏处理。所有日志输出卡号、手机号时统一只保留后四位查询接口返回的数据也经过脱敏封装。这个习惯必须在写第一段日志的时候养成否则后面要在成堆的历史日志里做清理非常痛苦。另外密钥不是永久的。我们规定每 90 天轮换一次主密钥历史数据用一个密钥版本号标记解密时根据数据上的版本号找对应密钥这样即便轮换老数据也能正常读取。我们还专门准备了一个独立的临时密钥池用于紧急情况下的数据导出所有导出操作都要走审批流并记录导出理由。4.2 接口鉴权与防重放内部服务之间的调用我们用 AK/SK HMAC-SHA256 签名。每次请求带上时间戳、随机 nonce 和签名串签名串由请求体、时间戳、nonce 和密钥计算得出接收方校验签名后把 nonce 写入 Redis 做短期去重时间戳超过五分钟的请求直接拒绝这样即使报文被截获也没办法重放。签名的实现有一个容易踩坑的细节参与签名的字段一定要固定好顺序否则前后端各签各的永远对不上。我们在网关层统一对请求字段做排序、拼接、HMAC 计算业务服务不需要自己实现签名逻辑。资金类接口的鉴权级别要更高一些对前端来的请求除了登录令牌关键动作还要做二次校验比如短信验证码或独立支付密码。渠道侧的回调我们使用非对称签名只有持有对应公钥的渠道方消息才会被处理。4.3 审计留痕与权限边界审计日志我们单独建表只允许插入不允许任何更新和删除。每次敏感数据访问、每笔状态变更都记录操作人、操作时间、操作前后值。举一个具体例子客服人员要查看一个用户的绑卡信息系统会先判断权限角色然后记录本次查询查询返回的卡号后四位可见完整卡号需要一个一次性授权码。审计日志会记录授权码的发放人、使用时间、使用人。这套机制把“查得到”和“可以查”分开了。数据库账号按最小权限分配支付服务只能访问自己的库表不能顺手查到用户中心的数据每个业务方过来对接发放独立的凭证并在服务层强制做归属校验避免 A 业务的订单号去查 B 业务的账单。5. 性能压测与稳定性治理上线前被现实教育的那几课功能都写完之后我们做了整整三轮压测。如果当时少做一轮上线之后大概率要出事。这一部分我想讲讲我们吃到过的几个亏以及最终怎么处理的。5.1 第一次压测连接池和线程池同时被打穿第一轮压测的场景是 200 并发同时发起支付结果系统直接扛不住。查下来原因很经典我们当时走的是全同步链路支付服务同步等渠道网关返回订单服务又同步等支付服务返回一个请求平均要占数据库连接差不多一秒钟连接池只配了 20200 并发一上来连接立即耗尽大量请求在排队等待数据库连接继而内存和 CPU 也被拖爆。我们把配置调整成下面这组数字之后才算勉强过关数据库连接池从 20 调到 50并且对每个外部渠道单独维护一个线程池渠道一个慢吞吞的响应不会把系统全局拖垮同时把渠道调用放到异步线程里主线程只负责接受受理结果和记录状态。压测轮次并发主要配置P99结果第一轮200全同步连接池 20大量超时未通过第二轮300异步受理连接池 50约 400ms通过第三轮800渠道线程池隔离 超时熔断约 600ms通过这个教训让我明白一件事支付链路里的连接池、线程池和超时设置不是配好就一劳永逸的它们必须跟着流量和渠道特性反复调整而且每次调整都要有压测数据支撑。5.2 热点账户与拆分记账压测还暴露了一个隐藏问题热点账户。我们有一个平台红包账户所有营销活动的资金都集中在这一个账户上。活动一开始几十个并发同时更新同一行账户余额行锁把性能直接拉垮。数据库行锁的等待时间会随着并发量指数上升谁都别想正常工作。解决方案是把账户拆成总账户和子账户资金先进子账户子账户只插入明细不频繁更新余额后台任务定期汇总子账户到总账户。对外展示余额时用总账户加上未汇总的明细实时计算。这个设计天然适合营销这种读写比失衡的场景但要注意对账模块必须同时校验总账和子账的一致性否则异步汇总一旦丢数据对账会很难受。5.3 缓存穿透与超时治理签约关系、商户配置这类读多写少的数据我们一开始加了 Redis 缓存但实测发现缓存命中率并没有想象中高。原因是每次有新商户接入带来一批全新的请求 key缓存没有数据库也没有直接形成穿透。处理方式很朴素对查不到的数据也写一个短 TTL 的空值缓存在更极端的场景比如用户信息批量核查再用布隆过滤器挡掉不存在的 key。另一个教训是外部渠道的超时设计。我们最初所有渠道统一用 3 秒超时后来发现有的渠道平均响应就 2 秒多一旦抖动这个超时设置基本形同虚设。后来改成分档超时高风险接口 1.5 秒、普通渠道 3 秒、批量出款类长接口单独配置 10 秒每个渠道都有独立的重试次数和熔断阈值。失败时快速返回比长时间干等要安全得多毕竟超时之后的补偿逻辑是可以设计的但一个卡住的请求可能把整个线程池耗尽。6. 灰度上线与一次真实排障复盘系统顺利跑过压测后并不意味着可以全量上线。资金系统的上线策略讲究一点先让一小撮流量替你验证确认账不会差再逐步放大。我们当时设计了一个五步灰度方案。6.1 灰度策略先切流量再切资金第一步选两三个体量很小的内部商户切到新系统先做只读验证确认查询和账单数据正常第二步放 1% 的支付流量并且限制单笔金额在 100 元以内观察支付成功率、金额差错率、退款成功率这三个核心指标第三步逐步放大到 5%、20%、50%每一步都要完整观察至少一个结算周期第四步切新渠道第五步全量。回滚预案不是一句“有问题就回滚”那么简单资金一旦出去流程不可能重放只能通过逆向冲正处理。所以我们的回滚预案里写的是具体到每类交易如何处理、什么时候人工介入、冲正操作由谁审批。灰度期间的每个步骤都会产出一份数据对账报告只有报告显示账目一致才允许继续放量。6.2 签约成功但扣款失败一次完整的排查过程灰度期间我们遇到了一个非常经典的线上问题。现象是用户完成绑卡签约后立刻发起第一笔扣款失败率明显偏高反馈集中在灰度流量里。我带着工程师开始排查第一步看扣款服务的错误日志清一色的“签约关系不存在”第二步查数据库主库签约记录明明存在第三步怀疑主从延迟但随机抽出几条记录写入时间已经过去一分钟了主从同步不可能还滞后。走到这里常规路径都被排除了我们只好去翻代码结果发现扣款服务查询签约关系时读的是 Redis 缓存而缓存里存的是旧数据。为什么旧因为签约服务写库成功后会发一条“签约变更”消息负责更新缓存的服务应该消费这条消息。灰度期间我们只让收单服务接上了消息扣款服务的消费逻辑还没上线所以它拿到的永远是旧缓存。修复不复杂把扣款服务的消息消费补上主动失效并重建缓存同时把缓存 TTL 从 30 分钟缩短到 5 分钟再加一条“签约缓存版本落后”的监控告警。这个坑告诉我们多服务之间的数据一致性不能只靠代码里碰运气要有一致性消息链路和监控作为兜底。6.3 资金类监控指标最后整理了我们日常盯盘的资金类指标支付成功率、渠道回调成功率、退款成功率、资金差错率、对账差异单量、未冲正交易数、支付耗时 P99、幂等冲突量、签约缓存命中率。这九个指标分别从资金、渠道、账务、缓存四个维度盯着系统。金融系统出问题应急的第一反应永远是账对不对得上如果对不上先停新流量再查原因如果对得上功能问题按普通故障处理。我们把这些指标做成了大盘值班的人每天看一眼数字偏离基线就自动报警。灰度期间这套监控帮我们提前发现了不少边缘问题比如某个渠道在凌晨时段成功率掉到 90%第二天查下来是渠道侧系统维护险些被当成我们自己的 bug。7. 项目复盘什么情况下不该拆出独立服务项目上线正常三个月后我们做了一次复盘。复盘里有一个结论让我印象很深不是所有团队都应该立刻去拆一个独立的金融服务模块。如果条件不成熟硬拆只会增加成本不会增加安全感。7.1 不该拆的情况第一种情况产品线单一只有一种支付方式业务量也不大这时候一个简单服务足够拆出独立模块纯属增加维护成本。第二种情况团队没有配套的监控、灰度、发布体系独立服务上线后出了问题定位可能比原来的大泥球更难。第三种情况业务口径没有统一比如大家对“支付成功”“退款成功”的定义还各执一词这时候先把名词定义清楚比写代码更紧急。我见过不少团队把需求复杂度高、业务变更多当作拆服务理由但拆完之后才发现真正的问题根本不在服务边界而在于没有人在全局层面定义清楚每一笔钱的状态。新服务只是把混乱搬了个家并不会自动变整齐。我们这次之所以能拆得动是因为前期花了大量时间统一口径并且所有业务线的高层都认可 financial-services 是唯一资金入口。如果这两点不具备独立模块上线后大概率被人绕过形成事实上的双头那比集中化之前更危险。7.2 值得先做的三件事如果让我重新搭一次 financial-services我会把三件事放到最优先级第一先统一账务口径所有和钱相关的名词、状态、规则先写进一个文档第二先把对账建起来哪怕最初用最笨的办法每天自动跑批加人工复核也要做到日清第三在写任何接口之前把幂等键设计好这是所有资金系统的地基。统一口径要具体到工单级别比如“支付成功”以渠道回调为准还是以支付单状态为准必须写明。对账号最初哪怕只是简单比对支付单和渠道账单也要把差异处理流程跑通。幂等键则要覆盖所有写接口并把唯一索引建好。这三件事做完架构怎么设计都不会太偏。这也是我这次项目里最深的体会金融系统的复杂度从来不在代码本身而在于你对每一笔钱的流向有没有真正掌控力。
1. 项目背景为什么我们要拆出一个独立的金融服务模块我参与的这个项目内部代号叫 financial-services。说白了就是把一家公司散落在各个业务系统里的资金相关逻辑全部收进一个独立系统里集中管理。如果你正在做交易中台、支付系统、账务系统或者已经被对账、重复扣款、渠道切换这些事折腾得够呛这篇文章值得你耐心看完。下面讲的每一段都是我们在这个项目里真实踩坑之后的总结不是什么教科书式的理想方案。金融类项目最先要回答的问题是这个模块到底管什么。我们的答案非常克制——不做账本不做信贷核心只管一件事让所有涉及用户资金流转的操作包括余额支付、渠道扣款、退款、账单查询和对账都从业务系统里剥离出来由一个模块集中控制。这个决定当时在团队里引发了不少争论反对的声音主要有两类一类觉得项目太敏感资金数据挪窝风险大另一类觉得公司已经有那么多开源支付框架直接集成不是更省事。但等我们把前期排查报告摆上桌面争论就自动停止了。因为原来的账确实已经对不上了。1.1 账务逻辑散落带来的三座大山我们当时面对的问题可以归纳成三座大山。第一座是账对不平每一条产品线都有自己的一套余额和账单财务部每个月靠人工拉 Excel 做对账一次要耗掉好几天而且经常对完仍有长短款。第二座是差错定位难同一个用户订单在订单服务里显示支付成功在支付单服务里显示处理中在渠道侧却显示失败。三个表各记各的谁都不敢说自己是对的。第三座是行为不一致订单服务能直接调渠道扣款营销服务也能直接调连客服系统都有一根处理“异常退费”的通道。每个服务都觉得自己在做一个合法动作但整体上没有任何人说得清一笔钱到底经过了多少节点。这三座大山叠加在一起造成的直接后果是业务侧上线新功能时只要涉及钱都要先拉上支付、财务、客服的人开一轮评审会而且评审会开完仍然不敢拍板。因为谁也不知道改了一处余额逻辑另一处还在偷偷扣钱的旧逻辑会不会跳出来捣乱。1.2 一个需求要改七个系统的触发点真正让我们下决心立项的是一个看起来很普通的需求部分退款。这个需求本身不难难的是它要改七个系统——订单、售后、客服、财务、渠道网关、运营后台、用户账单。我们做评估时发现每个系统都有自己的退款状态定义有的叫“退款成功”有的叫“已退回”有的叫“处理完成”但触发的条件和余额恢复的逻辑完全不一样。改完这个需求之后还要继续维护它每一个新渠道接入都意味着所有业务线再各改一遍。这种结构不管你怎么打补丁成本只会越滚越高。于是在那次需求评审会上我们提了一个多少有点大胆的提案把资金相关的逻辑全部收口到 financial-services 里让业务系统只表达交易意图不碰余额、不写流水、不直接对接渠道。提案通过的原因也很现实渠道统一、对账自动化和资金差错可追溯已经是公司财务和运营部门憋了很久的诉求。技术上的重构困难反而成了最后需要解决的问题。1.3 项目定位成为唯一的资金事实来源项目定位一句话就能说清楚成为全公司唯一的资金事实来源。所有业务线查余额、查支付状态、查账单都必须以 financial-services 的返回为准资金流经的每一步都能在这里找到记录。这听起来像个庞大的“核心系统”但我们刻意把范围控制得很小业务复杂度可以留给你们我不关心你卖的是课程还是实物商品我只负责管好钱。想清楚这一点之后后面所有设计都会顺很多。因为“唯一事实来源”意味着我们不能只做一个支付网关还要管好账户、账单、对账、退款、渠道连接并且保证任何一条资金记录都可以被审计。它是业务系统和外部渠道之间的翻译层同时也是资金安全的守门员。2. 模块边界与核心能力设计先搞清楚哪些必须自己做拆模块之前我们花了整整两周时间做边界梳理。很多人一上来就画微服务架构图问要不要上 Kafka、要不要上分布式事务这些当然重要但都不如先把边界定清楚。边界不清楚后面写多少代码都是给自己埋雷。2.1 边界划分原则我们最后沉淀下来三条硬性规则。第一条动钱的必须走 financial-services余额扣减、支付、退款、出款一律不允许业务系统自行处理。第二条业务系统只传交易意图比如下单时传入“我要支付订单 OID”而不是自己先算好余额再去调用接口。第三条查询可以共享写操作必须收敛查余额可以走共享接口但任何写操作都必须经过统一入口。这三条规则看起来简单但执行时最大的阻力不是技术而是让存量业务系统不再继续偷偷改余额。我们为此做了一个比较彻底的动作把旧系统里所有直接 update 余额的入口全部收回逐个业务线上线检查。排查时还真发现了几个隐藏多年的“野接口”甚至连负责维护的同事都忘了它们还在跑。2.2 六大能力域与数据分层边界划好之后我们按能力把系统拆成六个域支付域、账户域、账单域、对账域、退款域、渠道网关域。支付域负责受理支付请求、生成支付单、驱动支付状态机账户域负责余额变动和账户记录账单域负责消费账单的生成与查询对账域拉取各渠道账单做差异处理退款域管理逆向资金流渠道网关域统一封装第三方支付和银行渠道。六个域之间通过内部事件通信尽量避免服务之间直接互相调用到绕不开。数据模型上我们坚持四层分离业务订单、支付单、渠道流水、账单各是一张独立的表。业务订单由业务系统自己管financial-services 只处理支付单支付单记录一次完整的支付请求及其状态渠道流水记录和外部渠道每一次交互的原始结果账单则面向用户展示。这样分层的好处是任何一层出了问题都不会污染其他层的语义。渠道流水甚至可能由于渠道回溯而发生变更但我们仍然保留原始记录再用追加记录表达变更而不是覆盖。2.3 异步化的设计取舍最开始我们的方案是全同步的用户点击支付订单服务同步调支付服务支付服务同步调渠道网关渠道网关同步等渠道返回。这种方案理解起来最简单但第一次压测就翻车了。同步链路越长最慢的一个环节会拖死整条链路。我们后来做了一个关键调整把资金动作拆成“受理”和“处理”两个阶段。用户提交支付后接口只负责校验权限、生成支付单、返回受理成功真正的扣款放到异步任务里执行结果通过回调或者主动查单返回给调用方。这么做的代价是业务复杂度增加但换来了吞吐量和容错能力。同步模式下一个渠道 3 秒超时整个调用链就傻等 3 秒异步模式下渠道慢了只会影响那笔对应的订单系统整体仍然可以继续受理新请求。我们选择异步还有一个核心原因支付业务永远允许最终一致只要保证状态最终可解释、可校验就行。为了不让异步消息丢失我们在本地建了一张任务表业务操作和任务写入放在同一个数据库事务里再由后台任务定时补偿基本做到了既不丢单也不重复入账。3. 支付与账务链路的实现细节幂等、对账、状态机进入具体实现之后最能区分一个金融系统靠不靠谱的不是用了什么新技术而是幂等、状态机、对账这三件事做到什么程度。我把它们单独拿出来说因为这三件事任何一个出问题都会直接表现为资金差错。3.1 三层幂等设计我们做了三层幂等。第一层是业务请求幂等所有调用方必须传一个全局唯一的 request_id同一笔请求重复提交不会产生重复扣款。第二层是支付单幂等同一笔业务订单只能生成一张有效的支付单防止业务方换一个场景又来建一笔。第三层是渠道流水幂等最终落到渠道侧的每一笔扣款都以渠道返回的流水号为唯一键重复回调不会重复入账。幂等的实现方式我强烈建议在数据库层做唯一索引而不是只依赖 Redis 锁。Redis 锁在分布式环境下有超时、误删、并发穿透这些边界问题当作前置过滤没问题但最终兜底一定要靠唯一索引。我们建表时直接带上唯一键比如下面这种方式CREATE TABLE pay_order ( id BIGINT PRIMARY KEY AUTO_INCREMENT, biz_order_no VARCHAR(64) NOT NULL, request_id VARCHAR(64) NOT NULL, pay_no VARCHAR(64) NOT NULL, status TINYINT NOT NULL, -- 其余字段略 UNIQUE KEY uk_request_id (request_id), UNIQUE KEY uk_pay_no (pay_no), UNIQUE KEY uk_biz_order_no (biz_order_no) );这样就算同一个请求被重放了十次数据库也会拒掉后面九次顶多报一个唯一键冲突你把它当成成功的幂等结果处理即可。我们在实践中还发现唯一键冲突不要直接暴露给调用方统一转成“请求已受理”的语义否则上游会以为系统报错反而触发不必要的重试风暴。3.2 支付单状态机的落地支付单的状态我们一开始没有管得很严结果出了不少非法跳变问题。后来我们把状态机显式建模状态只有六种待支付、支付中、成功、关闭、退款中、退款成功。每个状态的变化都必须走规定路径比如只有“待支付”可以到“支付中”“支付中”可以到“成功”或“关闭”“成功”可以到“退款中”“退款中”可以到“退款成功”。代码里任何一处更新状态的地方都要经过状态机校验不允许随意直接 update status。当前状态允许流转到说明待支付支付中、关闭用户发起支付后进入支付中超时未付可关闭支付中成功、关闭关闭需要经过人工确认或超时逻辑成功退款中有逆向资金需求时进入退款中退款成功、成功退款失败时回到成功状态保留可重试能力关闭无终态不允许再被拉起退款成功无终态资金逆向已完成每次状态变化都会写一条状态变更流水记录变化前状态、变化后状态、触发人和幂等键。这既是为了排查问题也是审计的基本要求。任何资金数据都不能覆盖历史只能通过追加状态来完成变更。3.3 对账体系的搭建对账这件事我们做了两层。第一层是渠道对账每天把渠道侧返回的账单和我们的支付单逐笔比对找出我单方成功、渠道单方成功、金额不一致这些差异。第二层是内部对账把账户余额变动跟账单流水做一致性核对确保记账没有漏记、重记。批量跑完对出差异只是第一步真正费力的是差异处理闭环。我们将差异单自动发起重查重查失败进入人工池由运营和财务处理每张差异单都有状态处理过程全程留痕。这套流程跑顺之后财务那边原先一周做一次对账的节奏变成了每天自动完成人工只需要处理异常池。我们自己定的目标是所有差异单必须在 24 小时内完成重查或人工处理如果某天差异池超过 20 张值班负责人的第一优先级是清池子而不是开新功能。4. 安全合规与数据保护金融系统的命门金融系统的命门不在功能在安全。动钱的系统一旦出现数据泄漏或者越权操作可能比功能故障严重得多。所以我们在安全上花的力气不比业务功能少。4.1 敏感数据加密与日志脱敏银行卡号、身份证号、手机号这类字段我们全部用 AES-256-GCM 加密后落库。选 GCM 模式是因为它自带随机初始向量和附加认证数据密文一旦被篡改或者被挪到其他环境解密时会直接失败这比单纯的 ECB 模式强太多。密钥统一由 KMS 管理代码里只保存密钥 ID不保存明文密钥解密动作发生在内存中落日志之前再脱敏处理。所有日志输出卡号、手机号时统一只保留后四位查询接口返回的数据也经过脱敏封装。这个习惯必须在写第一段日志的时候养成否则后面要在成堆的历史日志里做清理非常痛苦。另外密钥不是永久的。我们规定每 90 天轮换一次主密钥历史数据用一个密钥版本号标记解密时根据数据上的版本号找对应密钥这样即便轮换老数据也能正常读取。我们还专门准备了一个独立的临时密钥池用于紧急情况下的数据导出所有导出操作都要走审批流并记录导出理由。4.2 接口鉴权与防重放内部服务之间的调用我们用 AK/SK HMAC-SHA256 签名。每次请求带上时间戳、随机 nonce 和签名串签名串由请求体、时间戳、nonce 和密钥计算得出接收方校验签名后把 nonce 写入 Redis 做短期去重时间戳超过五分钟的请求直接拒绝这样即使报文被截获也没办法重放。签名的实现有一个容易踩坑的细节参与签名的字段一定要固定好顺序否则前后端各签各的永远对不上。我们在网关层统一对请求字段做排序、拼接、HMAC 计算业务服务不需要自己实现签名逻辑。资金类接口的鉴权级别要更高一些对前端来的请求除了登录令牌关键动作还要做二次校验比如短信验证码或独立支付密码。渠道侧的回调我们使用非对称签名只有持有对应公钥的渠道方消息才会被处理。4.3 审计留痕与权限边界审计日志我们单独建表只允许插入不允许任何更新和删除。每次敏感数据访问、每笔状态变更都记录操作人、操作时间、操作前后值。举一个具体例子客服人员要查看一个用户的绑卡信息系统会先判断权限角色然后记录本次查询查询返回的卡号后四位可见完整卡号需要一个一次性授权码。审计日志会记录授权码的发放人、使用时间、使用人。这套机制把“查得到”和“可以查”分开了。数据库账号按最小权限分配支付服务只能访问自己的库表不能顺手查到用户中心的数据每个业务方过来对接发放独立的凭证并在服务层强制做归属校验避免 A 业务的订单号去查 B 业务的账单。5. 性能压测与稳定性治理上线前被现实教育的那几课功能都写完之后我们做了整整三轮压测。如果当时少做一轮上线之后大概率要出事。这一部分我想讲讲我们吃到过的几个亏以及最终怎么处理的。5.1 第一次压测连接池和线程池同时被打穿第一轮压测的场景是 200 并发同时发起支付结果系统直接扛不住。查下来原因很经典我们当时走的是全同步链路支付服务同步等渠道网关返回订单服务又同步等支付服务返回一个请求平均要占数据库连接差不多一秒钟连接池只配了 20200 并发一上来连接立即耗尽大量请求在排队等待数据库连接继而内存和 CPU 也被拖爆。我们把配置调整成下面这组数字之后才算勉强过关数据库连接池从 20 调到 50并且对每个外部渠道单独维护一个线程池渠道一个慢吞吞的响应不会把系统全局拖垮同时把渠道调用放到异步线程里主线程只负责接受受理结果和记录状态。压测轮次并发主要配置P99结果第一轮200全同步连接池 20大量超时未通过第二轮300异步受理连接池 50约 400ms通过第三轮800渠道线程池隔离 超时熔断约 600ms通过这个教训让我明白一件事支付链路里的连接池、线程池和超时设置不是配好就一劳永逸的它们必须跟着流量和渠道特性反复调整而且每次调整都要有压测数据支撑。5.2 热点账户与拆分记账压测还暴露了一个隐藏问题热点账户。我们有一个平台红包账户所有营销活动的资金都集中在这一个账户上。活动一开始几十个并发同时更新同一行账户余额行锁把性能直接拉垮。数据库行锁的等待时间会随着并发量指数上升谁都别想正常工作。解决方案是把账户拆成总账户和子账户资金先进子账户子账户只插入明细不频繁更新余额后台任务定期汇总子账户到总账户。对外展示余额时用总账户加上未汇总的明细实时计算。这个设计天然适合营销这种读写比失衡的场景但要注意对账模块必须同时校验总账和子账的一致性否则异步汇总一旦丢数据对账会很难受。5.3 缓存穿透与超时治理签约关系、商户配置这类读多写少的数据我们一开始加了 Redis 缓存但实测发现缓存命中率并没有想象中高。原因是每次有新商户接入带来一批全新的请求 key缓存没有数据库也没有直接形成穿透。处理方式很朴素对查不到的数据也写一个短 TTL 的空值缓存在更极端的场景比如用户信息批量核查再用布隆过滤器挡掉不存在的 key。另一个教训是外部渠道的超时设计。我们最初所有渠道统一用 3 秒超时后来发现有的渠道平均响应就 2 秒多一旦抖动这个超时设置基本形同虚设。后来改成分档超时高风险接口 1.5 秒、普通渠道 3 秒、批量出款类长接口单独配置 10 秒每个渠道都有独立的重试次数和熔断阈值。失败时快速返回比长时间干等要安全得多毕竟超时之后的补偿逻辑是可以设计的但一个卡住的请求可能把整个线程池耗尽。6. 灰度上线与一次真实排障复盘系统顺利跑过压测后并不意味着可以全量上线。资金系统的上线策略讲究一点先让一小撮流量替你验证确认账不会差再逐步放大。我们当时设计了一个五步灰度方案。6.1 灰度策略先切流量再切资金第一步选两三个体量很小的内部商户切到新系统先做只读验证确认查询和账单数据正常第二步放 1% 的支付流量并且限制单笔金额在 100 元以内观察支付成功率、金额差错率、退款成功率这三个核心指标第三步逐步放大到 5%、20%、50%每一步都要完整观察至少一个结算周期第四步切新渠道第五步全量。回滚预案不是一句“有问题就回滚”那么简单资金一旦出去流程不可能重放只能通过逆向冲正处理。所以我们的回滚预案里写的是具体到每类交易如何处理、什么时候人工介入、冲正操作由谁审批。灰度期间的每个步骤都会产出一份数据对账报告只有报告显示账目一致才允许继续放量。6.2 签约成功但扣款失败一次完整的排查过程灰度期间我们遇到了一个非常经典的线上问题。现象是用户完成绑卡签约后立刻发起第一笔扣款失败率明显偏高反馈集中在灰度流量里。我带着工程师开始排查第一步看扣款服务的错误日志清一色的“签约关系不存在”第二步查数据库主库签约记录明明存在第三步怀疑主从延迟但随机抽出几条记录写入时间已经过去一分钟了主从同步不可能还滞后。走到这里常规路径都被排除了我们只好去翻代码结果发现扣款服务查询签约关系时读的是 Redis 缓存而缓存里存的是旧数据。为什么旧因为签约服务写库成功后会发一条“签约变更”消息负责更新缓存的服务应该消费这条消息。灰度期间我们只让收单服务接上了消息扣款服务的消费逻辑还没上线所以它拿到的永远是旧缓存。修复不复杂把扣款服务的消息消费补上主动失效并重建缓存同时把缓存 TTL 从 30 分钟缩短到 5 分钟再加一条“签约缓存版本落后”的监控告警。这个坑告诉我们多服务之间的数据一致性不能只靠代码里碰运气要有一致性消息链路和监控作为兜底。6.3 资金类监控指标最后整理了我们日常盯盘的资金类指标支付成功率、渠道回调成功率、退款成功率、资金差错率、对账差异单量、未冲正交易数、支付耗时 P99、幂等冲突量、签约缓存命中率。这九个指标分别从资金、渠道、账务、缓存四个维度盯着系统。金融系统出问题应急的第一反应永远是账对不对得上如果对不上先停新流量再查原因如果对得上功能问题按普通故障处理。我们把这些指标做成了大盘值班的人每天看一眼数字偏离基线就自动报警。灰度期间这套监控帮我们提前发现了不少边缘问题比如某个渠道在凌晨时段成功率掉到 90%第二天查下来是渠道侧系统维护险些被当成我们自己的 bug。7. 项目复盘什么情况下不该拆出独立服务项目上线正常三个月后我们做了一次复盘。复盘里有一个结论让我印象很深不是所有团队都应该立刻去拆一个独立的金融服务模块。如果条件不成熟硬拆只会增加成本不会增加安全感。7.1 不该拆的情况第一种情况产品线单一只有一种支付方式业务量也不大这时候一个简单服务足够拆出独立模块纯属增加维护成本。第二种情况团队没有配套的监控、灰度、发布体系独立服务上线后出了问题定位可能比原来的大泥球更难。第三种情况业务口径没有统一比如大家对“支付成功”“退款成功”的定义还各执一词这时候先把名词定义清楚比写代码更紧急。我见过不少团队把需求复杂度高、业务变更多当作拆服务理由但拆完之后才发现真正的问题根本不在服务边界而在于没有人在全局层面定义清楚每一笔钱的状态。新服务只是把混乱搬了个家并不会自动变整齐。我们这次之所以能拆得动是因为前期花了大量时间统一口径并且所有业务线的高层都认可 financial-services 是唯一资金入口。如果这两点不具备独立模块上线后大概率被人绕过形成事实上的双头那比集中化之前更危险。7.2 值得先做的三件事如果让我重新搭一次 financial-services我会把三件事放到最优先级第一先统一账务口径所有和钱相关的名词、状态、规则先写进一个文档第二先把对账建起来哪怕最初用最笨的办法每天自动跑批加人工复核也要做到日清第三在写任何接口之前把幂等键设计好这是所有资金系统的地基。统一口径要具体到工单级别比如“支付成功”以渠道回调为准还是以支付单状态为准必须写明。对账号最初哪怕只是简单比对支付单和渠道账单也要把差异处理流程跑通。幂等键则要覆盖所有写接口并把唯一索引建好。这三件事做完架构怎么设计都不会太偏。这也是我这次项目里最深的体会金融系统的复杂度从来不在代码本身而在于你对每一笔钱的流向有没有真正掌控力。
)
)
