分布式不是”加机器”这么简单。本文重新梳理：什么算分布式、为什么拆、拆完麻烦从哪来，并给出可执行的学习顺序，避免一头扎进共识算法却说不清业务为什么需要多节点。

要解决什么问题

一台机器能跑通的业务，拆成多服务后，本地方法调用变成网络请求，超时不再等于失败，事务不再天然原子。团队常在未遇瓶颈时过早拆分，复杂度先涨、收益滞后。电商下单链路一旦跨库存、订单、支付多个服务，重复消息、部分失败和响应丢失都会变成日常问题，而单体时代这些麻烦往往被本地事务掩盖。

核心原理

分布式系统由多个独立计算单元经网络协作对外提供完整服务。核心变化包括：通信走网络、故障可局部发生、无瞬时全局视图、时钟不可完全对齐。典型演进是单体应用→多实例负载均衡→按业务域拆服务→引入消息队列与分库分表。每个阶段解决一类压力，也引入新的协调成本，这是后续 CAP、锁、事务等专题存在的背景。

方案权衡

拆分带来独立扩容和故障隔离，也引入跨服务一致性、链路追踪和运维成本。单体开发调试简单，分布式适合高并发、大数据量和多团队并行。CAP 和分布式事务是后续专题，入门阶段只需知道它们处理”分区与协作”类麻烦，并能在架构评审时判断当前痛点是否真的需要微服务而非单纯加机器。

落地要点

评估是否拆分：看 CPU、存储、可用性是否真的到瓶颈；拆服务时按业务域和数据归属而非单纯按技术层；为每个跨服务调用设计超时、幂等与补偿。学习路线建议：动机与特征→协调与 CAP→RPC 与网关→ID、锁、事务→配置与 ZK。每阶段配合一个小实验，例如用 Docker 起两个服务观察超时重试行为。

常见误区

常见误区包括：把机器数量当分布式本质（同机多进程同样面临网络语义）；认为分布式一定比单体高级；忽视”响应丢失”与”执行失败”的区别导致错误重试；把微服务当成目标而非手段，最终造出调用链极长的”分布式单体”。