分布式理论架构概述

一、分布式架构演变

架构演进顺序：单体架构 → 单体多模块架构 → 多体单实例架构 → 分布式微服务（多体多实例）

1. 单体架构

所有业务、所有功能统一打包为一个 Jar，单进程部署。

优点：开发、部署、维护简单；无服务间网络调用损耗，执行效率高；无需额外中间件治理。

缺点：性能完全受限于单机配置，无法横向扩容；无容灾能力，一旦服务宕机整体业务不可用；模块高度耦合，迭代风险高；仅适用于低并发、小流量的小规模业务场景。

2. 单体多模块架构

代码层面按模块分层解耦，但最终仍然打包为一个 Jar、单进程运行。仅优化代码结构，未解决部署、扩容、容灾的核心问题。

3. 多体单实例架构（过渡形态，资源有限情况下考虑）

属于单体向微服务过渡的中间形态，可归纳为单体多模块的进阶分支。将业务拆分为多个独立 Jar 包，服务之间通过网络调用通信。

核心特点：多个 Jar 可分散部署在多台服务器，但每类业务服务仅部署单个实例。

优势：实现了业务进程级隔离，单个服务故障不会拖垮整体业务；支持单个业务独立迭代、独立部署；相比单体架构，容灾能力、可扩展性、性能上限均有提升；服务拆分粒度适中，业务耦合度低于纯微服务，维护成本更低。

局限：无同服务副本容灾，单实例宕机则对应业务瘫痪；无法实现单业务横向扩容，高并发承载能力有限。

4. 分布式微服务架构（多体多实例，生产标准架构）

在多体拆分的基础上，每类业务服务部署多个实例，形成集群化运行。

核心目的：解决高并发、高可用、容灾扩容问题，适配大规模、高流量、迭代频繁的业务场景。

缺点：架构复杂度大幅提升，依赖大量中间件支撑，服务链路长、运维难度高，问题排查成本更高。

二、分布式层级体系

分布式不只是代码架构层面，同时包含中间件与数据存储层面的集群化：

• 数据库分布式：MySQL 主从复制、读写分离、分库分表，解决单机数据库性能瓶颈与单点故障问题

• 缓存分布式：Redis 集群（一主多从、哈希分片），实现缓存高可用、热点数据分流、分布式缓存管理

• 业务分布式：微服务集群化部署、跨服务调用、流量治理、事务管控

集群化部署后，必须通过各类分布式解决方案，解决多节点协作、数据同步、故障容错的问题。

三、分布式核心理论（CAP & BASE）

1. CAP 理论

分布式系统三大核心特性，无法同时满足，只能三选二：

• C 一致性：所有节点数据实时统一

• A 可用性：服务永久可用、响应正常

• P 分区容错性：网络分区故障时系统仍可正常运行

互联网微服务标准选型：优先保证 AP（可用性+分区容错），放弃强一致性，接受短暂数据不一致。

2. BASE 理论

是 CAP 理论的落地延伸，适配绝大多数微服务场景：

• 基本可用：故障时保证核心业务可用，允许非核心功能降级

• 软状态：允许系统数据存在短暂中间状态，无需实时一致

• 最终一致性：不追求实时强一致，保证一段时间后数据自动同步一致

核心思想：微服务架构优先保障高可用，通过最终一致性解决跨服务数据同步问题。

架构选型核心原则：没有最优的架构与技术，只有最适配业务场景的方案，所有技术都是为业务需求服务，杜绝过度设计。

四、微服务分布式核心问题

架构演进核心痛点：多实例集群部署后，衍生出一系列分布式难题：多服务统一管理、跨服务通信、分布式事务一致性、定时任务重复执行、MQ 重复消费、多实例并发竞争、最终数据一致性保障等。

同一个服务存在多个实例，请求应该找谁？负载均衡

服务挂了怎么通知？健康检查，服务下线

多台机器同时干活，怎么分配？分布式并发问题

1. 服务治理问题

负载均衡：

• 客户端负载均衡，loadbalancer自己去注册中心选节点

• 服务端负载均衡：nginx

常见负载均衡策略：轮询、随机、最小连接、一致性哈希

权重适合新老版本发布，机器配置不同的场景

一致性哈希适合缓存，尽量让请求固定访问到同一台节点，提高命中率。

多实例集群场景下： 需要解决服务注册、发现、健康检查、上下线感知、统一配置管理的问题。

服务注册，服务发现，心跳监测，健康检查，故障剔除，动态上下线，

所有服务启动主动注册到nacos，nacos监测心跳，长时间没有心跳自动剔除下线；

客户端本地缓存服务列表，通过负载均衡挑选可用节点。

2. 分布式并发问题

单机环境下： 可以用synchronized，ReentrantLock等本地锁解决并发

多实例环境下： 多个实例同时运行，会出现资源抢占、并发冲突问题，需要通过分布式锁保障并发安全。

主流用redisson实现，常见场景：库存扣减，订单创建，秒杀，定时任务抢执行等。

（看门狗锁续期释放，setnx等，读写锁等）

3. 数据一致性问题

跨服务、跨库操作无法依赖本地事务，存在数据不一致风险；需要通过分布式事务、接口幂等性保障数据可靠。

幂等性问题：

分布式场景下很容易mq重复投递，重试，重复请求等，

常见解决方式： 唯一索引，唯一订单号判断，token防重，状态机判断，消费端幂等处理。【提一嘴：幂等并不是只有微服务才有，单机也要做好幂等，如果你的项目使用了mq，定时任务，或者有订单金额相关业务，该做得做==】

分布式事务：

服务拆分后，一个业务可能调用多个服务，多个库

单机服务下，本地事务即可解决事务问题，

但是分布式场景下要保证整个调用链路的数据一致性，需要一系列幂等，重试，补偿机制来保证最终一致性。

【跨表跨服务保证强一致就要注意一致性问题，我想的解决方案大多是在业务层之间异步推送+定时状态检查，或者回调状态检查兜底（不依托seata）】

4. 流量稳定性问题

高并发场景下易出现服务调用超时、依赖服务故障、服务雪崩等问题，需要通过限流、降级、熔断保障服务稳定性。

超时控制：不能无限等待

失败重试：只对幂等接口重试

舱壁模式：不同线程池隔离，避免相互影响

限流：拦出超出承载的重量

降级：异常时返回兜底数据（fallback）

熔断：失败率高直接断开调用，不再瞎请求

5. 中间件分布式问题

redis分布式问题

redis集群主要解决单机缓存容量不足，单点故障问题

经典问题：缓存穿透（不存在key），击穿（热点key过期），雪崩（多key同时过期）

集群模式演变：单机-》主从哨兵-》一主多从

mysql分布式问题

单机mysql达到数据量，io等性能瓶颈，改集群

主从复制（读写分离），写主库，读从库，io分离，扩展吞吐量，也能仅用于数据备份

分库分表：解决单表千万级性能瓶颈，但需注意跨数据源，跨表分页，join，排序，分布式ID等问题，

处理相对比较复杂【本人接触过分表的场景是设备数据表分库分表，只有查询，相对来说好做一点，考虑时间成本没有上重型分库中间件】

mq分布式问题

mq主要做异步解耦，削峰，流量缓冲

注意事项（只要使用mq都需要注意，并非分布式情况下独有）：

1. 消息丢失：引入确认机制，持久化，重试机制

2. 重复消费：消费端做幂等

3. 消息乱序：顺序队列，分区有序

4. 消息堆积：排查消费卡顿，扩容消费者和死信队列，处理一直异常消费失败的消息

五、Spring Cloud Alibaba 核心组件解决方案

整套组件分层解决微服务的治理、通信、稳定、事务、异步调度等核心问题

1. 服务治理与配置：Nacos

兼具服务注册发现中心 + 配置中心能力。解决多服务集群寻址、动态感知服务上下线、统一配置管理、环境隔离、配置动态刷新问题，是微服务集群的治理核心。

2. 流量入口与服务通信：Gateway + OpenFeign

Gateway：统一流量入口，实现路由转发、全局鉴权、统一限流、请求拦截，屏蔽后端服务细节。

OpenFeign：声明式 RPC 远程调用，简化微服务之间的同步通信调用流程。

3. 服务稳定性防护：Sentinel

专门解决微服务流量稳定性问题，提供限流、降级、熔断、流量整形、热点流量管控能力，防止高并发或服务异常引发服务雪崩，保障集群高可用。

4. 分布式定时任务：XXL-JOB

替代单机 SpringTask，解决多实例场景下定时任务重复执行、调度混乱、无统一管控的问题，实现分布式统一调度、失败重试、日志监控。

5. 分布式事务：Seata

解决跨服务、跨数据库的数据一致性问题。主流使用 AT 无侵入模式，基于 UndoLog 实现事务回滚；同时支持 TCC 等强一致模式，保障分布式场景下的数据可靠。

6. 异步解耦通信：MQ（RabbitMQ/RocketMQ/Kafka）

实现服务间异步通信、业务解耦、削峰填谷。解决同步调用耦合严重、超时阻塞、高并发流量冲击等问题；同时配套解决消息重复消费、消息丢失、业务幂等消费等衍生问题。

补充

1.同步调用和异步调用技术选型

同步OpenFeign，实时，简单，阻塞

缺点：耦合高，等待阻塞，容易超时，雪崩

异步MQ：解耦，抗并发，削峰

缺点：非实时返回，需要保证最终一致性

查询：强实时业务优先使用同步

耦合的任务，通知，日志，库存扣减，后续操作用异步

2.拆分思路

避免过渡拆分，避免调用链爆炸

3.发布

灰度发布，部分新部分老，平稳切换

4.微服务监控

链路追踪：看整条业务链路调用走向

监控指标：QPS，异常率，响应时间，cpu内存

集中日志：统一查日志，不用一台台登录翻找

发布注意事项

灰度发布

（新老共存）双向兼容是前提（新增功能）

常见坑：

消息mq不兼容

本地缓存结构不一致

服务调用链路连锁版本问题

负载均衡权重（一会打到新版一会打到老版）

配置中心变更风险

定时任务冲突

蓝绿发布

（新版本上好后停旧版全量发布）

常见坑：

需要双倍服务器资源

流量顺时切换雪崩风险

共享存储-数据互通问题

回滚时机

mq重复消费

注意事项

数据兼容

幂等兜底

提前观测

区分读写操作接口风险

分布式环境下，改一样东西不能像单体架构那样简单，一定要考虑共存期间的数据兼容问题，做好幂等性和回滚