跳到主要内容 微服务监控与运维体系：构建可观测的 Java 微服务 | 极客日志
Java java
微服务监控与运维体系：构建可观测的 Java 微服务 微服务架构下系统复杂度提升，需构建可观测性体系。本章介绍基于 Java Spring Boot 的微服务监控方案，涵盖指标监控（Prometheus+Grafana）、日志收集（ELK/EFK）及链路追踪（SkyWalking）。详细讲解 Actuator 暴露指标、自定义业务监控、PromQL 查询、Grafana 仪表盘定制与告警配置。同时阐述 Filebeat 采集日志至 Elasticsearch 并通过 Kibana 分析的方法，以及 SkyWalking Agent 无侵入式集成与调用链分析。结合实战案例演示故障排查流程与性能优化策略，如数据库慢查询修复、限流防雪崩及超时重试治理，帮助开发者建立完整的微服务运维体系。
苹果系统 发布于 2026/2/21 更新于 2026/4/18 微服务监控与运维体系：构建可观测的 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/钉钉)│ └─────────┘ └───────────┘ └───────────┘ └───────────┘
微信扫一扫，关注极客日志 微信公众号「极客日志」，在微信中扫描左侧二维码关注。展示文案：极客日志 zeeklog
相关免费在线工具 Keycode 信息 查找任何按下的键的javascript键代码、代码、位置和修饰符。 在线工具，Keycode 信息在线工具，online
Escape 与 Native 编解码 JavaScript 字符串转义/反转义；Java 风格 \uXXXX（Native2Ascii）编码与解码。 在线工具，Escape 与 Native 编解码在线工具，online
JavaScript / HTML 格式化 使用 Prettier 在浏览器内格式化 JavaScript 或 HTML 片段。 在线工具，JavaScript / HTML 格式化在线工具，online
JavaScript 压缩与混淆 Terser 压缩、变量名混淆，或 javascript-obfuscator 高强度混淆（体积会增大）。 在线工具，JavaScript 压缩与混淆在线工具，online
Base64 字符串编码/解码 将字符串编码和解码为其 Base64 格式表示形式即可。 在线工具，Base64 字符串编码/解码在线工具，online
Base64 文件转换器 将字符串、文件或图像转换为其 Base64 表示形式。 在线工具，Base64 文件转换器在线工具，online
核心组件说明 组件 作用 核心优势 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();
}
}
@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: '/actuator/prometheus'
static_configs:
- targets: ['127.0.0.1:8083' ]
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 版本）。
Windows：双击 grafana-server.exe。
Linux/Mac：执行 ./grafana-server（默认端口 3000）。http://localhost:3000，默认用户名/密码：admin/admin（首次登录需修改密码）。
3.4.2 添加 Prometheus 数据源 ① 点击左侧'Configuration'→'Data Sources'→'Add data source'。
Name：Prometheus（自定义名称）。
URL：http://localhost:9090（Prometheus 地址）。
其他默认，点击'Save & test'，提示'Data source is working'则配置成功。
3.4.3 导入微服务监控仪表盘 ① 搜索 Spring Boot 微服务相关模板，推荐模板 ID：
12900（Spring Boot 2.7+ 监控，包含 JVM、HTTP、业务指标）。
6756（微服务集群监控）。
3.4.4 定制业务指标仪表盘 除了导入模板，还可自定义仪表盘展示业务指标（如订单创建数、支付成功率）：
① 点击左侧'Dashboards'→'New dashboard'→'Add visualization'。business_order_create_count{service="order-service"}）。
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" class ="ch.qos.logback.core.rolling.RollingFileAppender" >
<file > ${LOG_PATH}/app.log</file >
<rollingPolicy class ="ch.qos.logback.core.rolling.TimeBasedRollingPolicy" >
<fileNamePattern > ${LOG_PATH}/app-%d{yyyy-MM-dd}.log</fileNamePattern >
<maxHistory > 7</maxHistory >
</rollingPolicy >
<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 >
<root level ="INFO" >
<appender-ref ref ="CONSOLE" />
<appender-ref ref ="FILE" />
</root >
<logger name ="com.example.order.service" level ="DEBUG" />
</configuration >
4.2.2 日志中添加链路追踪 ID（TraceID） 为了将日志与链路追踪关联，需在日志中添加 TraceID（每个请求的唯一标识），可通过 SkyWalking 或 Spring Cloud Sleuth 实现（此处以 SkyWalking 为例，后续链路追踪章节详细讲解）。
4.3 Elasticsearch 部署 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# 关闭安全认证（开发环境）
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"
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"
Windows：双击 bin/kibana.bat。
Linux/Mac：执行 bin/kibana。http://localhost:5601，进入 Kibana 控制台。
4.5.2 创建索引模式 Kibana 需通过索引模式关联 Elasticsearch 中的日志索引：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
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/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 为例：
-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 为微服务名称（需与其他服务区分）。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 记录。
整个请求的流转路径（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），帮助读者构建完整的微服务部署体系。
