老系统性能优化实战：从技术债治理到丝滑回归

入行时间久了总会遇到几个让你又爱又恨的老系统。它们可能代号响亮可能撑过核心业务也可能在某个深夜因为一次代码变更变得“卡成幻灯片”。标题里的 Q33其实就是这类老服务的一个缩影曾经很丝滑如今处处掣肘。接到过类似项目的人应该懂我说的不是某个具体组件而是一种普遍状态——代码能跑但没人敢动接口能用但越来越慢文档缺失逻辑靠猜每次发版都像拆炸弹。这篇文章不贩卖焦虑也不讲玄学。我会以“Q33 老服务性能退化与技术债务治理”为场景分享一套可落地的老系统优化思路怎么从现状盘点到瓶颈定位从数据库、代码、配置、可观测性几个方向逐步改造以及如何控制改造过程中的风险。无论你是刚接手老项目的后端工程师还是正在为“越来越卡”的核心服务发愁的技术负责人这篇文章都会提供一份能直接照着做的行动清单。1. 背景与核心概念什么叫“不再丝滑”1.1 老服务变慢的本质很多开发者会把“系统变慢”等同于“机器性能不够”于是第一反应是加配置、扩节点。但大多数时候Q33 这类老服务的问题不是硬件扛不住而是软件层面的“结构性退化”。所谓“不再丝滑”通常体现在几个方面接口响应时间整体上升高峰期 P99 明显恶化CPU 和内存使用率居高不下但业务量并没有同比例增长数据库慢 SQL 越来越多连接池经常告警上线后容易出问题回滚频繁团队不敢频繁发布代码分支混乱修改一个需求需要同时改动多处且害怕影响其他功能。这些现象的背后本质是技术债的积累。技术债不是一个抽象概念它可以体现为循环调用数据库、缺少索引、无用的大字段查询、过大的事务边界、硬编码配置、缺少日志和监控以及依赖版本老化带来的兼容性问题。1.2 为什么老系统会积累这些问题老系统并不是一开始就慢的。它往往经历了快速迭代期那时业务优先级最高工程师优先保证功能可用很难有时间做结构性优化。等业务稳定后再想优化时发现核心模块没有单元测试谁也不敢乱动早期开发人员已经离职业务逻辑只能靠猜系统间耦合严重一个接口背后牵扯十几个服务缺少性能基线和监控大盘连“慢了多少”都说不清楚。所以优化 Q33 这类老系统第一步不是改代码而是先建立“可观测、可度量、可回滚”的治理基础。1.3 适用场景与优化目标本文的优化方法适用以下场景场景表现接口延迟上升核心接口 TP99 持续走高CPU/内存异常单机负载高频繁 GC数据库压力大慢 SQL 多连接池打满交付效率下降代码难以维护发布风险高稳定性不足高峰期出现超时、报错优化的目标不是一次性把系统重写而是通过一系列小步快跑的手段把系统拉回“安全、可控、丝滑”的状态。记住一个原则老系统治理永远先保稳定再造性能。2. 环境准备与现状盘点先摸清家底很多同学拿到老项目第一件事就是看代码看到烂代码就忍不住想重构。这里我强烈建议先忍一忍先做一次现状盘点。没有现状数据支撑的优化后续很难证明有没有效果。2.1 梳理系统技术栈先把 Q33 涉及的技术栈理清楚。可以采用一个简单的表格逐项确认盘点项需要确认的内容应用语言Java、Go、Python 还是其他框架版本Spring Boot/Spring Cloud 等版本运行环境操作系统、JDK 版本、容器或虚拟机中间件数据库、缓存、MQ、注册中心版本部署方式单机部署、集群、容器化外部依赖第三方服务、内部 RPC 接口注意不要只看 pom.xml 或 requirements.txt 里的版本还要到服务器上确认实际运行版本。因为有些老系统打包时和运行时版本不一致会造成很多诡异问题。2.2 建立性能基线没有基线就没有对比优化效果也很难量化。建议至少采集以下四类指标业务指标核心接口的 QPS、RT、成功率、错误率系统指标CPU、内存、磁盘 IO、网络带宽、负载JVM 指标堆内存使用、GC 频率、GC 耗时、线程数数据库指标活跃连接数、慢 SQL 数量、锁等待、主从延迟。采集命令可以先用系统自带的工具快速看一轮# 查看系统负载和 CPU 使用情况 uptime top -c # 查看内存使用情况 free -g # 查看磁盘空间和 IO 情况 df -h iostat -x 1 5 # 查看网络连接情况 ss -s如果是 Java 应用还可以用 JDK 自带工具采集应用视角的指标# 查看 Java 进程 PID jps -l # 查看堆内存使用情况 jcmd PID GC.heap_info # 查看 JVM 参数 jcmd PID VM.flags生产环境执行诊断命令前请确认有对应权限并且操作窗口在低峰期。尤其 jmap、jcmd 这类命令可能触发停顿建议先和团队确认。2.3 梳理关键链路与业务地图除了看机器指标还要画一张“业务链路图”。不用画到什么架构图软件里可以先按调用关系列出来用户请求从哪个网关入口进来经过哪些应用服务每个服务调用了哪些数据库、缓存、外部接口哪些环节是同步调用哪些是异步消息。画这张图的目的是找出“链路中最脆弱的节点”。很多时候 Q33 慢不是每个节点都慢而是某个节点在高峰期出现瓶颈导致上游排队最终表现为整体卡顿。3. 定位性能瓶颈从入口到出口的分层排查完成现状盘点后下一步就是定位瓶颈。排查顺序一般是从入口到出口也就是“接入层 → 应用层 → 数据层”。3.1 接入层排查如果是 Web 服务先看接入层是否有问题连接数是否打满是否有大量 TIME_WAIT 连接负载均衡是否把流量打到了不健康的节点是否有请求重试导致放大效应。常见的命令组合# 查看 TCP 连接状态统计 ss -ant | awk {print $1} | sort | uniq -c | sort -rn # 查看 nginx 主动健康检查日志按实际情况 tail -f /var/log/nginx/access.log接入层问题通常表现为应用 CPU 不高但请求超时率高。这时候优先排查连接池、线程池和上游超时配置。3.2 应用层排查应用层主要关注两个点线程状态和调用链路。先看线程状态。用 top 找到高 CPU 的 Java 进程再看进程内高 CPU 线程# 找到 Java 进程 PID假设为 12345 top -Hp 12345记下 CPU 占用最高的线程 PID转成十六进制printf %x\n 12346然后导出线程栈jstack 12345 /tmp/thread_dump.txt在线程栈文件中搜索对应十六进制线程号就能定位到具体代码位置。这里提醒一点线程栈是瞬时快照建议在问题出现的持续时间内多抓几次比如每隔 5 秒抓一次连续抓 5 到 10 次。如果觉得 JDK 原生命令不够直观可以使用 Arthas 在线诊断平台。注意 Arthas 本身也是一个诊断工具使用前要在测试环境验证权限策略。# 启动 Arthas示例版本以官方发布为准 java -jar arthas-boot.jar # 进入 dashboard 查看全局实时状态 dashboard # 查看最忙的前 N 个线程 thread -n 3 # 跟踪方法调用耗时 trace com.example.Q33Service queryOrder通过线程栈和 Arthas通常能快速定位到三类典型问题线程大量阻塞在数据库连接获取上线程大量阻塞在锁等待上线程在循环调用外部接口导致单请求耗时放大。3.3 数据层排查数据层的瓶颈非常容易出现因为老系统往往在 SQL 写法上不够讲究。先开启数据库慢查询日志或者用数据库运维平台查看慢 SQL。以 MySQL 为例查看当前慢查询状态SHOW VARIABLES LIKE slow_query_log%; SHOW GLOBAL STATUS LIKE Slow_queries;注意不同数据库版本的变量名和参数可能有差异这里只演示思路。拿到慢 SQL 之后用执行计划分析EXPLAIN SELECT * FROM q33_order WHERE user_id 12345 ORDER BY create_time DESC;重点看以下几个字段字段关注点type是否为 ALL全表扫描或 index 扫描key是否命中索引有没有可用索引rows预估扫描行数越大越危险Extra是否出现 Using filesort、Using temporary如果发现慢 SQL 频繁全表扫描或扫描行数远超实际返回行数这个方向就非常明确了。3.4 瓶颈汇总与优先级排序排查完成后把发现的问题汇总成一张表按“影响面 × 改动风险”排序问题影响面改动风险优先级慢 SQL 缺索引高低P0循环查询数据库高中P0大事务锁竞争严重高中P1外部接口超时过长中低P1无用日志刷盘低低P2原则是优先做“影响大、风险低”的改动先摘低垂的果实。不要一上来就重构核心模块。4. 代码与架构层面的“减脂”很多人以为优化就是加缓存、加索引其实代码层面的重复劳动和资源浪费往往比单次慢 SQL 更致命。4.1 消除循环调用数据库这是老系统里最常见的问题之一。比如查询订单列表后在 for 循环里逐个查询用户信息// 反例循环内查库 ListOrder orders orderMapper.selectPage(pageParam); for (Order order : orders) { User user userMapper.selectById(order.getUserId()); order.setUserName(user.getName()); }如果订单列表有 20 条这里就产生 20 次数据库查询。改成批量查询后只需要 2 次查询// 正例先查列表再批量查用户 ListOrder orders orderMapper.selectPage(pageParam); ListLong userIds orders.stream() .map(Order::getUserId) .distinct() .collect(Collectors.toList()); MapLong, User userMap userMapper.selectBatchIds(userIds).stream() .collect(Collectors.toMap(User::getId, Function.identity())); orders.forEach(order - { User user userMap.get(order.getUserId()); if (user ! null) { order.setUserName(user.getName()); } });这段代码的思路很简单但能显著降低数据库压力。实际项目里如果批量查询条数过多还要注意 IN 查询的条数上限拆成多批执行。4.2 缩小事务边界老系统的事务往往“顺手”就加到了方法级别。比如一个方法里先更新订单再调用外部接口最后更新库存整个过程都在一个事务里。表面看保证了数据一致性实际上外部接口调用时间被计入事务数据库连接持有时间变长锁竞争变严重。反例Transactional(rollbackFor Exception.class) public void processOrder(Order order) { orderMapper.updateStatus(order.getId(), PROCESSING); boolean success externalApi.notifyWarehouse(order); if (!success) { throw new BusinessException(通知仓库失败); } orderMapper.updateStatus(order.getId(), PROCESSED); }更好的做法是把事务控制在本地数据变更范围内外部调用放在事务外执行。如果必须保证最终一致性可以引入本地消息表或 MQ。public void processOrder(Order order) { orderMapper.updateStatus(order.getId(), PROCESSING); // 事务外通知仓库通过消息队列异步重试 mqSender.send(order.getId()); }注意这种改造会改变失败语义必须确保有补偿机制。如果没有 MQ 等基础设施不要硬改可以先从“移除事务内远程调用”这类小点入手。4.3 避免大对象与无用字段查询老系统查询列表时经常SELECT *把大字段也查出来然后只用其中两三个字段。数据量大时这会浪费大量内存和 IO。优化方式很简单查询时只返回需要的字段。-- 反例查询全部字段 SELECT * FROM q33_order WHERE buyer_id 12345; -- 正例只查列表展示需要字段 SELECT id, order_no, amount, status, create_time FROM q33_order WHERE buyer_id 12345;在代码层面也可以为列表查询单独定义轻量 VO避免把实体大对象全部序列化返回到前端。4.4 合理引入缓存缓存是提升性能的有效手段但引入缓存必须谨慎。老系统最大的风险是缓存与数据库不一致。常见做法是 Cache-Aside旁路缓存模式读请求先查缓存命中则直接返回未命中则查数据库把查询结果写入缓存更新数据时先更新数据库再删除缓存。示例思路如下public Order getOrderById(Long orderId) { String key order: orderId; String value redisTemplate.opsForValue().get(key); if (value ! null) { return JSON.parseObject(value, Order.class); } Order order orderMapper.selectById(orderId); if (order ! null) { // 设置过期时间避免缓存雪崩 redisTemplate.opsForValue().set(key, JSON.toJSONString(order), 30, TimeUnit.MINUTES); } return order; } public void updateOrder(Order order) { orderMapper.updateById(order); // 先更新数据库再删除缓存 String key order: order.getId(); redisTemplate.delete(key); }代码本身不复杂关键是设置合理的过期时间、监控缓存命中率以及对缓存击穿、穿透、雪崩有预案。5. 数据库优化实战从索引到 SQL 改写数据库往往是老系统“丝滑”与否的关键。很多高峰期故障的根因都是数据库连接被慢 SQL 拖垮。5.1 索引优化先看现有索引老系统的索引通常有两种极端一种是索引缺失严重大量查询走全表扫描另一种是索引建得太多写放大严重优化器选错索引。查看现有索引SHOW INDEX FROM q33_order;结合慢 SQL 和高频查询条件判断是否有必要新增联合索引。比如高频查询条件是“买家 ID 下单时间”那么联合索引设计为ALTER TABLE q33_order ADD INDEX idx_buyer_create_time (buyer_id, create_time);注意这里只是示例。线上加索引属于 DDL 变更要评估表的数据量、锁表风险尽量使用在线 DDL并在低峰期执行。5.2 SQL 改写避免隐式类型转换和函数包裹一个非常隐蔽的性能问题是隐式类型转换。比如order_no是 varchar 类型查询用数字比较索引会失效。-- 反例order_no 是 VARCHAR却传入数字 SELECT * FROM q33_order WHERE order_no 123456789; -- 正例与字段类型保持一致 SELECT * FROM q33_order WHERE order_no 123456789;另一个问题是把字段放在函数里-- 反例在索引字段上使用函数 SELECT * FROM q33_order WHERE DATE(create_time) 2024-01-01; -- 正例使用范围查询 SELECT * FROM q33_order WHERE create_time 2024-01-01 00:00:00 AND create_time 2024-01-02 00:00:00;5.3 分页优化深分页问题老系统列表分页经常这样写SELECT * FROM q33_order ORDER BY create_time DESC LIMIT 100000, 20;MySQL 的 LIMIT 深分页会扫描前面所有行然后丢弃非常耗费资源。可以用“延迟关联”或“基于游标”的方式优化。延迟关联思路SELECT t.id, t.order_no, t.amount FROM q33_order t INNER JOIN ( SELECT id FROM q33_order ORDER BY create_time DESC LIMIT 100000, 20 ) tmp ON t.id tmp.id;这种方式先通过覆盖索引找到主键再回表查询具体字段能显著降低扫描成本。更彻底的做法是改为基于上次查询位置的分页-- 客户端传入上一页最后一条记录的排序字段值 SELECT * FROM q33_order WHERE create_time #{lastCreateTime} ORDER BY create_time DESC LIMIT 20;这种游标分页在数据量大时体验更好但需要客户端配合改造。5.4 批量操作避免一条条执行老代码里批量更新经常是 for 循环里执行单条 UPDATE。如果确实无法改成批量 SQL可以评估用 JDBC 批量提交而不是每条自动提交。示例思路// 伪代码示意需要按实际数据库驱动调整 try (Connection conn dataSource.getConnection()) { conn.setAutoCommit(false); String sql UPDATE q33_order SET status ? WHERE id ?; try (PreparedStatement ps conn.prepareStatement(sql)) { for (Order order : orders) { ps.setInt(1, order.getStatus()); ps.setLong(2, order.getId()); ps.addBatch(); } ps.executeBatch(); conn.commit(); } catch (Exception e) { conn.rollback(); throw e; } }批量操作要控制批次大小避免单事务过大同时注意数据库连接超时配置。6. 配置与依赖现代化小改动大收益除了性能和 SQL老系统还有一个容易被忽视的问题配置和依赖的“僵尸化”。很多项目常年不升级依赖配置项散落在各台服务器改一个参数要登录好几台机器。6.1 配置外置化老项目的配置通常写在本地application.properties里部署时用sed替换。这样非常容易造成环境差异。建议引入配置中心或者至少统一把环境相关配置放到环境变量和部署平台上。以 Spring Boot 为例一份典型配置应该区分离线环境和运行环境# application.yaml公共配置 spring: application: name: q33-service datasource: hikari: maximum-pool-size: ${DB_POOL_SIZE:20} minimum-idle: ${DB_POOL_MIN_IDLE:5} connection-timeout: 3000 server: port: ${SERVER_PORT:8080} management: endpoints: web: exposure: include: health,info,metrics使用环境变量默认值的写法可以避免在代码仓库里写死数据库密码和线上地址。这里建议不要使用明文密码优先使用公司统一的密钥管理服务。6.2 依赖升级克制且谨慎升级依赖是老系统治理里收益高、但也容易踩坑的部分。比如老项目还在用早已停止维护的 Spring Boot 版本遇到安全漏洞或 JDK 兼容问题时非常被动。但盲目升级到最新版本也可能因为 API 变更导致大量代码编译不过。比较稳妥的路径是先梳理依赖树找到直接的冲突来源升级到当前所用大版本内的最新小版本编译并跑完整测试再评估是否跨大版本升级升级过程中保留旧的构建产物便于快速回滚。以 Maven 项目为例查看依赖树mvn dependency:tree -Dverbose示例输出中如果出现同一个组件多个版本说明依赖冲突需要用dependencyManagement统一版本。具体升级策略一定要以你当前项目的实际依赖为准不要照搬任何一份现成版本号清单。6.3 日志治理老系统慢日志也可能是“元凶”之一。常见问题包括核心接口打印大对象全量日志日志框架配置不当同步刷盘导致线程阻塞错误日志没有分级大量 WARN 把有效信息淹没日志文件没有清理策略磁盘被写满。日志治理要做的不是“不打印”而是“有效打印”。建议访问日志记录关键入参、耗时、结果码业务日志记录业务 ID、订单号、用户 ID异常日志记录堆栈摘要避免重复堆栈刷屏对超时、失败等关键事件使用独立统计指标。例如在代码里打印耗时日志时要区分正常路径和异常路径long start System.currentTimeMillis(); try { // 业务处理 Order result doProcess(orderId); long cost System.currentTimeMillis() - start; log.info(processOrder success, orderId{}, cost{}ms, orderId, cost); return result; } catch (Exception e) { long cost System.currentTimeMillis() - start; log.error(processOrder error, orderId{}, cost{}ms, orderId, cost, e); throw e; }注意日志中不要出现身份证号、手机号、密码等敏感信息避免数据泄露风险。7. 可观测性与稳定性保障让问题提前暴露老系统最怕的不是有问题而是出了问题没人知道、不知道影响范围、不知道从哪查起。所以可观测性和稳定性保障是治理过程中必须补的一课。7.1 建立监控大盘不一定要第一时间上全链路 Tracing但至少要有四个维度的监控应用监控QPS、RT、错误率、JVM、线程池数据库监控连接数、慢 SQL、锁等待、主从延迟中间件监控缓存命中率、MQ 堆积量基础设施监控CPU、内存、磁盘、网络。如果公司已经有 Prometheus 和 Grafana优先复用。没有的话可以先用 Spring Boot Actuator 暴露指标再接入监控体系。比如在 Spring Boot 中暴露健康检查和指标端点management: endpoints: web: exposure: include: health,info,metrics,prometheus metrics: tags: application: ${spring.application.name}这里的 prometheus 端点需要额外引入对应依赖。如果你用的 Spring Boot 版本较老配置前缀可能不同请以官方文档为准。7.2 限流、熔断与隔离老服务在高峰期退化往往是因为没有保护机制。一个慢接口会把线程池拖垮最终影响其他正常接口。常见的保护手段有限流保护自身不被突发流量打垮熔断下游异常时快速失败而不是无限等待隔离核心线程池与非核心线程池分离避免互相影响。以 Resilience4j 为例的配置思路如下版本差异较大请按实际依赖调整resilience4j: circuitbreaker: instances: q33-order-service: sliding-window-size: 10 failure-rate-threshold: 50 wait-duration-in-open-state: 10s timelimiter: instances: q33-order-service: timeout-duration: 3s配置外置后线上调参不用重新发版但也要注意配置变更的生效范围和回滚方案。7.3 灰度发布与快速回滚老系统改造风险高所以发布策略比改代码更重要。建议在改造期间采用灰度发布先在测试环境全量验证生产环境先灰度一台或一个 Zone观察核心指标无明显恶化后再逐步放量每一步都可以快速回滚。回滚方案不能只靠“重新部署上一个包”要提前准备好数据库变更的回滚脚本缓存清理预案依赖外部接口的开关配置回滚步骤。如果这次优化涉及 SQL 索引调整更要评估 DDL 回滚成本。因为索引一旦删除可能需要重新构建耗时较长。8. 常见问题排查清单与避坑指南下面整理了一份老服务优化过程中最常见的问题排查清单。遇到类似现象时可以按表格里的方向快速定位问题现象常见原因解决思路接口偶尔超时重启后恢复连接池耗尽或线程阻塞查看活跃连接数、线程栈调整连接池与超时CPU 居高不下死循环、频繁 GC、高消耗算法用 top -Hp jstack 定位线程GC 频繁且耗时高堆内存不足、大对象过多通过 jcmd 查看堆占用优化对象创建数据库连接池打满慢 SQL 太多或连接未释放定位慢 SQL检查代码中资源释放分页越来越慢LIMIT 深分页扫描过多改为延迟关联或游标分页缓存命中率低缓存过期时间过短、key 设计不合理统计命中率优化缓存策略日志导致磁盘写满日志无保留策略、单条日志过大配置日志轮转和归档发版后出现诡异报错依赖冲突或环境配置差异对比灰度前配置回滚并统一配置管理排查时记住一个清单先确认影响范围是全部接口还是单个接口先看监控指标CPU、内存、连接数、GC 曲线是否异常再抓证据线程栈、慢 SQL、错误日志最后再改代码每次只改一个变量验证一个结果。不要同时修改多个部分否则出了问题无法定位。这也是老系统优化最容易犯的错误。9. 最佳实践与工程建议经历过 Q33 这类老系统的整治后我最大的体会是技术问题最终都是“工程管理”问题。有几条实践建议想分享给你。9.1 把优化当成迭代任务而不是重构项目老系统承载着真实业务重构周期越长风险越高。更好的做法是把优化拆成小迭代每个迭代只做一项优化每项优化都要有明确指标和回归验证每项优化都要可回滚有测试环境验证尽量先补充关键路径测试。不要试图一口吃成胖子。一次改动 100 个文件的重构大概率会在上线后“翻车”。9.2 为关键链路补充自动化测试Q33 为什么没人敢动往往是因为没有测试。你改了一个看似无关的方法结果线上订单状态错了。补测试不需要覆盖全部历史代码优先覆盖资金、订单等核心链路被多个调用方复用的公共方法经常出现回归问题的模块。测试不是为了追求覆盖率数字而是给后续优化穿上“防弹衣”。9.3 命名、注释与代码可读性老代码刚接手时很难懂但你能做的是让“下一段代码”变得更好新代码遵循统一的命名规范深逻辑必须写注释说明业务背景不要在新的优化代码里继续堆积“魔法数字”删除无用代码时先确认没有其他调用方。比如突然看到一段查询条件if (status 3 || status 7) { // 为什么不直接写成 status in (3,7)背后的业务含义是什么 // 应该在注释里说明3已取消7退款中 }老代码里这类“不可解释”的逻辑特别多不要轻易删但新代码里不要再制造新的“未解之谜”。9.4 安全边界与权限最小化很多老系统运行多年数据库账号还是 DBA 权限应用配置里是明文密码。日常优化过程中顺便做一次安全体检应用账号是否只有所需库表的 DML 权限配置中心是否有访问控制对外接口是否有鉴权日志中是否含有敏感信息依赖组件是否存在已知高危漏洞。安全不是独立的阶段应该贯穿整个优化过程。任何涉及权限变更、配置变更的操作都要走审批流程并且在测试环境验证。9.5 文档沉淀把经验留下来老系统治理过程中最大的成果往往不是“变快了”而是团队终于搞清楚了系统是怎么运转的。建议把以下内容沉淀到文档核心链路图关键表结构说明常见问题排查手册发布与回滚操作步骤已知技术债清单。这份文档不追求漂亮追求“后来的人能照着操作”。很多老系统的问题本质上就是因为原来的知识都锁在个别人脑子里。10. 总结与学习路线老服务 Q33 的“丝滑”不会自己回来它需要有人愿意先花时间去理解再花耐心去微调。这篇实战笔记主要覆盖了以下几个方面老系统性能退化的本质是技术债积累而不是单纯的硬件瓶颈优化前必须做好现状盘点和性能基线采集排查要从接入层、应用层、数据层分层推进数据库索引、SQL 改写、分页优化是效果最明显的起步点代码层面要消除循环调用、缩小事务边界、合理引入缓存配置外置化、依赖升级、日志治理属于低风险高收益的治理项可观测性和发布回滚预案是确保改造安全的底线最佳实践的核心是“小步快跑、可度量、可回滚”。如果你接下来想深入学习可以按这样的顺序继续先掌握 JVM 和线程调优工具比如 jstat、jstack、jcmd、Arthas再系统学习数据库执行计划与索引原理然后研究缓存一致性、分布式事务等进阶主题最后了解可观测性体系包括指标、日志、链路追踪三支柱。最后留一个问题给你如果你的“Q33”就在你手上你敢不敢先做一次只观测、不修改的体检我建议你从今天下午开始。老系统不会自己变好但会在你一步步的衡量、调整和验证里重新恢复往日丝滑。