微服务拆分精讲 / 第 17 章：故障排查
第 17 章：故障排查
分布式系统的故障排查是另一维度的挑战。一个请求经过 10 个服务，问题可能出在任何一个环节。
17.1 微服务常见故障类型
17.1.1 故障分类
┌──────────────────────────────────────────────────────────────┐
│ 微服务故障分类 │
├──────────────────────────────────────────────────────────────┤
│ │
│ ┌────────────────┐ ┌────────────────┐ ┌────────────────┐ │
│ │ 网络故障 │ │ 服务故障 │ │ 数据故障 │ │
│ ├────────────────┤ ├────────────────┤ ├────────────────┤ │
│ │ • 网络分区 │ │ • 服务崩溃 │ │ • 数据不一致 │ │
│ │ • DNS 解析失败 │ │ • OOM │ │ • 数据丢失 │ │
│ │ • 连接超时 │ │ • 死锁 │ │ • 数据损坏 │ │
│ │ • 带宽不足 │ │ • 线程池耗尽 │ │ • 缓存穿透 │ │
│ │ • 负载不均 │ │ • 内存泄漏 │ │ • 缓存雪崩 │ │
│ └────────────────┘ └────────────────┘ └────────────────┘ │
│ │
│ ┌────────────────┐ ┌────────────────┐ ┌────────────────┐ │
│ │ 配置故障 │ │ 安全故障 │ │ 依赖故障 │ │
│ ├────────────────┤ ├────────────────┤ ├────────────────┤ │
│ │ • 配置错误 │ │ • 认证失败 │ │ • 上游服务不可用│ │
│ │ • 环境变量缺失 │ │ • 证书过期 │ │ • 下游服务超时 │ │
│ │ • 版本不兼容 │ │ • Token 失效 │ │ • 第三方 API 故障│ │
│ └────────────────┘ └────────────────┘ └────────────────┘ │
└──────────────────────────────────────────────────────────────┘
17.1.2 故障频率排行
| 排名 |
故障类型 |
频率 |
影响范围 |
| 1 |
网络超时 |
极高 |
局部-全局 |
| 2 |
服务不可用 |
高 |
局部 |
| 3 |
内存泄漏/OOM |
中 |
单服务 |
| 4 |
数据库连接池耗尽 |
中 |
单服务-关联服务 |
| 5 |
配置错误 |
中 |
单服务 |
| 6 |
线程池/连接池死锁 |
低 |
单服务 |
| 7 |
数据不一致 |
低 |
业务层 |
17.2 分布式调试方法论
17.2.1 调试流程（RED 方法）
RED 调试法：
R - Reproduce (复现)
──────────────────
• 确认问题现象
• 收集错误日志和时间范围
• 确定影响范围
E - Explore (探索)
──────────────────
• 查看链路追踪（TraceID）
• 查看每个服务的日志
• 查看监控指标（QPS、延迟、错误率）
D - Diagnose (诊断)
──────────────────
• 定位问题根因
• 验证假设
• 制定修复方案
17.2.2 使用 TraceID 串联调试
场景：用户反馈下单失败
Step 1: 从用户请求中获取 TraceID
──────────────────────────────────
请求 Header: X-Request-ID: req-abc-123-def
Step 2: 在链路追踪系统中搜索
──────────────────────────────────
Jaeger/Tempo 搜索: traceID = req-abc-123-def
Trace 结果：
│
├── API Gateway (5ms) ✅
│ └── Order Service (150ms) ❌ 超时
│ ├── User Service (10ms) ✅
│ ├── Product Service (15ms) ✅
│ ├── Inventory Service (50ms) ✅
│ └── Payment Service (85ms) ❌ timeout!
│ └── Bank API: 连接超时
Step 3: 定位根因
─────────────────
Payment Service → Bank API 的调用超时
原因：银行 API 网络抖动
Step 4: 查看相关日志
─────────────────────
Loki 查询: {service="payment-service"} | json | traceId="req-abc-123-def"
日志结果：
[ERROR] Failed to call Bank API: Connection timeout after 5000ms
[WARN] Circuit breaker OPEN for Bank API
17.2.3 常用调试命令
# 1. 查看 Pod 状态
kubectl get pods -n production -l app=order-service
kubectl describe pod order-service-xxx -n production
# 2. 查看 Pod 日志
kubectl logs order-service-xxx -n production --tail=100
kubectl logs order-service-xxx -n production --previous # 查看上一个容器的日志
# 3. 进入容器调试
kubectl exec -it order-service-xxx -n production -- /bin/sh
# 4. 查看资源使用
kubectl top pods -n production -l app=order-service
# 5. 查看服务端点
kubectl get endpoints order-service -n production
# 6. DNS 解析测试
kubectl run debug --image=busybox -it --rm -- nslookup order-service.production.svc.cluster.local
# 7. 网络连通测试
kubectl run debug --image=curlimages/curl -it --rm -- curl -v http://order-service:8080/actuator/health
17.3 性能排查
17.3.1 性能问题定位流程
性能问题定位：
┌──────────────────────────────────────────────────────┐
│ 1. 确认问题现象 │
│ ├── P99 延迟从 100ms 升到 2s │
│ ├── 仅影响订单服务 │
│ └── 上午 10 点开始 │
└───────────────────────┬──────────────────────────────┘
▼
┌──────────────────────────────────────────────────────┐
│ 2. 查看基础设施指标 │
│ ├── CPU: 订单服务 Pod CPU 90%+ ❌ │
│ ├── Memory: 正常 60% │
│ ├── Network: 正常 │
│ └── Disk: 正常 │
└───────────────────────┬──────────────────────────────┘
▼
┌──────────────────────────────────────────────────────┐
│ 3. 查看应用指标 │
│ ├── JVM Heap: 正常 │
│ ├── GC: Full GC 频率增加 │
│ ├── Thread Count: 线程数 500+ (正常 200) ❌ │
│ ├── DB Connection: 连接池 50/50 (满) ❌ │
│ └── HTTP Connections: 大量 CLOSE_WAIT ❌ │
└───────────────────────┬──────────────────────────────┘
▼
┌──────────────────────────────────────────────────────┐
│ 4. 查看链路追踪 │
│ ├── 大量请求卡在 DB 查询 (平均 800ms) │
│ ├── DB 查询：SELECT * FROM orders WHERE ... (慢查询)│
│ └── 缺少索引 │
└───────────────────────┬──────────────────────────────┘
▼
┌──────────────────────────────────────────────────────┐
│ 5. 根因分析 │
│ 慢 SQL → 连接池等待 → 线程堆积 → CPU 升高 → 延迟飙升│
└───────────────────────┬──────────────────────────────┘
▼
┌──────────────────────────────────────────────────────┐
│ 6. 修复 │
│ ├── 添加数据库索引 │
│ ├── 优化 SQL 查询 │
│ └── 增加连接池大小 │
└──────────────────────────────────────────────────────┘
17.3.2 性能排查工具箱
| 工具 |
用途 |
使用场景 |
| Prometheus + Grafana |
指标监控 |
宏观性能趋势 |
| Jaeger/Tempo |
链路追踪 |
请求链路瓶颈 |
| Arthas |
Java 在线诊断 |
线程/方法级分析 |
| async-profiler |
Java 性能剖析 |
CPU/内存热点 |
| jstat/jmap |
JVM 诊断 |
GC/堆分析 |
| tcpdump |
网络抓包 |
网络层问题 |
| strace |
系统调用追踪 |
I/O 问题 |
17.3.3 Arthas 使用示例
# 安装 Arthas
curl -O https://arthas.aliyun.com/arthas-boot.jar
# 连接到目标 Java 进程
java -jar arthas-boot.jar
# 查看最繁忙的线程
thread -n 3
# 查看方法调用耗时
trace com.example.order.service.OrderService createOrder
# 查看方法调用栈
stack com.example.order.service.OrderService createOrder
# 查看对象属性
watch com.example.order.service.OrderService createOrder '{params, returnObj}' -x 2
# 反编译类
jad com.example.order.service.OrderService
# 监控方法调用（统计 QPS 和成功率）
monitor -c 5 com.example.order.service.OrderService createOrder
17.4 熔断与降级
17.4.1 熔断器模式回顾
熔断器状态转换：
正常流量 → CLOSED (所有请求通过)
│
│ 连续失败超过阈值 (如 5 次)
▼
OPEN (所有请求直接拒绝，返回降级响应)
│
│ 等待超时 (如 30 秒)
▼
HALF-OPEN (允许少量探测请求)
│
┌──────┴──────┐
│ │
探测成功 探测失败
│ │
▼ ▼
CLOSED OPEN
17.4.2 降级策略
| 策略 |
说明 |
示例 |
| 返回缓存数据 |
使用缓存中的旧数据 |
商品详情返回缓存 |
| 返回默认值 |
返回预设的默认值 |
推荐商品返回热门列表 |
| 功能降级 |
关闭非核心功能 |
关闭商品推荐 |
| 排队等待 |
请求排队，稍后处理 |
秒杀排队 |
| 友好提示 |
返回用户友好的错误信息 |
“系统繁忙，请稍后” |
17.4.3 Resilience4j 降级配置
@Service
public class OrderService {
@CircuitBreaker(name = "paymentService", fallbackMethod = "createOrderFallback")
@Retry(name = "paymentService")
@TimeLimiter(name = "paymentService")
public CompletableFuture<Order> createOrder(CreateOrderCommand command) {
// 正常逻辑
PaymentResult result = paymentClient.createPayment(command);
return CompletableFuture.completedFuture(new Order(command, result));
}
// 降级方法
public CompletableFuture<Order> createOrderFallback(CreateOrderCommand command,
Exception e) {
log.warn("支付服务不可用，订单进入待支付状态", e);
// 降级策略：创建订单但标记为待支付
Order order = new Order(command, OrderStatus.PENDING_PAYMENT);
orderRepository.save(order);
// 发送延迟消息，稍后重试支付
messageQueue.send("payment-retry", new PaymentRetryMessage(order.getId()));
return CompletableFuture.completedFuture(order);
}
}
17.4.4 Resilience4j 配置
# application.yml
resilience4j:
circuitbreaker:
instances:
paymentService:
slidingWindowSize: 10
failureRateThreshold: 50
waitDurationInOpenState: 30s
permittedNumberOfCallsInHalfOpenState: 3
registerHealthIndicator: true
retry:
instances:
paymentService:
maxAttempts: 3
waitDuration: 500ms
retryExceptions:
- java.io.IOException
- java.net.SocketTimeoutException
ignoreExceptions:
- com.example.BusinessException
timelimiter:
instances:
paymentService:
timeoutDuration: 5s
cancelRunningFuture: true
17.5 常见问题速查表
17.5.1 服务调用类
| 问题 |
可能原因 |
排查方法 |
解决方案 |
| 服务调用超时 |
下游服务慢/网络问题 |
TraceID 追踪 |
优化下游/增加超时 |
| 连接拒绝 |
连接池满/服务未启动 |
netstat / 日志 |
扩大连接池 |
| DNS 解析失败 |
CoreDNS 异常/Service 不存在 |
nslookup |
检查 Service 配置 |
| 502 Bad Gateway |
Pod 未就绪/健康检查失败 |
K8s 事件/日志 |
修复健康检查 |
| 连接池耗尽 |
连接泄漏/并发太高 |
监控指标 |
修复泄漏/扩容 |
17.5.2 数据类
| 问题 |
可能原因 |
排查方法 |
解决方案 |
| 数据不一致 |
分布式事务失败 |
数据校验脚本 |
补偿/修复数据 |
| 缓存穿透 |
大量不存在的 key 查询 |
监控 + 日志 |
布隆过滤器/缓存空值 |
| 缓存雪崩 |
大量 key 同时过期 |
监控 |
随机过期时间 |
| 慢 SQL |
缺少索引/全表扫描 |
慢查询日志 |
添加索引/优化 SQL |
| 死锁 |
并发更新同一行 |
DB 死锁日志 |
优化事务/减少锁范围 |
17.5.3 资源类
| 问题 |
可能原因 |
排查方法 |
解决方案 |
| OOM |
内存泄漏/堆太小 |
Heap Dump 分析 |
修复泄漏/增加内存 |
| CPU 100% |
死循环/大量计算 |
top/Arthas |
优化代码 |
| 磁盘满 |
日志太多/临时文件 |
df -h |
日志轮转/清理 |
| 线程池耗尽 |
慢操作占用线程 |
Thread Dump |
异步化/扩容 |
17.6 故障演练清单
定期故障演练（建议每月一次）：
┌───────────────────────────────────────────────────────────┐
│ 故障演练清单 │
├───────────────────────────────────────────────────────────┤
│ │
│ 基础设施层： │
│ □ 杀死一个服务 Pod → 验证自动重启 │
│ □ 杀死数据库主节点 → 验证主从切换 │
│ □ 注入网络延迟 500ms → 验证超时和熔断 │
│ □ 注入网络分区 → 验证服务降级 │
│ │
│ 应用层： │
│ □ 模拟支付服务不可用 → 验证订单降级 │
│ □ 模拟缓存全部失效 → 验证缓存穿透保护 │
│ □ 模拟消息队列堆积 → 验证消费追赶能力 │
│ □ 模拟数据库慢查询 → 验证连接池和超时 │
│ │
│ 业务层： │
│ □ 模拟秒杀流量 (10x) → 验证限流和排队 │
│ □ 模拟重复下单 → 验证幂等性 │
│ □ 模拟部分支付失败 → 验证补偿机制 │
└───────────────────────────────────────────────────────────┘
17.7 事后复盘（Postmortem）
17.7.1 复盘模板
# 故障复盘报告
## 基本信息
- **故障时间**: 2026-05-10 10:00 - 11:30 (90 分钟)
- **影响范围**: 订单服务不可用，影响约 30% 用户
- **严重程度**: P1
## 故障时间线
| 时间 | 事件 |
|------|------|
| 10:00 | 监控告警：订单服务 P99 延迟飙升到 5s |
| 10:05 | 值班人员确认问题，开始排查 |
| 10:15 | 定位到数据库慢查询 |
| 10:30 | 确认是全表扫描导致 |
| 10:45 | 紧急添加索引，准备上线 |
| 11:00 | 索引上线完成 |
| 11:30 | 性能恢复正常，故障结束 |
## 根因分析
订单表新增字段后，原有查询未更新索引，导致全表扫描。
## 修复措施
1. 紧急：添加缺失索引
2. 长期：SQL 变更需经过 DBA Review
## 改进项
| 改进项 | 负责人 | 截止日期 |
|--------|--------|----------|
| 添加慢 SQL 监控告警 | 张三 | 2026-05-20 |
| SQL 变更需 DBA Review | 李四 | 2026-05-15 |
| 补充索引覆盖度测试 | 王五 | 2026-05-25 |
⚠️ 注意事项
- 不要在故障中做大的改动——故障期间只做最小修复
- 保持冷静，按流程排查——恐慌会导致更多错误
- 及时沟通——故障期间保持团队和业务方的沟通
- 事后复盘不要追责——聚焦于流程和系统的改进
- 建立 Runbook——常见故障的处理手册
📖 扩展阅读
- Google SRE Book — 故障管理的最佳实践
- Arthas Documentation — Java 在线诊断工具
- Resilience4j — 弹性通信框架
- Site Reliability Engineering — O’Reilly SRE 实践
- The Phoenix Project — IT 运维小说（理解故障管理的重要性）
本章小结
| 要点 |
说明 |
| 调试方法 |
RED 方法：复现 → 探索 → 诊断 |
| 核心工具 |
TraceID 串联 + 链路追踪 + 日志聚合 |
| 性能排查 |
从宏观指标到微观线程的逐层分析 |
| 熔断降级 |
Resilience4j 实现熔断 + 降级策略 |
| 故障管理 |
定期演练 + 事后复盘 + Runbook |
📌 下一章：第 18 章：最佳实践 — 架构演进、组织架构、反模式总结。