做了十几年金融系统从最初日均几万笔的小平台一路做到支撑百亿交易规模、618单日9亿请求量的核心系统期间踩过的坑比我写过的代码还多。前几天团队复盘时翻出历年的故障报告突然觉得应该把这些用真金白银换来的经验整理出来。这篇文章不聊理论框架也不抄书上的“最佳实践”只讲我在一线真实遇到过的架构问题、当时的决策过程、以及事后复盘得出的教训。无论你是刚接手交易系统的开发还是已经在金融行业摸爬滚打多年的老手我相信这些记录都能让你少走一些弯路。先交代一下背景方便大家理解后文的决策逻辑。我当时所在的系统属于头部电商平台的自营金融板块核心链路覆盖用户账户、余额、优惠券、积分、支付、清结算等多个子系统。系统最核心的挑战有三个一是资金类操作对一致性要求极高容不得半点差错二是业务峰值极其集中618、双11这类大促能把流量瞬间拉到日常的几十倍三是业务规则复杂多变营销活动、优惠叠加、分账逻辑几乎每个月都在调整。这三个挑战交织在一起让每一次架构选型都变成了在性能、一致性、成本和研发效率之间的权衡游戏。下面的内容我会按照从宏观到微观、从设计到排障的顺序把这些年踩过的坑和填坑的思路一并记录下来。1. 从单体到分布式16年间金融系统架构的演进路线1.1 早期的单体架构简单粗暴但问题初现我刚入行那会儿金融交易系统远没有现在这么复杂。一套典型的单体应用Tomcat扛HTTP请求Oracle存数据再挂一个MQ做异步解耦基本上就能支撑起一个中等规模的交易平台。说实话在业务量每天几万笔、并发几百的情况下这套架构非常舒服。事务由数据库本地事务保证数据一致性靠ACID约束出了问题直接翻日志就能定位发布也就是一台一台重启的事。但问题在业务量增长到一定程度后就开始暴露了。首先是数据库连接数不够用每个请求都要占用一个连接池的连接高峰期连接等待直接把Tomcat线程池打满应用卡死然后数据库也跟着遭殃。其次是发布和扩容必须绑在一起营销团队想上一个新活动整个系统都要跟着发版风险面巨大。我记得有一次仅仅修改了一个优惠券的校验逻辑结果因为线程里的共享变量没处理好影响到了支付链路的初始化流程线上故障持续了将近三个小时。这个阶段给我最重要的教训是单体架构的“简单”是有上限的一旦撑过某个业务量阈值它的维护成本会指数级上升。判断单体能撑多久不能只看当前流量还得看业务复杂度的增长速度。如果业务团队每两周就上线一个新玩法那你该考虑拆分的时间点应该比流量指标先到。1.2 服务化改造基于领域边界切分核心链路我们真正下定决心做服务化拆分是在一次大促压测之后。当时目标TPS是5000实测只能跑到800数据库CPU直接100%慢查询堆积如山。那次压测报告出来以后技术委员会开了整整三天的会最终确定了一条原则按照业务领域边界切分而不是按照技术分层切分。这套思路拆出来的服务大致是这样用户服务负责账户、实名、限额、资产服务负责余额、冻结、解冻、交易服务负责订单、支付单、营销服务负责权益、优惠券、账务服务负责流水记录、会计凭证。每个服务独立部署、独立数据库对外提供粗粒度的接口。这个拆法有两个明显优点第一每个团队的职责边界非常清晰营销团队改活动不会再牵连到交易底层第二各个服务可以独立扩缩容哪个压力大就扩哪个资源利用率高了很多。当然拆分也带来了新的问题最大的难题是分布式事务。原来一个本地事务能搞定的事现在要跨服务、跨数据库。我们最终没有采用强一致的分布式事务方案比如两阶段提交而是引入了事务消息加本地消息表的最终一致性方案。具体来说交易服务在本地事务里写订单数据、同时插入一条消息记录然后通过MQ把消息发给账务服务和资产服务下游消费成功后回调确认。这个方案牺牲了强实时性但换来了极高的可用性和吞吐能力而且只要消息状态表设计得够好配合对账任务最终都能对齐。1.3 微内核与业务中台在大促峰值中重塑架构拆完服务之后系统确实平稳了一段时间但新问题又冒出来了。优惠券、积分、红包这些业务逻辑散落在各个服务里每个服务都有一份类似的“营销判断代码”维护成本非常高。大促期间产品经理提出一个“跨品类满减叠加积分抵扣”的活动涉及的改动横跨五个服务、三张数据表开发排期要三周直接错过了活动窗口。这时候我们开始考虑做业务中台。核心思路是把营销规则引擎独立成一个平台型服务所有促销、优惠、折扣的规则都配置在引擎里外部服务只负责传入订单上下文商品、用户、金额等引擎统一计算出最终优惠结果。这样业务改动就不需要动交易主链路代码只要在规则引擎中新增规则即可。这个架构改造我愿称之为“微内核模式”交易主链路保持稳定规则引擎作为可插拔模块运行插件化的方式支持业务快速创新。代价是规则引擎内部的状态管理变得异常复杂需要一套完整的领域特定语言DSL来描述规则优先级、互斥关系、叠加逻辑。我们实际花在规则编排器上的调试时间比写引擎本身还多。但这笔投入非常值得后来的618、双11大促60%以上的新营销玩法都是只改配置就上线了研发效率提升了不止一个量级。2. 百亿交易链路的核心设计从下单到资金到账的那一公里2.1 高并发下账户余额的读写之争账户余额是所有金融系统的命脉也是最容易出现并发问题的点。刚拆分完服务的那段时间我们直接用了数据库行锁来保证余额扣减的正确性每次扣款都先SELECT ... FOR UPDATE锁定余额行然后做扣减。这个方案正确性没问题但性能实在堪忧。用户高频操作时同一个账户的余额行会变成全局热点5000TPS的压测目标死活上不去数据库锁等待反而占了60%以上的耗时。后来我们引入了分层余额架构。简单说就是按照资金属性把账户余额拆成多个子账户可用余额、冻结余额、在途余额、营销赠送余额各自独立存储和更新。绝大多数营销活动和常规交易只操作营销赠送余额或小额可用余额真正动到大额核心余额的操作比例大幅下降锁冲突自然就少了。再配合账户级的异步记账先把扣款请求写进流水表再由独立的记账Worker异步更新账户余额用户端的响应速度直接翻倍。这套设计的关键点是不要让高并发请求直接打到底层账户表上而是通过流水表缓冲让写入变成顺序追加。流水表本质上就是一个不可变日志MySQL的InnoDB引擎对顺序追加的写入优化得非常好插入速度比随机更新的行锁方案快上十几倍。当然代价是余额存在短暂的不一致性窗口毫秒到秒级这对于绝大多数业务场景是可接受的互联网金融产品的余额展示本身就有“昨日收益、今日待结算”这种概念用户天然能理解短暂延迟。2.2 幂等性设计金融系统最容易被忽略的防线我见过太多团队在分布式改造时把90%的精力花在性能和一致性上却忽略了幂等性设计。幂等性设计的本质是同一个请求无论因为网络超时、重试、还是消息重复消费而被执行多少次产生的结果都应该是完全一样的。我们系统里的幂等方案分为三层。第一层是接口层所有写操作的请求都必须携带全局唯一的请求ID业务流水号服务端收到请求后先查幂等表如果已经处理过就直接返回上次的结果不再重复执行。第二层是消息消费层MQ消费端必须用消息ID做去重我们用的是数据库唯一索引加插入冲突捕获的方式相比先查询再插入的Check-Then-Act模式这种方式在高并发下不会有竞态窗口。第三层是状态机层核心交易单据都有明确的状态机定义比如待支付→支付中→支付成功→已结算所有状态转移都必须是单向的如果收到一个无法转移的状态请求直接拒绝并返回当前状态。有一件事我反复跟团队强调幂等性不是上线后再补的而应该在接口设计阶段就作为一种约束固化下来。一旦你的接口被下游调用方依赖再想增加幂等逻辑就会变得非常困难因为你不知道每个历史调用方是否都传了请求ID。2.3 数据分片百亿数据量下的存储博弈百亿交易规模意味着核心流水表的数据量是百亿级别的。单一MySQL实例根本装不下这么多数据即便装得下查询性能也会让索引完全失效。我们采用的是标准的分库分表方案分片键选用用户ID因为绝大多数查询都是围绕用户维度展开的查我的订单、查我的资产。具体分片规则是这样的先把用户ID做哈希然后对256取模映射到32个物理库每个库8张表。这样水平扩展能力非常强如果后续数据量翻倍只需要把256取模改成512取模同时做数据迁移即可。听起来简单但实际踩坑非常多。最典型的是分页和聚合查询一个管理员如果想查“最近一小时交易金额排名前100的用户”在分库分表的场景下这个问题本身就变成了一个分布式查询问题。我们的解法是建设一套离线近实时的OLAP分析链路通过Binlog同步把交易流水实时同步到ClickHouse所有分析类查询全部走OLAPMySQL只承接单用户维度的在线事务查询。还有一个很多人容易忽略的问题分片键的选择会直接影响数据分布的均匀性。如果按用户ID哈希分片大促期间那批超级用户比如头部主播的粉丝群产生的流量会集中在某些分片上导致数据倾斜和热点库。我们后来在分片键上叠加了一个“逻辑分片”的概念每个用户ID在物理分片内可以拥有多个逻辑子账户大流量用户的数据会分散到多个逻辑子账户中查询时通过路由表找到正确的子账户。这相当于把“大用户”做了一层内部分流效果非常显著。3. 618日9亿大促容量评估、压测与应急预案的实战复盘3.1 容量评估不是拍脑袋关键链路模型拆解618大促的流量预估我们有一套相对成熟的模型。这个模型的起点不是“去年多少今年翻倍”这种拍脑袋的做法而是从业务指标倒推技术指标。运营团队确定的目标是“大促当天成交额100亿、支付用户数3000万、峰值并发下单30万TPS”基于这三个数字我们按照漏斗模型逐层拆解访问首页的用户比例、点击商品详情的转化率、加购率、下单转化率、支付转化率。每一层对应一个核心服务每个服务都有一个容量计算公式。以支付服务为例容量 峰值下单TPS × 支付转化率 × 单笔支付耗时的影响因子 × 冗余系数。冗余系数我们统一取1.5~2.0因为大促期间总会出现各种预想不到的情况留足缓冲是底线。这中间最容易出问题的其实是外部依赖的容量盲区。支付服务依赖银行网关、短信服务商、风控服务商这些外部系统的容量完全不受我们控制。曾有一次大促我们自己的系统压测全部通过但大促刚开始五分钟银行侧就因为流量过载把渠道限流了支付成功率瞬间掉了20个点。后来我们专门建立了一条“外部依赖容量巡检机制”大促前两周逐一跟所有银行渠道、短信服务商确认他们的容量上限和预案同时在后端做了渠道分级和降级开关。一旦主渠道超时率超过阈值自动把流量切换到备渠道用户无感知。3.2 全链路压测不压测的大促等于裸奔618前的压测我们有一套完整的流程分五步执行流量录制、基线压测、链路压测、容量调整、回归验证。流量录制阶段我们通过网关层把日常的真实请求脱敏后全部录制下来存到压测流量仓库。基线压测的目的是把系统的性能指标和资源消耗在正常状态下打一个底比如每个服务单实例的QPS上限、RT的P99值、数据库的连接池水位这些都是后续调优的基准线。链路压测最复杂也最有用。我们会在预发环境部署一套跟线上拓扑一模一样的完整集群然后按预估的峰值流量进行阶梯加压。压测过程中重点观察两个指标一是RT的拐点正常情况下QPS上升时RT基本平稳一旦出现RT急速上涨说明系统已经逼近极限二是资源水位数据库连接数、线程池活跃数、GC频率有没有异常这些在监控面板上都要盯紧。每轮压测结束后的容量调整是大促准备的核心工作。我记得有一年压测发现账务服务在进行批量入账时因为SQL里有个没走索引的关联字段数据库CPU直接飙到80%后来优化索引后同样的压测流量下数据库CPU降到了20%。这种问题如果没压测大促当天几乎必然出故障。3.3 预案体系和逃生舱故障必然发生关键是恢复速度做金融架构十几年我最大的心得之一是你永远无法保证系统不会出故障但你可以保证出故障后能快速恢复。大促前的最后一道防线是一套完备的应急预案具体到可执行的开关、脚本和责任人。我把预案分成三个等级。一级预案是降级型比如关闭非核心的积分提示、关闭商品详情页的个性化推荐这类操作牺牲部分用户体验但保住交易主链路。二级预案是限流型在网关层按用户等级设置流量阈值普通用户超出阈值直接排队或者提示繁忙保障高价值用户的核心操作。三级预案是隔离型如果某个下游服务比如营销推荐服务出现故障直接熔断交易链路用缓存兜底数据不再等待下游响应。预案不能只写在文档里大促前必须做故障演练。我们有一年做了一个“突袭演练”运维突然把支付服务的两台机器kill掉看监控告警是否正常触发、自动扩容机制能不能拉起来新节点、团队是否有值班人员能在5分钟内响应。演练的结果非常出乎意料确实有人因为没收到告警而错过了响应窗口第二天我们就把告警渠道从单一的即时通讯群扩展到了电话、短信、IM多渠道并且给值班人员配了轮流值班表。4. 金融核心系统的关键选型从中间件到数据库的取舍逻辑4.1 注册中心与配置中心选型ZooKeeper、Nacos还是Consul服务化改造以后第一个要解决的技术选型问题是注册中心和配置中心。市面上主流的选择有三个ZooKeeper、Nacos、Consul。我们最终选了Nacos原因很实际第一Nacos同时支持注册中心和配置中心一套组件解决两个问题运维成本低第二Nacos在配置管理上支持灰度发布和版本回滚这对金融系统的配置变更非常重要大促期间一个配置项改错了能通过回滚快速恢复第三阿里系技术栈对Nacos的维护力度非常大社区活跃遇到问题的排查路径很成熟。但Nacos本身也并不是没有坑。比如Nacos客户端默认的故障容错是“容灾目录”也就是本地会缓存一份配置快照如果Nacos服务端挂了客户端能继续用快照里的配置启动。听起来很完美但实际上我们遇到过一个诡异的问题某个服务实例的配置被误删Nacos服务端已经没这条配置了可这个实例还能继续使用本地快照里的旧配置导致线上行为和预期完全不一致。排查了很久才定位到问题所在从那以后我们给所有配置操作都加了审批流程禁止直接删除线上配置。4.2 数据库选型业务类型决定引擎没有银弹金融系统的存储选型市面上有很多“神论”比如“MySQL不行必须上Oracle”、“NoSQL能搞定一切”等这些我都不赞同。我的观点是先梳理业务的数据访问模式再决定用什么存储引擎。我们系统里基本是混用模式账户余额和交易流水用MySQLInnoDB因为需要强事务和精确查询热点商品信息、营销活动配置用Redis因为读多写少、需要极低延迟用户行为日志、点击流数据用ClickHouse和HBase因为这类数据写入量大、查询多为分析型同城多活的场景下还得配合分布式数据库或者数据传输组件做双向同步。有一个选型教训非常深刻我们曾在某个项目里把订单数据全部放到了ElasticsearchES理由是查询非常灵活、支持全文检索。上线初期确实很爽但随着数据量增加ES的写入瓶颈和内存开销让运维崩溃最要命的是ES不能像MySQL那样保证强一致的事务一旦集群节点发生故障可能导致数据丢失。后来我们改成了MySQL ES双写MySQL承担事务和精确查询ES只做搜索索引通过Binlog同步更新。这才既保证了数据安全又保留了灵活的搜索能力。4.3 消息队列事务消息与顺序消息的最佳实践在分布式系统里消息队列不只是“削峰填谷”的工具更是实现最终一致性的基础设施。我们在选型时对比过RocketMQ、Kafka和RabbitMQ最终选择了RocketMQ核心原因是它对事务消息和顺序消息的支持最完善。事务消息的用法我在前面提到过本地事务和消息发送放在同一个事务里保证要么都成功、要么都失败。RocketMQ的事务消息机制具体是这样的先发送一条“半消息”half message到Broker此时消息对消费者不可见然后执行本地事务根据本地事务的执行结果向Broker提交“COMMIT”或“ROLLBACK”如果本地事务执行过程中宕机了Broker会定时回查生产者询问这条消息最终应该提交还是回滚。这套机制非常优雅地解决了“数据库操作和消息发送不能保证原子性”这个分布式经典难题。顺序消息主要用于资金类的操作序列比如同一个账户的充值、消费、退款必须保证严格按顺序处理否则余额状态就会错乱。RocketMQ的顺序消息实现方式是把相同业务ID的消息发送到同一个队列消费者端再按队列维度串行消费。设计时需要注意的点是队列数量一旦确定就不能轻易修改否则顺序会被打乱所以订单量扩容时我们通常按用户ID哈希分片把每个用户的请求路由到固定的队列这样既保证了单用户维度的顺序性又能横向扩展队列数量来提升吞吐。5. 高频踩坑实录那些差点让系统挂掉的魔鬼细节5.1 连接池参数引发的蝴蝶效应有一年618我们做了一次非常常规的扩容把交易服务的实例数从20台加到50台结果反而引发了线上故障。现象是数据库连接数暴涨数据库CPU飙升紧接着一大波“Connection pool exhausted”的报错从各个服务涌出。当时所有人都在看数据库以为数据库出问题了排查了很久才发现根因在配置上每台实例的连接池最大值设置的是20020台实例时最大连接数是400050台实例时直接变成10000远远打穿了数据库允许的最大连接数。从那以后我定了一条硬规矩连接池参数的设置必须和实例总数联动计算而不是单独看单个实例。具体来说数据库侧能承受的最大连接数除以实例数的安全余量才是每个实例允许配置的连接数上限。同时我们给连接池加了动态调整机制根据当前实例数和数据库负载自动收敛或扩展连接池大小避免人工配置的滞后性。5.2 缓存穿透、击穿与雪崩以及A/B降级策略金融系统里商品详情、余额明细、实时价格这类数据都是高频率读取的通常会在Redis里做缓存。但缓存有一个非常经典的“三兄弟”问题穿透、击穿、雪崩。穿透是指查询一个根本不存在的数据Redis没有命中请求直接打到数据库如果攻击者恶意构造大量不存在的ID数据库会直接被压垮。解决方案是引入布隆过滤器把所有合法ID提前加载到布隆过滤器里不存在的数据直接拒绝查询。击穿是指某个热点key在过期的一瞬间大量请求同时穿透到数据库导致数据库压力瞬间暴涨。我们用的是永不过期加逻辑过期时间的方案每个缓存key存储的是带过期时间戳的对象后台有一个线程池异步刷新即将过期的热点key。这套方案能让热点key永远不会真正失效扛住了无数个大促当天的流量冲击。雪崩是指大量key在同一时间集中过期导致数据库压力突增。这个场景最难防范因为大促开始时很多活动配置的缓存会在同一秒失效。我们的做法有两种一是缓存过期时间增加随机偏移量比如基础过期时间加0~300秒的随机值让过期时间错开二是加了一层本地进程缓存Caffeine作为二级缓存即使Redis集中过期本地缓存也能挡住大量请求。5.3 分布式事务反例一次错误的消息顺序引发的资损事故这是我从业以来离“资损事故”最近的一次。当时新上线的一个营销功能用户发起退款时会同时给用户发一张补偿优惠券。业务逻辑落地的顺序是先发起退款事务然后发送一条“发券”MQ消息券系统消费消息后为用户发券。看起来没有任何问题但实际上线后一小部分用户发现券没到账而订单却已经退款了。排查后发现问题出在消息消费的顺序上用户发起退款后立刻又下了一笔新订单新订单的营销校验逻辑依赖“待发券”状态结果新订单先被处理而发券消息还在队列里排队导致新订单没有享受到应有的优惠。这个案例本质上是事务之间的时序依赖没有被显式建模。修复方案是不再通过异步消息驱动券的发放而是退款事务和发券动作放进同一个本地事务或者至少通过分布式事务框架如Seata保证原子性。金融系统中凡是涉及资金和权益的联动操作绝不能依赖“消息就能保证最终一致”这种解耦思维因为消息的时序无法保证业务逻辑的正确性。正确做法是要么强一致要么引入额外的状态机来显式管理时序。5.4 慢SQL性能问题的隐形杀手慢SQL是金融系统中最隐蔽但破坏力最大的问题之一。很多时候系统的CPU、内存、连接数看起来都正常但整体RT就是高居不下用户体验极差。这种场景下第一排查目标应该是数据库的慢查询日志。我遇到过的一个典型问题是某个“用户优惠券列表”的查询SQL语句里用了ORDER BY expire_time DESC而expire_time上建有索引看起来没问题。但数据量超过5000万行以后这个查询的耗时从50ms飙升到了2000ms原因是ORDER BY expire_time DESC触发了文件排序filesortMySQL需要在内存或磁盘里对整个结果集排序无法利用索引的有序性。优化方案是调整索引结构把索引设计成(user_id, expire_time, status)这样的联合索引并且SQL写法改成先WHERE user_id ? AND status ?再用索引有序性取数据彻底消除了文件排序。慢SQL治理要形成制度化不能每次都靠线上故障来驱动。我们的做法是MySQL慢查询日志开启后通过一套定时任务每天扫描慢查询记录自动推送到研发群里由对应接口的负责人认领并给出优化排期。这个机制坚持了两年系统整体的P99延迟下降了近一半。6. 架构管理的软实力从技术决策到团队协作的实战沉淀6.1 技术评审把架构风险前置拦截分布式架构做得越久我越意识到技术评审的重要性。很多线上故障追溯到根因都不是代码写错而是在设计阶段就有缺陷。比如某个接口的入参设计得不够幂等、某个状态机的流转路径有环、某个分片键的分布不均匀这些问题一旦进入编码阶段再发现修复成本极高。我们的技术评审有两条硬性要求一是所有涉及资金、库存、优惠的核心接口评审时必须画清楚状态机图和时序图确认不存在并发冲突和非法状态流转二是所有新增存储或缓存评审时必须回答“数据丢失怎么办、数据不一致怎么办、未来数据量翻十倍怎么办”这三个问题。如果答不上来设计就得打回去重做。这套机制一度被团队吐槽“过于繁琐”但坚持下来之后线上故障率确实下降了一个数量级。6.2 故障复盘不是追责而是系统性补漏每次大促或者重大故障后我们都会做一次正式的复盘。复盘会有几个固定的环节时间线还原从故障发生到恢复每个关键节点做了什么决策、根因分析用5-Why法逐层追问直到找到系统和流程层面的根本原因、改进项跟踪每一条改进项必须有负责人和截止日期下次复盘时逐项检查闭环情况。这里面最难做到的是把故障跟个人解耦。一旦复盘会上出现“这是某某的失误”这种话大家就会开始防御性沟通关键信息就会被隐藏复盘就变成走过场。我们团队内部的原则是技术故障没有“人祸”只有“系统性缺陷”。如果一个错误一个人能犯那一定是系统缺少了防错机制如果一个事故没有及时被发现那一定是监控有盲区。这个视角的转变对团队的成长帮助非常大。6.3 架构师的成长技术深度与业务理解的乘法关系最后说说架构师这个角色本身。这些年我带过不少初中级工程师最大的感受是很多人把“架构师”理解成“技术更强的人”但其实架构师的核心竞争力在于把业务问题转化为技术方案的能力。同一个业务需求初级工程师看到的是“要加一个接口”中级工程师看到的是“要加一张表”而架构师看到的是“这个需求涉及的链路有哪些影响哪些状态和数据如何做到不影响现有功能和性能”。这种能力的养成没有捷径只能靠大量的实战积累和复盘。我经常跟团队说不要只盯着自己负责的那一块代码要尽量去吃透一条完整的业务链路比如用户从注册到下单到支付到售后的全流程尝试画出它的系统时序图、数据流图、状态机图搞清楚每一个环节为什么这样设计、有没有更好的设计。久而久之你会发现自己对系统的理解会从“点”连成“线”、从“线”织成“面”这时候再看架构问题视野和判断力都会完全不同。7. 写在后面给同路人几句经验之谈十六年金融架构的摸爬滚打如果非要提炼成几句话我会说第一架构设计永远没有最优解只有当前业务阶段下的最合适解别迷信任何“业界标准”要结合自己的团队能力、技术栈和历史包袱来做权衡第二稳定性是金融系统的生命线任何性能优化、成本控制、体验提升都必须以不牺牲数据准确性和系统可用性为前提第三架构师不能脱离业务谈技术你对业务的理解深度决定了你技术方案的高度和可落地性。最后分享一个我一直在用的习惯每次遇到线上故障或诡异问题无论多晚我都会在解决之后花半小时把整个过程记录下来——现象、排查思路、根因、修复方案、后续防范措施。这些记录不会立刻产生价值但一年、两年后回头翻看你会惊讶地发现成长都藏在那些踩过的坑里。这套架构方法和踩坑经验来自于一个从百万交易量一路走到百亿交易规模的实战过程。术业有专攻不同团队遇到的瓶颈可能各不相同但底层的方法论——先理清业务、再做技术选型、最后靠预案和监控兜底——是相通的。希望这份记录能给你带来一些启发或者至少让你在下一次大促压测前心里多一分底气。