我们线上核心系统的性能瓶颈是在一次大促压测中集中暴露的。当时系统架构还是个典型的单体应用加单库平时 QPS 两千左右还能撑住可压测流量一旦拉到五千以上数据库连接池立刻被打满接口响应时间从几十毫秒飙升到几秒紧接着就是一波接一波的慢查询告警和超时异常。那个星期我们基本都在救火每天盯着监控面板找瓶颈从 SQL 到 JVM 再到带宽能调的都调了但效果有限。后来团队达成共识光在原有架构上修修补补已经到头了必须做一次从架构设计到性能优化的系统性改造。这篇文章就是那次改造的完整复盘。我会把整个过程拆开讲怎么定架构方案、怎么选型中间件、怎么做容量评估和数据分片、压测时发现了哪些问题、上线后又踩了哪些坑、最终性能数字变成了什么样。同时会给出一些可以直接抄作业的参数配置和排查思路。适合正在做系统拆分的后端开发、架构师或者是准备对核心系统做性能治理的技术负责人参考。1. 项目背景与整体设计思路1.1 旧架构的痛点到底在哪先说一下系统原来的样子。这是一个典型的交易类系统核心链路是用户下单、库存扣减、订单查询、对账结算。部署上就是一台网关加多台应用服务器背后挂一个主库和一个从库缓存用的 Redis 单实例消息队列没有引入所有同步调用都是走 HTTP 接口硬扛。表面上看起来不复杂但流量一上来问题就很明显。第一个痛点是数据库扛不住。订单表、库存表、流水表都在一个库里单表数据量过了千万级之后即使有索引写入和查询都会明显变慢。更麻烦的是一些统计类查询会扫描大范围数据比如运营后台要拉某段时间的订单列表一条 SQL 就能把主库的 IO 打满。我们当时做过一次 profiling发现高峰期主库的 CPU 使用率长期维持在 85% 以上Buffer Pool 命中率不到 95%大量时间浪费在随机磁盘读取上。第二个痛点是服务间的调用关系太乱。下单接口要同步调用库存服务、用户服务、优惠券服务任何一个服务抖动下单接口就跟着超时。这种强耦合的同步调用链路在流量高峰时还会出现线程池排队线程耗尽之后新的请求直接拒绝表现就是接口大面积 5xx。第三个痛点是缺乏容量感知。没有压测基线也没有明确的容量规划每次大促前都是拍脑袋加机器。加机器确实能缓解一部分压力但治标不治本而且成本很高。到了某次压测我们尝试把 QPS 拉到一万结果系统直接崩了那一刻才意识到必须做架构层面的调整。1.2 改造目标与方案取舍既然决定改造先定目标。我们当时定了几个硬性指标核心下单链路在 QPS 一万的压测下P99 响应时间控制在 500ms 以内。数据库主库 CPU 使用率在高峰期不超过 60%。核心服务可用性不低于 99.95%允许有损降级但不能全挂。具备水平扩展能力流量再涨时通过加机器就能扛住而不是改代码。围绕这些目标我们讨论过几个方案。一个是直接上微服务拆分把订单、库存、用户拆成独立服务另一个是保持单体但做数据库读写分离加缓存还有一个是引入消息队列做异步化把非核心链路从同步调用里摘出去。最后定下来的方案是三者结合但节奏上有先后。不做一刀切的微服务拆分因为业务边界没理清之前拆分只会把调用链搞得更乱。我们采用的方式是先做数据层的读写分离和分库分表再引入消息队列做链路异步化最后在应用层做服务模块化为后续独立部署留好接口。这个取舍的核心逻辑是优先解决最痛的数据库瓶颈用异步化削峰填谷服务拆分放到最后而不是第一步。这个决策后来被证明是对的。如果一开始就拆微服务光处理分布式事务和调用链追踪就要花掉大量时间而我们的核心矛盾其实是数据库和同步调用不是服务数量。2. 核心组件选型与架构落地2.1 分库分表方案分片键怎么定数据层改造是整个项目的重头戏。订单表、订单明细表、流水表都需要分片分片键的选择我们讨论了很久。候选的分片键无非是订单 ID 和用户 ID。按订单 ID 分片的好处是订单相关的查询都走本地路由按用户 ID 分片的好处是用户维度的查询可以直接定位。但我们的业务里用户查自己的订单列表是最高频的查询占了读请求的 70% 以上而订单 ID 维度的查询主要来自后台运营频率低很多。所以我们最终选了用户 ID 作为分片键。分片数量是根据未来三到五年的数据量估算的。当时订单表已经有三千万行按每年翻一倍的增速估算三年后大概一亿两千万行。单库单表两千万行左右是 MySQL 性能的一个比较舒适的上限所以我们定 8 个库、每个库 32 张表总共 256 个物理分片。换算下来单分片约五十万行这个量级对索引和查询都非常友好。分片规则用的是简单的取模。shard_id user_id % 256。为什么不用区间分片或者一致性哈希区间分片的缺点是热点问题很难规避比如某个头部商家的订单量巨大会集中在某个区间一致性哈希虽然解决了扩容时的数据迁移问题但实现复杂而且我们的业务场景里用户 ID 取模已经足够均匀没有必要引入额外复杂度。取模方案最大的问题是后续扩容需要迁移数据。我们的应对是提前把分片数定到 256用空间换时间至少三到五年内不需要扩容。这个思路在业务量可预估的阶段是合理的不要为了一个可能永远不会发生的扩容场景把当前的架构搞得太复杂。2.2 缓存设计缓存什么、缓存多久、怎么防穿透缓存层原来的问题是只有单实例 Redis而且没有做细致的缓存策略基本是接口层手动 set/get命中率全看代码怎么写。这次改造我们系统性地重新设计了缓存。缓存的数据分成三类。第一类是热点数据比如商品信息、库存数量特点是读多写少实时性要求中等我们设置过期时间五到十分钟用主动刷新兜底。第二类是用户维度数据比如用户购物车、收货地址列表特点是每个用户的数据量小但访问频率高过期时间两小时用户在修改操作后主动删除缓存。第三类是统计聚合数据比如首页的商品推荐列表这部分数据加工成本高允许一定延迟过期时间半小时后台有定时任务定期刷新。这里要特别说一下缓存穿透的坑。我们上线初期没有做防护结果某个活动期间有大量请求查不存在的商品 ID每次都直接打到数据库把从库打到报警。后来加了布隆过滤器把所有有效商品 ID 加载到过滤器里查询前先判断 ID 是否存在不存在直接返回空。布隆过滤器的误判率我们设置的是 1%用了两个哈希函数内存占用大概每个商品 8 字节一千万商品也就 80MB完全可接受。另外缓存雪崩我们也做了预案。统一的过期时间打散了加一个随机偏移量比如基础过期时间五分钟实际过期时间是五分钟加减 0 到 60 秒的随机值。这样即使一批缓存同时失效也不会在同一时刻集中打到数据库。2.3 消息队列选型与异步化改造引入消息队列是这次改造里争议最大的一个点。有同事认为引入 MQ 会增加运维复杂度而且异步链路出了问题不好排查。但从架构角度看异步化是削峰填谷最有效的手段也是把核心链路和非核心链路解耦的必由之路。选型时我们对比了市面上主流的几款消息中间件。我们需要的是高吞吐、低延迟、支持延迟消息和事务消息最好有现成的监控面板。最终选了 RocketMQ原因主要有几点事务消息机制和我们的对账场景契合可以保证本地事务和消息发送的最终一致性自带延迟消息队列适合订单超时关闭这种场景社区活跃遇到问题能找到参考案例。异步化改造集中在三个链路。第一个是下单后发送通知短信和站内信原来是同步调用高峰期短信服务一抖动下单接口就跟着慢现在改成发消息后直接返回消费者慢慢处理。第二个是订单状态的变更记录写流水这部分数据量巨大但对实时性要求不高异步写入之后主库的写压力降了不少。第三个是订单超时未支付自动关闭用 RocketMQ 的延迟消息实现下单时发送一条延迟三十分钟的消息消费者收到消息后检查订单状态如果还是未支付就执行关闭。改造后效果最明显的是下单接口。原来完整链路要同步调用五个服务现在只需要操作数据库和发一条消息接口响应时间直接降了一个量级。3. 性能优化从量化到落地3.1 先建立压测基线和容量模型做优化之前我们花了很长时间做压测。压测不是简单地用工具打流量而是要建立一套基线数据知道系统当前的瓶颈在哪、每一项优化措施到底提升了多少。我们用 LoadRunner 加自研的压测脚本两套方案并行。LoadRunner 负责模拟真实的用户行为自研脚本负责做针对性的大流量冲击。压测环境是和生产环境配置一致的独立集群数据量也做了对齐这样压测结果才有参考价值。第一轮压测的结果非常难看。核心下单接口的 TPS 只有 1800P99 响应时间 2.3 秒数据库主库的 CPU 直接打到 100%连接数长时间维持在峰值。通过火焰图分析CPU 消耗的大头在 SQL 执行和 JSON 序列化另外有 12% 的线程时间花在了日志打印上。基于这轮压测我们建立了一个简单的容量模型。核心链路的 TPS 目标是一万数据库单台能支撑的最大 TPS 是两千所以至少需要五个读库实例应用层的线程池模型是核心线程数 TPS 目标 / (单线程每秒可处理的请求数)如果单个线程每秒能处理 50 个请求一万 TPS 就需要两百个核心线程。但是线程数不能无限加因为线程切换有开销而且数据库连接数是有限的。连接池大小的经验公式是连接数 ((核心数 * 2) 高效存储磁盘数)但这个公式更多是给单机数据库参考的。我们的实际做法是把连接池上限设置为 50通过压测调到最优。要记住一个原则连接池不是越大越好过大的连接池反而会导致数据库端线程竞争加剧出现连接获取等待。3.2 SQL 优化慢查询治理的完整过程慢查询是这次性能优化里收获最大的一块。我们开启了慢查询日志阈值设为 200ms连续采集一周把 Top 20 的慢查询全部拿出来分析。结果发现一个规律大部分慢查询都是因为索引失效而索引失效的根源是查询条件里对索引列做了函数操作。比如有个查询写了WHERE DATE(create_time) 2024-05-20这个写法会让 create_time 上的索引完全失效改成WHERE create_time 2024-05-20 00:00:00 AND create_time 2024-05-21 00:00:00之后扫描行数从几百万降到了几千。另一个典型案例是订单列表查询的深分页问题。运营后台要查第 10000 条到第 10010 条的数据LIMIT 10000, 10这种写法会让数据库扫描前 10010 条再丢弃前 10000 条效率极低。我们改为基于游标的分页方式用上一页最后一条记录的 ID 作为下一页的查询条件WHERE id 10000 ORDER BY id LIMIT 10这种方式无论翻到第几页扫描行数都只有 10 条。还有一个很容易被忽略的点是排序字段的索引设计。原本订单表的索引是(user_id, status)但列表查询经常按create_time排序导致每次查询都要走 filesort。后来把索引调整成(user_id, status, create_time)让排序直接走索引filesort 直接消失了查询时间从 800ms 降到了 30ms 以内。SQL 优化这块我的建议是不要依赖 DBA开发人员自己也要会看执行计划。EXPLAIN里重点关注 type 字段全表扫描是ALL索引扫描是range或ref如果看到ALL就要警觉了。另外Extra字段里出现Using filesort和Using temporary都要想办法去掉。3.3 JVM 与连接池参数调优数据库那边优化完之后应用层的调优接着跟上。我们用 JDK 自带的 Flight Recorder 做了一次线上 JVM 分析发现老年代 GC 频率大约是每分钟一次每次停顿 400ms 左右。这个停顿在低峰期没什么感觉但在高峰期会直接影响接口响应时间。GC 优化的思路不是改垃圾收集器而是减少对象分配。我们用 MAT 分析了堆转储发现订单对象里面有大量冗余字段比如物流信息在创建订单时还没产生但对象里已经初始化了这些字段大部分时候都是 null白白占用了内存。把对象精简之后Young GC 的频率明显下降老年代 GC 从一分钟一次变成了五分钟一次。连接池这边踩过一个坑。一开始我们把数据库连接池最大连接数设置成 200结果压测时数据库端反而报警了说线程数过高。原因是连接数是 200 的话数据库端要为每个连接维护一个线程200 个线程做上下文切换本身就消耗大量 CPU。后来把最大连接数降到了 50配合合理超时时间整体吞吐反而上去了。连接数不是越多越好这个是性能优化里一个很反直觉的点。3.4 网关层限流与缓存前置网关层的改造更多是防御性的。我们在网关层做了三层保护第一层是 IP 维度限流第二层是用户维度限流第三层是接口维度限流。限流算法选了令牌桶因为它允许一定的突发流量比固定窗口限流更适合业务场景。令牌桶的参数设置要根据业务压测结果来。比如下单接口的单一用户限流是每秒 5 个请求突发容量是 10接口总限流是每秒 2000 个请求突发容量是 4000。这些值不是拍脑袋定的而是通过历史峰值数据加上压测的最大承受能力算出来的。缓存前置这块主要是把一些读多写少的数据直接放到 CDN 或者网关层缓存。比如商品详情页的数据虽然应用层有 Redis 缓存但每次还要经过一次网络请求在极端流量下网关层有缓存可以直接挡掉 30% 的请求。网关缓存我们设置的是 TTL 60 秒更新频率不高唯一要注意的是缓存淘汰时不要所有 key 同时过期同样加随机偏移。4. 稳定性保障与问题排查实录4.1 限流熔断降级的落地实践架构改造完成之后稳定性保障变成了重点工作。我们基于 Sentinel 做了服务的限流熔断降级核心规则有三类。第一类是并发线程数限制。下单服务的并发线程数上限是 200超过之后新的请求直接快速失败返回提示稍后重试。这个策略防止的是线程池耗尽导致的雪崩。当请求积压时如果让所有请求都排队最终结果是线程池被占满后续的请求全部超时而且 CPU 被无意义的等待耗尽。快速失败至少保证了系统还活着。第二类是异常比例熔断。当某个下游服务的调用异常比例超过 20%熔断器打开接下来的请求直接走降级逻辑不再尝试调用真实服务。熔断器的恢复策略是半开状态每五秒放一个请求去探活如果成功了就关闭熔断器否则继续熔断。第三类是依赖服务的降级。比如优惠券服务挂了下单链路不能跟着挂。我们定义了降级开关检测到优惠券服务不可用时自动跳过优惠券计算用户下单不受影响只是不能用券。这种有损降级在大型活动中是必须接受的选择要保住核心链路。4.2 上线后的几个真实故障和排查过程分享几个上线后真实遇到的问题希望能帮大家少走弯路。第一个是消息堆积。某次活动大促刚开始订单量暴涨消费者集群的处理能力跟不上生产者发消息的速度RocketMQ 的消息堆积量在半小时内从 0 涨到了几十万条。排查发现原因有两个一是消费者线程数设置太少默认只有 20 个二是消费者里做了重量级操作每个消息要调用一次外部服务外部服务的响应时间从 50ms 涨到了 500ms直接拖慢了消费速度。解决办法是增加消费者线程数到 50同时把消费逻辑里的外部调用改成批量处理减少网络往返次数。另外我们设置了消费延迟告警堆积量超过阈值就报警避免下次问题发生半天才发现。第二个是缓存穿透加数据库连接池耗尽。这个问题的场景是某接口没有做好缓存空值的处理导致某个不存在的数据被高频查询所有请求都穿透到数据库数据库连接池被占满正常业务也受到牵连。处理流程是先临时在代码里加了一个空值缓存处理再对接口做限流最后排查为什么会有大量不存在的数据请求发现是前端页面调整后旧链接还在被爬虫抓取。这个问题的教训是所有缓存都必须同时处理缓存穿透空值也要缓存只是过期时间可以短一些。第三个是分库分表后的跨分片查询问题。分片键是用户 ID但后台运营需要按商家维度统计订单数据这属于跨分片查询。最开始的做法是扫全表跨分片聚合256 个分片全部查询一遍再合并结果一个统计接口要几十秒才能返回。后来用了双写的方案在分库分表的同时额外维护了一张商家维度的汇总表写入时同时更新查询时直接查汇总表。虽然写入多了一次操作但读取性能提升巨大几十秒的查询变成了一秒以内。4.3 监控告警体系的搭建没有监控的优化是不可信的。我们从改造第一天就在完善监控体系最终分了三层。第一层是基础监控用的是 Prometheus 加 Grafana。采集项包括每个服务节点的 CPU、内存、磁盘 IO、网络带宽、JVM 指标GC 次数、堆内存使用、数据库连接数和慢查询数。这些指标全部按 10 秒粒度采集保存 30 天可以回溯查看任何时间点的状态。第二层是链路监控。我们用 SkyWalking 接入了全链路追踪每个请求会生成一个 Trace ID通过这个 ID 可以查看请求经过了哪些服务、每个环节耗时多少。这在排查跨服务慢请求时有奇效。以前出了问题只能靠几个服务分别看日志猜现在直接看链路图哪个环节耗时一眼就知道。第三层是业务监控。除了技术指标我们还定义了一批业务指标比如下单成功率、订单支付率、购物车加购量等。这些指标和技术指标不一样它们反映的是用户实际体感。有时候技术指标一切正常但业务指标在掉那一定是业务逻辑出了问题而不是技术问题。告警规则方面我们的原则是宁可漏报不可误报。告警阀值不是越高越好也不是越低越好关键是不要频繁触发导致告警疲劳。比如 CPU 使用率告警阀值我们设在 85% 持续 5 分钟GC 停顿时间超过 1 秒才告警。设置告警的时候要想清楚这个告警触发后收到的人应该采取什么行动。如果不能回答这个问题这个告警就没有必要存在。5. 性能数据对比与效果评估改造投入了大量人力到底值不值最终要看数据。这里把改造前后的关键指标做一份对比。核心接口的下单响应时间改造前 P99 是 2.3 秒改造后是 180ms下降了 92%。这里面的提升主要来自三个环节缓存命中率大幅提升大部分读请求不再打到数据库、消息队列替代同步调用不再等待下游服务以及 SQL 优化单次查询耗时从百毫秒级降到几十毫秒级。数据库主库的 CPU 使用率改造前高峰 95% 以上改造后稳定在 40% 到 50% 之间。这部分降低主要来自读写分离把统计类查询全部切到从库和汇总库和缓存前置80% 的读请求被缓存拦截。系统吞吐能力改造前压测极限是 QPS 2000 左右改造后第一次压测就跑到了 QPS 8000经过两轮参数调优后稳定在 QPS 12000而且还有余量。这个吞吐量已经把未来两年的增长空间都覆盖了。可用性方面改造前整个季度出现过三次严重的线上故障最长一次从发现问题到恢复用了四个小时。改造后连续几个季度没有出现过一次 P0 级别故障最严重的问题也就是消息堆积延迟了几分钟没有影响核心下单链路。成本方面反而是唯一没有达到预期的指标。我们原本以为通过优化可以减少服务器数量从而降低硬件成本但实际上因为引入了消息队列、监控系统、以及分库分表的冗余存储整体服务器数量并没有减少太多。不过换个角度想同样的服务器数量之下系统的承载能力提升了六倍单位请求的处理成本其实是大幅下降的。指标改造前改造后变化幅度下单接口 P99 响应时间2.3s180ms下降 92%主库 CPU 峰值使用率95%45%下降 50%压测极限 QPS200012000提升 6 倍P0 级故障次数季度30趋于 0月均线上故障恢复时间2 小时15 分钟下降 87%6. 复盘与经验总结6.1 哪些决策做对了哪些走偏了重新复盘整件事有些决策值得坚持有些方向我们确实走偏了。做得对的地方第一个是坚持先做数据层再做应用层。数据库瓶颈一天不解决应用层做得再好接口也只能在数据库等待上浪费时间。第二个是引入消息队列的时机拿捏得比较准我们没有在项目一开始就引入而是等核心链路跑通以后再逐步替换同步调用降低了改造风险。第三个是压测前置这个太重要了不压测根本不知道瓶颈在哪所有优化都是盲人摸象。走偏的地方第一个是过度追求技术完美。比如我们在分库分表之前花了很多时间讨论要不要引入分布式事务框架后来发现大部分场景根本用不到强一致性用最终一致性配合消息队列就够了。第二个是监控体系早期搭得过于复杂一次性上了太多指标和告警结果告警频率太高值班的人根本处理不过来后来不得不砍掉一大批不重要的告警规则。第三个是早期忽略了容量预估的准确性对分片数的估算偏保守导致部分分片的数据量虽然不多但后续如果想重新分片就比较困难。6.2 这些经验可以迁移到别的项目这次改造沉淀下来的方法论我认为不只适用于交易类系统。第一点是性能优化要有数据驱动的意识。不管优化什么先量化现状再确定优化目标最后用数据验证效果。每一步优化最好都能对照压测数据看变化而不是凭感觉说提升了多少。第二点是架构改造要小步快跑而不是大爆炸。我们这次把改造拆成了几个独立的阶段每一阶段上线后都观察了一段时间再走下一步这样即使某一阶段出了问题影响范围也是可控的。第三点是稳定性建设一定要前置。不要等系统挂了才想到需要限流熔断这些东西应该在压力测试阶段就加上去让问题在测试环境暴露而不是在生产环境让用户去承受。最后说一个我在实际项目中反复验证过的小技巧性能优化的优先级永远是先看网络和数据库再看应用代码最后才是 JVM 调优和参数调整。很多人一上来就调 JVM 参数或者并发线程数其实数据库一条慢 SQL 带来的性能损耗可能比所有 JVM 参数加在一起都大。先找到最粗的那根瓶颈木桶把它加长再去找下一根。这个顺序不要搞反了。