微服务拆分后，问题定位会变难。一个接口慢，可能慢在网关、服务 A、服务 B、数据库、Redis，也可能慢在某个远程调用。没有监控，排查基本靠猜。

一句话概括：微服务监控要解决问题定位、性能分析、服务关系和告警通知；SkyWalking 这类 APM 工具能把一次请求经过哪些服务、哪些接口慢、哪里报错串成一条链路。

为什么微服务必须做监控

单体项目里，一个请求大多在一个进程内完成。微服务拆分后，一次请求可能跨多个服务、多个数据库、多个中间件。

监控主要解决四件事：

目标	说明
问题定位	找到慢接口、异常接口、故障服务
性能分析	看每个服务、每个端点的耗时
服务关系	看服务之间的调用拓扑
服务告警	线上异常时第一时间通知负责人

常见工具有 Spring Boot Admin、Prometheus + Grafana、Zipkin、SkyWalking 等。

SkyWalking 是什么

SkyWalking 是一个分布式系统应用性能监控工具，也就是 APM 工具。它提供链路追踪、指标分析、服务拓扑、告警等能力。

课程里重点提到三个概念：

概念	含义
Service	服务，通常对应一个微服务应用
Endpoint	端点，通常对应一个接口或方法
Instance	实例，通常对应一台机器或一个进程

比如：

• user-service 是一个 Service。
• /api/user/login 是一个 Endpoint。
• 192.168.200.101 上运行的进程是一个 Instance。

SkyWalking 自身由哪些部分组成

如果面试官继续追问 SkyWalking 架构，可以按四个部分回答：

组件	作用
Agent	挂在应用进程上，采集调用链、SQL、接口耗时等数据
OAP Server	接收 Agent 数据，做分析、聚合和告警判断
Storage	存储链路和指标数据，常见是 Elasticsearch
UI	控制台页面，展示拓扑、Trace、指标和告警

这里的关键是 Agent。业务代码通常不用侵入式改造，Agent 会通过探针方式采集常见框架和中间件的调用信息。

一次链路追踪怎么看

SkyWalking 的价值不是“装了一个页面”，而是能把排查路径从猜测变成证据链。

项目里怎么描述监控

可以这样讲项目经验：

我们项目中使用 SkyWalking 做链路追踪和服务监控。它可以监控服务、接口、实例的状态，压测时能看到哪些服务和接口比较慢，然后针对性优化。上线后我们配置了告警规则，比如接口错误率、响应时间超过阈值时，通过短信或邮件通知相关负责人，方便第一时间定位和修复问题。

这段回答里有三个关键信息：

1. 不是只会部署，而是知道监控对象。
2. 知道它能用于压测性能分析。
3. 知道线上要配置告警闭环。

面试回答模板

可以这样答：

微服务系统调用链比较长，一个请求可能经过网关、多个服务和多个中间件，所以需要监控来做问题定位、性能分析、服务关系查看和告警。我们项目里使用 SkyWalking 做链路追踪，它能监控 service、endpoint、instance 的状态，也能看到一次请求经过了哪些服务、每个服务耗时多少。压测时可以根据慢接口定位瓶颈，上线后也可以配置告警规则，比如接口报错或响应时间超过阈值时通知负责人。

小结

微服务监控要讲清楚两层：

平时看拓扑和指标，出问题看 Trace 和告警。

只说“用了 SkyWalking”不够，能说出它帮你怎么定位慢接口，回答才像项目里真正用过。