企业官网建设流程全解析

金融行业的技术选型和架构设计，一直是个容易被过度神秘化的话题。市面上讲“金融级”方案的文章，要么堆砌一堆监管术语让人昏昏欲睡，要么直接甩出一套开源组件清单，却不告诉你为什么这么搭、哪些环节最容易翻车。我在支付和风控系统里摸爬滚打了十来年，从最早的银行核心系统外围改造，到后来帮几家持牌消费金融机构做交易链路重构，踩过的坑比写过的代码还多。这篇内容不打算复述任何官方文档，而是把“financial-services”这个领域里，一个后端或架构方向的从业者真正需要吃透的东西，按我自己的理解重新拆一遍。不管你是刚入行想搞明白金融系统跟普通互联网系统的本质区别，还是已经做了几年CRUD想往核心交易方向转，下面这些从真实项目里抠出来的经验，应该都能让你少走不少弯路。

1. 金融系统跟普通业务系统的分水岭到底在哪

很多人觉得金融系统无非就是多了几个对账接口、加了几把锁、数据库事务用得频繁一点。这个认知偏差，是导致后期架构推倒重来的头号原因。普通互联网系统追求的是高并发下的最终一致性，用户看到点赞数晚几秒更新无所谓；金融系统从第一行代码开始，就必须把“钱不能错”刻进骨子里。这个“不能错”不是靠某个中间件或者某个设计模式就能保证的，它是一整套从数据模型到运维流程的约束体系。

1.1 资金守恒是第一性原理

任何一笔资金变动，在系统里都必须满足“有借必有贷，借贷必相等”。这句话听起来像会计基础课的内容，但在技术实现上，它意味着你不能简单地用一个balance字段去加减。我见过太多从电商转过来的团队，习惯性地设计一张用户余额表，然后直接UPDATE balance = balance - amount。这种写法在秒杀场景下可能没问题，但在金融场景里，一旦出现并发扣款、网络重试、或者程序异常，你根本没办法回溯这笔钱到底是怎么少的。

正确的做法是引入复式记账模型。每一笔交易至少产生两条流水记录，一条借方、一条贷方，金额相等、方向相反。用户余额只是这些流水的一个物化视图，可以通过流水重新计算出来。这样做的好处是，任何时候你发现余额对不上，都可以拿流水去逐笔核对，而不是面对一个孤零零的数字干瞪眼。我在实际项目里会强制要求：任何直接修改余额字段的代码，在代码评审阶段直接打回，没有例外。

1.2 状态机比流程编排更重要

金融业务天然是状态驱动的。一笔支付从创建到最终成功或失败，中间会经历“待支付”“支付中”“已支付”“部分退款”“全额退款”“已关闭”等多个状态。很多团队喜欢用工作流引擎或者一堆if-else来管理这些状态流转，结果就是状态爆炸、边界条件漏判、对账时发现一堆“幽灵订单”。

我的经验是，把每个业务实体的状态机显式定义出来，用一张状态迁移表来约束所有可能的流转路径。比如支付单，只允许从“待支付”到“支付中”，从“支付中”到“已支付”或“支付失败”，其他任何跳转都是非法操作，直接抛异常并记录告警。这张表不一定要用代码生成，但必须写进设计文档，并且有对应的单元测试覆盖每一条边。这样做还有一个隐性好处：当产品经理提出“能不能加一个状态”时，你可以拿着这张表告诉他，加这个状态会影响哪些上下游，而不是拍脑袋就改。

1.3 幂等不是可选项，是生存底线

在金融系统里，任何对外暴露的写接口，都必须支持幂等。用户点两次提交、网络超时后客户端重试、消息队列重复投递，这些在普通系统里可能只是产生两条重复数据，在金融系统里就是两笔真实的资金变动。我处理过的线上事故里，至少有三分之一跟幂等失效有关。

实现幂等有很多种方式，我常用的组合是：全局唯一业务流水号 + 数据库唯一索引 + 状态机校验。业务流水号由调用方生成，服务端拿这个号去查是否已经处理过；如果没处理过，就插入一条流水记录，利用数据库唯一索引兜底并发；如果已经处理过，直接返回上次的处理结果。这里有个细节：返回上次结果时，要确保返回的内容跟第一次完全一致，包括错误码和错误信息，否则调用方可能会因为两次返回不一致而做出错误判断。

2. 交易链路里那些文档不会写的设计取舍

交易链路是金融系统的心脏，也是最容易出性能瓶颈和一致性问题的环节。教科书上会告诉你用TCC、用Saga、用本地消息表，但具体到你的业务场景该选哪个，往往取决于一些很微妙的因素。下面这几组取舍，是我在真实项目里反复权衡过的，每一个都对应着具体的业务约束。

2.1 同步扣减还是异步记账

用户发起一笔支付，你是同步调用账务系统扣钱，还是先写一条待记账消息，异步去扣？这个问题没有标准答案，但有一个判断原则：看你的业务对失败率的容忍度。如果是余额支付，用户就盯着屏幕等结果，同步扣减能立刻告诉他成功还是失败，体验最好，但账务系统的抖动会直接传导到用户端。如果是信用卡还款或者理财申购，用户对几秒钟的延迟不敏感，异步记账能更好地隔离故障，但需要处理“支付成功但记账失败”的中间态。

我一般会做一个折中：核心的余额变动走同步，但同步调用设置一个较短的超时（比如800毫秒），超时后转为异步补偿，同时给用户返回“处理中”。这个“处理中”状态必须有明确的终态收敛机制，不能让它一直挂着。我们当时的设计是，后台有一个定时任务，扫描超过一定时间还处于“处理中”的支付单，主动去账务系统查询实际结果，然后更新状态并通知用户。

2.2 热点账户的锁粒度怎么定

秒杀场景下，一个收款账户可能瞬间收到几万笔入账。如果你用数据库行锁去更新余额，这个账户就是绝对的热点，所有请求都会排队等锁，TPS直接掉到个位数。我试过几种方案，最后比较稳定的是账户分片 + 异步汇总。具体来说，把一个热点账户拆成多个子账户，每笔入账随机或者按用户ID哈希落到某个子账户上，子账户之间独立更新，互不阻塞。然后有一个后台任务定期把子账户的余额汇总到主账户，对外展示和提现都走主账户。

这个方案听起来简单，但有两个坑：一是子账户的余额汇总会有延迟，如果业务要求实时看到总余额，就得在查询时做实时聚合，这又引入了新的性能问题；二是退款或者冲正时，必须能定位到当初入的是哪个子账户，否则就会把某个子账户扣成负数。我们的做法是，在流水表里记录子账户ID，退款时按原路返回，保证每个子账户的余额始终非负。

2.3 对账文件的解析比生成难十倍

跟银行或渠道对账，是每个金融系统都绕不开的环节。生成对账文件相对简单，按约定格式把当天的流水导出来就行。真正麻烦的是解析对方给的对账文件，因为格式千奇百怪，而且经常有“惊喜”。我遇到过用GBK编码但文件头写着UTF-8的，遇到过金额字段带千分位逗号的，遇到过日期格式是“20240101”但偶尔冒出“2024-01-01”的，还遇到过文件末尾有几十行空行导致解析器报错的。

我的经验是，对账文件的解析一定要做成可配置的模板，把分隔符、编码、日期格式、金额格式都抽成配置项，而不是硬编码在代码里。同时，解析过程要分两步：先做结构校验，确认行数、列数、文件头尾符合预期；再做内容校验，逐行检查金额、日期、订单号是否合法。任何一步失败，都要把原始文件存档并告警，绝对不能静默跳过。我们当时还做了一个“对账差异池”，把解析出来的每一笔跟本地流水做比对，不一致的丢进差异池，由人工介入处理，而不是自动去调账。自动调账听起来很美好，但一旦逻辑有bug，就是灾难性的资金损失。

3. 数据一致性：从理论到落地的最后一公里

分布式事务是金融系统里被讨论最多、也最容易踩坑的话题。CAP理论、BASE理论大家都懂，但具体到代码层面，怎么保证“支付成功”和“订单状态更新”这两个操作要么都成功要么都失败，很多人就懵了。我下面讲的不是理论，而是我在生产环境里验证过的几种落地方式，以及它们各自的适用边界。

3.1 本地消息表：最土但最可靠

本地消息表是我用得最多、也最放心的方案。核心思路很简单：在业务数据库里建一张消息表，跟业务操作在同一个本地事务里写入。比如支付成功后，在同一个事务里更新支付单状态为“已支付”，同时往消息表里插入一条“通知订单系统更新状态”的记录。然后有一个独立的线程或者定时任务，不断扫描消息表，把未发送的消息投递到消息队列，投递成功后更新消息状态为“已发送”。

这个方案的好处是，它把分布式事务转化成了本地事务加异步重试，实现简单，不依赖任何特殊的中间件。坏处是消息表会随着业务量增长而膨胀，需要定期归档。我一般会按天分表，并且只保留最近7天的消息在热表里，更早的归档到冷存储。另外，消息的投递必须保证至少一次，消费端必须做幂等，这两点缺一不可。

3.2 TCC的坑主要在补偿逻辑

TCC（Try-Confirm-Cancel）听起来很优雅，Try阶段预留资源，Confirm阶段确认，Cancel阶段释放。但在实际项目里，Cancel逻辑往往比Try逻辑复杂得多。比如Try阶段冻结了用户100块钱，Cancel阶段要解冻，但如果这时候用户账户已经被销户了怎么办？如果冻结的钱已经被其他业务部分扣减了怎么办？这些边界情况在业务简单的时候不会暴露，一旦业务复杂起来，Cancel逻辑就会变成一团乱麻。

我的建议是，如果团队没有足够的经验，不要轻易上TCC。如果一定要用，把Cancel逻辑当成一个独立的业务场景来设计，给它写完整的测试用例，并且确保Cancel操作本身也是幂等的。另外，TCC的事务协调器一定要高可用，否则协调器挂了，所有处于中间态的业务都会卡住。

3.3 对账是最后一道防线

不管前面的一致性方案做得多好，对账都是必须的。我甚至认为，对账系统的重要性不亚于交易系统本身。因为交易系统再严谨，也可能因为代码bug、网络分区、人为误操作等原因产生数据不一致，而对账是唯一能发现这些不一致的手段。

对账系统的设计要点有三个：全覆盖、可追溯、能闭环。全覆盖是指所有涉及资金变动的业务都要纳入对账范围，不能有遗漏；可追溯是指每一笔差异都能定位到具体的交易流水和操作日志；能闭环是指差异处理完之后，要有机制确认差异确实被消除了，而不是被标记为“已处理”就完事。我们当时的做法是，每天对账结束后，生成一份差异报告，差异处理完之后，第二天再对一次，直到连续三天没有新的差异，才算这个差异真正闭环。

4. 安全与合规：技术人必须知道的边界

金融行业的安全合规要求，跟普通互联网公司完全不是一个量级。很多技术同学觉得合规是法务和风控的事，自己只管写代码就行。这个想法很危险，因为很多合规要求最终都要落到技术实现上，如果你在设计阶段没有考虑，后期改造的成本会高得吓人。

4.1 敏感数据的加密与脱敏

用户的身份证号、银行卡号、手机号，这些都属于敏感数据。监管要求是“存储加密、传输加密、使用脱敏”。存储加密不是简单地把字段用AES加密就完事，还要考虑密钥管理、加密后的查询问题。比如你加密了银行卡号，那用户用银行卡号来查询交易记录时，你怎么查？我的做法是，额外存一个银行卡号的哈希值（加盐），查询时用哈希值去匹配，这样既能保证安全，又不影响查询性能。

脱敏则是在展示和日志环节必须做的。我见过有团队在日志里直接把用户的完整银行卡号打出来，这是绝对不允许的。我们的规范是，所有日志输出必须经过一个统一的脱敏工具类，银行卡号只显示后四位，身份证号只显示前六后四，手机号中间四位用星号代替。这个工具类在代码评审时是重点检查对象，任何人绕过它直接打印敏感字段，都会被记录并通报。

4.2 交易限额与风控规则的落地

监管对不同类型的账户、不同的交易场景都有明确的限额要求。比如一类户和二类户的日累计限额不同，消费和转账的限额也不同。这些规则不能硬编码在业务代码里，因为监管政策会变，硬编码意味着每次调整都要发版。我的做法是，把限额规则抽成一个独立的配置服务，支持按账户类型、交易类型、渠道等维度灵活配置，业务代码在交易前调用这个服务做校验。

风控规则的落地也是类似。风控系统通常会返回一个决策结果，比如“通过”“拒绝”“人工审核”。业务系统拿到这个结果后，不能简单地if-else处理，而是要记录完整的决策上下文，包括命中了哪些规则、规则的版本号是什么。这样做一方面是为了事后审计，另一方面也是为了在出现误判时能快速定位和修复。

4.3 审计日志的不可篡改性

金融系统里的关键操作，比如修改用户信息、调整限额、手工调账，都必须有审计日志。审计日志的核心要求是不可篡改，也就是说，写进去之后就不能被修改或删除。技术上实现不可篡改有很多种方式，最简单的是把审计日志写到单独的数据库，并且只授予INSERT权限，不授予UPDATE和DELETE权限。更严格的做法是，每条日志都计算一个哈希值，并且把前一条日志的哈希值也包含进来，形成链式结构，这样任何一条日志被修改，后续所有日志的哈希都会对不上。

我在项目里一般会采用链式哈希的方案，虽然实现起来稍微麻烦一点，但能给审计和合规团队一个明确的交代。而且这个方案有一个额外的好处：当有人质疑某条日志的真实性时，你可以通过重新计算哈希来证明它没有被篡改。

5. 从单体到分布式：演进过程中的真实教训

很多金融系统一开始都是单体架构，随着业务量增长，逐步拆分成微服务。这个演进过程听起来很自然，但实际操作中充满了陷阱。我经历过两次比较大的架构演进，一次是从单体拆到微服务，一次是从微服务进一步拆到单元化，每次都有血泪教训。

5.1 拆服务的时机比怎么拆更重要

什么时候该拆服务？我的判断标准是：当团队规模超过两个披萨能喂饱的人数，或者当某个模块的发布频率明显高于其他模块时。如果团队只有五六个人，业务量也不大，强行拆成十几个微服务，只会让运维复杂度和沟通成本急剧上升，收益却微乎其微。

我第一次拆服务的时候，犯了一个典型错误：按技术分层来拆，把DAO层拆成一个服务，Service层拆成一个服务。结果就是，一个简单的查询请求要在两个服务之间来回调用，网络开销比本地调用大了几十倍，性能反而下降了。后来我改成按业务领域来拆，把支付、账务、用户、风控各自独立成服务，每个服务内部包含完整的从接口到存储的逻辑，性能才恢复正常。

5.2 分布式事务的代价被严重低估了

拆成微服务之后，原本一个本地事务能搞定的事情，现在变成了跨服务调用。为了保证一致性，你不得不引入分布式事务方案，而每一种方案都有性能损耗和复杂度成本。我粗略估算过，同样一笔支付操作，单体架构下平均耗时20毫秒，拆成微服务加上分布式事务之后，平均耗时涨到了80毫秒，翻了四倍。

这个代价在业务量小的时候可以接受，但当TPS上千之后，80毫秒的延迟就意味着需要更多的机器来支撑同样的吞吐量。所以我的建议是，能不分库分表的就不分，能不拆服务的就不拆。如果一定要拆，尽量把强一致性的操作放在同一个服务内，跨服务的操作尽量设计成最终一致。

5.3 单元化不是银弹

单元化架构（也叫“多活”或“异地多活”）在金融行业被炒得很热，好像不做单元化就落伍了。但单元化的复杂度极高，它要求你的业务能够按照某个维度（比如用户ID）进行分片，每个分片独立处理交易，并且分片之间的数据同步要保证最终一致。我参与过一个单元化项目，光是数据同步的延迟和冲突处理就折腾了大半年。

我的看法是，除非你的业务确实有异地多活的刚性需求（比如监管要求或者业务连续性要求），否则不要轻易上单元化。对于大多数金融系统来说，同城双活加上完善的备份恢复机制，已经能满足绝大部分的可用性要求。把单元化的精力省下来，投入到对账系统和监控告警的建设上，ROI会高得多。

6. 监控与应急：半夜被叫醒时你该看什么

金融系统的监控跟普通系统有一个本质区别：普通系统挂了，用户刷新一下可能就好了；金融系统挂了，每一秒都在产生资金损失和合规风险。所以监控的覆盖面和告警的准确率，直接决定了你半夜被叫醒的频率和解决问题的速度。

6.1 业务监控比技术监控更重要

技术监控告诉你CPU使用率、内存占用、GC次数，这些当然重要，但它们不能告诉你“用户支付成功率下降了5%”。业务监控才是金融系统监控的核心。我通常会定义几个核心业务指标：支付成功率、平均支付耗时、对账差异率、账务系统TPS。这些指标一旦偏离基线，立刻告警，而不是等到技术指标也出问题才反应过来。

业务监控的难点在于数据采集。很多业务指标需要从日志或者数据库中实时计算，对系统的侵入性比较大。我的做法是，在关键业务节点埋点，把事件异步发送到监控系统，由监控系统做聚合和告警。埋点本身要尽量轻量，不能因为埋点影响了主流程的性能。

6.2 告警风暴的治理

金融系统的告警一旦爆发，往往是铺天盖地的。一个数据库主库挂了，可能瞬间触发几百条告警，手机被打爆，反而让你无法快速定位根因。我吃过这个亏之后，下决心做告警收敛。具体做法是：按业务域分组，设置告警抑制规则，同一业务域内，如果已经有一条高级别告警，低级别告警自动静默。同时，告警信息里要包含足够的上下文，比如影响的业务范围、最近的变更记录、相关的日志链接，让你不用登录服务器就能初步判断问题。

另外，告警的阈值设置也是一门学问。设得太松，问题发生了不告警；设得太紧，天天被误报骚扰，久而久之就麻木了。我的经验是，先用一周的时间观察指标的正常波动范围，取P99值作为告警阈值，然后根据实际告警情况每周调整一次，直到误报率降到可接受的水平。

6.3 应急预案要演练，不能只写在文档里

每个金融系统都应该有应急预案，但很多团队的应急预案只是写在Confluence里，从来没演练过。真出问题的时候，手忙脚乱地翻文档，发现文档里的步骤跟实际情况对不上，或者需要权限的人联系不上。我坚持的做法是，每季度至少做一次故障演练，随机选一个场景，比如“账务系统主库不可用”，然后让值班同学按照预案实际操作一遍。演练过程中发现的问题，比任何文档评审都有效。

演练还有一个隐性好处：它能帮你发现哪些环节过度依赖某个人。如果某个操作只有张三会做，那这就是一个单点风险，必须通过文档化、自动化或者交叉培训来消除。金融系统对连续性的要求极高，任何单点都是不能接受的。

7. 团队协作与代码规范：那些影响资金安全的小事

技术架构再完美，最终还是要靠人来落地。我在金融团队里带过不少人，发现很多资金安全问题不是出在架构设计上，而是出在一些看似不起眼的编码习惯和协作流程上。

7.1 金额类型的选择

这是一个老生常谈的问题，但我还是要说：金融系统里绝对不能用float或double来表示金额。浮点数有精度问题，0.1 + 0.2不等于0.3，这在普通系统里可能只是显示上的小瑕疵，在金融系统里就是实实在在的资金差错。正确的做法是用整数表示最小货币单位（比如分），或者用BigDecimal（Java）这样的高精度类型。用整数的时候要注意溢出问题，用BigDecimal的时候要注意不要用equals比较，而是用compareTo。

我见过一个团队用double存金额，上线三个月后对账发现少了十几块钱，查了两天才定位到是浮点数精度累积误差导致的。虽然金额不大，但性质很严重，因为这意味着系统的资金计算是不可信的。

7.2 数据库字段的默认值和空值处理

金融系统的数据库表，金额字段、状态字段、时间字段，都应该有明确的默认值和非空约束。我见过有表设计允许金额字段为NULL，结果代码里到处都要判空，一旦漏判就是空指针异常。更危险的是，有些ORM框架会把NULL自动转成0，导致一笔本该失败的交易被当成0元处理，直接放行。

我的规范是：金额字段默认0，状态字段默认一个明确的初始状态，时间字段默认当前时间。所有字段尽量设置NOT NULL约束，如果业务上确实允许为空，也要在代码里显式处理，不能依赖框架的默认行为。

7.3 代码评审的重点检查项

金融团队的代码评审，不能只看代码风格和逻辑正确性，还要重点检查几个跟资金安全直接相关的点。我整理了一个检查清单，每次评审必看：

• 涉及资金变动的操作，是否在同一个事务内完成了流水记录和余额更新？
• 对外接口是否实现了幂等？幂等键的选择是否合理？
• 金额计算是否使用了正确的数据类型？有没有精度丢失的风险？
• 异常处理是否完整？有没有吞掉异常导致状态不一致的情况？
• 日志输出是否包含敏感信息？脱敏是否到位？
• 状态流转是否符合状态机定义？有没有非法跳转的可能？

这个清单看起来简单，但坚持执行下来，能拦住绝大部分低级但致命的错误。我带的团队里，新同学入职第一周就要背熟这个清单，并且在每次提交代码前自查一遍。

7.4 发布流程的卡点

金融系统的发布，绝对不能像互联网公司那样随时上线。我的要求是：任何涉及资金链路的变更，必须经过测试环境完整回归、预发布环境验证、并且有回滚方案。回滚方案不是一句“回滚到上一个版本”就完事，而是要明确回滚后数据怎么处理。比如你上线了一个新的计费逻辑，跑了半天发现算错了，这时候回滚代码只能让新交易恢复正常，但已经算错的交易怎么办？必须有对应的数据修复脚本，并且这个脚本也要经过测试。

另外，发布窗口也要有约束。我们当时的规定是，资金链路的变更只能在周二到周四的上午发布，周五和节假日前后不允许发布。这个规定看起来有点死板，但它避免了很多“周五上线出问题，周末全员加班”的惨剧。

8. 一些容易被忽略但很要命的细节

最后这部分，我想聊几个在文档和教程里很少被提及，但在实际项目中一旦忽略就会出大问题的细节。这些细节往往不涉及复杂的架构，但需要你对业务有足够深的理解。

8.1 时区问题

金融系统里，时间就是金钱，这句话是字面意思。一笔交易的创建时间、支付时间、记账时间，如果因为时区问题差了几个小时，对账的时候就会对不上。我的做法是，所有服务器统一使用UTC时间，数据库存储也统一用UTC，只在展示层根据用户时区做转换。同时，所有跟时间相关的字段，都要明确标注是UTC还是本地时间，避免混淆。

还有一个容易被忽略的点：夏令时。有些国家有夏令时，每年会调整两次时间。如果你的系统要支持这些国家的业务，就必须考虑夏令时切换时，那些跨越切换点的交易怎么处理。我遇到过一笔交易，创建时间在夏令时切换前，支付时间在切换后，结果系统算出来的持有时间少了整整一个小时，导致利息计算错误。

8.2 货币精度

不同货币的最小单位不一样。人民币是分，日元是元（没有分），有些货币有三位小数。如果你的系统只支持人民币，用整数存分没问题；但如果要支持多币种，就必须为每种货币定义精度，并且在计算和展示时严格遵守。我见过一个系统，把日元也按分来处理，结果一笔100日元的交易，在系统里变成了10000，闹了很大的笑话。

8.3 订单号的生成规则

订单号看起来很简单，但设计不好会带来很多麻烦。我的要求是：全局唯一、趋势递增、包含一定的业务信息、不能暴露敏感数据。全局唯一是基本要求；趋势递增是为了数据库索引的性能；包含业务信息是为了方便排查问题，比如从订单号能看出是哪个业务线、哪天的交易；不能暴露敏感数据是指，订单号里不能包含用户ID、金额等敏感信息，否则一旦泄露，后果很严重。

我常用的方案是：业务前缀 + 日期 + 分库分表位 + 序列号。序列号可以用数据库自增、Redis原子递增或者雪花算法生成。雪花算法要注意时钟回拨问题，一旦发生时钟回拨，要么等待，要么抛异常，绝对不能生成重复的ID。

8.4 测试数据的隔离

金融系统的测试，绝对不能在生产环境上做，也不能用生产数据做测试。但很多团队在项目初期，为了图方便，直接连生产库做测试，或者把生产数据导到测试库。这样做风险极大，一旦测试代码有bug，可能直接修改了生产数据。我的做法是，测试环境完全独立，测试数据用工具生成，并且生成的数据要符合业务规则，不能随便造。比如生成一个用户，他的账户余额、交易记录、风控等级都要是合理的，否则测试出来的结果没有参考价值。

8.5 容量规划

金融系统的容量规划，不能只看平均TPS，要看峰值TPS。比如发工资那天、电商大促那天，交易量可能是平时的几十倍。如果你按平均TPS来规划容量，峰值一来系统就崩了。我的做法是，收集至少一年的交易数据，找出峰值出现的规律，然后按峰值的1.5倍来规划容量。同时，要有弹性扩容的能力，在峰值来临前提前扩容，峰值过去后再缩容。

容量规划还包括存储容量。金融系统的流水数据是只增不减的，而且监管要求保留很长时间。所以存储容量的规划要考虑到未来几年的增长，不能只看当前。我一般会按年增长50%来预估，并且提前做好分库分表的方案，避免数据量大了之后临时抱佛脚。

这些细节单独拿出来看，好像都是小事，但金融系统的稳定性就是由这一个个小事堆起来的。我经常跟团队里的同学说，做金融系统，要有一种“如履薄冰”的心态，每一个决策都要问自己：如果这里出错了，钱会不会错？用户会不会受影响？监管会不会找上门？把这三个问题想清楚了，很多坑自然就避开了。