概念卡片：系统架构演进（集群 vs 分布式）

一句话机制：集群是「多个节点干同一件事」（纵向扩展能力），分布式是「把大事拆成小事分工协作」（横向功能划分）；架构从单体 → 集群 → 分布式（SOA → 微服务）一路演进，本质是把「一个服务扛不住」的问题，拆成「分工 + 冗余」来解决。

核心区别

维度	集群（Cluster）	分布式（Distributed）
目标	提高性能、可用性、容错	拆分复杂任务，提升整体处理能力
工作方式	多个节点做同一件事	多个节点做不同的事，协同完成
状态	通常共享存储或状态同步	各自管理局部数据，靠消息通信
典型场景	Web 服务器集群、数据库主从	微服务、Hadoop、区块链
比喻	多名骑手送外卖	工地各工种分工盖楼

记忆锚点：分布式像工地分工协作，集群像一群外卖小哥并行跑腿。实际系统常「分布式 + 集群」一起用——每个微服务是分布式的一环，每个服务背后又是多个实例组成的集群。

架构演进的动机

阶段	痛点	解法
单体	一个 war 包扛全部，改一处全量发布	按业务拆分
集群	单机性能/可用性不足	加实例 + 负载均衡
分布式/微服务	单体臃肿、团队耦合、无法独立扩容	拆服务 + 注册中心 + 网关

不变量（必须成立的约束）

• 集群解决「同一件事的量」（并发/可用性），分布式解决「一件事的复杂度」（拆分/协作），两者正交、常叠加。
• 微服务是分布式的落地形态，但引入分布式事务、链路追踪、运维复杂度，是有代价的。

踩坑案例

• 现象：业务量小却硬上微服务，结果一个需求改三个服务、联调困难、排查要靠链路追踪。 原因：把「微服务」当银弹，忽略了拆分成本。解决：业务简单、团队小、无独立扩容需求时，先用单体 + 集群扛，量上来再拆。

常见误解

• 把集群和分布式混为一谈 → 一个管「量」、一个管「复杂度」，判断标准是「节点做的是不是同一件事」。
• 以为微服务一定更快 → 拆服务增加网络调用、序列化、事务协调开销，快不快看场景。

关联

• 总览：微服务技术栈总览
• 源：B40-资源/语雀-Leo的知识库/微服务/01_SpringCloudAlibaba/01_系统架构演进（4 篇）