1 全球基础设施回答什么问题：把应用放到哪里
C1 讨论了云把哪些资源变成服务，以及使用者仍要承担哪些责任。本课把视角移到地图上：同样是创建云主机、数据库和存储，为什么控制台总要先选区域？因为应用运行在真实地点，用户请求要经过真实网络，数据也会落在具有法律边界的设施里。购买相同规格，并不能抹平这些差异。
云的全球基础设施是一组架构约束。它决定哪些资源能靠近部署、哪些调用必须跨越长距离、哪些故障可能同时影响多个组件。软件中的调用箭头，在部署后可能变成跨城链路；设计图上相邻的应用和数据库，也可能因为选错区域而隔着几十毫秒。位置选择既影响日常体验，也影响故障时还剩下什么。
因此应先筛选区域，再画区域内的网络和资源关系。VPC 可以先理解为应用在云里的网络边界，其具体设计留到 C9。网络图画得再整齐，也无法让某区域凭空拥有尚未提供的数据库产品，更无法用配置消除数据出境限制。把区域当成创建资源时顺手选择的下拉框，往往会把前期的小决定变成后期的大迁移。
筛选时要同时回答 4 个问题：用户主要在哪里，数据目前在哪里，规则允许放在哪里，供应商在哪里提供所需能力。用户位置决定接入距离，已有数据库和外部系统决定调用距离，合同与法规限定候选集合，供应商足迹则决定候选区域有没有所需服务、可用区和容量。任何 1 项都可能否决一个看似理想的位置。
例如，用户多数在国内，并不直接推出“选距离办公室最近的区域”。办公室可能不是流量来源；支付或库存系统可能在另一座城市；最近区域也可能缺少所需数据库版本。较稳妥的做法是先列出候选区域和排除理由，再验证时延。本课最终要产出的是有证据的放置草图，供后续计算、网络和存储设计沿用。
2 Region 与可用区：故障域怎么切
Region 通常译为区域，可以近似理解为供应商在某个地理范围内组织的一组基础设施，具有相对独立的地理、供电和运营边界。这个近似有助于判断相关风险，却不能代替供应商文档：区域之间是否共享某些控制系统、支持流程或网络依赖，需要分别核实。区域名称也不等于精确机房地址。
可用区，简称 AZ，是区域内相互隔离的故障域。一个 AZ 可能包含多个数据中心，不能简单画成一栋楼。不同 AZ 通常隔离部分供电、冷却和网络故障，同时通过区域内网络连接。故障域的含义是：某类故障可能一起影响这个范围内的资源。它描述共同失效的边界，不是资源数量的别名。
在同一 AZ 创建 2 台主机，可以应对部分主机故障，却仍暴露于该 AZ 的共同故障。把主机放进 2 个 AZ，才改变了这一层风险的分布。但应用是否还能服务，还取决于入口是否能到达存活实例、实例是否有足够容量，以及数据库、会话和文件是否仍然可用。只把计算节点分开，不能证明整个请求链已经分开。
用一个刻意简化的概率例子建立直觉。假设在同一个观察窗口内，每个 AZ 失效的概率都是 1%，并且相互独立，那么 2 个 AZ 同时失效的概率是 1% × 1% = 0.01%。这里比较的是同一窗口中的事件，不能把不同时间口径的数字相乘，也不能把结果直接当成应用可用性承诺。
现实中独立性可能不成立。若区域级公共依赖失效，或同一次错误发布影响所有实例，跨 AZ 的节点仍可能一起不可用。即使基础设施没有共同失效，只要数据库仍是单点，请求也会中断。所以这个算式只说明隔离独立风险的价值，不提供某家云的真实故障率，也不能用于推导服务等级协议。
多 AZ 还不等于自动多活。“部署在多个 AZ”描述位置；“多个位置同时处理业务”描述运行方式。一个备用实例可能尚未接流量，副本可能不允许写入，入口也可能没有健康检查。判断部署是否有效，要沿着请求逐项询问：流量到哪里，状态从哪里读，写入由谁接受，某个 AZ 消失后哪些假设还成立。
本课只要求把这些假设标出来。具体切换机制和恢复流程属于后续内容，不能用一次动画里的箭头移动，替代真实产品的复制、探测和切换条件。
3 边缘与接入点：用户体感从哪一段开始
用户通常不会直接沿一条专线抵达应用所在的机房。请求先经过本地网络、运营商和云的接入设施，才进入后端。边缘节点或接入点常用 PoP 表示，它们让用户在较近的位置进入某个服务网络，可能承载缓存、代理或流量接入能力。它们的作用范围由具体产品决定，不应把每个 PoP 都理解成能运行完整业务的区域。
对于图片、脚本等可缓存内容，命中边缘缓存时，请求可以在边缘结束，不必每次访问源站。对于查订单、提交支付这类动态请求，即使先到附近接入点，通常仍要到应用和数据库所在区域完成处理。边缘能够改变接入路径，却不能消除后端的数据依赖。CDN 的缓存规则和一致性细节留给后续课程。
例如，首页图片加载很快，点击“我的订单”却慢，并不矛盾。图片可能在附近缓存命中，而订单查询仍需跨越较长链路。反过来，页面上的某张大图慢，也不能直接证明后端区域选错了；它可能没有命中缓存，或用户接入网络拥堵。讨论“网站慢”之前，要先确定慢的是哪种请求。
还要区分地址解析与业务连接。DNS 决定客户端获得什么地址，之后才会建立连接并发送业务请求。解析慢、接入点选择不理想、连接建立反复重试，都可能发生在应用处理之前。应用日志里的处理时间很短，只能说明它看到的那一段很短，不能替用户证明完整路径很快。
区域选择和边缘接入因此需要一起验证：区域决定主要计算与数据放在哪里，边缘决定哪些流量能较早进入服务网络、哪些内容能就近返回。验收时要分别测静态命中、动态读取和动态写入，并覆盖主要用户网络。只从云主机内部测通目标地址，无法代表手机用户的接入体验。
4 时延预算：把往返拆成可验证数字
时延预算是把一次请求允许花费的时间分配到实际路径上。RTT 指一次往返时间；用户看到的请求耗时还可能包含地址解析、连接建立、排队、应用计算和数据处理。一个请求若串行等待多个远程调用，即使每次调用只多出少量 RTT，总耗时也会逐次增加。距离不是唯一因素，但会给每次跨越距离的交互增加成本。
先区分冷连接和复用连接。首次请求可能包含 DNS 查询以及连接和加密握手，后续请求可能复用既有连接。若把首次访问的耗时与内部长连接的 RTT 直接比较，就容易把差异误归因于区域。测量表应注明连接是否复用、是否经过边缘、响应大小以及采样时间。
为了建立数量级直觉，可假设在某个低负载、链路稳定的同城环境中，相关网络往返约为 1–3 ms；跨 Region 往返可能是数十 ms，距离更远或路径绕行时还会更高。这些是教学假设，不是产品承诺，也不能推广成“任意两个 AZ 必然在此范围”。真实数值要在目标区域、目标网络和目标服务之间采样。
把订单读取简化为：用户接入往返 30 ms，应用到同区域数据库的往返 2 ms，应用处理 8 ms，数据库处理 5 ms。假设连接已复用、请求只串行查询 1 次、响应很小，并忽略排队，则总耗时约为 30 + 2 + 8 + 5 = 45 ms。这里的接入往返已经包含去程与回程，不能再乘 2。
若数据库换到另一个 Region，其往返变成 45 ms，其他条件不变，则总耗时约为 88 ms。若应用串行查询数据库 3 次，网络等待就从 3 × 2 = 6 ms 变成 3 × 45 = 135 ms。还需另加实际数据库处理时间。这个例子说明：用户离应用近，并不能补偿应用反复跨区访问状态的成本。
存储访问也要放进同一张预算表。读取对象、访问数据库、调用远端文件服务，可能分别走不同路径。若数据库本身跨 AZ 复制，该产品如何确认写入，也会影响写请求的耗时。不要把产品内部确认时间与已经测得的完整数据库调用耗时重复相加；预算的各项必须口径一致、边界清楚。
平均值不足以描述体验。P99 表示样本中约 99% 的请求耗时不超过该值，剩余约 1% 更慢；它需要足够样本，并注明请求类型、时间窗口和负载。平均 60 ms 的服务，仍可能有显著的尾部等待。多个环节的 P99 也不能直接相加得到端到端 P99，因为各环节慢请求是否重合并不确定。
SLA 是供应商按合同定义的服务承诺，常涉及可用性、统计范围和补偿条件；它不自动等于你的端到端 P99 目标。方案应分别写明业务目标和供应商承诺，再用端到端测量检查差距。对于每个预算项，都要能指出测量位置；无法测量的数字，应明确标记为待验证假设。
5 放置策略：聚拢、分散与配额
放置策略首先围绕调用关系展开。有状态组件保存后续请求还要使用的信息，例如订单、库存和会话；无状态组件不依赖自身保存的业务状态，通常更容易在多个位置承接请求。这里的“聚拢”通常指把频繁交互的应用与数据放在同一 Region，不意味着把全部组件挤进同一个 AZ。
订单写入依赖事务数据库，应用和数据库若频繁跨 Region 往返，时延会直接进入用户等待。应先把这条紧密调用链放在较近的范围内，再按故障域需求跨 AZ 分布。无状态入口可以分散，但每个入口背后的数据路径仍要画出来；入口多了，远端数据库并不会因此变近。
“只读可后扩”也需要前提。只读副本可能存在复制延迟，适合容忍旧数据的查询，却未必适合付款后立即确认订单状态。是否能扩展到其他区域，应由数据新鲜度要求和测量结果决定。当前阶段先保留位置上的可能性，不提前展开完整弹性伸缩策略，那是 C5 的主题。
资源能否创建，还受配额和即时容量约束。配额是账号或项目在某个范围内允许使用的上限，可能按区域、资源类别或实例族分别计算；容量是平台当时能否在目标位置提供所需资源。获批配额不等于预留容量，另一个 AZ 也不一定有相同规格。两者需要分别核实。
假设每个 AZ 平时需要 4 台实例。若方案要求任意 1 个 AZ 不可用后，另一个 AZ 仍能提供全部处理能力，就必须说明存活侧资源从何而来，以及目标位置是否具备配额和容量。仅写“故障后再创建 4 台”仍是未经验证的依赖。这里不决定扩缩容算法，只检查位置选择是否支持所写的故障假设。
区域评审时就应列出关键资源的额度、当前用量、申请周期、目标 AZ 的规格供应，以及托管数据库等服务的约束。把申请留到上线前，可能迫使团队临时换规格或换区域。配额清单因此是放置方案的一部分，而不是采购完成后才补的一张表。
6 数据驻留与主权：能放哪里要先问清楚
数据驻留关注数据存储和处理发生在哪里；数据主权还涉及哪些法律、主体和管理权限能够作用于数据。两者相关，却不能只凭控制台里的一个区域名称得出完整结论。数据库选择了某区域，不代表日志、备份、导出文件、技术支持访问和外部分析服务都自动遵循相同边界。
加密解决的是在一定密钥和权限条件下，谁能读取数据，并不直接回答数据落在何处。把数据加密后传到未经允许的区域，仍可能违反驻留要求。反过来，数据留在约定区域，也不能替代访问控制。讨论驻留时，应同时看位置、处理活动和合同责任，不能用某个安全功能勾选项概括全部要求。
先确定约束针对什么数据：订单中的身份信息、支付关联信息、业务日志，还是经过特定处理后的统计结果。再确定限制针对存储、备份、处理或访问中的哪些环节。“所有数据不得出区”与“某类原始数据不得在境外存储”会导向不同的候选方案，必须由有权解释要求的人确认。
接着把要求映射到产品。核对服务条款中的区域范围、复制选项、备份位置、支持与分包安排，并确认控制台配置与合同购买的服务实体、区域一致。有些能力按产品单独约定，不能因为同属一个供应商就假设规则一致。界面截图能证明某次配置，不能代替合同对处理范围的承诺。
证明还要有明确的接收者。内部合规负责人可能需要数据流向与条款依据，客户审查方可能需要区域承诺和配置记录，监管检查可能要求另外的材料。方案应写清谁审核、接受什么证据、由谁持续维护。涉及法律解释时，让相应负责人给出结论，工程团队负责把结论落实到可检查的放置约束。
跨区域副本也必须经过这道筛选。即使它被命名为备份，仍然是数据的一份放置。可以先把“允许本区域内跨 AZ 副本，跨 Region 副本待审核”写进草图，避免后续团队把复制开关当成纯技术优化。此处只建立位置边界，不展开容灾执行流程。
7 常见坑：单 AZ 当高可用、忽略配额、把 Region 当「更近=更好」
第 1 个坑是把“有云主机”直接写成“高可用”。1 台主机位于 1 个 AZ，主机故障和 AZ 故障都可能使它不可用。即使平台能重新调度，恢复需要多久、期间是否保留数据、入口是否重新发现它，都不能凭“云”这个字推定。评审时应要求列出每个组件的实际 AZ，而不是只展示资源总数。
类似错误也会出现在 2 台主机上：它们同属一个 AZ，数据库又只有单份，图上却标着双节点高可用。纠正方法是逐个删除故障域内的资源，检查请求链还剩什么。只要入口、状态或必要依赖仍在被删除的范围内，就要注明剩余风险。多 AZ 的效果来自完整链路的条件，不来自节点图标的数量。
第 2 个坑是把默认配额当成未来随时可得的容量。测试期只用了少量实例，上线或故障时才发现额度已经被其他项目占用；即使总额度够，目标实例族仍可能受限。评审必须看资源类别、区域和共享使用情况，而不只是账号总量。关键额度应提前申请，并记录审批状态；目标容量则要另行确认。
第 3 个坑是把“更近”简化成地图距离最短。供应商网络路径未必沿地理直线，用户也分布在不同运营商和城市。最近区域可能没有必需的服务，可能无法满足合同，还可能离现有数据库更远。最终选择应在服务与合规约束内比较端到端路径，不能只比较城市之间的公里数。
这些错误都容易被漂亮的架构图遮住。把图上的“高可用”“低时延”“合规”换成可核对的陈述，会更有用：资源位于哪些 AZ，哪条路径测得什么分布，哪些数据受哪项条款约束，额度申请是否完成。没有证据时保留假设，比提前给方案贴结论更便于后续修正。
8 案例：双 AZ 起步的区域选择草图
设有一个面向国内用户的订单 API，主要请求是创建订单和查询订单详情。团队希望先在 1 个 Region 内使用 2 个 AZ，后续业务需要时再考虑扩展只读查询。已知写入必须回到统一的事务数据路径，付款后的订单查询需要及时看到最新状态，因此不能先假设任意远端只读副本都可替代主数据源。
先构造候选区域表。区域甲和区域乙都能提供所需计算服务；核查后发现，甲提供所需数据库版本和跨 AZ 部署能力，乙缺少其中一项关键能力。再由合规负责人确认甲在合同允许范围内。甲因此进入测量阶段，乙记录为当前排除项。这是教学案例中的条件，实际项目必须用所选供应商的当前资料填写。
草图把无状态 API 实例分布到甲的 2 个 AZ，由具有相应区域和 AZ 支持的入口承接请求。数据库选择经核实支持跨 AZ 部署的产品配置，写入仍遵循该产品规定的入口和确认方式。图中标注主副角色、复制与切换行为待产品文档确认，避免把“2 个 AZ”误画成任意节点都能同时写。
时延假说是：主要用户到区域甲的复用连接往返不超过约 40 ms，应用到数据库的常态往返约 2 ms，应用与数据库处理合计约 15 ms，单次数据库访问的读取请求预计约 57 ms。它只描述简化条件下的估计，不是 P99 保证。团队另设端到端 P99 验收目标，并在预期负载下采样，检查尾部是否满足要求。
配额清单覆盖 2 个 AZ 的计算资源、入口服务和数据库配置，注明当前可用额度以及尚未批准的申请。故障假设另写一行：若一个 AZ 不可用，是否要求继续接收全部订单写入？若要求，就要核实入口、数据库和存活侧计算能力是否一起满足条件。当前证据不足时，标为未完成项，不能在验收表中直接勾选通过。
只读扩展先作为后续选项，限定于可接受一定延迟的数据查询；创建订单和付款后确认保持原有一致性要求。这样既保留扩展方向，也避免为尚未出现的跨区域需求增加路径和驻留问题。
最终验收收取 3 份相互对应的材料：区域表说明为什么选甲，时延假说与采样记录说明路径是否可接受，配额清单说明资源是否可获得。资源草图上的每个关键组件，都应能在这些材料中找到依据。它们足以支撑下一阶段详细设计，不需要在本课写成完整恢复手册。
9 排查案例：跨区慢、单边故障、合规拒批
排查要从现象进入路径，而不是看到慢就立刻换区域。保留发生时间、请求类型、客户端位置和网络、请求标识以及是否复用连接，再对照服务端记录。相同接口的快慢请求需要在可比较条件下采样；否则把不同响应大小、负载或操作混在一起，容易得到一个无法解释的平均值。
先看“页面慢、API 服务端处理却很快”的情况。路径 A 检查 DNS 与边缘接入：记录解析耗时、连接耗时、实际连接的地址和边缘命中信息，并从主要用户网络重复采样。如果解析和连接占了大部分等待，而请求到达后端后的时间稳定，优先检查解析链、接入选择或接入网络，不应先把数据库迁走。
traceroute 可以辅助观察可见路径与异常跳点，但中间设备可能不回应，也可能对探测报文限速；显示的节点位置也未必准确。某一跳耗时高而后续跳正常，不能单独证明该节点阻塞业务流量。应把它与面向实际服务的连接测量、请求耗时及供应商接入信息一起判断，避免把探测输出当成完整拓扑。
路径 B 检查应用到数据库的跨区调用。假设应用记录显示数据库等待约 150 ms，而数据库自身执行只需约 10 ms；部署清单又发现数据库误建在另一 Region。继续核对应用实际连接的端点，并测量该路径 RTT。若接口串行访问数据库 3 次，测得每次网络往返约 45 ms，就能解释大部分额外等待。证据链把位置错误与慢请求联系起来，而不是只凭“数据库在远处”下结论。
修正方向是重新评估应用与状态的放置，使紧密交互回到合理范围。实施迁移前仍需检查数据和合同限制，本课不展开迁移步骤。改动后用相同请求、相近负载和相同采样口径比较结果，才能判断原假说是否成立。
路径 C 检查客户端确实较远的情形。如果区内调用稳定，国内主要用户正常，远端用户的接入往返持续偏高，原因可能位于客户端到接入点或接入点到源站之间。应按用户地区和网络比较分布，检查静态内容是否命中边缘，再评估动态路径。不能因为少量远端请求慢，就把所有状态迁到另一个区域；这可能让主要用户和现有依赖同时变慢。
再看“一个 AZ 出问题后，另一侧也无法接单”。第一份证据是按 AZ 分组的资源清单和健康记录。若存活 AZ 的 API 实例正常，但数据库唯一写入端仍位于故障 AZ，就找到了完整请求链上的缺口；若数据库可用却没有流量，再核对入口后端分布与健康检查状态。检查结果要区分节点存活、入口可达、状态可用和容量足够，不能用一个绿色主机图标概括全部。
最后看合规拒批。团队可能已经证明延迟足够低，却被指出数据库备份使用了合同不允许的区域。此时关键证据是数据流向、实际资源与备份位置、适用区域合同条款，以及审核方给出的解释。先确认拒批针对哪类数据、哪种处理活动，再修正区域选择或相关配置。加密截图无法回答副本是否位于允许区域的问题。
这 3 类排查分别检验路径、故障域和许可边界，却都依赖前期材料。区域表帮助核对预期位置，时延预算定位异常增加在哪一段，AZ 分布说明共同失效范围，合同条款说明允许的边界。排查结束应把新证据回填方案，让后续设计继承已确认的条件，而不是只留下“已恢复”或“已通过”的结论。
放进方案里
在方案中加入区域与 AZ 表，列出候选区域、选中理由、排除理由，以及所需服务和版本的可用情况。对选中区域，逐项标明入口、应用、数据库和必要依赖位于哪些 AZ。标注要对应实际资源或已核实的产品能力，使评审者能从表中判断哪些组件可能一起失效。
附上时延预算，写明主要用户位置、接入路径、应用到数据的调用次数，以及各段预期耗时。区分教学估计、供应商信息与实际采样结果，注明连接是否复用、请求类型、负载和采样窗口。平均值与 P99 分别记录，并给出端到端验收目标；未测量的链路要写明负责人和验证条件。
驻留约束按数据类别填写，至少覆盖主要业务数据、日志与备份，说明允许存储和处理的区域、禁止的流向及所依据的合同条款。记录由谁解释要求、由谁批准、需要提交什么证据。控制台区域配置与合同范围需要对应，跨区域副本在获得结论之前不能被当成默认选项。
配额表列出目标区域内关键资源的上限、当前用量、预期需求和申请状态，同时单独记录目标 AZ 的规格或容量限制。若故障假设依赖在存活 AZ 增加资源，明确其配额与容量依据；有额度但没有供应确认时，仍应保留这个未验证条件。
最后用可检查的句子描述故障域假设：某个 AZ 不可用时，哪些入口仍能接收请求，哪些实例继续运行，业务数据由什么已确认能力支撑，哪些业务可能暂停。把公共依赖和证据缺口标在同一张草图上，并给出材料日期与维护人。这些内容形成位置选择的交付边界，供后续网络、计算和存储设计继续细化。
10 小结：走向虚拟化入门（C3）
全球基础设施把用户距离、故障域、服务供应与数据边界带进同一个决策。Region 决定较大的放置范围，AZ 帮助隔离区内故障，边缘影响接入与内容返回路径；它们都不能单独保证业务结果。用区域表、时延预算、驻留约束和配额清单，才能把位置判断变成可验证的方案。
确定资源放在哪里之后，还要理解云如何把物理计算资源交给应用。C3 将进入虚拟化入门，解释虚拟机与底层资源的关系，为后续计算设计建立基础。