05 微服务与线上排障
这一块在面试里是干什么的
主要看你:
- 有没有真实做过线上系统
- 出问题时会不会慌
- 是否具备“工程师”视角而不是“写功能”视角
什么是微服务
把一个大系统拆成多个小服务,每个服务独立开发、部署、扩展。
优点:
- 拆分清晰
- 可独立部署
- 团队协作更灵活
问题:
- 调用链更复杂
- 运维成本更高
- 分布式问题更多
注册中心是干什么的
服务实例地址会变,注册中心负责服务发现。
一句话:
“服务不用写死对方地址,而是从注册中心找到对方。”
网关是干什么的
统一请求入口,常见作用:
- 路由转发
- 认证鉴权
- 限流
- 日志
为什么需要限流
防止系统被突发流量打挂。
常见算法先知道名字:
- 计数器
- 漏桶
- 令牌桶
熔断和降级
- 熔断:下游异常太多时,先别继续调用
- 降级:返回兜底结果,保证系统还能用
一句话:
“限流是入口拦住,熔断是调用停掉,降级是功能退化。”
超时和重试
调用外部服务时一定要考虑。
重试不是越多越好,因为可能放大问题。
回答框架:
- 设置合理超时
- 控制重试次数
- 区分幂等和非幂等接口
分布式事务
短期先知道:
“分布式事务很难做到强一致,实际业务里常用最终一致性。”
常见思路:
- 消息事务
- 本地消息表
- 补偿机制
接口幂等
同一个请求重复执行多次,结果应尽量一致。
典型场景:
- 支付回调
- MQ 重复消费
- 前端重复提交
线上问题排查怎么答
非常高频,建议背一个固定模板。
回答顺序:
- 先确认现象
- 再看日志
- 看监控指标
- 看最近变更
- 逐步缩小范围
常见线上指标
- CPU
- 内存
- 磁盘
- 网络
- QPS
- RT
- 错误率
常见线上问题
CPU 飙高
可能原因:
- 死循环
- 大量计算
- 频繁 GC
- 锁竞争
内存飙高
可能原因:
- 对象堆积
- 缓存过大
- 内存泄漏
- 请求积压
接口变慢
可能原因:
- 慢 SQL
- 远程调用变慢
- 线程池打满
- 锁竞争
日志怎么看
重点不是“多看日志”,而是要有顺序:
- 按时间定位
- 按 traceId 串调用链
- 找 error 和 warn
- 对比正常请求和异常请求差异
线程池打满怎么答
这是高频故障题。
回答框架:
- 先确认线程池队列和活跃线程数
- 看是任务执行太慢还是流量太高
- 排查慢 SQL、远程调用、锁等待
- 临时扩容只是缓解,不是根治
高频快答
为什么微服务比单体复杂
因为网络调用、服务发现、限流、熔断、链路追踪这些分布式问题都会出现。
如何保证接口不被重复提交
幂等 token、唯一请求号、状态控制。
遇到线上故障先做什么
先止血,再定位,再复盘。
这一章最小记忆包
- 微服务重点记网关、注册中心、限流、熔断、降级
- 线上排障重点记“现象 -> 日志 -> 监控 -> 变更”
- 慢接口优先查 SQL、远程调用、线程池
- 分布式事务先答最终一致性,不要硬说强一致