波仔
☁️ 第一章 云计算的基础知识
📄 一句话概括

客户端服务器这个"一问一答"的结构，云一点都没有改变；它改变的是那台服务器在哪里、由谁维护、有多少台——用户看到的仍然只是一个入口。

📝 本节和前面几节的关系

前面的内容都在讲"资源归谁、放在哪"（1-4、1-5）。这一篇换一个视角：不管资源归谁，系统在结构上长什么样。

教材把它放在第五章之前讲，用意是先立一个"什么没变"的基线——后面几节讲虚拟服务器、机架、存储，都是在这个不变的骨架里换零件。搞清哪些变了、哪些没变，才不会被一堆新名词绕晕。

一、客户端服务器：一个请求，一个响应

这是今天绝大多数系统的骨架：

这个结构的核心特征只有一句：主动权在客户端手上。你不发请求，服务器不会主动给你东西。你点一下，它答一次。

这个结构已经用了三十多年，原因很实在：它把最贵的那部分（数据和计算）集中在能集中管理的地方，把最便宜的那部分（显示和输入）分散到每个人手上。云正是沿着这个方向又推了一步——只不过把"集中管理"从"我们公司机房"变成了"服务商的机房"。

二、云改变了什么：三件事，不是结构

把结构本身放在一边，云在这套骨架里换掉的是三样东西：

注意这三件事都没有动到骨架本身：还是客户端发问、服务端回答。所以判断一件事是不是"上云"，不该看它有没有新的架构图，而该看位置、数量、维护者这三样变了没有。

三、移动连接环境带来的变化

教材把"移动连接环境"和客户端服务器并列，是因为移动设备给这个结构加了一个新约束：网络从"稳定"变成了"时通时断"。

台式机连的是固定网线，移动设备连的是会漂移的信号。这带来三个实际后果：

所以"移动连接环境"讲的不只是"用手机访问"，而是网络的不稳定性开始倒逼系统设计。

四、动手 Demo：一次请求走几跳

拆开一次请求，看看云到底在哪里省了、在哪里加了成本。

# 一次移动端请求的典型路径与耗时
hops = [("DNS 解析", 20), ("CDN 就近响应", 10), ("负载均衡", 2),
        ("Web 服务器", 6), ("应用服务器处理", 30), ("数据库查询", 8),
        ("结果回传", 15)]
total = sum(t for _, t in hops)
print("合计 =", total, "ms")
print("没有 CDN 时 =", total + 60, "ms")

实跑输出：

==================================================================================================
D6 一次手机请求，到云端要经过几跳
==================================================================================================
  路径：手机 → 运营商 → DNS → CDN → 负载均衡 → Web → 应用 → 数据库 → 返回

  环节                      典型耗时      它在这里干什么
  ----------------------------------------------------------------------------------------------
  DNS 解析                  20 ms         把域名换成 IP（缓存命中约 5 ms）
  CDN 就近响应              10 ms         静态资源从离你最近的节点拿
  负载均衡                  2 ms          在多台 Web 服务器之间挑一台
  Web 服务器                6 ms          接收请求、交给应用
  应用服务器处理            30 ms         真正的业务逻辑
  数据库查询                8 ms          取数据（这一跳最容易变慢）
  结果回传                  15 ms         沿原路回到手机
  ----------------------------------------------------------------------------------------------
  合计                      91 ms         用户感觉是【一点就开】

  【三种情况对比】
  情况                              耗时          变化来自哪儿
  ----------------------------------------------------------------------------------------------
  正常（有 CDN、同城）              91 ms         基准
  没有 CDN，全部回源站              151 ms        静态资源也要走一趟源站
  跨地域访问（隔 1500 km）          241 ms        光在光纤里跑就要这么久

  ④ 客户端服务器系统是【一个请求一个响应】的结构，云并没有改变这个结构。
     云改变的是：以前那台服务器是你自己的一台，现在它可能在全球任何一个机房里——
     而用户不需要知道是哪一个。教材把这两件事分开讲：结构没变，位置变了。

读这个输出：这 91 毫秒里，没有一毫秒是"云"本身的开销——每一跳都在做具体的活。真正值得注意的是最后两行：跨地域访问多出来的那 150 毫秒，光在光纤里跑就要这么久，花钱也买不回来。这就是云的"位置抽象"背后的物理代价：机器可以放在任何地方，但用户和机器之间的距离不会因此消失——所以选择区域这件事，本质上是在选"离谁近"。

五、⚠️ 2026 现状

30 秒实验

打开手机随便刷一个网页或小程序，然后回答三句：

  1. 这个页面里，哪些内容是"你点一下才来的"？（那些就是客户端服务器结构里"请求"的部分）
  2. 哪些内容几乎立刻就显示出来了？（多半是缓存在离你近的地方）
  3. 如果现在断网，哪些还能看？

做完你会发现：能离线看到的部分，都是提前"搬到你身边"的——这就是 CDN 与缓存在做的事，也是这套结构对抗距离的方式。

常见误区

  1. 错误：云计算的架构和传统客户端服务器完全不同。——纠正：骨架完全相同，都是一问一答。变的是位置、数量和维护者。把"云"当成一种全新结构，会导致一个新系统上来就追求复杂设计——而很多业务其实只需要"把服务器换成云主机"，架构一点都不用改。

  2. 错误：既然位置被抽象了，那机器放在哪就无所谓了。——纠正：位置抽象的是"具体哪一台"，不是"哪个地区"。物理距离带来的延迟无法消除：Demo 里跨地域访问多出的 150 毫秒就是证据。所以"区域选择"仍然是一个必须做的决定——它决定了你的用户离你的机器有多远。

  3. 错误：移动端就是"屏幕小一点"。——纠正：移动连接真正改变的是"网络不可靠"这件事。它逼着系统做到三件事：请求可重试、响应可压缩、状态放服务端。这三件事反过来塑造了今天云上应用的基本形态——无状态、可水平扩容，都是从这来的。

  4. 错误：多了那么多环节，请求自然更慢。——纠正：环节多不等于慢，关键看每一跳花多少。Demo 里负载均衡只花 2 毫秒，应用处理花 30 毫秒——真正吃掉时间的是业务逻辑，不是那些基础设施环节。所以优化响应时间，通常应该从自家代码和数据库查询入手，而不是先怪网络。

自测三问（点开对答案） 1. 为什么说"云没有改变客户端服务器这个结构"？ —— 因为**结构描述的是"谁发起、谁响应"这个关系，而不是"机器在哪、有多少台"**。云改变的是后两者（位置、数量、维护者），而"你发请求、它答一次"这个关系原封不动。**分清这一点很实用**：它意味着迁移上云时，应用层面的设计往往不必推倒重来。 2. CDN 这一跳为什么不是"多花钱换来的速度"？ —— 因为**它省下的恰恰是"远距离传输"的成本**。静态内容从离用户近的节点返回，既降低了延迟，也减少了对源站的带宽占用。**它把"距离"这个无法用算力弥补的劣势，用"提前把内容搬过去"的方式绕开了**——这也是为什么它对延迟的改善最立竿见影。 3. 移动连接环境为什么会推动"状态放服务端"？ —— 因为**移动设备上的会话随时可能断**：切网、进电梯、锁屏、换设备。如果登录状态或购物车留在客户端，一断就丢。**把这部分挪到服务端之后，客户端就变成了"随时可以替换的显示终端"**——而这正是一台服务器换成另一台时，用户感觉不到的前提。

相关笔记