集群与分布式：核心区别、判断方法及架构选型实践指南

分布式和集群，这两个词大概是后端架构领域被混用得最厉害的概念了。出去面试，十个人里有八个能把“集群”和“分布式”当成同义词讲；打开招聘JD，要求“精通分布式架构”，结果进去干的全是给服务器加机器部署多个实例的活儿。等真到了线上出问题，排查故障的时候才发现，连系统到底算集群还是算分布式都没想清楚，定位问题的方向直接跑偏。

我最早对这两个概念也是一笔糊涂账，什么负载均衡、多节点、消息中间件、高并发，全都往一个筐里装。直到后来自己设计调度平台，遇到同一套任务被多台机器同时执行的问题，才被迫把这两个概念掰开揉碎地重新捋了一遍。捋完之后再看各种中间件的架构文档，思路一下子就通透了。

1. 为什么网上所有解释都像绕口令：信息论视角下的"复制"与"拆分"

先看一个怪现象。随便搜一篇讲集群和分布式的文章，几乎都会出现这样的话——“集群是相同功能的节点组合，分布式是不同功能的节点协作”、“集群是多个服务器做同一件事，分布式是多个服务器做不同的事”、“分布式是多个节点通过网络协同完成一件任务，集群是多个节点共同对外提供同一服务”。话是没错，但看完基本还是懵的。因为这些话只描述了表象，没有回答最核心的问题：为什么分布式里的一组节点会“各干各的”？集群里的一组节点又是为什么会“干同一件事”？

答案不在语义层面，而在信息论层面。

抛开“集群”和“分布式”两个词直接看底层的技术现实：任何一套系统都需要靠多台机器联合工作才能撑起足够的性能和可用性。让多台机器联合工作、对外呈现为统一整体，本质上只有两条路可走：

• 复制：同样的一份数据、同样的计算逻辑，放到多台机器上，每台机器都能独立完成完整的请求处理。机器之间尽量少依赖，万一某台挂了，剩下的继续顶。这条路对外表现出来的就是一排一模一样的服务节点，通过负载均衡把请求分发到某一台上。前一台机器在处理A用户的请求时，后一台机器可能正在处理B用户的请求，两台机器处理的逻辑和数据类型完全相同。

• 拆分：单个请求的处理涉及多个步骤，每个步骤需要不同的数据、不同的算力、不同的资源。把完整处理流程拆成多个能力互补的模块，每个模块可以由不同的机器承载。一台机器处理完自己的环节，把中间结果交给下一台。任何一台机器单独拿出来都干不了完整的事，但所有机器串成一条流水线后，才能对外提供完整服务。

这就是集群和分布式最底层的分岔。集群的网络信息传递主要发生在“负载均衡器”和“节点”之间，核心内容是请求转发和健康检查；分布式节点之间的信息传递发生在整个处理链路的所有环节，核心内容是中间结果、状态同步、任务协调。

用这个视角回看最常引用的那句话——集群侧重“向外水平扩展”，分布式侧重“向内业务拆分”——就说得通了。因为集群每加一台机器，只是多了一个能独立处理完整请求的副本，相当于复印机多印了一页纸；分布式每加一个节点，是在业务链路上增加一个专门环节，相当于把汽车制造拆成了发动机车间和组装车间。

判断一个系统到底是集群还是分布式，不需要看它用了多少台机器，只需要追问一个问题：任意抽走一台机器，系统对外提供的功能是否仍然是完整的？如果抽走之后剩下的机器依然能完整处理所有类型的请求，这大概率就是集群；如果抽走之后剩下的机器只能处理部分环节，请求链路直接断掉，这就是分布式。

2. 先说集群：核心思想只有一个词，消除单点

集群这个词早期常被用在服务器场景，比如几台Web服务器用Nginx做负载均衡对外提供同一个站点服务。这类部署的目标非常纯粹——消除单点故障、提升整体吞吐。单机的CPU、内存、带宽再怎么堆都有上限，与其买一台超贵的高配机器把鸡蛋都放一个篮子里，不如买几台中配机器组成一个服务池。

集群的内部结构有几个典型形态，不同形态的管理复杂度天差地别：

无状态集群：这是最容易理解也最容易维护的集群。节点不保存与用户相关的业务状态，会话数据放在独立的Redis里或者每次都带token来。Nginx轮询、最少连接、IP哈希随便配，请求打到哪台机器都能处理。这类集群扩缩容几乎不需要顾虑，节点加入和退出对上层透明。很多公司的后端起服务，比如订单服务的无状态化处理接口、用户信息查询接口，基本都是这类结构。

有状态集群：麻烦就在这里。比如Redis集群、Kafka集群、ES集群、MySQL集群，数据必须多副本存储。节点之间需要做数据同步、主从选举、故障转移。在Redis集群模式下，槽位分布在多个主节点上，每个主节点再挂若干从节点做冗余。表面上看起来和“分布式”沾了点边，因为每个主节点确实只负责一部分数据槽位——但本质上，Redis集群要解决的核心问题仍然是数据容量和可用性，16384个槽位是数据分片逻辑，分片后的每个部分内部依然是“多副本复制”。集群这个档位强调的是“我用多台机器，把单机的容量和可用性撑大”，分片只是实现这个目标的手段之一。

面试时候很多人会下意识地说，“集群里的机器做的是同一件事”，但Redis集群的主从结构一旦展开，主节点和从节点好像干的又不是完全一样的事。这种纠结本质上是因为没搞清楚一个尺度问题：集群讨论的“同一件事”是在能力边界层面说的，指的是“任意一台机器都能对外提供某种完整能力”，而不是说“每台机器每一纳秒都在执行相同的指令”。Redis Cluster里的任意一个主节点加它的从节点组合起来，承担的是整个Redis服务的完整能力中的一个数据子集，主从之间做的还是复制那一套。把尺度放大到整个Redis Cluster整体来看，它依然是把“一个Redis能干的活”切成了片，每片有多份拷贝，整体是一个“带分片能力的超大规模集群”。

顺着这个思路再往后看，集群和分布式之间其实不存在不可逾越的鸿沟。一个业务系统从单机起步，先把后端起服务做无状态化，用集群方式平摊流量，这是第一条必经之路。等集群规模到了一定程度，单个服务的代码库变得臃肿，不同模块的资源需求差异巨大，这时候再拆微服务、做分布式调用链，就是自然的演进。

2.1 集群踩坑经验：XXL-JOB多机器重复执行的真相

热搜词里有一条很典型：xxl集群调度对于同一个任务出现多台机器同时执行的问题。这是我见过新团队最容易踩进去的坑，很多人天然以为任务调度平台搭建好集群之后，调度器就会自动把任务错开分配给不同的执行器，同一个定时任务自然只会跑在一台机器上。实际情况远没有这么简单。

XXL-JOB的架构分调度中心和执行器两端。调度中心本身可以集群部署做高可用，但一个任务的执行器如果注册了多台机器，默认路由策略是轮询——也就是这次触发打到执行器A，下次触发打到执行器B。对于抢单、状态机流转、批量补偿这类任务而言，处理动作要求“同一时刻只能被一台机器执行”。如果上一轮调度刚好落在A机器上，但任务还没跑完，下一轮轮询把同样的任务又发到了B机器，B机器不会感知到A机器还在处理同一个任务，两边同时开工就会造成数据错乱。

解决思路无非是从“让任务天然具备幂等性”和“调度端做分布式互斥”两个方向入手。幂等性靠业务侧把处理逻辑设计成可重复执行的，重复消费不会出问题；分布式互斥则是引入一把全局锁，比如基于Redis的setnx锁，拿到锁的执行器才真正运行任务，没拿到的直接放弃本轮调度。很多人在这一步又产生新的困惑：为什么会出现分布式锁？它跟集群是什么关系？其实分布式锁是解决分布式环境下多节点竞争同一资源时的互斥问题的一个中间件能力，与“系统是集群还是分布式”无关。只要存在多个节点可能操作共享资源，就需要这个能力。

• 把任务ID作为锁的key，value设置一个随机UUID，防止误删别人加的锁。
• 设置合理的过期时间，避免执行器宕机导致锁永久不释放。
• 释放锁时用Lua脚本先比对value再删除，保证原子性。

这套方案看着简单，真正落地后遇到的问题一点不少。执行器单次任务处理时间超过锁的过期时间，锁被自动释放，另一个执行器又拿到锁执行了一遍；Redis主节点故障切换期间，setnx锁可能因为主从数据异步复制而丢失。这些都是后续要解决的延伸问题，单靠一把锁搞定所有场景是不可能的。每次排查这类问题，我都会加深一次认识：任何集群方案都只是解决了一部分问题，剩下的问题会在架构的另一个层面冒出来，永远不要指望某个中间件能替你解决所有分布式难题。

2.2 从Hadoop伪分布式到Nacos集群，看集群部署的复杂度曲线

热搜词里还有一组高频内容：hadoop伪分布式搭建、hadoop3.0分布式集群搭建、ambari部署hadoop集群。Hadoop是理解集群和分布式关系的最好教材。

所谓伪分布式，是单台机器上同时启动NameNode、DataNode、ResourceManager、NodeManager，每个进程各占一个端口。数据和计算逻辑都在这台机器上，进程之间通信靠本机网络回环，看起来跑起来了，跟真实集群的逻辑完全一致，只是无法承载真实负载。很多人会觉得伪分布式没啥用，但实际做本地开发和单元测试时，伪分布式几乎是最快的验证环境。快速验证hdfs读写权限、提交一个MapReduce任务到Yarn上跑通，不需要三台Linux服务器，一套伪分布式环境足够把核心链路摸清。

到真正的多节点部署时，NameNode是典型的元数据单点。虽然Hadoop 2.x以后支持NameNode HA，配合ZooKeeper做自动故障转移，但整体机制立刻复杂了一个数量级：JournalNode集群负责同步NameNode的编辑日志，ZooKeeper负责选主，DFSZKFailoverController监控NameNode健康状态。这时候系统仍然是“集群”，但这个集群的内部协调逻辑已经非常接近分布式系统的玩法了。

Nacos集群部署也是同一类问题。注册中心必须保证高可用，多台Nacos节点组成集群后，需要选出一个Leader，数据写入需要过半节点确认。部署文档里要求至少三个节点，节点数最好是奇数，MySQL或外置存储作为统一数据源。如果这些节点之间网络隔离、版本不一致、存储配置不一，服务注册和发现就会随机失败。我见过有团队把Nacos集群搭在三个不同机架上，结果某个机架交换机故障导致整个集群失去多数派，Nacos直接进入只读模式——顺带一提，分布式共识算法（比如Raft、Paxos）在集群技术栈里是极其常见的实现基础，它要求大部分节点存活才能对外提供写服务。很多运维同学以为所谓集群只是把同样的进程多装几份，反正挂了一台还有另外几台，结果忽略了“多数派”这个限制条件。高可用是有前提的，不是机器多了就一定更可靠。

这类组件的共同特征是：对外看起来是一个服务入口，内部节点之间有强一致或最终一致的协调关系。换一个角度理解就更清晰了：调度集群、存储集群、注册中心集群，本质上都是“把一个基础能力做成可水平扩展、可故障转移的服务”，这正是集群范式的核心价值。

3. 再说分布式：核心是用多节点协同，完成单机无法承载的复杂任务

分布式这个词在不同上下文里的含义有点漂移。有时候指“一个系统的各模块部署在不同机器上，通过接口调用协同工作”，也就是微服务架构的底色；有时候又特指“分布式计算”这类把一个大任务切成无数小任务分发到大量节点并行计算的模式，比如MapReduce、Spark。两者都符合“拆分”的特征，只是拆分的粒度不同。

微服务式的分布方式：若干个独立部署的服务，比如订单服务、库存服务、用户服务、支付服务。每个服务可以独立开发、独立发布、独立伸缩。服务之间通过RPC或HTTP通信，形成一张复杂的调用网。拿一个下单操作来说，请求先到API网关，网关转发给订单服务，订单服务扣减库存要调库存服务，查询余额要调用户服务，发起扣款要调支付服务。任何一个单独的服务都完不成“完整下单”这个动作，必须多个服务协同。这跟集群的“任意一台都能独立处理完整请求”是完全相反的组织逻辑。

计算型分布方式：热点数据有几十亿条，单机排序根本排不完，把数据按范围分片放到几百台机器上，每台机器只对本地数据做排序，最后把所有排好序的分片合并起来。Mapper和Reducer各司其职，单个任务的进度受最慢的节点拖累，一两个节点延迟可能会让整个作业时间成倍拉长，也就是常说的木桶效应。分布式计算框架的核心不止在于把任务下发到N台机器，还包括任务切分策略、数据本地性、失败重试、进度协调。研究Spark或者Flink源码就会发现，一个看似简单的WordCount背后，有DAG调度器在编排执行计划、有Shuffle机制在跨节点搬运数据、有容错机制在节点故障时根据血缘关系重新计算丢失的数据分片。

分布式系统的核心困难不只在于“功能拆分”，更在于拆分之后节点之间的耦合关系无法回避。集群因为各节点能力等价，请求打到哪个节点都行，节点间交互天然很少；分布式因为各节点能力互补且需要接力，节点间的调用、调度、数据流转就是主旋律。由此衍生出一系列集群里不太需要担心、在分布式里却天天头大的问题。

3.1 分布式事务：为什么拆分之后最痛的问题出现了

热搜词里分布式事务出现频率极高，相关的还有：订单与库存分布式事务、分布式事务的解决方案、分布式事务一致性。这个主题几乎是所有服务化改造团队必经的坎。

单体应用时代，一个下单操作在同一个数据库事务里更新订单表、扣减库存表，要么全成功要么全失败，ACID数据库帮你把一致性管好了。拆成微服务之后，订单数据和库存数据落在两个独立的库里，各自的本地事务互相不知道对方的存在。订单服务在自己的库里把订单状态改成“已创建”，库存服务在自己的库里扣减库存，如果扣库存成功、改订单失败，两边数据就出现了不一致。全局事务管理器的两阶段提交协议在跨服务场景下很难做到高性能和强一致，而且协调者本身又是新的单点风险。所以实际落地中大多采用柔性事务方案：基于消息队列的事务消息，把扣库存和改订单通过可靠消息解耦；基于TCC（Try-Confirm-Cancel）模式，在业务层实现补偿；基于本地消息表，把业务操作和消息发送放进同一个本地事务，保证消息必然发出，消费端处理后回调确认。

所有方案的核心思想一句话概括：把一个大事务拆成多个可补偿的本地操作，用最终一致性替代强一致性。代价是从此系统的正确性不再依赖数据库的ACID，而要依赖业务代码里的对账、重试、补偿和幂等控制。每次看到团队为了一个字段错误到处打补偿日志、写数据订正脚本的时候，我都觉得这是分布式架构最难教给人的一课：一致性不是免费的，服务拆得越碎，一致性成本越高。想好自己业务模型里哪些数据必须强一致（一般很少）、哪些可以最终一致（通常是绝大部分），再去动手拆服务，是最划算的决策。

3.2 ES集群的“数据写入查询”现象，以及跨集群的分布式协同

再说一个容易困扰人的具体场景：es集群数据写入查询。Elasticsearch本身的布局就已经把两种范式揉在一起了。一个索引被切分成多个分片，每个分片是一个独立的Lucene索引，分片散落在不同节点上。一条文档写入时，通过路由算法决定它落到哪个分片——主分片负责写，副本分片负责冗余和读，分片的主副本尽量不要落在同一节点上。集群中的所有节点通过节点发现机制获知彼此的存在，在心跳超时、主节点失联时，从节点会重新选举出新的主节点，同步分片数据。

从路由和分片的角度看，ES是分布式的，数据打散、查询聚合都是多节点协同；从主副本和数据冗余的角度看，它又带着集群的影子。任何一个主分片挂了，它的副本要提升为主分片继续提供写入服务。这个故障转移过程涉及分片副本的路由同步、集群元数据的更新，整个过程对业务方是透明的。所谓的“分布式协同”，在ES这类内部组件上的体现，就是节点间自动化的数据分片、副本复制、故障检测、Master选举这些机制。这些机制统统不能被业务侧感知，不然集群就失去意义了。

3.3 无人集群与分布式智能协同：分布式概念的另一个极端体现

热搜词里有一条很有意思：无人集群通测一体化及分布式智能协同。如果觉得前面讲的分布式都是软件和计算领域的概念，看看无人系统的例子就能明白“分布式”这个词表述的并不是什么特定技术点，而是一种系统组织方式。

一群无人机、无人车组成集群执行任务时，没有一架中央指挥机来统一调度每一架无人机的所有动作，每一台无人装备都带着自己的传感器、计算单元和决策模型。它们通过自组网交换位置、速度、环境信息和局部任务状态，基于分布式协同算法形成统一的编队队形、分配侦察区域、避开障碍物。如果单靠一架中央指挥机去指挥上千架无人机，通信带宽、控制延迟、单点故障分分钟让系统瘫痪。分布式智能协同的核心就是指挥控制权限下放到每一个节点，用局部信息交互撑起全局任务的执行。

回到软件领域，这个思想可以类比无中心化的共识系统。以前需要一台中心服务器做任务分发，现在用分布式哈希表把任务哈希到不同节点上，节点之间通过Gossip协议传递状态信息，任何节点挂掉都只影响整体能力的很少一部分，其余节点自动接管它负责的数据。这种演进的本质，是把以前属于中心的控制权尽量打散，让系统更抗故障、更易扩展。

4. 一张图讲透判断逻辑：从故障域和一致性两个维度做对比

前面说了不少概念和案例，现在把关键判断维度提炼出来，方便阅读时自查。判断一个正在看的架构是集群还是分布式，不需要纠结它的宣传口径，看三个维度就够了。

实际系统里，一个大型平台往往是集群和分布式的混合体。前端接入层是集群，后端的服务层是分布式，服务内部可能又依赖集群形态的缓存集群、消息队列集群。诊断一个线上问题的时候，如果先判断问题发生在哪一层，再判断这一层的组织方式是集群还是分布式，定位思路会清晰得多。比如下游接口超时，是集群内某台机器异常导致响应变慢，还是分布式调用链上某个服务依赖外部存储导致整体阻塞？情况不同，处理手段完全不同。

集群故障一般先看负载均衡的健康检查是否把异常节点摘掉了、被摘掉的节点上有没有堆积的请求、多副本之间是否存在数据不一致；分布式故障则先看调用链追踪，找到延迟最高的那个环节、确认依赖的组件或服务是否可用，再判断是否需要降级或熔断。

以前跟同事复盘一个线上问题，现象是某个接口偶发超时。开始怀疑是Kafka集群压力大，排查了半天发现Kafka本身的吞吐完全正常；又怀疑消费端处理慢，最后才发现是某个服务从单节点改成双节点集群后，请求被分发到新节点时恰好命中了没有缓存热数据的冷启动阶段，处理时间比老节点慢了接近一整个数量级。事后回想，整个排查过程已经默认了问题发生在分布式协作链路的某个环节，而实际上出的问题纯粹是集群层的负载均衡策略与缓存预热机制的配合盲区。这两种概念的思维方式不一样，排查问题的切入点也完全不同。

5. 分布式架构的真实代价，以及选型时的判断依据

看到这里很容易产生一种想法：既然分布式听起来更高级，是不是所有系统都应该直接上分布式？恰恰相反，分布式带来的复杂度非常昂贵，在绝大多数业务场景下是负收益。

一个简单的CRUD系统，单机只需要部署一份代码、一个数据库，出现问题看日志即可。如果强行拆成微服务，启动运维、链路追踪、配置管理、网关路由、分布式事务等一整套基础设施的建设和维护成本立刻砸下来。团队没有足够的运维能力和SRE支持时，分布式系统的故障率可能会高于单体系统。分布式环境的网络分区隔开了本来可以直接内存访问的数据，任何一次网络抖动、一个服务发布，都可能引发超时重试导致的下游雪崩。

做技术选型时我给团队定过几条简单判断准则：

• 访问量还在单机可以支撑的范围内，一致性要求又极高，优先用集群扩展而不是微服务拆分。
• 业务复杂度已经让单体代码库难以维护，团队规模能支撑多服务并行开发，再考虑分布式服务化。
• 需要用到多种异构存储或外部能力（比如对接第三方平台），无法在同一个进程里完成，只能走分布式协作。
• 能否接受最终一致性的业务模型约束，如果业务必须强一致，分布式方案要付出的成本远大于好处。

在实际做业务架构规划时，我一般把预期流量、数据规模、团队运维能力、需求变更频率这四条结合起来评估。流量和数据规模决定了到底要不要引入集群；需求变更和团队规模决定了要不要横向拆服务；真正的分布式协调难题出现在拆服务之后，上了这条船再想回头，成本比当初上船时大得多。这不是劝退，而是先想清楚自己要付什么价钱。集群和分布式从来不是优劣关系，只是不同复杂度场景下的不同组合方式。

6. 结合高频热搜做综合辨析，替大家回答几个容易混的面试题

很多困惑来自具体技术组件在集群和分布式两个词之间的归属。整理几个高频问题，用本文的视角直接过一遍。

Redis分布式锁是分布式还是集群的产物？

分布式锁解决的是多个独立节点（可能是集群节点，也可能是分布式服务实例）并发操作共享资源时的互斥问题。它本质是分布式协调工具，而不是某个集群或分布式系统的专属组件。单机时代用synchronized就够了，多实例部署后进程内的锁互相感知不到，只能依赖集中的外部组件，比如Redis、ZooKeeper或数据库行锁。锁的范围决定它的适用范围，用它就是看中了它在多节点间建立互斥的能力。

Kafka集群的Partition机制算分布式吗？

Kafka在物理上通常部署为集群，Topic在逻辑上被切分成多个Partition，每个Partition分布在不同Broker上，Partition内部保证消息的顺序性。从Topic把消息发到哪几个partition、消费者组里谁消费哪个partition的角度看，这是分布式协调的经典操作；从集群视角看，多个Broker协同提供消息队列能力，它又是一个分布式消息中间件，通常不会有人刻意强调它是“集群”还是“分布式”，因为答案是在不同抽象层次上都成立。架构师讨论它时，说“Kafka集群部署”指的是Broker的部署拓扑，说“Kafka分布式消息平台”更多指消息分区和消费协调的运作机制。

MySQL集群架构在生产环境怎么选？

单机MySQL扛不住读压力，可以做主从复制：主库负责写，从库负责读，读写分离。从库挂一台，用半同步复制或者增强半同步减少数据丢失；一旦主库宕机，从库提升为主库，应用层要做连接切换。主主复制、MGR（MySQL Group Replication）、MHA这类方案都是围绕“数据多副本+自动故障转移”展开的，本质上是高可用集群。如果单机数据量太大、写入超出单机能力，就需要分库分表，引入ShardingSphere这类中间件或者MyCat，把数据分散到多个MySQL实例上，这是把单机容量做大的分布式扩展思路。高可用和数据分片经常同时出现，但它们解决的问题是不同的。

Spark集群和分布式计算是一回事么？

Spark本身是分布式计算引擎，实际部署时通常多台机器组成集群，由Master和Worker管理资源、分配任务，Driver把计算任务切分成多个Stage和Task分发到Executor上并行执行。从部署形态上看它是集群，从计算模式看它是分布式任务调度与执行。Spark官方文档说的“standalone集群模式”指的是它的资源调度方式。

RocketMQ集群模式、Kafka集群安装这类问题为什么总是成为热搜词？

这些中间件的使用必须先搭建集群环境。安装步骤看着简单，真正部署过程中会碰到跨节点网络、存储目录权限、JVM堆内存调整、Broker注册失败等一堆问题。部署经验本身没有太多文章可写，但踩坑经历对后来者价值很大。很多人搜这些词其实是收藏类的学习路径，真正遇到问题时还是得看实操型的故障排查方案。分布式系统本身就是用大量可替换零件组装成可靠整体的工程方法论，中间件越多，管理和运维复杂度越高，出问题的可能面也越广。

7. 落到实践：什么时候该上集群，什么时候该上分布式，个人建议路径

最后分享几条实操建议。没有一套绝对普遍适用的架构方案，只有结合自身团队情况能落地推进的步骤。

第一，先做容量评估。当前单机能扛住的QPS和并发是多少？未来半年到一年的预期增长是多少？如果几十倍的流量增长没有清晰预期，直接上Kafka集群搭建是无意义的炫技。做了五年研发，见过太多系统刚上线就堆上四五个中间件的Kubernetes集群，每天光处理依赖组件的配置就消耗近一半开发人力，业务本身的功能倒是没怎么迭代。

第二，再想清楚拆分时机。代码仓库能由一个团队维护，发布回归成本可以接受时，不要为了服务化而服务化。服务化的前置条件一般是：团队人数已经多到一个代码库的变更冲突严重影响交付效率，或者不同功能的资源需求差异大到无法用同等配置服务器支撑。

第三，遇到一个具体场景，先按“能不能用集群方案解决”来尝试。需要高可用？加副本、加负载均衡、启用健康检查。需要提升读吞吐？加从库架构。需要提升某一类接口的吞吐？把这部分无状态服务做成集群并水平扩容。只有当集群的硬帽子无法盖住业务复杂度时，再考虑引入分布式拆分的思路。

第四，如果确定要上分布式，先把基础设施补齐。链路追踪系统、集中式日志、配置中心、监控告警、CI/CD，缺少这些工具就去拆服务，大概率会在排查问题时原地爆炸。我见过不少团队花大精力把服务拆完了，却在服务调用出问题时对着几十个服务一个个查日志，基础组件的重要程度在做架构规划时常常被不当回事。

集群是稳健的起点，分布式是应对更大规模、更复杂业务的组织演进。二者不是同一个赛道上的替代品，而是核心逻辑各不相同的编排方式。与其迷信某个词的高级感，不如把底层机制摸清楚，在合适的场景用合适的结构表达出最合理的方案。理清这两者之间关系的价值，不在于面试时答一个漂亮题，而在后续每一轮架构取舍中少走弯路。