1 主流云对比要回答的决策问题
零售团队准备上线订单 API：用户点击提交订单，系统检查商品与库存，生成订单，再把后续处理交给后台任务。候选平台可能包括 AWS、Microsoft Azure、Google Cloud、阿里云、腾讯云、华为云。每个平台都能提供计算、网络、数据库与存储服务，但产品名称、默认行为、可用区域和计费规则不同。初学者容易把对比做成名称背诵：记住某家的虚拟机叫什么，却说不清订单写入失败以后该检查什么。
学习对比的目的，是把业务要求翻译成平台必须满足的条件。订单接口要求什么地区能访问、可以中断多久、能否重复扣减库存、谁可以读取用户信息，这些问题比产品列表更稳定。先写约束，再找服务，最后用实验验证，可以避免因为熟悉某个控制台就提前确定方案。云平台的名气、服务数量和单项性能纪录，都不能替代当前订单链路的证据。
本课把候选云放在相同场景中：平时每秒 200 次下单请求，活动峰值每秒 2000 次，业务希望提交接口的第 95 百分位延迟低于 500 毫秒。这个百分位表示约 95% 的请求耗时不超过该值。用户收到成功结果前，订单必须可靠保存；库存扣减不能因为重试执行多次。这里的数字是教学假设，实际项目需要根据流量记录、用户体验和业务损失重新确定。
对比也有边界。本课不选出长期有效的冠军，不把所有云的同类产品视为等价，不深入数据库内核与跨地域一致性算法。我们练习的是可迁移的顺序：明确需求、识别责任、拆解请求路径、检查故障行为、收集观测数据、估算费用。服务改名或价格调整后，这套顺序仍然可用。
本课的对照练习以 AWS 与阿里云为主样本，并允许替换为你实际候选的两家平台；方法不变：同一订单场景、同一地区与负载、同一 RTO/RPO 口径。第三家云只在前两家出现不可接受缺口时再进入短名单，避免一上来做六家名词赛。
2 主流云对比：账户、地域、网络与身份模型差异
比较前先分清平台、服务和配置。平台是提供多种服务与管理能力的整体；服务是其中可购买的能力；配置决定当前项目中的具体行为。相同平台里，配置不同也可能产生完全不同的可用性。把某家云的单可用区数据库与另一家的跨可用区数据库比较价格，数字虽然准确，比较本身却不公平。
账户层级是第一道对照。以 AWS 与阿里云为例：AWS 常见组织是 Organization → 多个 Account → IAM 用户/角色；阿里云常见是企业主账号 → Resource Directory / 资源夹 → RAM 用户/角色。两边都能做到「订单生产与实验隔离」，但隔离边界的名字与默认权限不同。订单项目应单独账户（或资源夹）承载账单与配额，避免实验账号的密钥策略漂移进生产。跨账户读日志或共享镜像时，要核对信任策略写的是哪个主体，而不是假设「同组织即可访问」。
地域与网络作用域也要同条件对照。AWS 的 Region/AZ 与阿里云的地域/可用区都表达地理与故障隔离单元，但具体城市覆盖、延迟和产品可用性以文档为准。VPC（AWS）与专有网络 VPC（阿里云）都能划私网；子网是否默认出公网、安全组与网络 ACL（或等价访问控制）的默认放行集合不同。订单 API 若要求「仅私网访问数据库」，两边都要分别验证：子网路由、安全组入站、以及托管数据库是否绑定了正确的私网地址——不能因为两边都叫 VPC 就认为默认相同。
身份授权模型对照要落到「谁能下单、谁能改库存」。AWS IAM 的身份策略与资源策略可分开写；阿里云 RAM 策略同样区分身份与资源，但条件键、会话时长默认值与 STS 换票流程的控制台入口不同。比较时固定同一故事：应用角色只能写订单表、运维角色可重启实例但不能导出全表。在两边各创建等价角色后，用一次拒绝访问与一次成功写入做证据，而不是只截策略 JSON。
责任共担与控制面/数据面仍要分开问。租用虚拟机时，团队通常维护操作系统与应用；使用托管数据库时，平台承担更多底层运维，团队仍负责权限、数据模型与恢复目标。控制面创建资源失败时，已有订单请求是否仍可走数据面？两边答案可能都是「多数情况下可以」，但限流、配额打满与区域级事件的表现要用当前状态页与演练记录核对，不能互相抄结论。
做账户对照时，建议固定一张「谁能碰生产订单」矩阵：列是角色（应用、值班、平台管理员），行是动作（读库、改安全组、发版、下载备份）。在 AWS 与阿里云各落地一次后，矩阵里不允许出现「两边默认管理员都能下载全量备份」却无人签字的空档。身份差异往往比计算规格差异更早变成事故。
3 主流云对比：计算/存储/网络产品能力映射
第 1 个机制是把需求变成可检查的条件。「高可用」需要改写为允许哪些故障、影响多大范围、多久恢复。RTO 表示希望多快恢复服务；RPO 表示最多能接受多长数据丢失窗口。订单系统可以要求某类故障下 RTO 不超过 10 分钟、RPO 接近 0，但只有在明确故障范围、复制方式和切换流程后，这些数字才有意义。
第 2 个机制是沿责任边界做产品语义对照，而不是名称索引。计算：AWS EC2 与阿里云 ECS 都能跑同一容器镜像，但停机行为、元数据服务地址、实例自定义数据注入方式不同；健康检查与自动替换要分别看 Auto Scaling / 弹性伸缩组的探针字段。对象存储：S3 与 OSS 都提供按对象读写，但一致性说明、跨区域复制、生命周期规则与预签名 URL 的权限边界要以当前文档为准。托管数据库：Amazon RDS 与阿里云 RDS 都提供自动备份，但跨可用区切换是否导致连接串变化、只读副本滞后如何观测，必须各自验证一次。
第 3 个机制是保持比较基线一致。固定目标地域（例如都选「离用户近且产品齐全」的同一业务地区）、同样的每秒 200 / 峰值 2000 请求、同样的订单表规模与第 95 百分位延迟目标，再填对照表。若某平台在该地区缺少托管队列，应记录缺口与自建/换服务的代价，不能悄悄改到另一地区再宣称「都支持」。
第 4 个机制是把费用放回完整链路。按需实例单价低，不代表完整订单链路便宜；跨可用区流量、公网出网、日志索引与支持计划可能反转结论。用同一流量模型分别跑两边的官方估算器，并标注价格日期。
第 5 个机制是衡量迁移与锁定。容器镜像便于携带应用文件，但 IAM/RAM 条件键、队列可见性超时语义、监控指标名仍可能绑定平台。可迁移性要写清：迁移哪些部分、允许多长停机、谁做恢复验证。把 SDK 调用收到少量适配层，比提前自建「万能云抽象」更务实。
建立对比表时，每行包含需求、AWS 实现、阿里云实现、证据来源、验证结果与剩余风险。官方文档确认支持范围，账单估算提出成本假设，压测与恢复演练确认当前配置表现。任何结果都要附日期、地域、规格与负载条件。
产品语义对照还要包含失败模式。例如对象存储的「覆盖写是否立即对所有读者可见」、队列的「同一消息是否可能被两个消费者看到」、负载均衡在后端全挂时的返回码。把这些失败模式各写一行到对照表，比只抄产品彩页更能决定订单链路能不能扛住重试。
4 订单方案：可移植约束与锁定点
订单链路可以从入口开始画：客户端通过域名访问负载均衡，负载均衡把请求交给应用实例，应用在数据库事务中保存订单与必要的业务状态，再由后台任务处理通知等工作。不同云提供不同入口、计算形态和消息服务，但每个节点承担的职责应写清楚。否则，把虚拟机替换成函数计算后，团队可能遗漏连接池、并发限制和冷启动带来的延迟变化。
同步路径只放入用户必须立即知道结果的工作。若承诺“订单已创建”，返回成功前就必须满足对应的持久化条件。短信通知通常可以异步完成。库存与订单若由不同服务管理，需要另外设计业务状态和补偿，不能靠画出 1 条箭头就假设跨服务操作具有原子性。入门阶段可以先采用单个事务数据库保存订单及相关状态，减少尚未掌握的分布式协调问题。
客户端可能因为网络抖动重试。假设应用已提交订单，返回响应时连接断开，用户只看到超时。客户端重新发送请求，如果服务端每次都新建订单，就可能产生重复订单。可以让客户端为同次下单使用稳定的幂等键，服务端将其与请求摘要、订单编号和处理结果关联，并以数据库唯一约束保护。相同键携带不同商品内容时，应拒绝混用，避免返回不属于当前请求的结果。
消息队列也不应被理解为“投递后只处理 1 次”。实际服务常提供至少 1 次投递等语义，消费者需要允许重复消息。若订单已保存但发送消息失败，就会出现订单存在、后台任务未触发的缺口。可以在同个数据库事务里保存订单和待发送事件，再由后台程序读取事件并投递；投递与消费仍需去重、重试和观测。这种做法有额外维护成本，应根据链路可靠性要求决定是否采用。
跨可用区部署能降低部分故障的影响，但要检查实际流量与依赖。如果应用有 2 个实例，分别位于不同可用区，而数据库只有单区实例，数据库仍可能成为共同故障点。如果负载均衡健康检查只访问固定文本页面，应用失去数据库访问能力后仍可能被判为健康。健康检查应与流量调度目的匹配，也要防止依赖短暂抖动引发所有实例反复退出。
对比候选云时，逐个标注入口的超时、应用并发、数据库连接、队列重试和跨区通信。超时应由外到内协调，为必要的响应与清理留出余量。重试要限制次数，采用退避，并只对适合重试的错误执行。否则峰值期间每个失败请求都立刻重发，实际负载会继续增加。平台提供的自动扩容只能缓解部分容量问题，无法修复重复扣减库存这种业务错误。
把「可移植约束」写成两列对照更不容易飘。例如：订单主键与幂等键格式不依赖某云生成器；对象键名与元数据不绑定单一厂商的特殊头字段；密钥通过各云的 KMS/密钥管理注入，应用只读环境变量。锁定点也要显式列出：若选择某云的专有队列语义或独有的 IAM 条件键，就在方案里标注「迁移时需改写适配层」，并估算人天。这样对比的是约束与锁定，而不是口头上的「我们可多云」。
5 动手：对照控制台对象与计费项
动手时选择测试账号或隔离项目，在 AWS 与阿里云 各部署相同的最小订单接口。实验保持相同应用版本、数据库初始数据、请求内容和测试时长，并记录地域、规格和网络路径。先验证每秒 200 次请求的基本行为，再逐步提高负载。只有请求成功率、重复订单数与延迟都符合要求，吞吐数字才有比较价值。
控制台按相同顺序观察两边：账户/项目与地域 → 虚拟网络与子网 → 入口与证书 → 计算实例 → 数据库 → 权限 → 日志 → 费用。每到一项，记录创建者、配置值与默认值，尤其是公网访问、备份周期、删除保护与日志保留。把「默认值」当成待确认配置，而不是安全基线。
命令行形成可重复记录。核对当前身份、目标项目/账户和地域后，再查资源状态。以下请求打本机教学接口，用于核对幂等，与云厂商无关；云侧则分别用各平台 CLI 列出实例与数据库状态（命令名不同，但核对字段同类：运行状态、私网地址、备份窗口）。
curl --request POST 'http://localhost:8080/orders' \
--header 'Content-Type: application/json' \
--header 'Idempotency-Key: demo-order-001' \
--data '{"sku":"SKU-100","quantity":1}' \
--write-out '\nstatus=%{http_code} total=%{time_total}\n'连续执行相同请求，检查订单编号与数据库记录。换一个幂等键应表示新下单意图。费用实验固定口径：同样的每月请求量、平均响应大小、数据库容量和日志保留天数，分别填入两边估算器；再增加峰值时长、跨区传输与恢复资源情景，看哪些项最敏感。结束时按清单清理临时实例、磁盘、快照、地址和日志，避免只删进程却继续计费。
滑块只解释冗余容量与费用的关系。真实选型要用压测修正容量，用候选云当前报价替换单位费用，并核对实例故障时剩余容量是否足够。
动手记录模板建议每家云各 1 份：创建时间、地域、VPC/子网 ID、实例规格、数据库引擎与多可用区开关、估算器截图日期、清理完成时间。两份模板字段对齐后，才谈差异；字段都对不齐时，先统一观测口径。
6 观测：迁移成本信号与配额差异
比较可观测与配额时，先写要回答的问题：哪类订单变慢、慢在哪段、是否重复写入、恢复是否有效。指标看趋势，日志看事件，追踪连接同次请求的片段。平台能否接入这些信号很重要，但关联字段仍要应用侧设计。
对照 AWS CloudWatch / X-Ray（或等价）与阿里云云监控 / 链路追踪：能否按接口、状态码、可用区拆分第 95 百分位延迟？日志能否用同一 trace_id / 请求标识检索？导出与保留策略的费用是否在估算里？某次失败「追踪里没有」，可能是采样未覆盖，不能证明请求未发生。
配额差异经常在活动前才暴露。两边都可能对 vCPU、公网 IP、API 调用速率、数据库连接代理有账户级上限。把「支持扩容」与「活动当天额度已批」分开验证：在目标地域提交提额工单（或确认已有额度），记录审批时长；压测前确认限额 ≥ 计划峰值，并保留工单编号作为方案附件。
迁移成本信号要可观测：一次小规模导出—导入演练中，记录数据导出耗时、导入校验差额、DNS/配置切换窗口、以及跨云出网费用估算。若主库只在一家云，另一家的应用副本读到的滞后与冲突规则必须写进观测看板，而不是上线后才发现。
建立基线时保存正常时期的相同指标与配置快照。故障时才能判断变化来自活动流量、版本发布还是资源调整。
7 常见坑：名词对齐当能力对齐、忽略支持边界
第 1 类坑是用服务数量或产品名相似程度选云。订单团队实际只使用少量能力，更需要确认目标地域的支持、现有人员经验和恢复流程。宣称“兼容某接口”时，应检查使用到的操作、错误码、权限与边界行为。只跑通上传 1 个对象，并不能证明迁移工具依赖的分片上传、签名验证和生命周期行为都一致。
第 2 类坑是只看正常路径。演示中所有请求都成功，无法说明数据库切换、实例退出或消息重复时系统的行为。测试环境应覆盖少量明确故障，并事先定义观察点和恢复条件。故障演练不必一开始就覆盖所有组件；先验证应用退出后流量是否转移，再验证响应丢失后的重复提交，通常能发现很实际的问题。
第 3 类坑是把多云当成自动容灾。部署在 2 家平台会增加网络、身份、数据复制、发布和故障切换的复杂度。若主数据库只在其中 1 家，另一家的应用可能仍然无法下单。跨云切换还需要明确谁能写入、如何防止双写冲突、域名变更多久生效。对于入门团队，先把单云中的备份、跨区部署和恢复演练做扎实，往往更容易得到可证明的可靠性。
第 4 类坑是把标价当最终成本。费用还受操作次数、流量方向、日志量、备份和折扣利用率影响。比较时不能把某平台的试用额度当成长期单价，也不能忽略运维投入。记录价格日期与估算假设，给出正常、峰值和故障恢复等情景，比单独写出 1 个精确到小数点的总额更有解释力。
第 5 类坑是用扩大权限解决所有失败。应用访问数据库或存储失败时，应检查身份、网络路径和授权范围，临时授予管理员权限会掩盖根因，还可能把实验配置带入生产。平台间权限模型并不完全相同，迁移时应重新验证允许与拒绝的操作。可用性与安全性都依赖准确配置，不能以“已经上云”为由跳过检查。
第 4 类坑是把「两家都有同类产品」写成「可以随时切主」。没有演练过的写入切换、没有防双写开关、没有出网预算，多云只是两份账单。对照表里对切主相关行必须填演练日期；空白即未具备该能力。
8 案例：多云灾备选型争议
零售团队争论要不要做「双云灾备」：订单库主写在云 A，云 B 放置热备应用与异步复制的只读库；目标写进方案的是 RTO ≤ 15 分钟、RPO ≤ 1 分钟。争议焦点不是品牌，而是复制延迟、跨云出网、写入切换与支持边界能否同时满足。
演练证据先摆到桌上。近 30 天复制滞后 p95 约 40 秒，偶发到 3 分钟；跨云出网按当前流量估算每月固定成本已接近一台数据库实例。切换演练中，DNS/流量入口切到云 B 后，只读库升主需要人工确认，期间若云 A 仍有迟到写入，会出现双写风险。支持界面上，跨云链路的丢包要分别开两家工单，缺少统一故障时钟。
反对「双活写入」的理由成立：两家云都没有为该订单模型提供开箱即用的跨云同步提交；自建两阶段提交会把库存扣减的复杂度抬到团队当前无法值班的程度。折中方案改为：单云多可用区承担日常 RTO/RPO，跨云只做每日校验的冷备导出；活动前把冷备恢复时间测到 ≤ 2 小时，并接受该情景下 RPO 以最近成功导出为准。这样跨云出网从持续复制降为定时增量，支持边界也回到「本云工单 + 备份可读」。
选型争议的结论必须带条件：若未来复制滞后稳定 < 30 秒且切换可自动防双写，再重新评估热备；当前证据不支持把「多云」写成自动容灾。应用层仍要保留幂等键与唯一约束——那是换任何拓扑都要带走的正确性底线。
验收：RTO/RPO 数字旁附演练日期与拓扑图；跨云方案必须写明写入主归属、防双写机制、出网费用与支持路径；做不到的项标为未采纳并说明单云多 AZ 的替代证据。
9 排查案例：选型争议证据链
值班收到两条互相矛盾的结论：架构组主张「已经双云，活动可扛单云故障」；运维组根据最近演练认为「切换窗口超过 15 分钟且存在双写窗口」。排查不先争论品牌，而先对齐证据链。
第 1 步核对拓扑事实。当前主写在哪家云、复制方向、入口 DNS 的 TTL 与实际生效时间、冷备最近成功点。打开两边控制台与监控，确认只读库滞后曲线、跨云带宽使用与最近一次切换工单时间戳一致。若文档写「热备」但监控显示每日一次导出，先改名再谈 RTO。
第 2 步按时间线重放演练。选取最近一次切换：流量切走时刻、旧主是否隔离写入、新主提升完成时刻、第一笔成功订单与第一笔冲突订单的时间。用同一 trace_id / 订单号在两边日志交叉检索。若旧主隔离晚于新主接写，双写风险成立，RPO/RTO 承诺无效。
第 3 步核价与支持路径。把跨云持续复制的出网费用按最近 7 天流量外推到活动月；对照「单云多 AZ + 定时冷备」的费用与恢复演练时长。同时列出故障时要开的工单通道：单云工单是否覆盖复制链路，还是必须两家并行。费用或支持任一不可接受，都足以否定当前双云热备叙事。
第 4 步给出可执行结论。短期：保持单云多 AZ，冷备恢复演练达标后写入方案；双云热备标为未采纳并附演练缺陷。应用侧幂等与唯一约束继续保留。复审条件写清：复制滞后 p95、自动防双写、出网预算与支持时钟 4 项同时满足后再开题。
若证据链显示复制滞后与防双写任一未达标，方案应明确写「不采用跨云热备」，并附单云多可用区演练记录作为替代；把未采纳写成可复查的工程决定，而不是口头偏好。
放进方案里
在订单系统方案中，先写业务边界：服务面向的用户地区、数据允许存放的位置、平时与峰值请求量、订单成功的定义，以及重复提交的处理方式。再填写第 95 百分位延迟目标、可接受中断时间、RTO 与 RPO，并说明这些目标针对的故障范围。需求有待确认时标注负责人和确认日期，避免把教学数字直接当成生产承诺。
候选云对比表按计算、入口网络、数据库、消息、身份、观测和费用展开。每项记录目标地域是否支持、所选配置、团队承担的工作、文档日期和实验结果。公平比较要使用相同流量、数据量、备份与冗余要求；无法满足的条件单独说明，不通过更换假设来隐藏。选型理由应能对应具体需求，例如恢复演练达到约定时间，或现有团队可以维护所选计算形态。
架构图标出同步提交边界、数据库事务范围、异步事件和可用区分布。明确幂等键的生成与保留规则、唯一约束、重试上限、超时预算和连接总量。对外返回成功的时刻必须与持久化承诺一致。监控清单同时包含请求错误、尾部延迟、连接等待、事件年龄和重复订单信号，并为告警指定处置入口。
费用部分提供正常、活动峰值与故障恢复情景，覆盖计算、数据库、传输、日志、备份及必要支持。列出折扣假设、价格日期和预算告警。迁移部分说明数据导出、配置重建和恢复验证方式，给出实际演练证据。最终保留剩余风险、回滚条件与复审时间，让选型成为能够随业务变化重新检查的决定。
候选云进入采购前，应在目标地域验证峰值配额已获批、数据库切换后订单无重复、备份可恢复到约定时间点。验收附件保留配额审批记录、切换期间的请求结果与恢复数据核对表；仅有产品文档或估算器截图的项目仍列为待验证。
10 小结：走向方案设计练习（P12）
- 能先说明订单业务约束，再列出候选平台与服务类别。
- 能区分平台能力、当前配置和团队承担的责任。
- 能用相同地域要求、负载与恢复目标建立比较基线。
- 能沿请求路径检查超时、重试、幂等、连接预算与消息重复。
- 能用指标、日志、追踪和业务记录形成可核对的证据链。
- 能把费用假设、恢复演练与迁移限制写入选型理由。
自测：如果增加应用实例后错误率反而升高，应先补齐哪些连接与并发证据？如果客户端超时后重新提交，怎样确认只生成了 1 个订单？如果某候选月估算更低，哪些费用与恢复条件还需要核对？能把这些问题讲清楚，就已经开始用工程判断比较云平台。
下一课转向 P12 方案设计入门练习。
把本课的对照表口径带走：同一地域与负载基线、账户/网络/身份差异、产品语义与配额证据、以及「多云灾备」只有在 RTO/RPO/防双写/出网与支持路径都可演练时才写入方案。下一课用这些约束完成一份可检查的方案练习，而不是再扩一份厂商名词表。
作业：附上 AWS vs 阿里云各 1 行「需求—实现—证据」样例，以及本课灾备争议的采纳/未采纳结论，作为 P12 练习的输入附件。