1. 项目定位与核心设计思路提到 financial-services 这个词很多人第一反应是银行App里那一堆转账、理财、贷款菜单。但我这里想聊的是一个偏底层的技术项目把金融服务拆成标准化的 API 能力让上层业务线快速接入项目内部代号直接就叫 financial-services。听起来很大其实它是一堆独立服务的集合负责账户、支付、账本、风控这些基础能力更像是一个给业务产品提供金融能力的“插座板”而不是一个面向用户的 App。为什么要做这个因为业务方的真实需求往往不是定制一套核销流程而是“我有个订单需要收一笔钱我有笔补贴需要发到用户余额里”。如果每条业务线都自己做支付、做结算最后一定是一地鸡毛渠道重复签约、账户模型各写各的、对账时要同时面对七八套账。所以 financial-services 的核心价值不是“做出了什么界面”而是把资金链路上最高频、最容易出错的部分收敛成统一服务。1.1 先定业务边界再谈技术选型做这类项目最容易踩的坑是一上来就讨论“用不用微服务”“上不上K8s”然后被框架牵着走。我自己的做法是先把业务边界画出来再让技术选型去适配它。financial-services 内部我划分了三层资金核心层账户、余额、流水、账本。这一层不允许随意改任何变更都要留痕。交易处理层支付下单、渠道路由、回调接收、退款、转账。这一层是高频动作需要做充分的异步化。接入与风控层对外API、签名鉴权、风控规则、限额限频、对账报表。这一层跟外部系统和业务方打交道最频繁。分层的理由很简单资金核心层是“出事就要死人”的必须保守稳定交易处理层是“并发高但可以重试”的尽量设计成可补偿接入层是“改动最多”的要跟内部其它系统保持解耦。把这三件事混在一个服务里后续每一次需求迭代都等于踩钢丝。技术选型反而没那么纠结。账本用MySQL缓存用Redis消息队列用常规的MQ服务间调用走HTTP或RPC。只要每一层的边界没乱常规技术栈完全扛得住业务起步阶段。很多项目出问题不是技术选型不够新而是业务边界先糊了后面怎么补都别扭。1.2 服务粒度拆成多大才合适拆分粒度是另一个反复被问的问题。有人觉得一个“账户服务”就够有人恨不得把余额和流水拆成两个服务。我的经验是按“会不会独立扩展”和“有没有独立安全要求”来判断而不是按代码量。financial-services 里账户服务和流水服务最初是一个服务后来拆开了。因为账户的写入压力远低于流水但流水查询量极大还经常要做分页、导出、归档。混在一起时一次大查询就可能拖慢账户响应拆开后账户服务只需要保证余额一致性流水服务可以放心加索引、做分库。支付路由和账户服务必须拆开。支付路由随时可能要加渠道、切渠道它的变更频率很高而账户服务最怕被无关变更牵连。风控服务则单独拆出来因为它的数据访问特征完全不同需要读设备指纹、历史行为、名单库还要跑规则引擎一旦和交易服务耦合风控策略调整就得重新发版。另外提一个容易被忽视的维度团队协作边界。如果团队里有专人负责合规、专人负责风控那么对应的服务就要拆到他们能独立交付的程度。技术上的“高内聚低耦合”最终要落到“人和事能对得上”否则架构图画得再漂亮落地时依然会乱。2. 核心模块拆解身份、支付、账本、风控如果把 financial-services 比作一辆车那身份账户体系是底盘支付路由是发动机账本是仪表盘风控是刹车。这四个模块缺一个整个项目都没法上线。2.1 身份账户体系把“人”和“账号”拆开这是最容易一开始就设计错的地方。很多人做账户体系时脑子里默认“一个用户只有一个账户”于是把用户ID和账户ID直接画等号。实际跑起来马上就出问题同一用户可能既是C端消费者又是B端商户同一用户可能在不同业务线各有独立余额甚至一个企业客户要挂多个子账户来分门店管理。我的设计思路是分层建模用户身份认证、实名、绑卡信息解决“这人是谁”。客户档案用户在某个业务域的档案解决“这人在这条业务线里是什么角色”。账户真正的资金载体解决“钱记在谁的头上”。账户又分两类虚拟账户和外部资金账户。虚拟账户就是内部记账用的余额账户用户看到的是可用余额服务内部还有冻结余额、待结算余额等细分字段。外部资金账户则是真实银行账户或支付渠道账户虚拟账户与外部账户之间通过一笔笔流水建立映射关系。账户字段里有两个字段我建议从一开始就保留account_type和currency。哪怕当前业务只支持人民币、只有两种账户类型也要把字段先留好。否则后面接跨境业务或者接入预付卡时数据迁移会让你怀疑人生。账户服务还有一个核心原则外部接口永远不允许直接增加或扣减余额。所有余额变动都必须通过“交易凭证”来驱动。也就是说业务方只能提交一个“冻结请求”“解冻请求”“扣款请求”由账务服务根据交易指令生成流水再更新余额。这样才能保证每一分钱的变动都有据可查。2.2 支付路由不是“选通道”而是链路可回放支付路由常常被理解成一个单纯的负载均衡或智能推荐比如“哪家费率低走哪家”。但真正做过 financial-services 的人都明白支付路由要解决的是一整套生命周期管理。一次支付的完整状态并不是“成功”或“失败”两个终点。真实状态至少包括已创建本地落单已请求渠道渠道处理中渠道通知成功本地确认成功对账异常已退款已关闭路由层要把这些状态完整记录下来。我见过最头疼的问题就是回调丢了之后系统里只剩一个“支付中”状态既不知道渠道到底有没有扣款也不敢给用户发货。后来我们养成了一个习惯每次请求渠道之前先本地落库保存完整的请求报文、渠道单号、回调地址并且给每个支付事件生成全局唯一的事件ID。这个设计让链路的每一环都可以被回溯哪怕渠道没有任何回调我们也能拿着渠道单号去主动查单再根据查单结果修正本地状态。路由策略不能只盯着费率和成功率。还要考虑商户号维度、银行通道的维护时间、单笔限额和行业限制。比如某些行业在特定渠道被限制交易就算成功率再高也不能用。所以路由配置里我建议维护一份可动态更新的渠道能力表字段包含渠道编码、支持的业务类型、限额范围、维护窗口、优先级、权重。配置变更要能热加载但不能在交易高峰期直接切全量流量应该按比例灰度。2.3 资金账本余额是“算出来”的账户余额看起来很直接就是一个数值。但如果你用 update 语句去直接改 balance很快就会遇到三个问题并发扣款、脏读、流水和余额对不上。正确姿势是把余额当成账本计算结果来维护。每次余额变动都必须生成一条单独的流水记录流水包含账户ID、变动类型、变动金额、变动前余额、变动后余额、关联交易单号、操作时间戳。账户表里的 balance 只是对流水的一个汇总快照而不是账本本身。当多笔扣款并发发生时不能靠“先查余额再更新”的方式因为中间有窗口期。我常用的做法是在流水表里用唯一键约束保证同一笔交易凭证只能生效一次同时在更新余额时使用带条件的 update比如UPDATE account SET balance balance - ? WHERE id ? AND balance ?。如果影响行数为0说明余额不足或者账户异常再抛错。资金账本不只有余额还有试算平衡的概念。简单说任意时间点所有账户的“昨日余额 今日收入 - 今日支出”应该等于“今日余额”任何一笔流水都能对应到某个交易。我们每周跑一次自动对账脚本把流水表、账户表、交易表三方的数据做汇总比对不平的自动生成异常列表。第一次写完这个脚本时我盯着异常列表看到凌晨三点但从此以后再也没人敢乱写余额了。2.4 风控不是拦截是给每次操作打分很多项目把风控当成“黑名单拦截”这是非常危险的简化。真正有用的风控是给每次操作输出一个风险分值再根据分值决定放行、人工审核、加强验证或直接拒绝。financial-services 里的风控服务主要做三件事名单管理内部黑名单、灰名单、白名单支持手机号、设备ID、身份证号、银行卡号等多个维度。规则引擎比如“同一设备号一天内绑定超过3张银行卡则触发人工审核”“单笔金额超过5万则要求二次验证”“新注册用户24小时内不允许提现”。行为画像统计用户历史行为频率、常用设备、常用地区作为模型特征。规则引擎我强烈不建议一开始就交给数据团队去搭复杂模型。先把基于规则的版本跑起来规则写进配置中心能实时调整就行。模型可以在积累足够数据后再逐步引入。这个顺序一旦反了数据没沉淀好就上模型风控就变成玄学连误杀原因都讲不清楚。3. 从0到1实操跑通一个最小闭环项目设计得再完整最终都要落到“能不能跑通一笔真实资金业务”。我这边的习惯是选一个最小场景从开户、充值、消费到对账全部手工走一遍。场景越简单越好不要一开始就想同时支持支付和退款。3.1 最小闭环开户、充值、消费、对账我们选的最小闭环是用户在业务线注册后自动开一个内部余额账户然后通过第三方支付渠道充值再用余额购买业务线的一个虚拟商品。流程拆下来大概是业务线调用POST /api/v1/accounts传入用户ID和账户类型账户服务创建账户并返回账户ID。用户发起充值业务线调用POST /api/v1/payments支付服务创建充值订单请求支付渠道返回收银台地址。支付渠道在用户支付成功后异步通知支付服务支付服务验签后更新订单状态再调用账务服务给账户增加余额。用户用余额购买商品业务线调用POST /api/v1/payments/pay_balance账务服务执行扣款并返回扣款凭证。日终对账任务拉取渠道账单与本地充值订单逐笔匹配。这条链路看着简单但每一环都有值得较真的细节。比如第四步“余额扣款”一定要使用我们在2.3里说的条件更新而不是先查余额再扣。再比如第五步对账如果发现渠道侧有扣款而本地没有订单就要先标记“长款”如果本地有订单而渠道没有流水就要标记“短款”。长款要人工介入短款要自动补偿退款或重试。3.2 幂等和回调的代码级实现做支付服务最常被问的一个问题是“渠道回调到底触发了几次”答案是至少一次而且经常多于一次。所以幂等处理是硬性要求不是可选优化。这里给一个简化的回调处理逻辑供参考def handle_payment_callback(event_id, order_no, channel_status): lock_key fcallback_lock:{event_id} # 用 Redis SETNX 做分布式锁锁到订单终态为止 if not redis.set(lock_key, 1, nxTrue, ex120): # 锁冲突说明已有线程在处理直接返回成功 return received try: order order_repo.get_by_order_no(order_no) if order.status in (SUCCESS, CLOSED): # 订单已到达终态不再重复处理 return received if channel_status SUCCESS: apply_account_entry(order) order.status SUCCESS order_repo.update(order) notify_business(order) else: order.status FAILED order_repo.update(order) finally: redis.delete(lock_key)这段逻辑有两个关键点。一是锁的粒度必须是单笔事件不能锁整个回调队列二是订单只要进入终态就绝不允许再次变更。否则渠道先回调成功、再发起一笔退款回调时系统就会把已经成功的订单覆盖成失败而钱其实已经扣了。除了事件锁数据库表里也要有兜底唯一约束。比如回调记录表里对event_id建唯一索引哪怕代码层锁失效数据库也会拦截重复的明细。做资金项目永远要假设上层逻辑会有漏洞然后在下一层兜住。3.3 最小闭环验收清单整个闭环跑通之后我会按下面这张清单验收防止自己有遗漏检查项通过标准幂等验证对同一回调重复请求10次订单状态只变更一次并发扣款同一余额账户被并发扣款时不出现负数回调丢失手动模拟不回调解法通过主动查单能修复状态对账差异故意从渠道账单删掉一笔流水能对出“短款”缓存故障Redis挂掉后不再继续发起余额扣款鉴权失败非法商户调用API时返回统一错误码风控触发超出限额交易会被拦截或进入人工审核这七项是我认为资金类服务上线前的及格线不是优秀线。及格线没过就上线后面大概率要用运维同学的头发来偿还。4. 上线后踩坑实录文档里不会写的细节项目上线之后遇到的大部分问题都不是复杂算法问题而是一些“你以为是环境问题查了一天发现是逻辑问题”的细节。这里挑几个真实踩过的坑展开说说。4.1 回调重复推送引发的灵异事件有一次上线后运营反馈说用户被重复扣款了。查日志发现渠道确实只扣了一次但我们的账务服务给用户加了两笔余额。原因是我在代码里用event_id做了锁但同一个支付事件在渠道侧关联了不同的event_id——渠道在发起重试时自作聪明地换了一个事件号。这也提醒了我幂等不能只依赖链路某一环的事件ID。最稳妥的做法是以业务订单号作为数据层面的唯一键而不是直接信任外部系统传入的 event_id。后来我把回调表改成“业务订单号 渠道单号 事件ID”三重校验才彻底堵住这类问题。4.2 时间戳和精度四个最容易出问题的字段资金项目里金额和时间是两个最容易埋雷的字段。金额方面我见过因为浮点运算导致的一分钱差账也见过接口文档说“单位是元”实际渠道传回来的是带两位小数的字符串结果被代码里的乘法一算变成了放大一百倍的数字。我的建议很土但很有效金额一律用整数最小单位存储比如“分”接口传输用字符串不用数字计算用整数运算禁止使用浮点数。时间方面所有内部存储统一用UTC时间戳展示层再转本地时区。账务日切时千万不要用业务服务器的本地时间一定要用统一的时钟源否则跨时区服务器各记各的对账必炸。4.3 渠道联调时的兼容性陷阱第三方支付渠道的文档永远“看起来很标准”实际联调时各种隐藏差异。比如同样的退款接口A渠道用同步响应表示退款受理B渠道的同步响应只是“收到请求”真正结果要看异步通知。再比如签名算法有些渠道要求对所有参数排序拼接有些渠道又要求URL解码后再签名稍不留神就验签失败。对付这种情况我把所有渠道封装成统一的适配层每个渠道只保留一个实现类统一输出标准化的支付状态。渠道特有字段都放在扩展参数里不进统一订单模型。这样即使要接新渠道也不需要改上层逻辑。我踩过的教训是不要相信“接口规范完全兼容”这句话联调时一上来就要把报文打印全对照文档逐字段核对。4.4 监控指标不要只盯成功率刚开始做监控时大家只盯着“支付成功率”和“回调成功率”。后来发现这两个指标太粗了成功率掉了固然要紧但更怕的是“成功率没变但资金账对不上”。我后来把监控拆成多个维度请求量水位每秒支付请求量以及渠道单队列积压量。回调延迟分位值P50、P95、P99。回调慢了直接拖垮用户体验。对账差异数每日长款短款数量这个数字必须趋近于零。异常状态滞留卡在“支付中”状态超过30分钟的订单量。余额试算差额任何时点账户试算不平的累计差额。监控的价值不在于看仪表盘好看而在于出现问题后能把“影响范围”和“发生时间”迅速定位。我们有一次就是靠“支付中状态滞留数”的分钟级曲线顺藤摸瓜找到了一个渠道查单接口超时的问题比业务投诉早了两天。5. 后续演进从最小闭环到产品化financial-services 跑通之后最明显的感受是业务方提需求不再从零开始了很多能力只要配置一下参数就上线。这个阶段最需要考虑的是如何演进而不是继续堆功能。5.1 增加一个信贷产品要动哪些环节很多人以为信贷就是一个“放款 还款”接口真要做才知道金融服务的每一层都要跟着调整。账户层需要支持“贷款子账户”和“还款计划账户”支付层需要支持代扣和主动还款账本层要增加“加息”、“罚息”、“结清”等流水类型风控层要增加额度模型和贷后监控。这意味着 financial-services 的平台化能力必须预留足够灵活的分类账户和流水类型否则每接一个业务都要改表结构。我当时给自己的要求是任何新增产品都优先通过配置完成而不是新写一套代码。比如账户类型用配置字典管理结算周期做成参数手续费规则写成可配置的表达式。能配置化就不写代码这是中台服务控制长尾成本的关键。5.2 让数据变成资产报表和分析服务资金服务跑一段时间后最有价值的不仅是功能而是数据。财务想看每日结算汇总运营想看渠道成功率趋势风控想看异常交易分布。如果这些报表都是从业务库现查每次都会互相影响性能。我在 financial-services 旁边加了一套独立的报表库通过 binlog 或定时任务将账务流水、交易明细、渠道账单同步过去做宽表加工。这套数据体系真正跑起来后很多“拍脑袋”决策都变成了有数据支撑的讨论。比如渠道切换不再凭感觉而是看三个月的手续费和成功率趋势用户流失分析也能关联到支付失败原因。金融服务的核心是信任而信任很大程度上来自透明可查的数据。5.3 想长期维护 financial-services 的三点建议最后说三点我个人的经验供参考。第一不要把“账平”当成理所当然。每天都要有人负责对账哪怕当天没有异常也要留痕。很多资金事故都不是一次性爆发的而是连续几天小差异没人管积累成大窟窿。第二任何新功能上线之前先回答“挂了怎么办”。服务不可用不可怕可怕的是不可用的状态下资金状态变得不可知。所以设计时要提前想清楚暂停交易、拒绝新单、存量订单怎么处理都要有预案。第三多和财务、运营、法务的同学聊天。代码里的一分钱差异在外面可能意味着一次客诉一个没考虑到的结算周期可能会让财务加班到深夜。金融项目的技术负责人如果只盯技术文档很容易在业务侧翻车。做 financial-services 这类项目最有成就感的时刻不是上线那晚而是一个月后财务发来消息说“这个月账全平了”。那一刻我才觉得这个服务是真的可以被信任的。希望这篇记录能给正在做同类项目的朋友一些参考少踩几个我已经替你们踩过的坑。
