分布式不是架构上的时尚单品，而是单机撞上天花板之后的被迫选择。本文先回答”为什么必须拆”，再盘点拆开之后必然面对的八类问题，最后厘清微服务与分布式的关系。

为什么走向分布式：单机的天花板

单体系统的问题从来不是”低级”，而是有明确的物理边界：

  • 算力：单机 CPU 核数和主频有上限，纵向升级价格陡峭且很快触顶；
  • 存储：一张表涨到十亿行量级后，索引维护、备份、故障恢复的成本和风险都不可接受；
  • 可用性：一个进程、一台机器就是单点，硬件故障或机房断电直接等于服务中断；
  • 协作：几十人改同一个代码库，发布窗口和故障边界完全耦合，谁也快不起来。

横向扩展用更多机器分摊计算与存储，多副本用冗余换可用性，按业务域拆分用隔离换协作效率——分布式系统就是为这三件事付出的组织形式。

拆开之后：分布式的八类问题

机器变多，问题不是等比例变多，而是出现了单机时代不存在的新品种：

  1. 网络不可靠：请求可能没发出去、执行了但响应丢了、或者纯粹延迟。超时不等于失败，这是分布式推理的第一课。
  2. 部分失败：单机要么全好要么全坏，分布式是常态化的”半边好半边坏”。一个节点没响应可能是宕机，也可能只是 GC 停顿或网络抖动，靠”有没有响应”判断故障很容易误判。
  3. 没有全局视图：任何节点只能看到本地状态和已收到的消息，不存在某个瞬间的真实全系统快照。两个节点对同一事实的判断可以暂时相反，且各自都有道理。
  4. 时钟不一致：物理时钟有漂移，NTP 只能缩小误差不能消除。事件排序要靠版本号或逻辑时钟，不能拿墙上时间当因果依据。
  5. 数据一致性：分片解决容量、副本解决可用性，但跨分片事务和副本同步延迟随之而来——刚写完立刻读，落到旧副本上就是旧值。
  6. 重复与幂等：只要存在超时和重试，同一业务操作就可能被执行多次。扣款、扣库存必须靠业务幂等号兜底。
  7. 事务与补偿：本地事务随服务拆分失效，跨服务的”要么都成功要么都失败”要靠 TCC、Saga、事务消息等协调方案，多数业务最终接受最终一致。
  8. 观测与排障：一次请求穿过六七个服务，没有链路追踪、统一指标和规范日志，定位问题只能靠猜。

这八类问题的共同根源只有两条：网络带来的不确定性，和节点独立故障带来的视图分裂。CAP、共识算法、分布式事务、幂等设计，都是围绕这两条根因长出来的解法。

微服务与分布式是什么关系

分布式描述的是一种系统形态：多个独立计算单元靠网络协作，对外提供完整服务。微服务是一种应用架构风格：按业务能力把系统拆成可独立开发、部署、扩容的小服务。

两者是包含关系而非等同关系。微服务系统几乎必然是分布式系统，因为服务间调用必须走网络；但分布式系统不一定是微服务——Kafka、HDFS、ZooKeeper 都是分布式系统，却不是业务微服务。另一个方向同样成立：一个单体应用跑在 Redis Cluster 和 MySQL 主从之上，它没做服务化拆分，但已经活在分布式世界里，照样要面对副本延迟和故障切换。

把微服务当目标而不是手段，是拆分失控的开始：服务越拆越细、调用链越拉越长，最终得到一个”分布式单体”——改一个需求要发五个服务，复杂度付了，收益没拿到。要不要拆、拆多细，判断依据始终是单机那四块天花板，而不是架构图的时髦程度。

小结

  • 分布式的动机是单机的算力、存储、可用性、协作四块天花板；拆是手段，不是目的。
  • 拆完必然面对八类问题，根因是网络不确定性与节点独立故障；后续所有理论与中间件都在处理这两条。
  • 微服务是分布式的子集场景：服务化必然分布式，分布式未必微服务。