微服务拆分后，问题定位会变难。一个接口慢，可能慢在网关、服务 A、服务 B、数据库、Redis，也可能慢在某个远程调用。没有监控，排查基本靠猜。
一句话概括：微服务监控要解决问题定位、性能分析、服务关系和告警通知；SkyWalking 这类 APM 工具能把一次请求经过哪些服务、哪些接口慢、哪里报错串成一条链路。
用户请求
Gateway 网关
服务 A
服务 B
MySQL / Redis / MQ
SkyWalking Agent
采集链路数据
OAP 服务
分析与聚合
UI 控制台
拓扑、Trace、指标
告警规则
短信或邮件通知
为什么微服务必须做监控
单体项目里，一个请求大多在一个进程内完成。微服务拆分后，一次请求可能跨多个服务、多个数据库、多个中间件。
监控主要解决四件事：
| 目标 | 说明 |
|---|---|
| 问题定位 | 找到慢接口、异常接口、故障服务 |
| 性能分析 | 看每个服务、每个端点的耗时 |
| 服务关系 | 看服务之间的调用拓扑 |
| 服务告警 | 线上异常时第一时间通知负责人 |
常见工具有 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、指标和告警 |
业务服务 JVM
SkyWalking Agent
采集链路数据
OAP Server
分析和聚合
Storage
保存指标和 Trace
告警规则
判断异常
SkyWalking UI
查看拓扑和链路
短信 / 邮件通知
这里的关键是 Agent。业务代码通常不用侵入式改造，Agent 会通过探针方式采集常见框架和中间件的调用信息。
一次链路追踪怎么看
网关
业务服务
数据库
中间件
接口响应变慢
查看 SkyWalking Trace
定位请求经过的服务
查看每个 Span 耗时
耗时集中在哪里
检查路由、鉴权、限流
检查方法耗时和远程调用
检查 SQL 和索引
检查 Redis / MQ / ES
修复后观察指标
SkyWalking 的价值不是"装了一个页面"，而是能把排查路径从猜测变成证据链。
项目里怎么描述监控
可以这样讲项目经验：
我们项目中使用 SkyWalking 做链路追踪和服务监控。它可以监控服务、接口、实例的状态，压测时能看到哪些服务和接口比较慢，然后针对性优化。上线后我们配置了告警规则，比如接口错误率、响应时间超过阈值时，通过短信或邮件通知相关负责人，方便第一时间定位和修复问题。
这段回答里有三个关键信息：
- 不是只会部署，而是知道监控对象。
- 知道它能用于压测性能分析。
- 知道线上要配置告警闭环。
面试回答模板
可以这样答：
微服务系统调用链比较长，一个请求可能经过网关、多个服务和多个中间件，所以需要监控来做问题定位、性能分析、服务关系查看和告警。我们项目里使用 SkyWalking 做链路追踪，它能监控 service、endpoint、instance 的状态，也能看到一次请求经过了哪些服务、每个服务耗时多少。压测时可以根据慢接口定位瓶颈，上线后也可以配置告警规则，比如接口报错或响应时间超过阈值时通知负责人。
小结
微服务监控要讲清楚两层：
平时看拓扑和指标，出问题看 Trace 和告警。
只说"用了 SkyWalking"不够，能说出它帮你怎么定位慢接口，回答才像项目里真正用过。