1. 分布式系统概述：定义、发展历程、典型应用场景
大家好，我是你们这门课的主讲人。今天咱们正式开篇，聊聊分布式系统到底是什么。说实话，我做了十几年分布式系统，从最初在实验室搭Hadoop集群，到后来在电商公司扛双十一流量，对这个概念的理解也是一步步深化的。嗯，咱们不整那些虚的，直接上干货。
1.1 到底什么是分布式系统？
先给个最朴素的定义：分布式系统，就是把一堆廉价的普通计算机连起来，让它们协同工作，对外表现得像一台超级计算机。
你想想看，单机再强也有天花板。内存插满也就那么大，CPU主频也快到头了。但业务量在涨啊，用户量在涨啊，怎么办？加机器呗。这就是分布式系统最原始的驱动力。
核心要点：分布式系统不是简单的「多台机器」，而是「多台机器 + 协同软件」构成的整体。没有协同，那叫一堆散沙。
我个人习惯用一个比喻来解释：单机系统就像一个人干活，分布式系统就像一支足球队。每个人（节点）都有自己的位置和职责，通过传球（网络通信）配合，最终目标是赢球（完成业务）。
这里有个关键点：用户感知不到背后有多少台机器。你刷淘宝，不会关心这个请求是杭州的服务器处理的还是张北的服务器处理的。这就是分布式系统的透明性。
1.2 发展历程：从单机到集群的演进
分布式系统不是一天建成的。我把它分成三个阶段来讲。
第一阶段：单机时代（1980s - 1990s）
那时候的计算机，就是一台大铁疙瘩。所有程序、数据都在一台机器上。优点是简单，缺点嘛——挂了就全挂了。我记得早期做银行系统，每天下班前要手动备份数据，生怕硬盘坏了。
第二阶段：集群时代（2000s - 2010s）
互联网爆发了，Google、Amazon这些公司发现单机根本扛不住。于是开始用廉价PC搭集群。这时候出现了两个标志性系统：
- Google的GFS和MapReduce：2003年发表的论文，奠定了大规模数据存储和计算的基础
- Amazon的Dynamo：2007年发表，解决了高可用键值存储的问题
说白了，这个阶段的核心矛盾是：如何让一堆不可靠的机器，组成一个可靠的服务。我在项目中遇到过，一台机器宕机不可怕，可怕的是你不知道它宕了，还在往上面发请求。
第三阶段：云原生时代（2010s - 至今）
容器化、微服务、Service Mesh……这些词你肯定听过。现在的分布式系统，已经不只是「多台机器」了，而是「动态编排、弹性伸缩、自动运维」。Kubernetes成了新的「操作系统」。
我的建议：学分布式系统，不要只盯着技术细节。要理解每个阶段要解决的核心问题是什么。问题驱动学习，比死记硬背有效得多。
1.3 典型应用场景：看看巨头们怎么玩的
光讲理论太枯燥，咱们看看Google、Amazon、阿里这些公司实际是怎么用分布式系统的。
Google：搜索背后的分布式引擎
你每次在Google搜索，背后发生的事情是这样的：
- 你的查询被发送到最近的Google数据中心
- 分布式文件系统（GFS）存储着海量的网页索引
- MapReduce任务在数千台机器上并行处理你的查询
- 结果在毫秒级返回给你
我曾经拆解过Google的架构，最让我震撼的不是技术多牛，而是他们把「容错」刻在了骨子里。每台机器都可能随时挂掉，但系统整体不能挂。这就是分布式系统的精髓。
Amazon：电商巨头的分布式实践
Amazon的分布式系统，核心是DynamoDB和AWS。我给大家讲个故事：
2004年，Amazon的数据库撑不住了。购物车、订单、库存……所有数据都挤在一个Oracle数据库里。每次大促，DBA都提心吊胆。后来他们决定：把所有服务拆开，每个服务用自己的数据库。这就是微服务的雏形。
关键教训：分布式系统不是技术炫技，是被业务逼出来的。Amazon如果不拆，可能早就被流量压垮了。
阿里：双十一背后的分布式架构
说到阿里，就不得不提双十一。2019年双十一，峰值达到54.4万笔/秒。这个数字意味着什么？
- 每秒钟要处理54.4万次下单请求
- 每笔订单要扣库存、生成订单、通知物流
- 所有操作必须在几十毫秒内完成
阿里是怎么做到的？核心是单元化架构。他们把用户分成很多「单元」，每个单元是一个独立的分布式系统。流量来了，先分到各个单元，单元内部自己处理。这样就不会出现「所有请求打到一个数据库」的悲剧。
避坑指南：我曾经在项目中犯过一个错误——把所有服务都做成分布式。结果系统复杂度爆炸，运维成本比单机还高。记住：分布式是手段，不是目的。能用单机解决的问题，别硬上分布式。
1.4 分布式系统的核心挑战
说了这么多好处，咱们也得聊聊难点。分布式系统要面对三个「魔鬼」：
| 挑战 | 描述 | 我的经验 |
|---|---|---|
| 网络不可靠 | 消息可能丢失、延迟、乱序 | 我曾经调试过一个bug，最后发现是网络包重排导致的 |
| 时钟不一致 | 每台机器的时钟有偏差 | 分布式锁超时问题，十有八九跟时钟有关 |
| 部分失败 | 部分节点挂了，其他节点不知道 | 这是最头疼的，没有之一 |
你想想看，单机系统里，函数调用要么成功要么失败，很明确。但在分布式系统里，你发一个请求过去，可能对方处理成功了但回复丢了，也可能对方根本没收到。你怎么判断？这就是分布式系统最核心的问题——不确定性。
1.5 本章小结
好了，咱们第一章就讲到这里。总结一下核心要点：
- 分布式系统是「多台机器 + 协同软件」的整体
- 发展经历了单机→集群→云原生三个阶段
- Google、Amazon、阿里的实践告诉我们：分布式是被业务逼出来的
- 核心挑战是网络不可靠、时钟不一致、部分失败
下一章，咱们会深入聊聊分布式系统的理论基础——CAP理论和一致性模型。嗯，那才是真正烧脑的地方。做好准备。
课后思考：你身边有没有「为了分布式而分布式」的系统？试着分析一下，它真的需要分布式吗？