分布式微服务核心技术体系个人笔记本笔记梳理微服务架构下从消息中间件集成、全链路监控、分布式核心理论到分布式事务的全链路核心原理与落地实操所有内容均贴合Spring Cloud Alibaba主流生态低侵入、可直接复用。第一章 微服务架构核心基础1.1 核心技术栈主流微服务架构以Spring Cloud Alibaba为核心生态官方最新稳定版本适配关系如下Spring Cloud Alibaba VersionSpring Cloud VersionSpring Boot VersionJDK版本要求2025.1.0.02025.1.04.0.021 LTS2025.0.0.02025.0.03.5.017生态核心组件服务注册/配置中心NacosAPI网关Spring Cloud Gateway服务调用OpenFeign LoadBalancer限流熔断降级Sentinel分布式事务Seata缓存Redis数据库MySQL1.2 微服务核心模块通用职责标准微服务架构的核心模块划分职责单一、可独立部署模块类型核心职责网关服务统一流量入口、路由转发、鉴权验签、限流熔断、请求日志记录认证中心统一登录认证、Token签发与校验、OAuth2权限管理业务服务核心业务逻辑实现如用户管理、订单管理、库存管理等文件服务统一文件上传、存储、下载、预览能力定时任务服务分布式定时任务调度、失败重试、执行日志管理公共依赖模块全局工具类、通用配置、安全组件、常量定义等公共能力API定义模块跨服务调用的Feign接口定义、出入参实体统一管理1.3 版本适配关键说明Spring Cloud Alibaba 2025.1.0.0 版本已正式废弃bootstrap.yml配置文件统一使用spring.config.import机制实现配置预加载。Spring Boot 3.x 版本基于Jakarta EE 10需使用JDK 17及以上版本不可兼容JDK 8。所有组件版本需与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_USERguest \ -e RABBITMQ_DEFAULT_PASSguest \ rabbitmq:3-management管理控制台地址http://localhost:15672默认账号密码guest/guest。2.2 依赖引入在Spring Boot/Spring Cloud项目的pom.xml中引入核心依赖父工程已统一管理版本时无需指定版本号!-- RabbitMQ 核心依赖 -- dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-amqp/artifactId /dependency2.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); // 消费失败拒绝消息根据重试次数决定是否入死信队列 // 第三个参数requeuetrue重回队列重试false直接进入死信队列 channel.basicNack(deliveryTag, false, false); } } }2.6 嵌入原有业务的标准方案零修改原有业务逻辑仅新增2处代码实现业务执行后异步发送消息以用户新增场景为例业务Service中注入RabbitTemplate// 新增导入 import org.springframework.amqp.rabbit.core.RabbitTemplate; Service public class UserServiceImpl implements UserService { // 原有注入完全不动 Autowired private UserMapper userMapper; // 新增注入MQ模板 Autowired private RabbitTemplate rabbitTemplate;原有业务方法末尾追加消息发送代码与本地事务绑定保证原子性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 Exporter3.2 Spring Boot Admin 服务健康监控Spring Boot Admin是针对Spring Boot应用的监控管理工具提供可视化界面实时监控应用状态、JVM指标、日志级别调整等能力。服务端部署新建独立的监控服务模块引入核心依赖!-- Spring Boot Admin Server 核心依赖 -- dependency groupIdde.codecentric/groupId artifactIdspring-boot-admin-starter-server/artifactId version3.4.0/version /dependency dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-web/artifactId /dependency启动类添加EnableAdminServer注解开启服务EnableAdminServer SpringBootApplication public class MonitorApplication { public static void main(String[] args) { SpringApplication.run(MonitorApplication.class, args); } }配置文件application.ymlserver: port: 9090 spring: application: name: monitor-server客户端接入所有需要被监控的微服务引入客户端依赖并配置服务端地址引入依赖dependency groupIdde.codecentric/groupId artifactIdspring-boot-admin-starter-client/artifactId version3.4.0/version /dependency配置文件添加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探针实现全链路数据采集。服务端部署下载官方稳定版推荐9.1.0https://skywalking.apache.org/downloads/解压后执行启动脚本Windowsbin/startup.batLinuxbin/startup.sh控制台访问地址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_namegateway-service -Dskywalking.collector.backend_service127.0.0.1:11800需配置的服务网关、认证中心、所有业务服务。Linux生产环境配置修改jar包启动脚本start.sh添加Agent参数java -javaagent:/opt/skywalking/agent/skywalking-agent.jar \ -Dskywalking.agent.service_nameuser-service \ -Dskywalking.collector.backend_service127.0.0.1:11800 \ -jar user-service.jar3.5 业务指标监控基于Micrometer Prometheus Grafana实现自定义业务指标监控核心落地步骤项目引入依赖!-- Spring Boot Actuator 监控端点 -- dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-actuator/artifactId /dependency !-- Prometheus 指标适配 -- dependency groupIdio.micrometer/groupId artifactIdmicrometer-registry-prometheus/artifactId /dependency配置暴露Prometheus端点management: endpoints: web: exposure: include: health,info,prometheus,metrics metrics: tags: application: ${spring.application.name}业务代码嵌入自定义指标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; } }Prometheus配置抓取任务Grafana配置数据源实现指标可视化与告警。【核心记忆点】微服务监控体系是四维一体服务健康注册配置全链路追踪业务指标SkyWalking实现无侵入链路追踪是微服务排障的核心工具。第四章 分布式核心理论CAP BASE4.1 CAP定理CAP定理是分布式系统的基础理论指出分布式系统的三大核心指标无法同时满足最多只能同时满足其中两项。三大核心指标一致性ConsistencyC任何时间点分布式系统中所有节点的数据完全一致所有客户端读取到的都是最新的数据。可用性AvailabilityA任何客户端的请求都能在有限时间内得到正常响应服务始终处于可用状态不会出现超时或拒绝访问。分区容错性Partition toleranceP当分布式系统出现网络分区故障节点间网络中断、延迟、丢包时系统仍能正常运行不影响核心业务。核心结论分布式系统的节点通过网络连接网络故障是必然发生的因此分区容错性P是必选项不可放弃。当网络分区出现时系统的一致性C和可用性A无法同时满足只能二选一选择CP优先保证数据一致性牺牲部分可用性选择AP优先保证服务可用性牺牲部分一致性通过最终一致性保证数据正确4.2 BASE理论BASE理论是CAP定理中AP模式的延伸是大型互联网分布式系统的核心设计哲学核心是放弃强一致性通过最终一致性保障数据正确同时最大化服务可用性。三大核心要素基本可用Basically Available当系统出现故障时允许损失部分非核心功能的可用性保证核心业务功能可用如限流、降级、熔断等机制。软状态Soft State允许系统中的数据存在中间状态该状态不影响系统整体可用性即允许不同节点之间的数据同步存在延迟。最终一致性Eventually Consistent允许数据在一段时间内不一致但经过一定的时间窗口后数据最终会达成全局一致这是BASE理论的核心。4.3 AP vs CP 核心对比对比维度AP模式最终一致性CP模式强一致性核心目标优先保障服务高可用优先保障数据强一致性一致性保障短暂数据不一致最终达成一致任何时间点所有节点数据全局一致可用性表现网络分区时服务仍可正常访问网络分区时为保证一致性可能拒绝服务典型实现本地消息表、MQ事务消息、Seata AT模式、Saga模式2PC/3PC、Seata XA模式、ZooKeeper、Nacos CP模式适用场景电商订单、支付回调、日志记录、用户通知等绝大多数业务场景金融转账、资金操作、分布式锁、配置中心等强一致要求场景4.4 分布式事务的两大核心思想最终一致思想AP模型各分支事务分别执行并提交若出现数据不一致的情况通过补偿、重试、对账等方式恢复数据优先保证服务可用。强一致思想CP模型各分支事务执行完业务逻辑后不提交等待彼此的执行结果由协调器统一决定全量提交或全量回滚保证数据全局一致。【核心记忆点】P是分布式系统的必选项日常业务优先选择AP模式保障高可用仅在资金、数据强一致要求的场景选择CP模式。第五章 分布式事务 Seata 完整落地指南5.1 Seata 核心定位Seata是阿里巴巴开源的分布式事务解决方案专门解决微服务架构下跨服务、跨数据库的数据一致性问题核心优势是无代码侵入、高性能、易集成、多模式适配是Spring Cloud Alibaba生态的默认分布式事务组件。5.2 三大核心组件Seata的分布式事务实现基于三大核心组件各司其职协同完成全局事务管理