微服务监控与运维体系:构建可观测的 Java 微服务

一、学习目标与重点
1.1 学习目标
- 理解微服务可观测性的核心概念(监控、日志、链路追踪)及价值,掌握微服务运维的核心痛点与解决方案。
- 熟练使用 Prometheus + Grafana 实现微服务指标监控,包括系统指标、业务指标的采集、可视化与告警。
- 掌握 ELK(Elasticsearch + Logstash + Kibana)日志收集与分析体系,实现分布式日志的集中管理与故障排查。
- 运用 SkyWalking 实现微服务链路追踪,定位跨服务调用的性能瓶颈与异常问题。
- 能够独立搭建完整的微服务运维体系,结合实际场景制定监控告警策略与故障排查流程。
1.2 学习重点
- 可观测性三大支柱(监控、日志、链路追踪)的协同工作原理。
- Prometheus 指标采集、PromQL 查询与 Grafana 仪表盘定制。
- ELK 日志收集流程与 Kibana 日志检索、可视化实战。
- SkyWalking 链路追踪的核心概念与分布式调用链分析。
- 微服务运维实战:告警配置、故障排查、性能优化案例。
二、微服务可观测性核心概念与体系设计
2.1 为什么需要可观测性?
💡 微服务架构下,系统被拆分为多个独立服务,部署在多台服务器或容器中,相比单体应用,运维复杂度呈指数级提升:
- 服务间依赖关系复杂,一个请求可能跨越多个服务(如用户下单→订单服务→商品服务→支付服务→物流服务),某个环节故障会导致整个流程失败。
- 分布式部署导致问题定位困难,传统单体应用的日志查看、断点调试方式失效。
- 流量波动频繁,需实时监控系统负载、响应时间等指标,提前预警潜在风险。
可观测性(Observability) 正是为解决这些问题而生,核心是通过收集系统的'信号'(指标、日志、链路),让系统的运行状态'可见',从而快速定位问题、优化性能、保障系统稳定。
可观测性的三大支柱:
- 监控(Metrics):以数值形式记录系统在不同时间点的状态(如 QPS、响应时间、错误率、CPU 使用率),支持实时告警与趋势分析。
- 日志(Logs):记录系统运行过程中的离散事件(如请求参数、错误堆栈、业务操作记录),是问题排查的核心依据。
- 链路追踪(Tracing):跟踪单个请求在分布式系统中的流转路径,记录每个环节的耗时,定位跨服务调用的性能瓶颈。
2.2 微服务可观测性体系架构
一个完整的微服务可观测性体系需覆盖'数据采集→数据存储→数据分析→可视化→告警'全流程,架构如下:
┌─────────────────────────────────────────────────────────────────┐ │ 微服务集群(user-service/order-service/product-service 等) │ └─┬───────────────┬───────────────┬───────────────┬───────────────┘ │ │ │ │ ┌─▼───────┐ ┌───▼───────┐ ┌───▼───────┐ ┌───▼───────┐ │指标采集 │ │日志采集 │ │链路采集 │ │健康检查 │ │(Prometheus)│ │(Filebeat)│ │(SkyWalking)│ │(Actuator)│ └─┬───────┘ └───┬───────┘ └───┬───────┘ └───┬───────┘ │ │ │ │ ┌─▼───────────────▼───────────────▼───────────────▼───────┐ │ 数据存储层 │ │ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ │ │ │ Prometheus │ │Elasticsearch│ │ SkyWalking │ │ │ │(指标存储) │ │(日志存储) │ │(链路存储) │ │ │ └─────────────┘ └─────────────┘ └─────────────┘ │ └─┬───────────────┬───────────────┬───────────────┬─────────┘ │ │ │ │ ┌─▼───────┐ ┌───▼───────┐ ┌───▼───────┐ ┌───▼───────┐ │Grafana │ │ Kibana │ │SkyWalking UI│ │ 告警系统 │ │(指标可视化)│ │(日志分析)│ │(链路分析)│ │(Email/钉钉)│ └─────────┘ └───────────┘ └───────────┘ └───────────┘
核心组件说明
| 组件 | 作用 | 核心优势 |
|---|
| Prometheus | 指标采集、存储与查询 | 时序数据库优化、PromQL 查询灵活、原生支持告警 |
| Grafana | 指标可视化与仪表盘定制 | 支持多数据源、图表类型丰富、配置简单 |
| Filebeat | 日志采集与转发 | 轻量级、低资源消耗、支持日志结构化 |
| Elasticsearch | 日志存储与检索 | 全文检索高效、支持海量日志存储 |
| Kibana | 日志可视化与分析 | 检索功能强大、支持日志聚合分析 |
| SkyWalking | 链路追踪、服务依赖分析 | 无侵入式采集、支持多语言、性能损耗低 |
| Spring Boot Actuator | 微服务健康检查与指标暴露 | 与 Spring Boot 无缝整合、配置简单 |
2.3 技术选型对比与推荐
2.3.1 监控工具对比
| 工具 | 适用场景 | 优势 | 不足 |
|---|
| Prometheus | 微服务指标监控、时序数据存储 | 开源免费、查询灵活、告警能力强 | 不适合存储非时序数据、长期存储需结合 Thanos |
| Zabbix | 服务器、硬件监控 | 成熟稳定、支持多设备监控 | 微服务指标采集能力弱、定制化成本高 |
| InfluxDB | 时序数据存储与监控 | 写入性能高、支持高并发 | 生态不如 Prometheus 完善 |
💡 推荐:Prometheus + Grafana(微服务监控首选,生态完善、与 Spring Cloud 无缝整合)。
2.3.2 日志工具对比
| 工具组合 | 适用场景 | 优势 | 不足 |
|---|
| ELK(Elasticsearch+Logstash+Kibana) | 海量日志收集、全文检索 | 功能强大、检索高效、可视化丰富 | Logstash 资源消耗高、部署复杂 |
| EFK(Elasticsearch+Filebeat+Kibana) | 海量日志收集、轻量级部署 | Filebeat 替代 Logstash,资源消耗低 | 日志处理能力弱于 Logstash |
| Loki(Prometheus 生态) | 日志与指标协同监控 | 存储成本低、与 Grafana 无缝整合 | 全文检索能力弱于 Elasticsearch |
💡 推荐:EFK(Elasticsearch + Filebeat + Kibana)(轻量级、高性能,满足大多数微服务日志需求)。
2.3.3 链路追踪工具对比
| 工具 | 适用场景 | 优势 | 不足 |
|---|
| SkyWalking | 微服务链路追踪、服务依赖分析 | 无侵入式、性能损耗低、支持多语言 | 生态不如 Jaeger 完善 |
| Jaeger | 分布式链路追踪(OpenTelemetry 兼容) | 开源免费、与 Kubernetes 整合好 | 对 Java 微服务的适配不如 SkyWalking |
| Zipkin | 简单链路追踪 | 部署简单、学习成本低 | 功能较基础、不支持复杂链路分析 |
💡 推荐:SkyWalking(Java 微服务首选,无侵入式采集、支持服务依赖图、性能指标与链路结合紧密)。
三、监控体系实战:Prometheus + Grafana
3.1 核心概念与环境准备
3.1.1 Prometheus 核心概念
- 指标(Metric):监控的核心数据,由名称和标签组成(如
http_requests_total{method="GET",status="200"}),支持 4 种类型:
- Counter(计数器):只增不减(如请求总数、错误总数)。
- Gauge(仪表盘):可增可减(如 CPU 使用率、内存使用率、当前在线人数)。
- Histogram(直方图):统计数值分布(如响应时间分布)。
- Summary(摘要):统计数值的分位数(如 P95、P99 响应时间)。
- 采集目标(Target):被监控的对象(如微服务实例、服务器)。
- 任务(Job):一组相同类型的 Target(如所有 user-service 实例)。
- PromQL:Prometheus 的查询语言,用于从时序数据库中检索指标数据。
3.1.2 环境准备
- 开发语言:Java 11
- 微服务框架:Spring Boot 2.7.x、Spring Cloud Alibaba 2021.0.4.0
- 监控工具:Prometheus 2.45.0、Grafana 10.2.0
- 依赖组件:Spring Boot Actuator、Micrometer Registry Prometheus(指标暴露组件)
3.2 微服务指标暴露(Actuator + Micrometer)
Spring Boot Actuator 提供了微服务的健康检查、指标暴露功能,Micrometer 则将 Actuator 的指标转换为 Prometheus 可识别的格式。
3.2.1 引入依赖(以 user-service 为例)
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-actuator</artifactId>
</dependency>
<dependency>
<groupId>io.micrometer</groupId>
<artifactId>micrometer-registry-prometheus</artifactId>
</dependency>
3.2.2 配置 application.yml
management:
endpoints:
web:
exposure:
include: health,info,prometheus
base-path: /actuator
endpoint:
health:
show-details: always
metrics:
tags:
application: ${spring.application.name}# 为指标添加应用名称标签(便于区分不同服务)
export:
prometheus:
enabled: true
business:
metrics:
order-count: 0
3.2.3 暴露自定义业务指标
除了 Actuator 默认提供的 JVM、HTTP 指标外,实际开发中需监控业务指标(如订单创建数、支付成功率),可通过 Micrometer 自定义:
import io.micrometer.core.instrument.Counter;
import io.micrometer.core.instrument.MeterRegistry;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.stereotype.Component;
@Component
public class BusinessMetrics {
private final Counter orderCreateCounter;
@Autowired
public BusinessMetrics(MeterRegistry meterRegistry) {
this.orderCreateCounter = Counter.builder("business.order.create.count")
.description("订单创建总数")
.tag("service", "order-service")
.register(meterRegistry);
}
public void incrementOrderCreateCount() {
orderCreateCounter.increment();
}
}
在 OrderController 中使用:
@RestController
public class OrderController {
@Autowired
private BusinessMetrics businessMetrics;
@GetMapping("/order/{userId}")
public Order createOrder(@PathVariable Long userId) {
businessMetrics.incrementOrderCreateCount();
return order;
}
}
3.2.4 验证指标暴露
启动 user-service,访问 http://localhost:8081/actuator/prometheus,可看到指标数据(如 JVM 内存使用、HTTP 请求数、自定义业务指标):
http_server_requests_seconds_count{application="user-service",exception="None",method="GET",outcome="SUCCESS",status="200",uri="/user/{id}",} 10.0
http_server_requests_seconds_sum{application="user-service",exception="None",method="GET",outcome="SUCCESS",status="200",uri="/user/{id}",} 0.567
business_order_create_count{service="order-service",} 5.0
3.3 Prometheus 部署与配置
3.3.1 安装 Prometheus
① 从 Prometheus 官网 下载 Prometheus(推荐 2.45.0 版本)。
② 解压后修改配置文件 prometheus.yml:
global:
scrape_interval: 15s
evaluation_interval: 15s
alerting:
alertmanagers:
- static_configs:
- targets:
scrape_configs:
- job_name: 'prometheus'
static_configs:
- targets: ['localhost:9090']
- job_name: 'user-service'
metrics_path: '/actuator/prometheus'
static_configs:
- targets: ['127.0.0.1:8081']
- job_name: 'order-service'
metrics_path: '/actuator/prometheus'
static_configs:
- targets: ['127.0.0.1:8082']
- job_name: 'product-service'
metrics_path:
[]
③ 启动 Prometheus:
- Windows:双击
prometheus.exe。
- Linux/Mac:执行
./prometheus --config.file=prometheus.yml。
④ 访问 http://localhost:9090,进入 Prometheus 控制台。
3.3.2 Prometheus 指标查询(PromQL)
在 Prometheus 控制台的'Graph'页面,可通过 PromQL 查询指标,常用查询示例:
| 需求 | PromQL 查询语句 |
|---|
| 查询 user-service 的 HTTP 请求总数 | http_server_requests_seconds_count{application="user-service"} |
| 查询 user-service 的 GET 请求错误率 | sum(http_server_requests_seconds_count{application="user-service",status=~"5.."} / sum(http_server_requests_seconds_count{application="user-service"})) * 100 |
| 查询 order-service 的订单创建总数 | business_order_create_count{service="order-service"} |
| 查询所有服务的 JVM 堆内存使用量 | jvm_memory_used_bytes{area="heap",application=~".+"} |
| 查询 user-service 的 P95 响应时间 | http_server_requests_seconds{application="user-service",quantile="0.95"} |
3.4 Grafana 可视化与告警配置
Prometheus 的可视化能力较弱,Grafana 可通过连接 Prometheus 数据源,生成美观、定制化的仪表盘,并支持告警功能。
3.4.1 安装与配置 Grafana
① 从 Grafana 官网 下载 Grafana(推荐 10.2.0 版本)。
② 启动 Grafana:
- Windows:双击
grafana-server.exe。
- Linux/Mac:执行
./grafana-server(默认端口 3000)。
③ 访问 http://localhost:3000,默认用户名/密码:admin/admin(首次登录需修改密码)。
3.4.2 添加 Prometheus 数据源
① 点击左侧'Configuration'→'Data Sources'→'Add data source'。
② 选择'Prometheus',配置数据源信息:
- Name:Prometheus(自定义名称)。
- URL:
http://localhost:9090(Prometheus 地址)。
- 其他默认,点击'Save & test',提示'Data source is working'则配置成功。
3.4.3 导入微服务监控仪表盘
Grafana 官网提供了大量现成的仪表盘模板(Dashboards),可直接导入使用:
① 搜索 Spring Boot 微服务相关模板,推荐模板 ID:
- 12900(Spring Boot 2.7+ 监控,包含 JVM、HTTP、业务指标)。
- 6756(微服务集群监控)。
② 点击左侧'Dashboards'→'Import',输入模板 ID,点击'Load'。
③ 选择数据源为之前配置的 Prometheus,点击'Import',即可看到完整的微服务监控仪表盘。
3.4.4 定制业务指标仪表盘
除了导入模板,还可自定义仪表盘展示业务指标(如订单创建数、支付成功率):
① 点击左侧'Dashboards'→'New dashboard'→'Add visualization'。
② 选择 Prometheus 数据源,输入 PromQL 查询语句(如 business_order_create_count{service="order-service"})。
③ 配置图表类型(如折线图、柱状图)、标题、坐标轴等,点击'Apply'。
④ 重复步骤②-③,添加多个业务指标图表,最终形成业务监控仪表盘。
3.4.5 配置告警规则
当指标超过阈值时(如错误率>5%、响应时间>1 秒),Grafana 需及时发送告警通知(邮件、钉钉、短信等):
① 配置告警通道:
- 点击左侧'Alerting'→'Contact points'→'Add contact point'。
- 选择告警类型(如 Email),配置 SMTP 信息(邮箱服务器、账号、密码),点击'Test'测试是否能正常发送邮件。
② 配置告警规则:
- 打开自定义的仪表盘,编辑某个图表(如响应时间图表),点击'Alert'→'Create alert rule'。
- 配置告警条件:
- Condition:
avg() of query(A, 5m) > 1(5 分钟内平均响应时间超过 1 秒)。
- For:
2m(持续 2 分钟触发告警)。
- 选择告警通道(如之前配置的 Email),设置告警标题和内容,点击'Save'。
③ 测试告警:
- 故意让微服务响应缓慢(如添加 Thread.sleep(2000)),等待 2 分钟后,即可收到告警邮件。
四、日志体系实战:ELK/EFK
4.1 核心概念与环境准备
4.1.1 EFK 核心组件
- Filebeat:轻量级日志采集工具,部署在微服务所在服务器,实时采集日志文件并转发到 Elasticsearch。
- Elasticsearch:分布式搜索引擎,用于存储和检索日志数据,支持全文检索和聚合分析。
- Kibana:日志可视化与分析平台,提供日志检索、过滤、图表展示等功能。
4.1.2 环境准备
- Elasticsearch 7.17.0(注意:Elasticsearch 与 Kibana 版本需一致)。
- Kibana 7.17.0。
- Filebeat 7.17.0。
- 微服务日志框架:SLF4J + Logback(默认集成)。
4.2 微服务日志配置(Logback)
首先需规范微服务的日志输出格式(结构化日志),便于 Elasticsearch 检索。
4.2.1 配置 Logback 日志文件
在 user-service 的 src/main/resources 目录下创建 logback-spring.xml:
<?xml version="1.0" encoding="UTF-8"?>
<configuration>
<property name="LOG_PATTERN" value='{"timestamp":"%d{yyyy-MM-dd HH:mm:ss.SSS}","level":"%p","thread":"%t","logger":"%logger{50}","message":"%msg","service":"${spring.application.name}","traceId":"%X{traceId:-}","exception":"%ex{full}"}'/>
<property name="LOG_PATH" value="logs/${spring.application.name}"/>
<appender name="CONSOLE" class="ch.qos.logback.core.ConsoleAppender">
<encoder class="ch.qos.logback.core.encoder.LayoutWrappingEncoder">
<layout class="ch.qos.logback.classic.PatternLayout">
<pattern>${LOG_PATTERN}</pattern>
</layout>
<charset>UTF-8</charset>
</encoder>
</appender>
<appender name="FILE" =>
${LOG_PATH}/app.log
${LOG_PATH}/app-%d{yyyy-MM-dd}.log
7
${LOG_PATTERN}
UTF-8
4.2.2 日志中添加链路追踪 ID(TraceID)
为了将日志与链路追踪关联,需在日志中添加 TraceID(每个请求的唯一标识),可通过 SkyWalking 或 Spring Cloud Sleuth 实现(此处以 SkyWalking 为例,后续链路追踪章节详细讲解)。
4.3 Elasticsearch 部署
① 从 Elasticsearch 官网 下载 Elasticsearch 7.17.0。
② 解压后修改 config/elasticsearch.yml:
cluster.name: elasticsearch-cluster
node.name: node-1# 节点名称
network.host: 0.0.0.0
http.port: 9200
discovery.seed_hosts:["127.0.0.1"]# 种子节点
cluster.initial_master_nodes:["node-1"]# 初始主节点
xpack.security.enabled:false# 关闭安全认证(开发环境)
③ 启动 Elasticsearch:
- Windows:双击
bin/elasticsearch.bat。
- Linux/Mac:执行
bin/elasticsearch。
④ 访问 http://localhost:9200,返回如下结果则启动成功:
{
"name": "node-1",
"cluster_name": "elasticsearch-cluster",
"cluster_uuid": "xxx",
"version": {
"number": "7.17.0",
"build_flavor": "default",
"build_type": "zip",
"build_hash": "xxx",
"build_date": "2022-01-28T08:36:04.875279988Z",
"build_snapshot": false,
"lucene_version": "8.11.1",
"minimum_wire_compatibility_version": "6.8.0",
"minimum_index_compatibility_version": "6.0.0-beta1"
},
"tagline": "You Know, for Search"
4.4 Filebeat 部署与配置
Filebeat 负责采集微服务的日志文件,并转发到 Elasticsearch。
① 从 Filebeat 官网 下载 Filebeat 7.17.0。
② 解压后修改 filebeat.yml:
filebeat.inputs:
- type: filestream
enabled: true
paths:
- D:\projects\user-service\logs\user-service\app-*.log
- D:\projects\order-service\logs\order-service\app-*.log
- D:\projects\product-service\logs\product-service\app-*.log
fields:
service: ${spring.application.name}# 自定义字段(服务名称)
output.elasticsearch:
hosts: ["localhost:9200"]
index: "micro-service-logs-%{+yyyy.MM.dd}"
setup.ilm.enabled: false
setup.template.enabled: false
setup.kibana:
host: "localhost:5601"
③ 启动 Filebeat:
- Windows:执行
filebeat.exe -e -c filebeat.yml。
- Linux/Mac:执行
./filebeat -e -c filebeat.yml。
4.5 Kibana 日志分析实战
4.5.1 Kibana 部署与配置
① 从 Kibana 官网 下载 Kibana 7.17.0。
② 解压后修改 config/kibana.yml:
server.port: 5601
server.host: "0.0.0.0"
elasticsearch.hosts: ["http://localhost:9200"]
i18n.locale: "zh-CN"
③ 启动 Kibana:
- Windows:双击
bin/kibana.bat。
- Linux/Mac:执行
bin/kibana。
④ 访问 http://localhost:5601,进入 Kibana 控制台。
4.5.2 创建索引模式
Kibana 需通过索引模式关联 Elasticsearch 中的日志索引:
① 点击左侧'Management'→'Stack Management'→'Index Patterns'→'Create index pattern'。
② 输入索引名称模式(如 micro-service-logs-*),点击'Next step'。
③ 选择时间字段(如 timestamp),点击'Create index pattern'。
4.5.3 日志检索与分析
① 点击左侧'Discover',选择创建的索引模式,即可看到所有微服务的日志。
② 常用检索功能:
- 全文检索:在搜索框输入关键词(如'订单创建失败'),检索包含该关键词的日志。
- 字段过滤:点击左侧字段列表(如
service、level),筛选特定服务(如 service:order-service)或特定日志级别(如 level:ERROR)的日志。
- 时间范围筛选:选择时间范围(如最近 1 小时、最近 24 小时),查看该时间段内的日志。
- 高亮显示:检索结果中关键词会高亮显示,便于快速定位。
③ 日志聚合分析:
- 点击左侧'Visualize Library'→'Create visualization',选择图表类型(如柱状图、饼图)。
- 配置聚合条件:如按
service 字段分组,统计各服务的 ERROR 日志数量,生成日志错误分布图表。
4.5.4 故障排查示例
假设用户反馈'下单失败',通过 Kibana 排查步骤:
- 筛选
service:order-service 且 level:ERROR 的日志,查看错误堆栈。
- 发现错误日志:
{"timestamp":"2024-05-20 14:30:00.123","level":"ERROR","thread":"http-nio-8082-exec-3","logger":"com.example.order.service.OrderService","message":"创建订单失败:库存不足","service":"order-service","traceId":"xxx","exception":"java.lang.RuntimeException: 库存不足..."}。
- 通过
traceId 检索该请求的所有日志(包括订单服务、商品服务的日志),定位到商品服务返回'库存不足'的响应。
- 进一步查看商品服务的日志,确认库存确实为 0,问题定位完成。
五、链路追踪实战:SkyWalking
5.1 核心概念与环境准备
5.1.1 SkyWalking 核心概念
- Trace(追踪):单个请求在分布式系统中的完整流转路径,由多个 Span 组成。
- Span(跨度):Trace 的基本单位,代表一次服务调用或一个本地方法执行,包含开始时间、结束时间、耗时、标签等信息。
- Segment(片段):一个微服务实例产生的 Span 集合,对应一个 Trace 的部分链路。
- 服务依赖图:展示微服务之间的调用关系(如 order-service 调用 user-service 和 product-service)。
- TraceID:Trace 的唯一标识,用于关联同一请求的所有日志和 Span。
5.1.2 环境准备
- SkyWalking OAP Server 8.16.0(链路数据存储与分析)。
- SkyWalking UI 8.16.0(链路可视化界面)。
- SkyWalking Agent 8.16.0(微服务链路采集代理,无侵入式)。
- 微服务框架:Spring Boot 2.7.x、Spring Cloud Alibaba 2021.0.4.0。
5.2 SkyWalking Server 部署
① 从 SkyWalking 官网 下载 SkyWalking 8.16.0(选择'Binary Distribution')。
② 解压后修改 config/application.yml(默认使用 H2 内存数据库,开发环境无需修改):
storage:
selector: ${SW_STORAGE:h2}# 存储类型(h2/elasticsearch/mysql 等)
h2:
driver: org.h2.jdbcx.JdbcDataSource
url: jdbc:h2:mem:skywalking-oap-db;DB_CLOSE_DELAY=-1
user: sa
metadataQueryMaxSize: 5000
③ 启动 SkyWalking Server:
- Windows:双击
bin/startup.bat。
- Linux/Mac:执行
bin/startup.sh。
④ 访问 http://localhost:8080,进入 SkyWalking UI(默认用户名/密码:admin/admin)。
5.3 微服务集成 SkyWalking Agent
SkyWalking Agent 采用无侵入式采集,通过 Java Agent 技术在微服务启动时挂载,无需修改代码。
5.3.1 配置 SkyWalking Agent
① 解压 SkyWalking 安装包中的 agent 目录(如 apache-skywalking-apm-bin/agent),复制到微服务项目目录下(或任意目录)。
② 修改 Agent 配置文件 agent/config/agent.config:
# 应用名称(与微服务名称一致)
agent.service_name=${SW_AGENT_NAME:user-service}
# SkyWalking Server 地址
collector.backend_service=${SW_AGENT_COLLECTOR_BACKEND_SERVICES:127.0.0.1:11800}
# 日志级别
logging.level=INFO
5.3.2 启动微服务时挂载 Agent
通过 JVM 参数 -javaagent 挂载 Agent,以 IDEA 为例:
① 打开微服务的启动配置(Edit Configurations)。
② 在'VM options'中添加:
-javaagent:D:\projects\agent\skywalking-agent.jar -DSW_AGENT_NAME=user-service -DSW_AGENT_COLLECTOR_BACKEND_SERVICES=127.0.0.1:11800
- 其中
D:\projects\agent\skywalking-agent.jar 为 Agent 的绝对路径。
SW_AGENT_NAME 为微服务名称(需与其他服务区分)。
③ 依次启动 user-service、order-service、product-service(每个服务需单独配置 Agent,修改 SW_AGENT_NAME)。
5.4 链路追踪实战与分析
5.4.1 触发分布式调用
访问 http://localhost:8082/order/1(order-service 调用 user-service 和 product-service),触发分布式调用。
5.4.2 查看链路追踪数据
① 进入 SkyWalking UI,点击左侧'Trace'→'Trace List',可看到所有 Trace 记录。
② 点击某个 Trace 的'Trace ID',进入链路详情页面,可查看:
- 整个请求的流转路径(order-service→user-service→product-service)。
- 每个 Span 的耗时(如 order-service 调用 user-service 耗时 50ms,调用 product-service 耗时 80ms)。
- 每个 Span 的详细信息(请求参数、响应结果、异常信息等)。
5.4.3 服务依赖图分析
点击左侧'Topology'→'Global',可查看微服务之间的依赖关系图,直观展示服务调用链路(如 order-service 依赖 user-service 和 product-service,product-service 无下游依赖)。
5.4.4 性能瓶颈定位示例
假设用户反馈'下单接口响应缓慢',通过 SkyWalking 排查步骤:
- 点击左侧'Trace'→'Trace List',筛选
service:order-service 且 duration>1000ms 的 Trace(响应时间超过 1 秒)。
- 查看链路详情,发现 order-service 调用 product-service 的 Span 耗时 900ms,占总耗时的 90%。
- 点击该 Span,查看详细信息,发现 product-service 的
/product/stock/deduct 接口耗时过长。
- 结合 Kibana 日志,查看 product-service 的该接口日志,发现库存扣减逻辑中存在数据库慢查询。
- 优化数据库索引后,重新测试,响应时间降至 200ms,问题解决。
5.4.5 业务指标与链路结合
SkyWalking 还支持将业务指标与链路关联,例如在链路中添加业务标签(如订单 ID、用户 ID),便于定位特定业务的链路问题:
import org.apache.skywalking.apm.toolkit.trace.TraceContext;
import org.apache.skywalking.apm.toolkit.trace.Tag;
import org.apache.skywalking.apm.toolkit.trace.Tags;
@RestController
public class OrderController {
@GetMapping("/order/{userId}")
@Tags({@Tag(key = "userId", value = "${userId}"), @Tag(key = "productId", value = "1")})
public Order createOrder(@PathVariable Long userId) {
String traceId = TraceContext.traceId();
System.out.println("TraceID: " + traceId);
return order;
}
}
重启微服务后,再次触发调用,在 SkyWalking UI 的 Trace 详情中可看到自定义标签(userId、productId),便于筛选特定用户或商品的链路。
六、微服务运维实战:告警、故障排查与性能优化
6.1 告警体系建设
一个完善的告警体系需覆盖'指标告警、日志告警、链路告警',确保问题早发现、早处理。
6.1.1 告警触发条件设计
| 告警类型 | 告警指标 | 阈值建议 | 告警级别 |
|---|
| 系统指标 | CPU 使用率 | 持续 5 分钟>80% | 警告 |
| 系统指标 | 内存使用率 | 持续 5 分钟>85% | 警告 |
| 系统指标 | 磁盘使用率 | 持续 10 分钟>90% | 严重 |
| 应用指标 | HTTP 错误率(5xx) | 持续 2 分钟>5% | 严重 |
| 应用指标 | 平均响应时间 | 持续 2 分钟>1 秒 | 警告 |
| 应用指标 | 服务不可用(健康检查失败) | 持续 1 分钟 | 严重 |
| 链路指标 | 链路错误率 | 持续 2 分钟>5% | 严重 |
| 链路指标 | 链路平均耗时 | 持续 2 分钟>2 秒 | 警告 |
| 日志指标 | ERROR 日志数 | 持续 1 分钟>10 条 | 警告 |
6.1.2 告警通知渠道选择
| 告警级别 | 通知渠道 | 说明 |
|---|
| 警告 | 钉钉群、企业微信群 | 批量通知,便于团队知晓 |
| 严重 | 短信、电话、邮件 + 钉钉群 | 紧急通知,确保负责人及时处理 |
6.2 故障排查流程
微服务故障排查需结合监控、日志、链路三大支柱,遵循'先定位范围,再细化排查'的原则,流程如下:
- 故障现象收集:明确用户反馈的问题(如'下单失败''接口响应慢')、发生时间、影响范围。
- 范围定位:
- 通过 SkyWalking UI 查看该时间段内的服务健康状态,判断是单个服务故障还是多个服务故障。
- 通过服务依赖图,判断故障是否由下游服务引发(如 order-service 故障可能是 product-service 不可用导致)。
- 指标分析:
- 通过 Grafana 查看故障服务的错误率、响应时间、QPS 等指标,确认是否存在性能瓶颈或流量突增。
- 日志检索:
- 通过 Kibana 检索故障服务的 ERROR 日志,查看错误堆栈和详细信息。
- 若涉及分布式调用,通过 TraceID 检索完整日志链路,定位问题环节。
- 链路追踪:
- 通过 SkyWalking 查看故障时间段的 Trace 记录,分析哪个 Span 耗时过长或出现异常。
- 问题修复与验证:
- 根据排查结果修复问题(如修复代码 bug、优化 SQL、扩容服务器)。
- 重新测试,通过监控、日志、链路确认问题是否解决。
6.3 性能优化案例
6.3.1 案例 1:数据库慢查询导致接口响应缓慢
现象:order-service 的下单接口响应时间超过 2 秒,SkyWalking 显示 product-service 的 /product/stock/deduct 接口耗时 1.8 秒。
排查:
- 通过 Kibana 查看 product-service 的日志,发现
deductStock 方法中执行的 SQL 语句耗时过长:SELECT * FROM product WHERE id=? FOR UPDATE(无索引)。
- 查看数据库表结构,发现 product 表的 id 字段未创建主键索引。
优化:
- 为 product 表的 id 字段创建主键索引:
ALTER TABLE product ADD PRIMARY KEY (id)。
- 优化 SQL 语句,只查询需要的字段:
SELECT id, stock FROM product WHERE id=? FOR UPDATE。
效果:接口响应时间降至 200ms,性能提升 90%。
6.3.2 案例 2:服务未做限流导致雪崩
现象:促销活动期间,user-service 的 QPS 突增到 5000,导致服务崩溃,依赖 user-service 的 order-service 和 product-service 也随之不可用。
排查:
- 通过 Grafana 查看 user-service 的 QPS 曲线,发现流量突增到 5000(远超服务承载能力 2000)。
- 查看 Sentinel 控制台,发现未配置限流规则。
优化:
- 在 Sentinel 控制台为 user-service 配置限流规则(QPS 阈值 2000)。
- 网关层添加限流规则,限制单个 IP 的请求频率(每秒最多 10 次)。
- 对 user-service 进行水平扩容,增加 2 个实例,提升服务承载能力。
效果:流量峰值被限制在 2000 QPS,服务稳定运行,未出现雪崩现象。
6.3.3 案例 3:分布式调用超时导致重试风暴
现象:order-service 调用 product-service 时频繁超时,导致大量重试,进而引发线程池耗尽。
排查:
- 通过 SkyWalking 查看链路,发现 product-service 的响应时间超过 5 秒(默认超时时间)。
- 查看 order-service 的配置,发现 Feign 重试次数配置为 3 次,且未设置超时时间。
优化:
- 配置 Feign 超时时间和重试次数:
feign:
client:
config:
default:
connect-timeout: 3000
read-timeout: 5000
retry:
enabled: true
max-attempts: 1
- 为 Feign 调用添加 Sentinel 熔断规则,避免频繁重试。
效果:超时请求及时失败,未引发重试风暴,线程池资源正常。
七、本章总结
✅ 本章详细讲解了微服务可观测性体系的三大支柱(监控、日志、链路追踪),通过 Prometheus + Grafana 实现指标监控与可视化,ELK/EFK 实现日志集中管理与分析,SkyWalking 实现分布式链路追踪,最终结合实战案例讲解了告警配置、故障排查与性能优化。
通过本章学习,读者应掌握:
- 微服务可观测性的核心价值与体系架构,理解监控、日志、链路追踪的协同工作原理。
- Prometheus + Grafana 的部署、配置与指标查询,能够定制监控仪表盘与告警规则。
- ELK/EFK 的日志收集流程与 Kibana 的日志检索、分析技巧,能够快速定位日志中的问题。
- SkyWalking 的无侵入式集成与链路分析,能够定位分布式调用的性能瓶颈。
- 微服务故障排查的标准流程与性能优化方法,能够独立解决常见的微服务运维问题。
微服务运维的核心是'可观测性',只有让系统的运行状态'可见、可测、可追溯',才能保障系统稳定运行。下一章将讲解微服务的容器化与云原生部署(Docker + Kubernetes),帮助读者构建完整的微服务部署体系。