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

核心组件说明

2.3 技术选型对比与推荐

2.3.1 监控工具对比

💡 推荐：Prometheus + Grafana（微服务监控首选，生态完善、与 Spring Cloud 无缝整合）。

2.3.2 日志工具对比

💡 推荐：EFK（Elasticsearch + Filebeat + Kibana）（轻量级、高性能，满足大多数微服务日志需求）。

2.3.3 链路追踪工具对比

💡 推荐：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: '/actuator/prometheus'
    static_configs:
      - targets: ['127.0.0.1:8083']

③ 启动 Prometheus：

• Windows：双击 prometheus.exe。
• Linux/Mac：执行 ./prometheus --config.file=prometheus.yml。
  ④ 访问 http://localhost:9090，进入 Prometheus 控制台。

3.3.2 Prometheus 指标查询（PromQL）

在 Prometheus 控制台的'Graph'页面，可通过 PromQL 查询指标，常用查询示例：

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" 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><!-- 保留 7 天日志 -->
        </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 部署

① 从 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 排查步骤：

1. 筛选 service:order-service 且 level:ERROR 的日志，查看错误堆栈。
2. 发现错误日志：{"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: 库存不足..."}。
3. 通过 traceId 检索该请求的所有日志（包括订单服务、商品服务的日志），定位到商品服务返回'库存不足'的响应。
4. 进一步查看商品服务的日志，确认库存确实为 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 排查步骤：

1. 点击左侧'Trace'→'Trace List'，筛选 service:order-service 且 duration>1000ms 的 Trace（响应时间超过 1 秒）。
2. 查看链路详情，发现 order-service 调用 product-service 的 Span 耗时 900ms，占总耗时的 90%。
3. 点击该 Span，查看详细信息，发现 product-service 的 /product/stock/deduct 接口耗时过长。
4. 结合 Kibana 日志，查看 product-service 的该接口日志，发现库存扣减逻辑中存在数据库慢查询。
5. 优化数据库索引后，重新测试，响应时间降至 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 告警触发条件设计

6.1.2 告警通知渠道选择

6.2 故障排查流程

微服务故障排查需结合监控、日志、链路三大支柱，遵循'先定位范围，再细化排查'的原则，流程如下：

1. 故障现象收集：明确用户反馈的问题（如'下单失败''接口响应慢'）、发生时间、影响范围。
2. 范围定位：
   • 通过 SkyWalking UI 查看该时间段内的服务健康状态，判断是单个服务故障还是多个服务故障。
   • 通过服务依赖图，判断故障是否由下游服务引发（如 order-service 故障可能是 product-service 不可用导致）。
3. 指标分析：
   • 通过 Grafana 查看故障服务的错误率、响应时间、QPS 等指标，确认是否存在性能瓶颈或流量突增。
4. 日志检索：
   • 通过 Kibana 检索故障服务的 ERROR 日志，查看错误堆栈和详细信息。
   • 若涉及分布式调用，通过 TraceID 检索完整日志链路，定位问题环节。
5. 链路追踪：
   • 通过 SkyWalking 查看故障时间段的 Trace 记录，分析哪个 Span 耗时过长或出现异常。
6. 问题修复与验证：
   • 根据排查结果修复问题（如修复代码 bug、优化 SQL、扩容服务器）。
   • 重新测试，通过监控、日志、链路确认问题是否解决。

6.3 性能优化案例

6.3.1 案例 1：数据库慢查询导致接口响应缓慢

现象：order-service 的下单接口响应时间超过 2 秒，SkyWalking 显示 product-service 的 /product/stock/deduct 接口耗时 1.8 秒。
排查：

1. 通过 Kibana 查看 product-service 的日志，发现 deductStock 方法中执行的 SQL 语句耗时过长：SELECT * FROM product WHERE id=? FOR UPDATE（无索引）。
2. 查看数据库表结构，发现 product 表的 id 字段未创建主键索引。
   优化：
3. 为 product 表的 id 字段创建主键索引：ALTER TABLE product ADD PRIMARY KEY (id)。
4. 优化 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 也随之不可用。
排查：

1. 通过 Grafana 查看 user-service 的 QPS 曲线，发现流量突增到 5000（远超服务承载能力 2000）。
2. 查看 Sentinel 控制台，发现未配置限流规则。
   优化：
3. 在 Sentinel 控制台为 user-service 配置限流规则（QPS 阈值 2000）。
4. 网关层添加限流规则，限制单个 IP 的请求频率（每秒最多 10 次）。
5. 对 user-service 进行水平扩容，增加 2 个实例，提升服务承载能力。
   效果：流量峰值被限制在 2000 QPS，服务稳定运行，未出现雪崩现象。

6.3.3 案例 3：分布式调用超时导致重试风暴

现象：order-service 调用 product-service 时频繁超时，导致大量重试，进而引发线程池耗尽。
排查：

1. 通过 SkyWalking 查看链路，发现 product-service 的响应时间超过 5 秒（默认超时时间）。
2. 查看 order-service 的配置，发现 Feign 重试次数配置为 3 次，且未设置超时时间。
   优化：
3. 配置 Feign 超时时间和重试次数：

feign:
  client:
    config:
      default:
        connect-timeout: 3000# 连接超时 3 秒
        read-timeout: 5000# 读取超时 5 秒
        retry:
          enabled: true
          max-attempts: 1# 重试 1 次（默认 3 次）

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

七、本章总结

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

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

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

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