分布式微服务核心技术体系个人笔记

本笔记梳理微服务架构下，从消息中间件集成、全链路监控、分布式核心理论到分布式事务的全链路核心原理与落地实操，所有内容均贴合Spring Cloud Alibaba主流生态，低侵入、可直接复用。

第一章 微服务架构核心基础

1.1 核心技术栈

主流微服务架构以 Spring Cloud Alibaba 为核心生态，官方最新稳定版本适配关系如下：

Spring Cloud Alibaba Version	Spring Cloud Version	Spring Boot Version	JDK版本要求
2025.1.0.0	2025.1.0	4.0.0	21+ LTS
2025.0.0.0	2025.0.0	3.5.0	17+

生态核心组件：

• 服务注册/配置中心： Nacos
• API网关： Spring Cloud Gateway
• 服务调用： OpenFeign + LoadBalancer
• 限流熔断降级： Sentinel
• 分布式事务： Seata
• 缓存： Redis
• 数据库： MySQL

1.2 微服务核心模块通用职责

标准微服务架构的核心模块划分，职责单一、可独立部署：

模块类型	核心职责
网关服务	统一流量入口、路由转发、鉴权验签、限流熔断、请求日志记录
认证中心	统一登录认证、Token签发与校验、OAuth2权限管理
业务服务	核心业务逻辑实现，如用户管理、订单管理、库存管理等
文件服务	统一文件上传、存储、下载、预览能力
定时任务服务	分布式定时任务调度、失败重试、执行日志管理
公共依赖模块	全局工具类、通用配置、安全组件、常量定义等公共能力
API定义模块	跨服务调用的Feign接口定义、出入参实体统一管理

1.3 版本适配关键说明

1. Spring Cloud Alibaba 2025.1.0.0+ 版本已正式废弃bootstrap.yml配置文件，统一使用spring.config.import机制实现配置预加载。
2. Spring Boot 3.x+ 版本基于Jakarta EE 10，需使用JDK 17及以上版本，不可兼容JDK 8。
3. 所有组件版本需与Spring Cloud Alibaba主版本严格对应，避免出现兼容性问题，依赖版本统一通过父工程dependencyManagement管理。

【核心记忆点】 微服务架构的核心是「分而治之」，Spring Cloud Alibaba提供了一站式生产级组件，版本适配是落地的第一前提。

---

🐇 第二章 RabbitMQ 消息队列全流程落地

2.1 前置环境准备

RabbitMQ是基于AMQP协议的开源消息中间件，核心解决微服务间异步解耦、流量削峰、系统解耦等问题，Docker一键启动命令（带管理控制台）：

docker run -d \
--name rabbitmq \
-p 5672:5672 \
-p 15672:15672 \
-e RABBITMQ_DEFAULT_USER=guest \
-e RABBITMQ_DEFAULT_PASS=guest \
rabbitmq:3-management

管理控制台地址：http://localhost:15672，默认账号密码`guest/guest`。

2.2 依赖引入

在Spring Boot/Spring Cloud项目的pom.xml中引入核心依赖，父工程已统一管理版本时无需指定版本号：

<!-- RabbitMQ 核心依赖 -->
<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-amqp</artifactId>
</dependency>

2.3 生产级核心配置

在项目application.yml中添加配置，覆盖消息可靠投递、消费确认、连接池等生产环境必备配置：

spring:
  rabbitmq:
    host: 127.0.0.1
    port: 5672
    username: guest
    password: guest
    virtual-host: /
    # 连接池配置
    cache:
      channel:
        size: 10
      connection:
        size: 5
    # 生产者消息可靠投递
    publisher-confirm-type: correlated
    publisher-returns: true
    template:
      mandatory: true
    # 消费者配置
    listener:
      simple:
        acknowledge-mode: manual # 手动ACK，生产环境必开，防止消息丢失
        concurrency: 1 # 最小消费线程数
        max-concurrency: 5 # 最大消费线程数
        prefetch: 1 # 每次预取1条消息，避免消息堆积
        retry:
          enabled: true # 开启消费重试

2.4 核心配置类（队列/交换机/绑定）

通过配置类统一声明队列、交换机、绑定关系，持久化配置避免重启后元数据丢失，同时内置死信队列处理消费失败的消息：

@Configuration
public class RabbitMqConfig {
    // 业务队列常量定义
    public static final String BIZ_TEST_QUEUE = "biz.test.queue";
    public static final String BIZ_TEST_EXCHANGE = "biz.test.exchange";
    public static final String BIZ_TEST_ROUTING_KEY = "biz.test.msg";
    // 死信队列常量定义
    public static final String DLX_QUEUE = "dlx.queue";
    public static final String DLX_EXCHANGE = "dlx.exchange";
    public static final String DLX_ROUTING_KEY = "dlx.key";

    // 1. 声明持久化业务队列，绑定死信交换机
    @Bean
    public Queue bizTestQueue() {
        return QueueBuilder.durable(BIZ_TEST_QUEUE)
                .deadLetterExchange(DLX_EXCHANGE)
                .deadLetterRoutingKey(DLX_ROUTING_KEY)
                .build();
    }

    // 2. 声明Topic交换机（支持通配符路由，最常用）
    @Bean
    public TopicExchange bizTestExchange() {
        return ExchangeBuilder.topicExchange(BIZ_TEST_EXCHANGE).durable(true).build();
    }

    // 3. 队列与交换机绑定
    @Bean
    public Binding bizBinding(Queue bizTestQueue, TopicExchange bizTestExchange) {
        return BindingBuilder.bind(bizTestQueue).to(bizTestExchange).with(BIZ_TEST_ROUTING_KEY);
    }

    // 4. 死信队列与交换机配置
    @Bean
    public Queue dlxQueue() {
        return QueueBuilder.durable(DLX_QUEUE).build();
    }

    @Bean
    public DirectExchange dlxExchange() {
        return ExchangeBuilder.directExchange(DLX_EXCHANGE).durable(true).build();
    }

    @Bean
    public Binding dlxBinding(Queue dlxQueue, DirectExchange dlxExchange) {
        return BindingBuilder.bind(dlxQueue).to(dlxExchange).with(DLX_ROUTING_KEY);
    }
}

2.5 生产者与消费者标准实现

生产者（消息发送）

@Slf4j
@Service
public class MqMessageProducer {
    @Autowired
    private RabbitTemplate rabbitTemplate;

    /**
     * 发送业务消息
     * @param content 消息内容
     */
    public void sendBizMessage(String content) {
        log.info("发送MQ消息：{}", content);
        rabbitTemplate.convertAndSend(
                RabbitMqConfig.BIZ_TEST_EXCHANGE,
                RabbitMqConfig.BIZ_TEST_ROUTING_KEY,
                content
        );
    }
}

消费者（消息监听与处理）

@Slf4j
@Service
public class MqMessageConsumer {
    @RabbitListener(queues = RabbitMqConfig.BIZ_TEST_QUEUE)
    public void handleMessage(String msg, Message message, Channel channel) throws Exception {
        // 获取消息投递标签，用于ACK确认
        long deliveryTag = message.getMessageProperties().getDeliveryTag();
        try {
            log.info("接收MQ消息：{}", msg);
            // ======================
            // 核心业务逻辑处理
            // ======================
            // 手动确认：消息消费成功
            channel.basicAck(deliveryTag, false);
        } catch (Exception e) {
            log.error("消息消费异常", e);
            // 消费失败：拒绝消息，根据重试次数决定是否入死信队列
            // 第三个参数requeue=true：重回队列重试；false：直接进入死信队列
            channel.basicNack(deliveryTag, false, false);
        }
    }
}

2.6 嵌入原有业务的标准方案

零修改原有业务逻辑，仅新增2处代码，实现业务执行后异步发送消息，以用户新增场景为例：

1. 业务Service中注入RabbitTemplate

// 新增导入
import org.springframework.amqp.rabbit.core.RabbitTemplate;

@Service
public class UserServiceImpl implements UserService {
    // 原有注入完全不动
    @Autowired
    private UserMapper userMapper;
    // 新增：注入MQ模板
    @Autowired
    private RabbitTemplate rabbitTemplate;

1. 原有业务方法末尾追加消息发送代码，与本地事务绑定保证原子性

@Override
@Transactional(rollbackFor = Exception.class)
public int addUser(User user) {
    // 原有业务逻辑完全不动
    checkUserUnique(user);
    user.setCreateTime(LocalDateTime.now());
    int rows = userMapper.insert(user);
    // 新增：业务执行成功后发送MQ消息
    if (rows > 0) {
        String msgContent = "新增用户成功，账号：" + user.getUsername() + "，时间：" + LocalDateTime.now();
        rabbitTemplate.convertAndSend(
                RabbitMqConfig.BIZ_TEST_EXCHANGE,
                RabbitMqConfig.BIZ_TEST_ROUTING_KEY,
                msgContent
        );
    }
    return rows;
}

2.7 常见报错与解决方案

报错现象	核心根因	解决方案
找不到RabbitTemplate的Bean	未引入amqp依赖、未配置rabbitmq连接信息、服务未重启	补全依赖和配置，重启项目
消息消费后无故丢失	未开启手动ACK，默认自动ACK，消费异常时消息已被标记为已消费	开启manual手动ACK模式，异常时用basicNack处理
消息无法路由到队列	交换机与队列绑定关系错误、路由key不匹配	检查绑定配置，开启publisher-returns回调
消费者频繁重复消费	消息处理逻辑异常，一直重回队列重试	限制重试次数，超过阈值后入死信队列，人工兜底

【核心记忆点】 RabbitMQ集成核心是「依赖+配置+配置类」三件套，生产环境必须开启手动ACK和死信队列，保证消息不丢失、不重复消费。

---

 第三章 微服务全链路监控体系

3.1 微服务监控核心维度与组件选型

微服务监控需覆盖四大核心维度，对应主流组件选型如下：

监控维度	核心目标	主流组件选型
服务健康监控	实时感知服务在线状态、JVM指标、健康度	Spring Boot Admin
注册配置监控	服务注册状态、心跳、配置推送记录	Nacos原生控制台
全链路追踪	跨服务调用链路可视化、慢接口定位、异常根因分析	SkyWalking
业务指标监控	自定义业务指标可视化、告警、趋势分析	Prometheus + Grafana
服务器硬件监控	服务器CPU、内存、磁盘、网络负载	Prometheus Node Exporter

3.2 Spring Boot Admin 服务健康监控

Spring Boot Admin是针对Spring Boot应用的监控管理工具，提供可视化界面实时监控应用状态、JVM指标、日志级别调整等能力。

服务端部署

1. 新建独立的监控服务模块，引入核心依赖：

<!-- Spring Boot Admin Server 核心依赖 -->
<dependency>
    <groupId>de.codecentric</groupId>
    <artifactId>spring-boot-admin-starter-server</artifactId>
    <version>3.4.0</version>
</dependency>
<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-web</artifactId>
</dependency>

1. 启动类添加@EnableAdminServer注解开启服务：

@EnableAdminServer
@SpringBootApplication
public class MonitorApplication {
    public static void main(String[] args) {
        SpringApplication.run(MonitorApplication.class, args);
    }
}

1. 配置文件application.yml：

server:
  port: 9090
spring:
  application:
    name: monitor-server

客户端接入
所有需要被监控的微服务，引入客户端依赖并配置服务端地址：

1. 引入依赖：

<dependency>
    <groupId>de.codecentric</groupId>
    <artifactId>spring-boot-admin-starter-client</artifactId>
    <version>3.4.0</version>
</dependency>

1. 配置文件添加：

spring:
  boot:
    admin:
      client:
        url: http://127.0.0.1:9090 # Spring Boot Admin服务端地址
  application:
    name: user-service # 当前服务名称，会显示在监控面板
management:
  endpoints:
    web:
      exposure:
        include: health,info,metrics,loggers # 暴露监控端点
  endpoint:
    health:
      show-details: always # 展示健康详情

3.3 Nacos 注册配置中心监控

Nacos原生提供可视化控制台，核心监控能力如下：

• 访问地址：http://localhost:8848/nacos，默认账号密码`nacos/nacos`
• 服务管理：查看服务列表、健康状态、实例详情、心跳上报记录
• 配置管理：查看配置历史、推送记录、监听查询、版本回滚
• 集群管理：查看Nacos集群节点状态、性能指标、容量监控

3.4 SkyWalking 全链路追踪集成

SkyWalking是国产开源的无侵入式分布式链路追踪系统，适配微服务架构，无需修改业务代码，通过Java Agent探针实现全链路数据采集。

服务端部署

1. 下载官方稳定版（推荐9.1.0+）：https://skywalking.apache.org/downloads/
2. 解压后执行启动脚本：
   • Windows：bin/startup.bat
   • Linux：bin/startup.sh
3. 控制台访问地址：http://localhost:8080，默认账号密码`admin/admin`

微服务无侵入接入
核心方式：给每个微服务添加JVM启动参数，挂载SkyWalking Agent探针，零代码修改。

IDEA开发环境配置
每个微服务的启动配置中，VM options添加如下内容，仅需修改service_name为当前服务名：

-javaagent:D:/skywalking-9.1.0/agent/skywalking-agent.jar
-Dskywalking.agent.service_name=gateway-service
-Dskywalking.collector.backend_service=127.0.0.1:11800

需配置的服务：网关、认证中心、所有业务服务。

Linux生产环境配置
修改jar包启动脚本start.sh，添加Agent参数：

java -javaagent:/opt/skywalking/agent/skywalking-agent.jar \
-Dskywalking.agent.service_name=user-service \
-Dskywalking.collector.backend_service=127.0.0.1:11800 \
-jar user-service.jar

3.5 业务指标监控

基于Micrometer + Prometheus + Grafana实现自定义业务指标监控，核心落地步骤：

1. 项目引入依赖：

<!-- Spring Boot Actuator 监控端点 -->
<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-actuator</artifactId>
</dependency>
<!-- Prometheus 指标适配 -->
<dependency>
    <groupId>io.micrometer</groupId>
    <artifactId>micrometer-registry-prometheus</artifactId>
</dependency>

1. 配置暴露Prometheus端点：

management:
  endpoints:
    web:
      exposure:
        include: health,info,prometheus,metrics
  metrics:
    tags:
      application: ${spring.application.name}

1. 业务代码嵌入自定义指标：

@Service
public class UserServiceImpl implements UserService {
    // 注入指标注册器
    @Autowired
    private MeterRegistry meterRegistry;

    @Override
    public int addUser(User user) {
        int rows = userMapper.insert(user);
        // 新增：业务指标计数，统计新增用户数
        if (rows > 0) {
            meterRegistry.counter("biz.user.add.count").increment();
        }
        return rows;
    }
}

1. Prometheus配置抓取任务，Grafana配置数据源，实现指标可视化与告警。

【核心记忆点】 微服务监控体系是四维一体：服务健康+注册配置+全链路追踪+业务指标，SkyWalking实现无侵入链路追踪，是微服务排障的核心工具。

---

 第四章 分布式核心理论：CAP & BASE

4.1 CAP定理

CAP定理是分布式系统的基础理论，指出分布式系统的三大核心指标无法同时满足，最多只能同时满足其中两项。

三大核心指标

1. 一致性（Consistency，C）：任何时间点，分布式系统中所有节点的数据完全一致，所有客户端读取到的都是最新的数据。
2. 可用性（Availability，A）：任何客户端的请求，都能在有限时间内得到正常响应，服务始终处于可用状态，不会出现超时或拒绝访问。
3. 分区容错性（Partition tolerance，P）：当分布式系统出现网络分区故障（节点间网络中断、延迟、丢包）时，系统仍能正常运行，不影响核心业务。

核心结论

• 分布式系统的节点通过网络连接，网络故障是必然发生的，因此分区容错性P是必选项，不可放弃。
• 当网络分区出现时，系统的一致性C和可用性A无法同时满足，只能二选一：
  • 选择CP：优先保证数据一致性，牺牲部分可用性
  • 选择AP：优先保证服务可用性，牺牲部分一致性，通过最终一致性保证数据正确

4.2 BASE理论

BASE理论是CAP定理中AP模式的延伸，是大型互联网分布式系统的核心设计哲学，核心是放弃强一致性，通过最终一致性保障数据正确，同时最大化服务可用性。

三大核心要素

1. 基本可用（Basically Available）：当系统出现故障时，允许损失部分非核心功能的可用性，保证核心业务功能可用，如限流、降级、熔断等机制。
2. 软状态（Soft State）：允许系统中的数据存在中间状态，该状态不影响系统整体可用性，即允许不同节点之间的数据同步存在延迟。
3. 最终一致性（Eventually Consistent）：允许数据在一段时间内不一致，但经过一定的时间窗口后，数据最终会达成全局一致，这是BASE理论的核心。

4.3 AP vs CP 核心对比

对比维度	AP模式（最终一致性）	CP模式（强一致性）
核心目标	优先保障服务高可用	优先保障数据强一致性
一致性保障	短暂数据不一致，最终达成一致	任何时间点所有节点数据全局一致
可用性表现	网络分区时服务仍可正常访问	网络分区时为保证一致性，可能拒绝服务
典型实现	本地消息表、MQ事务消息、Seata AT模式、Saga模式	2PC/3PC、Seata XA模式、ZooKeeper、Nacos CP模式
适用场景	电商订单、支付回调、日志记录、用户通知等绝大多数业务场景	金融转账、资金操作、分布式锁、配置中心等强一致要求场景

4.4 分布式事务的两大核心思想

1. 最终一致思想（AP模型）：各分支事务分别执行并提交，若出现数据不一致的情况，通过补偿、重试、对账等方式恢复数据，优先保证服务可用。
2. 强一致思想（CP模型）：各分支事务执行完业务逻辑后不提交，等待彼此的执行结果，由协调器统一决定全量提交或全量回滚，保证数据全局一致。

【核心记忆点】 P是分布式系统的必选项，日常业务优先选择AP模式保障高可用，仅在资金、数据强一致要求的场景选择CP模式。

---

第五章 分布式事务 Seata 完整落地指南

5.1 Seata 核心定位

Seata是阿里巴巴开源的分布式事务解决方案，专门解决微服务架构下跨服务、跨数据库的数据一致性问题，核心优势是无代码侵入、高性能、易集成、多模式适配，是Spring Cloud Alibaba生态的默认分布式事务组件。

5.2 三大核心组件

Seata的分布式事务实现基于三大核心组件，各司其职，协同完成全局事务管理