作为全书的开篇，本章将带领读者走出单机系统的舒适区，直面分布式环境下的真实挑战。我们将首先厘清分布式系统的核心定义，剖析其相较于集中式系统的本质差异与优势；随后，我们将重点探讨这一领域中不可回避的技术难题——从不可靠的网络通信到破碎的全局时钟，再到部分失效带来的不确定性。最后，本章将阐述架构师在转型过程中所需完成的心智转变，从追求绝对的确定性转向在一致性与可用性之间寻求平衡的权衡艺术。理解这些基础概念与思维范式，是掌握后续章节中复杂算法与一致性模型的前提，也是构建高可靠、高扩展系统的基石。

#什么是分布式系统

在展开介绍分布式系统之前，我们先来看分布式系统的对立面：集中式的单机系统（Monolithic）。在单机系统中，所有计算、存储和处理任务都集中在一台计算机或一个中心节点上。单机系统的主要特点有：

单一节点：所有功能（如计算、数据存储、用户请求处理）都在一台机器或单一服务器上完成。
共享资源：使用共享内存和本地资源，通信速度快，无需网络消息传递。
单点控制：所有决策和数据管理由中心节点控制，无需节点间协调。
单一时钟：机器上的所有运行进程，使用同一个时钟的时间。

集中式单机系统的优点是：系统简单，请求、计算、存储、处理都在同一台节点上完成，不存在网络延迟、系统时间不一致等分布式系统才会出现的问题，但是缺点也很明显：单一机器节点的故障会导致整个系统的不可用，缺乏容错性；同时性能受限于单台机器的处理能力，只能通过升级硬件（垂直扩展（scale up））来提升性能。

集中式系统的例子有：

传统的单机数据库。
单服务器的Web应用，处理所有的请求和数据存储。
个人电脑运行的本地应用程序。

然而，很多应用场景和要求并不是集中式系统能够解决的，例如：

高性能：集中式系统可以通过垂直扩展的方式提升机器的硬件性能（采用更快的CPU、更大的内存等），以提升系统的处理能力。然而，垂直扩展的方式始终无法突破单一机器物理限制的天花板。与之对应的，分布式系统通过*横向扩展（scale out）*的方式，通过将多台机器组合在一起形成一个系统对外提供服务。当发现当前系统扔不满足需求时，可以继续在这个系统上增加机器提升处理能力。例如，在2003年的论文[GFS]中，Google讲述了使用廉价的硬件搭建分布式文件系统的经验。
高扩展性：和性能上遇到的瓶颈一样，随着数据量的增大，集中式系统在数据存储上也会遇到瓶颈。而分布式系统通过将数据分布存储在多台机器上，可以在系统无法承载更多数据的时候通过增加节点以提供更大的存储容量。
高可用性：现在绝大多数的服务，都要求系统能够保持7x24小时运行，表 system-avaliability 给出了不同的系统可用性需要满足的全年不可用时间。集中式系统中，只有一台机器节点提供服务，这很容易导致*单点故障（single point of failure）*问题：一台机器的故障就导致系统整体不可用。在分布式系统中，通过多台机器构成一个系统，提供了更多的冗余度，在某些机器出现故障时，系统也能够继续运行。
在地理位置上离用户更近：在许多情况下，要考虑用户所处的地理位置。例如，一个社交应用，既有来自亚洲的用户，也有来自欧洲的用户，在这种情况下，可能需要分别在不同的大洲建立服务，这些分布于不同地区的服务之间需要协同：例如，用户ID必须是全局唯一的。
合规要求：随着全球数据隐私法规的日益严格，为了满足*数据驻留（Data Residency）与数据主权（Data Sovereignty）*的合规性要求，系统架构必须支持跨地域的分布式部署。通过在不同国家或司法管辖区内建立独立的数据中心节点，实现数据的本地化存储与处理，从而确保用户数据严格限制在其所属的地理边界内。
资源共享：这里的"资源"不仅指硬件资源，也包括软件资源。例如，在进行大量计算时，为了计算计算流程，需要将计算划分为多个任务，分发到多个机器上同时执行；通过在线共享文档这样的产品，多个用户可以同时浏览、修改文档，无需将文件下载到硬盘上进行修改，同时也不再需要在个人电脑上安装处理软件。
业务属性：最后，除去以上集中式系统由于物理限制，要求使用分布式架构以外，某些业务天然就必须满足分布式特性。例如，电商服务中浏览、购买商品在一个平台，但是支付账单要到另外的系统（例如支付平台、银行等）完成，在这种业务中，系统天然就必须是分布式的。