一、位置为什么算一个技术问题

在自建机房里，【系统放哪儿】这个问题几乎没有余地——机房就一个，服务器就那一排机柜。 到了云上，它忽然变成了一个真问题：

• 云商在全世界建了几十个区域，每个区域里又有好几个机房（可用区）。
• 同一个规格的机器，在不同区域价格不一样，延迟更不一样。
• 有些服务只在部分区域提供，选错区域，你想要的功能可能根本没有。

所以【放哪儿】这件事，在云上第一次变成了要动脑子的决定。 而它的难处在于：这个决定一旦做下去，移动的成本很高——把一堆系统从一个区域搬到另一个区域，不是改个下拉框就能完成的事。

教材把它排在整章的最前面，正是这个道理：它是所有后续动作都建立在它之上的那个地基。

二、动手 Demo：区域、可用区与租用方式的账

看到什么算成功：

==================================================================================================
【Demo 1】决定系统的设置位置：区域、可用区、租用
==================================================================================================

  【一】区域怎么选：四个因素的优先顺序

  因素            为什么排这个位置                  判据
  ------------------------------------------------------------------------------------
  合规与主权      一票否决，不合规的地域直接排除    法律与合同要求数据落地
  延迟            就近部署，影响每个用户的体感      用户和系统在哪
  服务与规格      不是每个地域都上全量服务          要的产品在不在
  成本            前面都打平后的最后一根稻草        同规格不同地域价不同

  优先级：合规 > 延迟 > 服务 > 成本。
  成本是【打平后的加时赛】，不是第一道门槛。

  【二】三种韧性模式：扛的是哪一级故障

  模式            做法                          扛得住什么                典型 RTO
  ------------------------------------------------------------------------------------
  单可用区        全部放一个 AZ                 机房内部件的单点故障      分钟级
  跨可用区        生产服务分散到 2~3 个 AZ      一整个机房全挂            秒级 ~ 分钟级
  多地域          跨地理区域同时跑              一整个区域（城市）        近零（不切换）

  可用性换算：单 AZ 约 99.9% = 一年停 8.76 小时；
  跨 2 个 AZ 约 99.99% = 一年停 52.6 分钟；跨地域约 99.999% = 一年停 5.3 分钟。

  【三】租用方式：同一种机器的三种买法

  方式          计费                      适合                            相对基准价
  ------------------------------------------------------------------------------------
  按需          按小时或按秒              临时、不可预测、测试            基准价（1 倍）
  预留          承诺 1~3 年，先付或月付   长期稳定的生产负载              省 30% ~ 60%
  竞价          用云商闲置容量，随时可回收    能容忍中断的批处理              省 60% ~ 90%

  这三条合起来回答一件事：把系统放在哪里、用哪种机器、买多久。
  它是一次性决定，但会跟着你很多年 —— 所以要在动手第一刻就想清。

读结果：

• 第一张表最该记住的是那个【优先顺序】。它不是说成本不重要，而是说成本只有在前面三项都打平之后才轮到它说话。理由很实在：合规不过，项目根本不能上线；延迟太高，用户先跑掉；服务没有，方案根本落不了地。 这三条都是【要么满足、要么出局】，只有成本是【多少的问题】——所以它是加时赛，不是第一轮。
• 第二张表回答的是【要花多少钱保多稳】。三种模式不是【进阶级别】，而是三种代价不同的赌注：单可用区赌的是【我的机房不会整个挂掉】；跨可用区赌的是【同一座城市不会同时停电】；多地域赌的是【城市级灾害不会发生在我头上】。 每往上一级，可用性涨一点点、账单涨一大截——所以正确的问法不是【哪种最安全】，而是【业务到底能停多久】。
• 第三张表的三种买法，本质是在卖【两种东西】：按需卖的是自由（随时开、随时关），预留卖的是折扣（用承诺换低价），竞价卖的是云商的闲置（便宜但随时可能被收回）。 选哪一种，取决于你对这份负载的了解程度——能预测 90 天以后还要用，就敢预留；说不准，就只能按需。

三、区域：先合规、再延迟、最后成本

Demo 第一段给了一条清晰的筛选链，值得单独展开：

第一关，合规与数据主权。 这是唯一一票否决的因素。法律或合同要求数据必须落在某国境内，那么这条线之外的所有区域都直接出局——不用比较它们谁更便宜、谁更快，因为它们根本不在候选名单里。 这一步要放在最前面，因为它是【筛掉】，不是【打分】。

第二关，延迟。 剩下的候选里，挑离你的用户和上游系统最近的那个。延迟这件事有一个特点：它对体验的影响是【非线性的】——几十毫秒的差别用户感觉不到，几百毫秒的差别用户会立刻关掉页面。 所以这一关比的是【够不够近】，而不是【够不够快】。

第三关，服务与规格。 不是每个区域都在同一天上线所有服务和机型。 最新的 GPU 实例、某些托管数据库，往往先在少数核心区域提供。如果方案里有一个非它不可的组件，先去确认那个区域有没有它——不然设计做完才发现落不了地。

第四关，成本。 同样规格的机器，不同区域价格确实不同，跨区域传输还有额外流量费。但它排最后，因为它前面三关任何一关不过，省下的钱都没有意义。

四、可用区：一份区域内的高可用

区域决定了【放哪个城市】，可用区决定的是【在这座城市里放几个机房】。

可用区的关键性质是：它是【同一区域内、物理上分开的独立机房】——各自独立的供电、制冷和网络。这意味着：

• 放在同一个可用区：省事、延迟最低（同可用区内部通信通常不到 1 毫秒），但那个机房出事，你就全停了。
• 生产服务分散到两个以上的可用区：某个机房整个掉线时，另一份还能接着服务——这是【高可用】在云上最标准的做法。

要提醒一点：多个可用区不等于自动高可用。 光把机器分散开还不够，前面还得配一个负载均衡器把流量分过去、数据库要做主从复制、应用本身要能无状态切换——少了这些，分散部署只是【多开几台机器】，故障来时还是接不住。

而多地域（跨城市）是另一个量级的事：它挡的是城市级灾害，代价是跨地域的网络延迟更高、数据同步更复杂、账单明显更贵。所以它通常只留给那些【真的停不起】的业务，而不是默认配置。

五、2026 现状：区域选择的三条新变化

教材写于 2022 年，区域选择的框架没变，但有几处【当下】的补充值得记一笔（本课沿用【⚠️ 2026 现状】的标记）：

① 合规从【选一边】变成了【一层套一层】。 2026 年，欧盟的 GDPR、各国的数据本地化要求、行业的监管规定同时生效，一个区域往往要同时满足好几套规则。云商为此推出了更细的选项——专属本地区域、区域内的多可用区部署、主权控制——这些是从【全球几十个区域】里再往下切一层，专门给合规要求严的场景用。

② 跨可用区不再算【额外开销】，而是默认配置。 早年把生产分散到两个可用区，会被当成【为了高可用多花的钱】；2026 年主流实践已经把它当成生产环境的起手式。跨可用区的数据传输费还在，但远低于跨地域传输——所以【同区域跨多个可用区】是高可用性价比最高的那一档。

③ 区域的【内容】变得不均匀。 新版 GPU、AI 加速实例常常先在少数核心区域上线。所以现在选区域时，要多查一步：【我可能用到的最重的那个组件，这个区域现在有没有？】——这比单纯比延迟更实际。

30 秒实验

打开任意一家云商的【区域列表】页面，做两件事：

1. 数一数它有几十个区域，其中在你所在的国家或地区有几个。
2. 随便点开三四个区域，看它们的价格和可用服务是不是完全一样。

做完你通常会确认两件事：区域的数量比想象的多，而它们之间确实【不一样】——同样的机器，价格有差、能用的服务也有差。这两个发现合起来就是这一节要教的动作：选区域不是随手挑一个，而是拿着自己的约束条件，一项一项往下筛。

常见误区

1. 错误：区域随便选一个就行，反正都在云上，性能差不多。——纠正：区域之间的差别，是【物理距离】带来的，不能靠软件消除。数据要跨城市跑，光速就是上限——几百公里的距离，延迟至少是毫秒级的差别，这个差别用户感觉得到。更别提合规：放错区域，可能是【数据出境】的合规问题，那不是性能问题，是能不能上线的问题。

2. 错误：既然多个可用区能保证高可用，那我全放两个可用区就万无一失了。——纠正：可用区挡的是【机房级】故障，挡不了【城市级】灾害，更挡不住【逻辑错误】。 误删、写坏的代码、勒索软件——这些会同步复制到你的每一个可用区。所以可用区要配，备份也要做（这正是 8-4 要讲的）；两者不是替代关系，是两道不同方向的防线。

3. 错误：成本是选区域时要考虑的最后一个因素，那它就不重要。——纠正：【排最后】不等于【不重要】。它的意思是：只有当前面三关都过了，成本才有资格参与比较。在候选名单内部的几个区域之间，成本就变成了那个打破平局的人——同样的合规、同样的延迟，谁便宜选谁，天经地义。 所以正确理解是：成本是筛选链的最后一环，但它是最后一环里最硬的那个标准。

4. 错误：预算有限，所以全部用竞价实例最省钱。——纠正：竞价实例便宜的前提是【你随时可能被收回】。它适合能容忍中断的批处理任务（跑一半被停，之后再跑）。但如果你把它用在数据库或者对外的网站上，那就是拿稳定性换折扣——省下的钱可能还不够一次故障的损失。 正确的做法是分层：核心负载预留、波动负载按需、能中断的批处理用竞价。

• ☐ 下一节（8-2 服务器的备份方法：热备份、冷备份、自动故障转移）

相关笔记

• 利用云服务的注意事项（看得见的地方） —— 【区域】这个词最早出现的地方
• 选择云服务提供商 —— 先选哪一家，再选放哪儿
• 支撑云服务的技术① 数据中心 —— 云上的机房到底长什么样
• ☁️ 云计算 · 索引 —— 全课路线图