微服务监控与运维体系：构建可观测的 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 种类型：
1. Counter（计数器）：只增不减（如请求总数、错误总数）。
2. Gauge（仪表盘）：可增可减（如 CPU 使用率、内存使用率、当前在线人数）。
3. Histogram（直方图）：统计数值分布（如响应时间分布）。
4. 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 为例）

<!-- Spring Boot Actuator：健康检查与指标暴露 -->
<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-actuator</artifactId>
</dependency>
<!-- Micrometer：适配 Prometheus -->
<dependency>
    <groupId>io.micrometer</groupId>
    <artifactId>micrometer-registry-prometheus</artifactId>
</dependency>

3.2.2 配置 application.yml

management:
  endpoints:
    web:
      exposure:
        include: health,info,prometheus # 暴露的端点（prometheus 为指标端点）
  base-path: /actuator # 端点基础路径（默认/actuator）
  endpoint:
    health:
      show-details: always # 健康检查显示详细信息
  metrics:
    tags:
      application: ${spring.application.name}# 为指标添加应用名称标签（便于区分不同服务）
  export:
    prometheus:
      enabled: true# 启用 Prometheus 指标导出
# 自定义业务指标（可选）
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 {
    // 订单创建计数器（Counter 类型，只增不减）
    private final Counter orderCreateCounter;

    // 注入 MeterRegistry，用于注册自定义指标
    @Autowired
    public BusinessMetrics(MeterRegistry meterRegistry) {
        this.orderCreateCounter = Counter.builder("business.order.create.count")
                .description("订单创建总数")
                .tag("service", "order-service")// 标签：服务名称
                .register(meterRegistry);
    }

    // 订单创建成功时调用（计数 +1）
    public void incrementOrderCreateCount() {
        orderCreateCounter.increment();
    }
}

在 OrderController 中使用：

@RestController
public class OrderController {
    @Autowired
    private BusinessMetrics businessMetrics;

    @GetMapping("/order/{userId}")
    public Order createOrder(@PathVariable Long userId) {
        // 订单创建逻辑（略）
        // 业务指标计数 +1
        businessMetrics.incrementOrderCreateCount();
        return order;
    }
}

3.2.4 验证指标暴露

启动 user-service，访问 http://localhost:8081/actuator/prometheus，可看到指标数据（如 JVM 内存使用、HTTP 请求数、自定义业务指标）：

# HELP http_server_requests_seconds HTTP server request duration
# TYPE http_server_requests_seconds summary
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
# HELP business_order_create_count 订单创建总数
# TYPE business_order_create_count counter
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 # 全局采集间隔（默认 15 秒）
  evaluation_interval: 15s # 规则评估间隔（默认 15 秒）
# 告警规则配置（后续讲解）
alerting:
  alertmanagers:
    - static_configs:
        - targets:
            # - alertmanager:9093
# 监控任务配置
scrape_configs:
  # 任务 1：监控 Prometheus 自身
  - job_name: 'prometheus'
    static_configs:
      - targets: ['localhost:9090']
  # 任务 2：监控 user-service
  - job_name: 'user-service'
    metrics_path: '/actuator/prometheus'# 指标端点路径
    static_configs:
      - targets: ['127.0.0.1:8081']# user-service 实例地址（多实例用逗号分隔）
  # 任务 3：监控 order-service
  - job_name: 'order-service'
    metrics_path: '/actuator/prometheus'
    static_configs:
      - targets: ['127.0.0.1:8082']# 任务 4：监控 product-service
  - 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>
    <!-- 日志输出格式（JSON 格式，便于结构化解析） -->
    <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 # 绑定所有 IP（允许外部访问）
http.port: 9200# HTTP 端口
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:
      # 微服务日志文件路径（多个服务用逗号分隔，或新增 inputs）
      - 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}# 自定义字段（服务名称）
# 输出到 Elasticsearch
output.elasticsearch:
  hosts: ["localhost:9200"]# Elasticsearch 地址
  index: "micro-service-logs-%{+yyyy.MM.dd}"# 日志索引名称（按天分割）
# 关闭 Elasticsearch 索引自动创建（可选）
setup.ilm.enabled: false
setup.template.enabled: false
# Kibana 配置（用于自动创建索引模式）
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# Kibana 端口
server.host: "0.0.0.0"# 允许外部访问
elasticsearch.hosts: ["http://localhost:9200"]# Elasticsearch 地址
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) {
        // 订单创建逻辑（略）
        // 获取当前 TraceID，添加到日志（已通过 Logback 配置自动实现）
        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# 连接超时 3 秒
        read-timeout: 5000# 读取超时 5 秒
        retry:
          enabled: true
          max-attempts: 1# 重试 1 次（默认 3 次）

为 Feign 调用添加 Sentinel 熔断规则，避免频繁重试。
效果：超时请求及时失败，未引发重试风暴，线程池资源正常。

七、本章总结

✅ 本章详细讲解了微服务可观测性体系的三大支柱（监控、日志、链路追踪），通过 Prometheus + Grafana 实现指标监控与可视化，ELK/EFK 实现日志集中管理与分析，SkyWalking 实现分布式链路追踪，最终结合实战案例讲解了告警配置、故障排查与性能优化。

通过本章学习，读者应掌握：

微服务可观测性的核心价值与体系架构，理解监控、日志、链路追踪的协同工作原理。
Prometheus + Grafana 的部署、配置与指标查询，能够定制监控仪表盘与告警规则。
ELK/EFK 的日志收集流程与 Kibana 的日志检索、分析技巧，能够快速定位日志中的问题。
SkyWalking 的无侵入式集成与链路分析，能够定位分布式调用的性能瓶颈。
微服务故障排查的标准流程与性能优化方法，能够独立解决常见的微服务运维问题。

微服务运维的核心是'可观测性'，只有让系统的运行状态'可见、可测、可追溯'，才能保障系统稳定运行。下一章将讲解微服务的容器化与云原生部署（Docker + Kubernetes），帮助读者构建完整的微服务部署体系。

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