金融级系统架构实战：从微服务拆分到对账幂等设计

1. 项目概述为什么要做“financial-services”这套东西做金融服务的业务系统跟做普通互联网应用完全不是一回事。普通应用挂了用户刷新一下还能用金融服务系统挂了光是合规问责就能让你焦头烂额。我最初接手这个代号为“financial-services”的项目时团队对它的定位就四个字稳定、可追溯。它不是某个单一业务模块而是一整套面向金融业务场景的基础服务体系覆盖账户、交易、风控、清算对账这几个核心链路。先说清楚它能解决什么问题。做过支付或者信贷系统的人都有体会业务发展到一定程度最痛苦的不是功能开发而是各个系统之间口径不一致。账务系统说这笔交易成功了风控系统却说这笔交易有风险需要拦截清算系统那边又因为两边数据不一致对不上账。这套“financial-services”项目的核心目标就是把这些金融通用能力统一收敛到一个中台层对外提供标准化的服务接口对内实现全链路的数据可追踪。适合谁来参考这套方案如果你是做互联网金融、电商支付、信贷风控、或者传统银行数字化转型的技术负责人或核心开发这篇内容可以给你一个比较完整的落地参考。即使是刚入行的同学也可以通过这篇文章了解金融级系统在架构设计时到底在关注什么。整个项目的落地过程中我踩了不少坑也积累了一些从文档里学不到的实操经验。这篇文章不打算讲那些虚的理论全部是实际干活时总结出来的东西从整体设计思路到核心模块实现再到上线后的运维排查争取一次讲透。2. 整体方案设计金融级系统的三层架构思路2.1 为什么不能直接在一个单体应用里做金融服务很多团队刚启动金融业务时图省事直接把账户、订单、支付、对账全部写在一个应用里。业务量小的时候确实没毛病但金融业务有它自己的特殊性最典型的是资金安全要求极高和对账逻辑极其复杂。一旦交易量上来任何一个子模块的故障都可能拖垮整个链路而且出了问题之后由于各模块共用数据库根本无法快速定位是哪个环节产生了脏数据。所以“financial-services”在最初设计时就确定了微服务化的方向。我采用了一种相对务实的微服务拆分方式不是按照简单的“按业务域拆”而是按照“稳定程度”和“变更频率”两条轴线来划分高稳定低变更的核心账务服务独立部署禁止随意改动高变更低稳定的渠道接入层频繁迭代与核心服务彻底隔离中间层的风控决策、额度管理、交易网关做逻辑隔离但共享部分基础数据这样做的好处很直接。渠道接入层可能一周发版两三次而核心账务服务可能半年都不会变一次。如果它们在一个进程里每次渠道层的发布都要重新启动整个应用核心账务服务就被迫跟着承担发布风险。拆开之后核心链路非常稳定渠道层的频繁迭代也不会影响资金安全相关的主流程。2.2 核心模块划分与数据流走向整个“financial-services”项目划分了六个核心子模块数据流转方向是单向依赖的不允许反向调用模块名称核心职责依赖关系账户中心管理客户账户状态、余额、冻结/解冻无底层依赖交易引擎处理交易路由、交易状态机流转依赖账户中心风控决策实时风险评分、规则拦截依赖账户中心和交易数据支付网关对接外部渠道统一报文转换依赖交易引擎清算对账渠道对账文件解析、差错处理依赖支付网关流水通知中心交易结果异步通知、回调重试依赖交易引擎举例说明数据的走向。一笔用户发起的支付请求首先进入支付网关网关只做协议转换然后调用交易引擎创建交易单。交易引擎创建成功后调用风控决策服务做实时检查风控返回通过后再调用账户中心完成资金扣减。扣减成功之后交易引擎更新交易状态为成功同时发送一条消息到通知中心通知中心负责把结果推送给商户。所有环节都产生标准化的流水事件清算对账模块在T1日通过流水与渠道文件进行核对。这套设计在逻辑上画起来很简单但真正落地时最考验人的是交易引擎的状态机设计。支付交易的状态不能只简单分成成功和失败至少要有初始化、处理中、成功、失败、部分成功、已退款、已关闭这几个状态而且每个状态之间的转换条件必须严格定义。我在后面会专门展开讲这块。3. 核心模块的实操细节从账户到风控的完整落地3.1 账户中心的“三户模型”设计账户模型是金融系统的地基。“financial-services”项目参考了银行核心系统中常用的“三户模型”也就是客户、账户、额度三者的分离。最初我们踩过一个大坑把客户基本信息、账户余额、可用额度全部存在一张表里结果遇到一个客户名下多个账户的场景每次计算总资产都要全表扫描而且冻结金额和可用余额的计算逻辑混乱经常出现账实不符。后来完全重构为三张独立的表客户表只存身份信息身份证号、姓名、手机号等不包含任何资金相关字段账户表关联客户ID记录账户类型、账户状态、币种、账面余额额度表关联账户ID记录授信额度、已用额度、可用额度、冻结额度关于余额的计算这里分享一个非常重要的经验。账面余额和可用余额必须分字段存储不能靠“账面余额减去冻结金额”实时算出来。如果实时计算在高并发场景下会出现严重的性能问题而且一旦出现数据不一致排查起来非常困难。正确的做法是每次资金变动都会通过事务同时更新账面余额和可用余额两个字段的更新在同一个数据库事务里完成再加一张流水表记录每一笔变动的前值后值。资金操作的核心SQL逻辑大概是这样的-- 扣减金额带条件更新防止并发超扣 UPDATE account SET available_balance available_balance - #{amount}, book_balance book_balance - #{amount} WHERE account_id #{accountId} AND available_balance #{amount} AND status ACTIVE;这个SQL的精髓在于金额大于0这个条件。如果影响行数为0说明余额不足或者账户状态异常程序直接抛异常终止不允许后续流程继续。这样做可以天然防住并发情况下同一个账户同时被多笔交易扣款的超扣问题而不是靠数据库锁。3.2 交易引擎状态机是核心中的核心交易引擎是整个“financial-services”最复杂的模块。每一笔交易从生到死都要经历明确的状态流转我们直接引入了状态机框架而不是用if-else硬写状态判断。以一笔支付交易为例状态流转如下交易请求到达创建交易单状态为“初始化”调用风控预检通过后状态变为“处理中”调用账户中心扣款成功状态变为“成功”如果扣款成功但后续通知失败状态保持“成功”但通知状态单独标记为“待重试”任何一步异常状态变为“失败”同时发起自动冲正处理这里最难处理的是“部分成功”的边界场景。举个例子用户支付100元账户扣款成功了但渠道商那边返回超时实际上渠道已经扣款成功。这种状态如果处理不好就会造成资金不一致。我们的方案是引入对账补偿机制交易状态先标记为“未知”写明是“扣款成功但渠道确认未知”交由T1日的对账任务去确认最终状态。这也是为什么我说交易状态不能只有成功和失败这套状态机在代码层面用配置驱动每笔交易的状态变更都会写入一张流水表完整记录状态迁移路径便于后续审计和问题定位。3.3 风控决策规则引擎加实时特征计算风控模块在“financial-services”里承担着交易安全阀的角色。这个模块的设计目标不是拦截所有可疑交易而是在最小化误杀的前提下把高风险交易挡在门外。我们采用了两层风控架构。第一层是规则引擎处理实时性要求最高的黑白名单和固定规则比如单笔限额、单日累计限额、黑名单手机号、IP异常等第二层是模型引擎基于机器学习模型做实时风险评分模型输入是过去30分钟的特征聚合结果。规则引擎的实现我们选用了Drools虽然学习曲线有点陡但胜在规则热更新非常方便。业务人员在管理后台配置好规则后规则文件推送到风控服务服务在内存中完成规则重新编译加载整个过程不需要重启应用对于大促等特殊时期的临时限额调整非常实用。一个典型的限额规则代码示例rule SingleTransactionLimit when $tx: Transaction(amount 50000) then $tx.setRiskLevel(HIGH); $tx.addRiskTag(单笔超限额); end实时特征计算这块使用的是Flink做流式计算。每笔交易事件实时进入Flink计算窗口统计当前用户在5分钟、30分钟内累计交易金额和次数并把结果写入Redis。风控决策时直接从Redis获取特征值一般控制在5毫秒内拿到全部特征数据。说实话整个项目里风控模块的沟通成本是最高的。风控策略同事和技术团队的思考方式差异很大策略同事关注的是规则的覆盖率和误杀率技术团队关注的延迟和吞吐量。后来我们建立了定期的策略回测机制每次规则调整前先用历史交易数据回测确保新规则不会大面积误伤正常交易。4. 清算对账与系统韧性的工程落地4.1 对账系统的“差额为什么总是查不出来”之痛所有金融系统都必须过对账这一关。对账的核心诉求就是拿内部的交易流水与外部渠道返回的结算文件逐笔核对。但实际做对账最痛苦的不是对不上而是两边都能对上却存在隐匿的差异比如渠道文件里有一笔手续费扣了我们这边没记录或者我们系统里某笔交易是成功的渠道返回的文件里根本没有这笔记录。在“financial-services”项目中对账模块采用了分阶段的核对机制笔数核对先统计两边各自的总笔数和总金额如果这两个大数对不上直接进入差异明细比对逐笔核对以渠道文件为基准按第三方交易流水号关联内部交易流水号找出两边不一致的记录差错处理对无法自动匹配的记录生成差错单进入人工处理流程或自动冲正流程这里有个从实操中总结的经验内部流水号和渠道流水号一定要分开存放。很多团队图省事直接把内部流水号作为渠道流水号存起来结果渠道那边因为重试导致流水号变化时我们这边对账就彻底对不上了。正确的做法是内部流水号由我们系统自行生成渠道流水号关联渠道返回的字段两个字段分别是独立存储的。对账文件的解析也有讲究。渠道方返回的文件格式五花八门有CSV、Excel、固定长度的TXT等等。一开始我们为每种格式写解析器维护成本极高。后来统一做了一层适配器将不同格式的文件全部解析为标准Java对象的列表后续的核对逻辑只针对标准对象新增渠道时只需要写一个适配器不需要动核对逻辑。批次对账任务推荐用分布式任务调度平台因为每日对账的数据量大逐笔核对在单机上跑经常出现内存溢出。我们当时用的方案是分片处理把一天的数据按渠道维度拆分成多个子任务每个子任务处理一个渠道并行执行最终汇总各分片的结果生成对账报表。4.2 恢复能力冲正、重试与幂等设计金融系统不能假设所有外部调用都会成功所以必须在下层实现“带补偿的恢复能力”。首先是超时重试。调用外部支付渠道扣款时如果第一次请求超时了我们不能立刻判定失败因为可能渠道那边实际已经扣款成功了。这种情况下的标准做法是查询订单状态而不是直接重试扣款。如果查询结果也是超时就标记为“未知状态”交给对账任务去确认。因为如果一个超时请求实际扣款成功而我们又发起一笔新的扣款请求用户会被扣两次钱这是原则性事故。其次是幂等设计。所有涉及资金操作的接口都必须支持幂等客户端的重试请求如果带着相同的业务流水号服务端要直接返回上次的处理结果而不是重复处理。我们通过数据库的唯一索引来兜底实现幂等交易流水号在交易表上建唯一索引重复插入时数据库抛异常程序捕获异常后去查询已存在的交易记录返回。重试机制也需要注意积压问题。如果外部渠道响应很慢重试队列里会堆积大量任务要给每个重试任务设置最大重试次数超过次数的进入死信队列触发告警人工介入。我见过太多系统因为重试任务无限堆积最终把下游数据库连接池打满导致整个应用雪崩的案例。4.3 缓存与数据库一致性的务实取舍在高并发金融场景下不可能所有数据都直接查数据库缓存是绕不开的手段。但缓存和数据库的一致性问题如果不处理好同样会出大事故。拿账户余额来说我们采用的是“数据库为主、缓存为辅”的策略。读余额时优先读缓存缓存没有时查数据库并回填缓存写余额时直接操作数据库然后删除缓存。这里选择删除缓存而不是更新缓存是为了避免并发下先更新缓存再更新数据库时两条更新语句顺序不一样导致缓存里存了旧值的问题。不过需要注意删除缓存也可能存在缓存击穿的风险。某个热点账户的缓存刚被删除瞬间大量读请求直接打到数据库数据库压力剧增。我们的方案是将热点账户标记出来对这些账户的缓存删除操作改为延迟双删先删除缓存再更新数据库隔一段时间再删除一次缓存确保任何并发场景下都不会读到旧值。5. 上线后的常见问题与排查技巧实录5.1 问题速查表我遇到过的那些经典故障现象可能原因排查方法解决方案交易全部超时数据库连接池被占满查看连接池活跃数慢SQL日志扩容优化慢SQL增加熔断对账不平且找不到原因内部流水号和渠道流水号映射错误对比两边原始流水查映射关系重建映射增加校验任务风控规则变更后误杀率飙升规则条件配置错误检查规则生效版本跑策略回测快速回滚规则版本账户余额莫名变负并发超扣条件更新没生效查看账户流水分析扣款顺序重新设计扣款SQL加余额条件缓存中余额为旧值缓存删除失败查看当日删除缓存错误日志启动延迟双删并做补偿清理渠道回调重复通知幂等设计缺失查交易日志确认重复消费增加唯一索引和去重表5.2 一个典型的数据库连接池耗尽排查过程有一次线上告警支付成功率突然大幅下跌。先看监控面板交易引擎的P99延迟从80毫秒飙到了4秒多数据库活跃连接数直接打满。进一步追查发现是一个外部渠道的响应时间从200毫秒恶化到了8秒而这笔调用的线程一直在等待渠道返回持有的数据库连接无法释放。请求持续涌入新的请求拿不到数据库连接于是排队等待整个支付链路都被拖垮了。这个问题表面看是渠道方的问题实际暴露了我们的设计缺陷调用外部渠道等待响应的过程中数据库连接被白白占用。后来我们做了两项改造一是把外部渠道调用改成异步化发起调用后立刻释放数据库连接通过回调或轮询结果的方式更新交易状态二是给所有外部调用加上了超时熔断超过2秒直接快速失败不再继续等待。这个案例给我留下的印象很深。做金融系统不能只盯着自己的代码逻辑还要考虑外部依赖出问题时系统的整体韧性。外部渠道是不可控因素但可以让它造成的爆炸半径最小化。5.3 性能压测必须要注意的几点“financial-services”在上线前做了三轮压测这里分享几个压测时容易忽略的细节问题。压测数据一定要用真实的脱敏数据不能自己造一批非常规整的数据。因为真实数据分布不均匀少数热点账户会承担大部分流量如果压测数据都是均匀分布的就测不出热点账户引起的性能问题。压测时数据库慢查询阈值要调到比较敏感的水平比如超过100毫秒的SQL全部记录下来。金融系统的日常请求量很大平时很难发现的问题在压测中会集中暴露。当时我们就通过压测发现了一个索引缺失的SQL平时数据量小看不出来压测时执行时间从30毫秒恶化到3秒加了一个联合索引后问题彻底消失。还有一个就是压测时要观察主机的CPU、内存、磁盘IO、网络带宽等基础设施指标不能只看应用的延迟和吞吐量。有时候应用的性能瓶颈根本不在应用层而是磁盘IO已经满了这时候换更强的CPU也无济于事。6. 后续扩展方向与个人感受“financial-services”这套项目上线运行之后生产环境表现比较稳定核心链路全年可用性保持在99.95%以上。不过金融业务的需求是不断演进的目前团队在做两个方向的扩展。第一个方向是实时对账。目前的T1日对账虽然稳定但在一些大额交易场景下用户和业务方都希望能够更快地确认资金状态。我们正在把对账周期从T1缩到T0也就是当天交易在半小时后进行准实时对账。这需要改造渠道方的文件推送机制同时增加准实时批量查询渠道交易状态的调度任务。第二个方向是算法风控的深化。规则引擎解决了已知的风险问题对新出现的风险模式覆盖有限。我们正在把用户行为序列数据引入特征计算比如通过用户的历史操作路径来判断当前交易是否存在异常。这个方向的数据工程量不小但是对降低欺诈损失的效果很明显。做金融系统这几年我个人最大的体会是不要炫技。金融系统不需要用最前沿的架构但一定要用最稳的方案。很多团队喜欢一上来就上Service Mesh、单元化部署这些看起来很牛的方案但如果没有足够的运维能力和故障演练经验复杂架构反而会在出问题时成为排查的障碍。先把基础能力打牢把状态机设计清楚把对账和幂等做好把监控告警完善这套系统的可靠性自然就上来了。架构上的“好”是在一次又一次的故障中磨出来的不是设计出来的。