概要

“这个接口昨天还是 200ms，今天突然变成 5 秒。”

遇到这类问题，最危险的做法是立即改线程池、加缓存或者重启服务。它们有时能暂时缓解问题，却可能掩盖真正原因，并给系统引入新的不确定性。

我做过中台慢接口治理、性能边界压测和高并发服务调优。面对接口变慢，我通常按照“先界定范围，再沿调用链缩小问题”的方式排查，重点检查以下五个位置。

一、先确认“慢”发生在哪里

第一步不是看代码，而是建立事实：

• 是平均耗时变慢，还是 P95/P99 尾延迟变慢？
• 是所有请求都慢，还是某类参数、租户或数据范围慢？
• 是单个实例慢，还是所有实例慢？
• 从什么时间开始？期间是否有发布、配置、数据量或流量变化？
• 服务端处理慢，还是网关排队、客户端网络或重试造成的慢？

高级 Java 与 AI 应用工程（五）：性能、DevOps 与生产可信

技术定位

性能工程回答系统在给定负载下能否满足 SLO；DevOps 将构建、测试、发布和回滚变成可重复流程；安全与可信研发限制身份、数据、依赖和操作风险。它们共同决定代码能否在生产环境长期运行，而不只是“功能能否演示”。

1. 性能工程的闭环

性能优化不是“把 TPS 跑高”，而是明确业务场景下的容量边界和服务质量。

1.1 先定义测什么

每个场景写清：业务动作、数据规模、并发模型、读写比例、依赖模拟方式、成功标准和失败阈值。核心指标至少包括吞吐（TPS/QPS）、P50/P95/P99 延迟、错误率、CPU、内存、GC、线程池、连接池、数据库负载和消息积压。