1. 从“financial-services”这个标题里能读出什么
“financial-services”这个标题看起来简单到几乎没有任何信息量，就两个英文单词，中间一个连字符。但恰恰是这种极简的命名方式，在技术圈里反而透露了很多东西。我第一次看到这个标题的时候，脑子里蹦出来的第一个判断是：这大概率不是一个面向终端用户的产品名，而是一个领域标识或者模块命名。为什么这么说？因为真正面向用户的产品，名字通常会带品牌感、场景感，比如“XX记账”“XX钱包”“XX理财助手”。而“financial-services”这种命名，更像是开发者在代码仓库、微服务模块、或者某个技术方案里给一个功能域起的名字。
这个判断很关键，因为它直接决定了我们后面所有讨论的方向。如果它是一个产品，那我们要聊的是用户体验、功能设计、运营策略；但如果它是一个技术模块或者领域抽象，那我们要聊的就是架构设计、数据模型、接口规范、安全合规这些东西。从标题的命名风格来看，我倾向于后者——它更像是一个金融服务领域的技术抽象层，可能是一个后端服务、一个SDK、一个微服务集群，或者一套面向金融业务场景的技术解决方案。
那“金融服务”这个领域本身有什么特殊性？这是理解这个标题背后价值的核心。金融业务和普通的电商、社交、内容类业务有本质区别，它的几个核心特征决定了技术方案的设计取向。第一是强一致性要求，钱不能算错，一笔转账要么成功要么失败，不能出现中间状态；第二是高安全性要求，涉及资金、身份、交易记录的数据必须加密存储、严格鉴权；第三是强合规要求，每一笔交易都要可追溯、可审计，监管层面有明确的留存期限和格式要求；第四是高并发与低延迟并存，比如支付场景既要扛住峰值流量，又要保证响应时间在几百毫秒以内。
所以当我们讨论“financial-services”这个主题时，本质上是在讨论如何用工程技术手段去满足金融业务的这些刚性约束。这不是一个纯技术炫技的领域，而是一个技术必须服务于业务规则、服务于合规底线的领域。我见过太多团队在这个方向上踩坑，不是因为技术能力不够，而是因为对金融业务的理解不够深，把普通互联网业务的那套做法直接搬过来，结果在一致性、审计、对账这些环节上出问题。
这篇文章适合谁看？如果你是后端工程师、架构师，正在接触或准备接触金融相关的系统开发，那这篇内容会帮你建立起对金融服务技术全景的基本认知。如果你是产品经理或者技术管理者，需要理解金融系统的技术边界和成本结构，那这篇也能给你一些决策参考。如果你只是对这个领域好奇，想了解“金融级别的系统”到底和普通系统有什么区别，那我会尽量用生活化的类比把关键概念讲清楚。
接下来我会从几个维度展开：先讲清楚金融服务系统的核心分层和每一层的职责，然后深入几个关键技术点——包括交易一致性怎么保证、数据模型怎么设计、安全与合规怎么落地，最后分享一些我在实际项目中踩过的坑和总结出来的经验。整个内容会围绕“financial-services”这个领域标识展开，不会跑偏到具体的某个产品或者某个公司。
2. 金融服务系统的分层逻辑与每一层的真实职责
2.1 为什么金融服务系统一定要分层
很多人做普通业务系统的时候，分层意识是模糊的，controller里直接写业务逻辑，业务逻辑里直接调数据库，数据库里直接存所有字段，跑得也挺好。但到了金融服务领域，这种写法会带来灾难性的后果。原因很简单：金融业务的规则复杂度高、变更频率高、合规要求严，如果业务逻辑和数据存储耦合在一起，任何一个小规则的调整都可能引发连锁反应，而且很难做审计和追溯。
分层本质上是一种关注点分离的手段。在金融服务系统里，我习惯把它分成四层：接入层、业务服务层、领域服务层、数据层。每一层的职责边界必须清晰，跨层调用要有明确的规范。接入层负责协议转换、鉴权、限流、日志埋点，它不应该包含任何业务规则；业务服务层负责编排领域服务，完成一个完整的业务用例，比如“转账”这个用例可能涉及账户校验、余额检查、风控评估、记账、通知等多个领域服务；领域服务层负责实现具体的业务规则，比如利息计算、手续费计算、额度控制；数据层负责持久化，包括关系型数据库、缓存、消息队列等。
这个分层看起来和普通DDD的分层差不多，但金融场景下有几个特殊要求。第一，领域服务必须是无状态的，因为金融交易可能涉及重试和幂等，有状态的服务很难保证一致性。第二，数据层必须支持事务，而且事务的隔离级别要仔细选择，不能随便用读未提交。第三，接入层必须做幂等控制，因为网络抖动、客户端重试在金融场景下是常态，没有幂等控制就会导致重复扣款或重复入账。
2.2 接入层：不只是网关那么简单
在普通业务里，接入层通常就是一个API网关，做做路由转发和鉴权就完了。但在金融服务系统里，接入层承担的责任要重得多。我总结下来，接入层至少要干这几件事：身份认证、权限校验、请求签名验证、幂等键提取、流量控制、敏感信息脱敏、审计日志记录。
身份认证和权限校验不用多说，金融系统里通常采用多因素认证，而且权限模型要比RBAC更细粒度，可能需要到字段级别。请求签名验证是为了防止请求被篡改，客户端和服务端共享一个密钥，对请求参数按约定规则排序后计算签名，服务端收到请求后重新计算签名并比对。这个机制在开放银行、支付网关这类场景里是标配。
幂等键提取是金融接入层的一个特色。客户端在发起一笔支付或转账时，必须带上一个全局唯一的幂等键，服务端在处理请求前先检查这个键是否已经处理过，如果处理过就直接返回上次的结果，不再重复执行。这个机制是防止重复扣款的第一道防线。我见过有团队把幂等控制放在业务层做，结果因为业务层有多个入口，漏掉了一些路径，导致重复交易。放在接入层统一处理，虽然牺牲了一点灵活性，但安全性大大提升。
流量控制也很关键。金融系统经常面临突发流量，比如理财产品开售、红包活动、账单日集中还款。接入层需要根据业务类型做差异化限流，比如查询类接口可以放宽，交易类接口必须严格限制。而且限流策略要能动态调整，不能硬编码在配置文件里，因为业务峰值是不可预测的。
2.3 业务服务层：编排的艺术
业务服务层是金融系统里最“薄”的一层，但也是最考验设计能力的一层。它的核心职责是编排——把多个领域服务组合起来，完成一个完整的业务用例。比如“用户发起一笔转账”这个用例，业务服务层需要依次调用：账户服务校验转出账户状态、账户服务校验转入账户状态、风控服务评估交易风险、账务服务执行扣款、账务服务执行入账、通知服务发送短信或推送。
这里的关键问题是：这些步骤哪些必须同步执行，哪些可以异步执行？我的经验是，涉及资金变动的步骤必须同步执行，而且要在同一个事务里；涉及通知、积分、优惠券这些附加动作的，可以异步执行，通过消息队列解耦。但异步执行会带来一个新问题：如果主交易成功了，但异步通知失败了怎么办？这就需要引入本地消息表或者事务消息机制，保证异步动作最终一定会被执行。
另一个关键问题是编排逻辑放在哪里。有些团队喜欢用工作流引擎来编排，比如用状态机或者BPMN。这在业务流程复杂且经常变化的场景下是合理的，比如贷款审批流程。但对于支付、转账这种标准化程度高、性能要求高的场景，我倾向于用代码编排，因为工作流引擎的额外开销和复杂度可能得不偿失。代码编排虽然看起来“土”，但性能好、可控性强、调试方便。
2.4 领域服务层：业务规则的唯一权威
领域服务层是金融系统里最“厚”的一层，所有业务规则都应该在这里实现。账户的余额计算、利息计算、手续费计算、额度控制、风控规则，全部属于领域服务层的职责。这一层的设计原则是：高内聚、低耦合、可测试。
高内聚意味着一个领域服务只负责一个明确的业务能力。比如“账户服务”负责账户的创建、查询、状态变更、余额变动；“计息服务”负责利息的计算和计提；“风控服务”负责交易风险的评估。不要让一个服务承担多个不相关的职责，否则后续维护会非常痛苦。
低耦合意味着领域服务之间尽量不直接依赖，而是通过领域事件或者接口契约来交互。比如账务服务完成扣款后，发布一个“扣款成功”事件，通知服务订阅这个事件并发送通知。这样账务服务不需要知道通知服务的存在，通知服务的变更也不会影响账务服务。
可测试意味着领域服务的业务规则必须能够被单元测试覆盖。金融业务的规则往往很复杂，比如利息计算可能涉及分段计息、复利、提前还款罚息等多种情况。如果没有完善的单元测试，任何一次代码变更都可能引入计算错误，而计算错误在金融场景下是致命的。
2.5 数据层：一致性最后的守门人
数据层是金融系统的最后一道防线。无论上面的逻辑写得多漂亮，如果数据层出了问题，整个系统就崩了。金融数据层的几个核心要求是：事务支持、高可用、可扩展、可审计。
事务支持是基础。金融交易必须保证ACID，尤其是原子性和一致性。关系型数据库在这方面有天然优势，所以大多数金融系统的核心交易数据仍然存在关系型数据库里。虽然NoSQL在某些场景下性能更好，但在涉及资金变动的核心链路上，我强烈建议用关系型数据库。
高可用意味着数据库不能有单点。主从复制、多副本、自动故障切换是标配。但金融场景下还要考虑数据一致性和故障切换时的数据丢失风险。比如主库宕机时，如果从库还没有同步完最新的交易数据，切换到从库就会导致数据丢失。所以金融系统通常要求强同步复制，即主库在提交事务前必须等待至少一个从库确认收到数据。这会增加写入延迟，但换来的是数据安全。
可扩展意味着数据库要能水平扩展。分库分表是常见手段，但金融场景下的分库分表要特别小心，因为跨库事务很难处理。我的经验是，尽量按照业务维度分库，比如账户库、交易库、账务库分开，这样跨库事务的概率会大大降低。如果确实需要跨库事务，可以考虑用分布式事务框架，但分布式事务的性能和复杂度都是挑战，能避免就避免。
可审计意味着所有数据变更都要有记录。金融系统通常采用双写策略：在更新业务数据的同时，写入一条审计日志。审计日志包含操作时间、操作人、操作类型、变更前后的值。这些日志通常写入独立的审计库或者日志系统，保留期限根据合规要求确定，一般是5年以上。
3. 交易一致性：金融系统最核心的技术挑战
3.1 为什么一致性在金融场景下如此棘手
一致性这个问题在普通业务里也存在，但通常不是最优先考虑的问题。比如电商下单，库存扣减和订单创建之间短暂的不一致是可以容忍的，大不了后续对账修复。但在金融场景下，一致性是红线，不能有任何妥协。一笔转账要么双方账户都变动，要么都不变动，不能出现A扣了钱B没收到的情况。
这个要求看起来简单，实现起来却非常棘手，因为金融系统通常是分布式的。分布式系统的CAP理论告诉我们，一致性、可用性、分区容忍性三者不可兼得。金融系统通常选择CP，即保证一致性和分区容忍性，牺牲部分可用性。这意味着在网络分区或者节点故障时，系统可能会暂时不可用，但绝不会返回不一致的数据。
但即使选择了CP，实现强一致性仍然有很多坑。比如网络超时问题：客户端发起一笔转账请求，服务端处理成功了，但响应在返回途中丢失了，客户端认为请求失败并重试。如果没有幂等控制，就会导致重复转账。再比如数据库主从延迟问题：主库写入成功后，从库还没有同步，此时读请求打到从库，读到的还是旧数据。在金融场景下，这种“读旧数据”可能导致严重的业务问题，比如用户看到余额还是旧的，又发起了一笔支付，导致透支。
3.2 本地事务与分布式事务的取舍
在单体应用时代，一致性靠数据库的本地事务就能解决。一个转账操作，在同一个数据库事务里完成扣款和入账，要么都成功，要么都回滚。简单、可靠、性能好。但到了微服务时代，账户服务和账务服务可能是两个独立的服务，各自有独立的数据库，本地事务就不够用了。
这时候就需要分布式事务。分布式事务的方案有很多，我按自己的使用经验排个序：TCC > 本地消息表 > 事务消息 > 最大努力通知 > 两阶段提交。这个排序综合考虑了可靠性、性能、实现复杂度。
TCC（Try-Confirm-Cancel）是我最推荐的方案。它的思路是：每个参与方都实现三个方法，Try阶段做资源预留，Confirm阶段做确认提交，Cancel阶段做回滚。以转账为例，Try阶段先冻结转出方的资金，Confirm阶段实际扣减冻结资金并给转入方入账，Cancel阶段解冻资金。TCC的优点是可靠性高、性能好，因为不需要长时间持有数据库锁。缺点是业务侵入性强，每个参与方都要实现三个方法，而且要考虑空回滚、幂等、悬挂等异常情况。
本地消息表是我在中小规模系统里常用的方案。它的思路是：在本地事务里同时更新业务数据和写入一条消息记录，然后通过定时任务或者异步线程把消息发送到消息队列，下游消费消息并执行相应操作。这个方案的优点是实现简单、不依赖特殊的中间件。缺点是消息表可能成为瓶颈，而且需要处理消息重复消费的问题。
事务消息是消息队列提供的一种特性，比如RocketMQ就支持事务消息。它的思路是：生产者先发送半消息，然后执行本地事务，根据本地事务的结果决定提交或回滚半消息。这个方案比本地消息表更优雅，但依赖特定的消息队列，而且事务消息的实现原理决定了它只能保证最终一致性，不能保证强一致性。
两阶段提交是最传统的分布式事务方案，但它的性能和可靠性都不太适合高并发的金融场景。两阶段提交需要协调者，协调者本身可能成为单点；而且在第二阶段，所有参与方都要锁定资源，并发度很低。所以我在实际项目中很少用两阶段提交，除非是极少数对一致性要求极高、并发量很低的场景。
3.3 幂等设计：防止重复交易的第一道防线
幂等这个词在普通业务里可能只是“锦上添花”，但在金融场景里是“雪中送炭”。没有幂等设计，任何网络抖动、客户端重试、消息重复消费都可能导致重复交易。我见过一个真实的案例：某支付系统因为没有做幂等控制，在一次网络抖动中，同一个用户的同一笔支付请求被重复处理了三次，用户被扣了三倍的钱，最后只能人工退款并赔偿。
幂等设计的核心是唯一标识 + 状态机。每一笔交易都有一个全局唯一的业务流水号，服务端在处理请求前先检查这个流水号是否已经处理过。如果处理过，直接返回上次的处理结果；如果没有处理过，则执行处理逻辑，并记录处理状态。
但这里有几个细节需要注意。第一，幂等键的生成规则要统一，不能有的地方用UUID，有的地方用时间戳+用户ID。第二，幂等记录的存储要可靠，不能存在本地缓存里，因为服务重启后缓存就丢了。通常存在数据库或者Redis里，而且要设置合理的过期时间，太短可能导致重复交易，太长会占用存储空间。第三，并发情况下的幂等控制要考虑，两个相同的请求同时到达，如果只是简单的“查一下有没有处理过”，可能会两个都查不到然后都执行。这时候需要用数据库的唯一索引或者分布式锁来保证只有一个请求能执行成功。
3.4 对账：一致性最后的兜底手段
无论前面的设计多完善，线上系统总会出现各种意外情况：消息丢失、服务宕机、数据库故障、代码bug。所以金融系统必须有一套对账机制作为最后的兜底。对账的思路很简单：每天定时把系统内部的交易记录和外部渠道（比如银行、支付网关）的交易记录进行比对，找出不一致的记录，然后人工或者自动修复。
对账听起来简单，做起来有很多细节。第一，对账的粒度要合理，通常按笔对账，但有些场景可能需要按金额汇总对账。第二，对账的时效要明确，是准实时对账还是T+1对账。准实时对账能更快发现问题，但对系统压力更大。第三，差异处理流程要清晰，发现差异后谁来处理、怎么处理、多久处理完，都要有明确的规范。
我在实际项目里总结了一个经验：对账系统要独立于交易系统。不要把对账逻辑写在交易服务里，因为交易服务出问题时，对账服务可能也受影响。对账系统应该有自己的数据源、自己的计算逻辑、自己的告警机制。这样即使交易系统出了严重故障，对账系统仍然能正常工作，帮助快速定位问题。
4. 金融数据模型的设计要点与常见误区
4.1 账户模型：不只是余额那么简单
很多人以为账户模型就是“用户ID + 余额”两个字段，这种理解在金融场景下是远远不够的。一个完整的账户模型至少包含这几类信息：账户基本信息、余额信息、状态信息、权限信息、关联信息。
账户基本信息包括账户ID、用户ID、账户类型（储蓄账户、信用账户、投资账户等）、开户时间、币种。余额信息包括可用余额、冻结余额、在途余额、总余额。这里的关键是余额不能只有一个字段，因为金融场景下资金的状态是多样的。比如用户发起一笔提现，资金先从可用余额转到冻结余额，等提现成功后再从冻结余额扣减。如果只有一个余额字段，就无法区分“可用”和“冻结”这两种状态。
状态信息包括账户状态（正常、冻结、销户）、风险等级、实名认证状态。权限信息包括账户的操作权限，比如是否允许转账、是否允许提现、单笔限额、日累计限额。关联信息包括账户绑定的银行卡、绑定的手机号、关联的子账户等。
我见过一个常见的误区：把余额直接存在账户表里，然后用一个字段记录所有变动。这种做法在简单场景下能用，但一旦业务复杂起来就会出问题。比如要查某个时间点的余额，或者要统计某段时间的收支，单靠一个余额字段是做不到的。正确的做法是余额和流水分开存储，余额表记录当前状态，流水表记录每一次变动。余额可以通过流水累加计算出来，但为了提高查询性能，通常会冗余一个余额字段，并通过事务保证两者一致。
4.2 交易模型：状态机是核心
交易模型的核心是状态机。一笔交易从创建到完成，会经历多个状态：待支付、支付中、支付成功、支付失败、已退款、部分退款等。每个状态之间的流转都有明确的触发条件和业务规则。比如“待支付”只能流转到“支付中”或“已取消”，“支付中”只能流转到“支付成功”或“支付失败”。
设计交易状态机时，有几个要点。第一，状态不能太多，太多会导致流转逻辑复杂，容易出错。第二，状态流转必须单向，不能出现A→B→A这种循环，否则会导致数据不一致。第三，每次状态变更都要记录，包括变更时间、变更原因、操作人。这些记录在后续的对账、审计、客服查询中都会用到。
交易模型还需要考虑交易类型的区分。转账、支付、退款、充值、提现，这些交易类型的业务规则不同，但底层的数据结构可以复用。我的做法是设计一个通用的交易表，包含交易ID、交易类型、交易金额、交易状态、发起方、接收方、创建时间、完成时间等字段，然后针对不同类型的交易，在业务层做差异化的处理。
4.3 流水模型：不可变与可追溯
流水模型是金融数据模型里最容易被忽视但最重要的部分。流水记录的是资金的每一次变动，它必须是不可变的——一旦写入就不能修改，只能追加。为什么？因为流水是审计的依据，如果流水可以被修改，审计就失去了意义。
流水模型的设计要点包括：每条流水都有一个全局唯一的流水号；流水记录关联的交易ID；流水记录变动前的余额和变动后的余额；流水记录变动类型（扣款、入账、冻结、解冻）；流水记录变动时间；流水记录操作来源（用户操作、系统自动、人工干预）。
我特别想强调变动前余额和变动后余额这两个字段。很多团队在设计流水表时只记录变动金额，不记录变动前后的余额。这在平时没问题，但一旦出现对账差异，没有这两个字段就很难定位问题。比如系统显示余额是100，但流水累加结果是90，到底哪个环节出了问题？如果有变动前后余额，就可以逐笔核对，快速定位到出问题的那一笔。
4.4 数据模型的反模式与修正
在金融数据模型设计里，有几个常见的反模式，我踩过坑，也见过别人踩坑。
第一个反模式是用浮点数存储金额。浮点数在计算机里是近似表示，0.1 + 0.2不等于0.3，这在金融场景下是致命的。正确的做法是用整数存储最小货币单位，比如人民币用分存储，美元用美分存储。或者用定点数类型，比如MySQL的DECIMAL。我强烈建议用整数，因为整数的运算没有精度问题，而且性能更好。
第二个反模式是余额字段和流水字段不一致。有些团队为了性能，只更新余额字段，不写流水；或者只写流水，不更新余额。这两种做法都会导致数据不一致。正确的做法是在同一个事务里同时更新余额和写入流水，保证两者要么都成功，要么都失败。
第三个反模式是用时间戳做唯一标识。在高并发场景下，同一毫秒内可能产生多笔交易，时间戳会重复。正确的做法是用分布式ID生成器，比如雪花算法，保证全局唯一且趋势递增。
第四个反模式是软删除业务数据。在普通业务里，软删除很常见，但在金融场景下，业务数据不能删除，只能标记状态。因为删除后审计就断了，而且可能影响历史数据的计算。比如一个账户被销户了，不能直接删除账户记录，而是把状态改为“已销户”，保留所有历史数据。
5. 安全与合规：金融系统绕不开的硬约束
5.1 数据加密：存储、传输、使用三个环节
金融系统的数据加密要覆盖三个环节：存储加密、传输加密、使用加密。存储加密是指敏感数据在数据库里不能明文存储，比如用户身份证号、银行卡号、密码。传输加密是指数据在网络传输过程中要加密，通常用TLS。使用加密是指数据在内存中使用时也要注意保护，比如密码不能明文比较，要用哈希加盐。
存储加密我通常分两类处理：可逆加密和不可逆加密。可逆加密用于需要还原原始数据的场景，比如银行卡号需要展示给用户看，但又不能明文存储。这时候用AES等对称加密算法，密钥存在独立的密钥管理服务里。不可逆加密用于不需要还原原始数据的场景，比如密码，用bcrypt或者argon2做哈希，加盐存储。
这里有个细节容易被忽略：加密密钥的管理。很多团队把密钥写在配置文件里，或者硬编码在代码里，这是非常危险的。密钥应该存在独立的密钥管理服务里，有独立的访问控制和轮换机制。而且密钥要有版本，因为密钥轮换后，旧数据还需要用旧密钥解密。
5.2 权限控制：从RBAC到ABAC
普通的权限控制用RBAC就够了，用户关联角色，角色关联权限。但在金融场景下，RBAC往往不够用，因为金融业务的权限维度更多。比如一个客服人员，可以查看用户的账户信息，但不能查看用户的完整银行卡号；可以发起小额退款，但不能发起大额退款；可以在工作时间操作，但不能在非工作时间操作。这些细粒度的控制，RBAC表达起来很吃力。
这时候就需要ABAC（基于属性的访问控制）。ABAC的思路是：权限判断基于一组属性，包括用户属性、资源属性、环境属性、操作属性。比如“允许客服在工作时间对金额小于1000元的交易发起退款”这条规则，用ABAC表达就很自然。
ABAC的优点是灵活、表达能力强，缺点是规则多了之后管理复杂，而且性能可能成为问题。我的经验是RBAC和ABAC结合使用：粗粒度的权限用RBAC，细粒度的、动态的权限用ABAC。而且ABAC的规则要尽量简化，不要搞得太复杂，否则维护成本很高。
5.3 审计日志：不只是记录，还要能追溯
审计日志在金融系统里是合规的硬性要求。但很多团队的审计日志只是简单记录“谁在什么时候做了什么”，这种日志在出问题时根本不够用。一个合格的审计日志应该包含：操作时间、操作人、操作类型、操作对象、操作前的值、操作后的值、操作结果、操作来源IP、操作设备信息。
审计日志的存储也有讲究。第一，审计日志不能和业务数据存在同一个数据库里，因为业务数据库可能被误操作或者被攻击，审计日志要独立存储。第二，审计日志要防篡改，通常用只追加的方式写入，不允许修改和删除。第三，审计日志要能快速检索，因为出问题时需要快速定位相关记录，所以要有合理的索引设计。
我见过一个坑：审计日志记录了大量信息，但没有建立有效的索引，结果查询一次审计日志要几分钟，根本没法用于实时排查问题。所以审计日志的索引设计要和查询场景匹配，比如按操作时间、操作人、操作对象建立组合索引。
5.4 合规要求对技术方案的实际影响
合规要求听起来很虚，但它对技术方案的影响是非常具体的。比如数据留存期限要求交易记录至少保留5年，这意味着你的数据库设计要考虑5年的数据量，分库分表策略要能支撑5年的增长。比如数据可携带权要求用户能导出自己的所有数据，这意味着你的数据模型要能方便地按用户维度聚合数据。比如交易可追溯要求每一笔交易都能追溯到发起方和接收方，这意味着你的流水设计要完整记录交易链路。
我在实际项目里的经验是：在系统设计初期就把合规要求考虑进去，而不是等系统上线了再补。因为合规相关的改动往往涉及数据模型、存储方案、接口设计，后期补的成本非常高。比如数据留存期限要求，如果初期没考虑，后期数据量大了再分库分表，迁移成本极高。
6. 我在金融服务项目里踩过的坑与总结的经验
6.1 坑一：低估了幂等设计的复杂度
我早期做支付系统的时候，觉得幂等很简单：请求带个唯一ID，服务端查一下有没有处理过就行了。结果上线后遇到了并发问题：两个相同的请求同时到达，都查了数据库，都发现没处理过，然后都执行了。用户被扣了两次钱。
后来我重新设计了幂等方案：用数据库的唯一索引来保证并发安全。具体做法是，在处理请求前，先往幂等表里插入一条记录，唯一索引建在幂等键上。如果插入成功，说明是第一次处理，继续执行业务逻辑；如果插入失败（唯一键冲突），说明已经处理过，直接返回上次的结果。这个方案简单可靠，而且不依赖分布式锁。
但这里还有个细节：幂等记录的过期时间。如果幂等记录永久保留，表会越来越大；如果过期时间太短，又可能导致重复交易。我的经验是，根据业务的重试窗口来定，通常设置24小时到7天。对于重试窗口很长的业务，比如银行转账，可能需要保留更久。
6.2 坑二：忽视了数据库主从延迟的影响
有一次做余额查询功能，读请求走从库，写请求走主库。测试环境一切正常，上线后用户投诉说余额不对。排查后发现是主从延迟导致的：用户刚完成一笔充值，主库写入了，但从库还没同步，用户查询余额时读到的是旧数据。
这个问题的解决方案有几个。第一，写后读走主库：对于刚完成写操作的用户，短时间内（比如1秒）的读请求强制走主库。第二，使用半同步复制：主库在提交事务前等待至少一个从库确认收到数据，这样主从延迟会大大降低。第三，在应用层做缓存：写操作完成后，把最新数据写入缓存，读请求优先读缓存。
我最终采用的是组合方案：核心交易链路走半同步复制，同时写后读强制走主库，非核心查询走从库并接受一定的延迟。这个方案在性能和一致性之间取得了平衡。
6.3 坑三：对账系统发现差异后没有闭环
对账系统上线后，每天都能发现一些差异记录，但团队没有建立差异处理流程，差异记录只是躺在报表里，没人处理。结果差异越积越多，最后对账系统形同虚设。
后来我们建立了完整的差异处理闭环：对账系统发现差异后，自动分类（金额差异、状态差异、记录缺失），然后根据分类分配给不同的处理人。处理人必须在规定时间内处理完毕，并记录处理结果。对于无法自动处理的差异，升级到人工处理。每周还要出对账报告，统计差异数量、处理时效、差异原因分布。
这个闭环建立后，差异数量大幅下降，因为很多差异在产生后很快就被发现和处理了，不会积累成大问题。
6.4 坑四：安全加密影响了性能
有一次为了满足安全要求，对数据库里的敏感字段全部做了加密。上线后发现查询性能大幅下降，因为加密后的字段无法走索引，而且每次查询都要解密。
解决方案是分级加密：对于需要精确查询的字段（比如手机号），用确定性加密，即同样的明文加密后得到同样的密文，这样可以走索引；对于不需要精确查询的字段（比如地址），用随机加密，安全性更高但不支持索引查询。另外，对于高频查询的字段，可以在应用层做缓存，减少数据库查询次数。
6.5 一些通用的经验总结
第一，金融系统的设计要以“资金安全”为第一优先级，性能、扩展性、开发效率都要为安全性让路。这不是说性能不重要，而是在做取舍时，安全性的权重最高。
第二，任何涉及资金变动的操作都要有日志，而且日志要包含足够的信息用于追溯。不要觉得日志占空间，出问题时日志就是救命稻草。
第三，对账系统要尽早建设，不要等系统复杂了再补。对账系统不仅能发现数据不一致，还能发现代码bug、消息丢失、服务异常等问题。
第四，测试要覆盖异常场景，比如网络超时、数据库宕机、消息重复、并发冲突。金融系统的bug往往出现在异常场景下，正常场景反而很少出问题。
第五，合规要求要提前了解，不要等监管检查了才发现不合规。合规相关的改动往往涉及数据模型和存储方案，后期改造成本极高。
第六，保持敬畏心。金融系统里的一分钱差错，可能意味着巨大的声誉损失和监管处罚。做这个领域的技术工作，细心、严谨、敬畏规则，比技术能力更重要。
