云平台内核：计算

1 云平台内核：计算要理解什么

点击“创建实例”后，页面很快出现 4 vCPU、8 GiB 内存和运行中的状态。应用团队随后部署订单 API，配置身份权限、安全组、数据库地址与监控，就能接收请求。但这张规格卡片没有回答：实例实际运行在哪台物理机器上，与谁共享资源，机器坏了以后由谁恢复。云平台的计算内核，正是把可申请的规格变成实际执行能力，并持续处理这些问题的系统。

可以先把宿主机理解为机房里真正提供 CPU、内存和网络接口的服务器，把实例理解为平台交付给租户的运行环境。本课主要使用虚拟机实例作为例子。虚拟化层在宿主机上提供隔离的运行环境，控制面接受创建、停止等请求，调度器从候选宿主机中选择位置。应用请求进入实例后，主要依赖实际计算资源执行；控制面显示创建成功，并不等于应用已经健康。

订单 API 的路径可以帮助我们看清责任：客户端经过入口访问应用实例，实例以自己的服务身份访问数据库，日志和指标进入观测系统。网络控制决定哪些连接可达，身份控制决定哪些调用获准，数据库保存业务状态，计算资源承载代码执行。实例位置变化可能影响连接和性能，但不能替代这些控制。平台把实例放好后，团队仍需正确配置权限、连接与健康检查。

学习计算内核，先抓住 3 个问题：请求的资源能否得到满足，多个工作负载共享机器时是否相互干扰，承载资源失效时业务能否继续。这些问题分别关联放置、隔离和恢复。它们不是互不相关的按钮：为了提高利用率而集中放置，会扩大共同故障影响；为了减少干扰而预留更多容量，会减少可售资源。理解这些关系，比背诵某种实例型号更有迁移价值。

还要区分实例生命周期与业务生命周期。实例处于运行状态，可能尚未完成配置加载；实例重建成功，可能尚未重新连接数据库；应用进程退出，也未必需要更换宿主机。本课讨论平台怎样承载实例，以及应用团队怎样提出可检查的计算要求。CPU 微架构、具体调度算法和虚拟化实现细节留给后续学习，这里先建立足以做方案和排障的判断框架。

2 调度、超卖与隔离

调度的入口通常是资源请求与放置约束。资源请求包括 vCPU 数量、内存容量以及实例所需的附加能力；约束可能包括区域、可用区、宿主机类型和与其他实例的位置关系。平台先排除不符合硬条件的机器，再对剩余候选位置进行比较。即使集群总空闲内存很大，也可能没有任何单台机器能容纳目标实例。总量充足与存在可行位置是不同判断。

例如实例需要 8 GiB 内存，2 台宿主机分别只剩 6 GiB 和 5 GiB 可分配容量，总量虽然超过需求，当前仍不能放置。CPU、内存和网络能力还必须同时满足要求。调度器不能把不相连的资源数字随意拼成实例，也不能为了得到较高利用率而越过强制隔离条件。排查创建失败时，应先看候选被排除的原因，再判断是否确实需要扩容。

超卖是把某类资源对外承诺的总量设置得高于可同时提供的物理执行能力，利用不同租户不会一直同时达到峰值的事实。这里要区分“承诺多少”与“此刻用了多少”。例如某资源池的 CPU 配置总量较大，但大部分实例平时很空闲，短期仍可能运行平稳。一旦大量实例同时繁忙，资源竞争就会显现。超卖没有创造算力，它把峰值重叠的风险变成需要管理的容量问题。

CPU 与内存也不能套用同样直觉。CPU 执行时间可以在工作负载之间分配，因此共享常表现为等待变长；内存则需要实际承载程序数据，压力过大时可能触发回收、换出或分配失败，具体取决于平台机制。本课不假定所有云都以相同方式超卖内存。阅读产品或内部规格时，应分别确认资源的分配方式、保底条件和压力行为，不能用“支持超卖”概括全部资源。

隔离至少包含安全边界与性能边界。前者关注租户能否越权读取或修改其他租户的数据与运行环境；后者关注共享资源竞争会怎样影响吞吐和延迟。虚拟化提供了重要隔离机制，但通过安全隔离检查，并不自动获得稳定性能。CPU 执行时间、共享网络和存储访问路径都可能形成竞争。专用宿主机减少了跨租户共享，也仍然存在应用自身争用和底层设备故障。

理解这个过程后，再看“调度成功”的含义就更准确：平台找到了当时符合已知条件的位置，并完成了相应创建流程。它不保证未来负载不增长，也不保证所有共享资源都没有竞争。容量监控、放置规则和业务健康检查必须继续工作。对于订单 API，创建后的验证应包括进程就绪、入口可达、身份授权成功和数据库连接正常，避免把资源交付误当作业务交付。

3 热迁移与故障域

热迁移通常指实例保持运行的同时，把执行环境从源宿主机转移到目标宿主机。可以把它理解为搬走正在工作的运行现场：先准备目标资源，逐步传递运行状态，在切换阶段暂停短暂执行，再让实例在目标位置继续。这个解释只是概念模型，不要求读者掌握内存复制机制。不同平台的实现、停顿时间、支持的设备和适用实例范围都可能不同。

计划维护是理解热迁移的合适场景。源宿主机仍能正常协作时，平台有机会提前准备目标，并控制切换时机。突然断电则不同：源机器可能无法提供最新运行状态，恢复常需要在其他位置重新启动或重建实例。因此“支持热迁移”不等于“宿主机任何故障都不会中断”。方案应分别说明维护迁移与意外故障的恢复路径，并明确哪些状态可能丢失。

迁移也有前提。目标需要满足容量和兼容条件，实例使用的存储与设备必须支持对应迁移方式。若应用使用临时本地数据，或绑定某些无法迁移的设备，平台可能限制迁移，或采用其他维护方式。即使网络地址保持不变，连接也可能受到短暂停顿影响。应用应设置合理超时和有限重试，并用请求标识防止订单重试造成重复处理。

故障域是可能因共同原因同时受影响的一组资源。宿主机是直观例子：同机的多个实例会共同受到该机器掉电影响。机架、供电单元或可用区也可能形成更大的故障域，但名称本身不能证明彼此独立。设计时应明确自己防的是哪种事件，以及位置规则究竟约束到哪层。分散到不同宿主机，不能直接推导出已经应对可用区故障。

副本数只有结合位置才有意义。订单 API 有 3 个副本，若都运行在同台宿主机上，进程级故障可能被其余副本承接，宿主机故障却可能让全部副本消失。放到不同宿主机后，还要确认剩余副本能否承担流量，以及入口能否及时剔除失效目标。实例分散、负载余量和健康路由共同构成恢复能力，缺少任意环节，都可能出现“副本还在但业务不可用”。

4 动手：对照一次实例放置决策

下面用纸面资源表模拟放置，不需要真实云账号。假定平台已经扣除系统预留，表中的 CPU 是本练习定义的可分配 CPU 预算，内存是可分配容量；它们不代表某款产品的物理核映射。准备创建订单 API 的第 3 个副本，规格为 4 vCPU、8 GiB 内存，位置要求为可用区 A，且必须避开已承载同组副本的宿主机。

先按硬条件划去候选。H1 的资源够，但违反同组副本分散要求；H3 的 CPU 预算够，内存不足；H4 的资源最多，却不在指定可用区。H2 满足全部条件，因此是本轮可行位置。这里没有必要引入复杂评分公式：可行候选只有 1 个，先解释为什么可行，比计算一个漂亮分数更重要。完成分配后，H2 的练习预算剩余 2，内存剩余 4 GiB。

接着改变条件，观察决定如何变化。如果将新副本内存改成 16 GiB，当前候选全部不满足条件。合理结果是等待容量、增加合适宿主机，或通过明确的变更流程调整需求。不能静默放宽强制分散规则，再把结果报告为高可用。若业务允许跨可用区放置，H4 可以进入候选，但这同时引入跨区通信、数据依赖和费用等问题，不能只看空闲数字。

再假定分散要求是“尽量”，而不是“必须”。此时 H1 可能保留为降级候选，平台在没有更好位置时仍可能创建实例。两类规则的行为不同：强制规则可能导致待调度，偏好规则可能牺牲位置目标。团队应把这一差异写入服务配置与告警，避免在容量紧张时误以为副本仍满足原先的故障假设。可用性要求需要可见的执行结果。

最后写下本次决策记录：需求版本、候选范围、逐项排除理由、最终位置、分配后的余量，以及创建后业务检查结果。若实际平台不向租户公开宿主机标识，可以使用平台提供的放置组、分散规则状态和故障事件信息验证对应保证。动手的目的不是猜出内部服务器编号，而是学会用约束与证据解释决定，并识别哪些信息仍需平台方提供。

5 利用率与吵闹邻居取舍

把实例集中放置，可以减少闲置机器，提高资源利用率；保留余量并分散关键服务，则为突发流量、迁移和故障接管留下空间。两种选择都要联系业务目标。每日离线报表允许晚些完成，订单提交接口却可能有明确延迟目标。同样的共享策略放在不同工作负载上，结果可能完全不同。先定义可接受的表现，再讨论怎样节省容量。

吵闹邻居指共享资源环境中，某个工作负载的活动对其他工作负载造成明显干扰。邻居未必越权，也未必超过自己允许的规格；多个合规工作负载同时进入高峰，仍可能在共享路径上竞争。例如订单 API 与批量导出任务同时繁忙时，API 的 CPU 等待或网络延迟可能上升。需要靠观测与对照辨认竞争发生在哪里，而不是把所有波动都归因于邻居。

平均利用率尤其容易掩盖问题。某小时平均 CPU 利用率较低，仍可能包含持续数分钟的争抢；请求平均延迟正常，也可能有少量订单等待很久。对于在线 API，应同时查看吞吐、错误率和延迟分布，例如 p95 表示约 95% 请求的延迟不超过该值。观察窗口和样本数也要一致，低流量下的分位数波动不能直接与繁忙时段比较。

交互里的资源池只演示“总需求超过容量时会出现缺口”的关系。实际延迟还受任务性质、调度机制、网络和应用代码影响，不能由超卖比例直接算出。某实例短期 CPU 利用率不高，也可能因可运行任务没有及时取得执行机会而变慢。平台若提供 CPU 等待或限流指标，应先阅读指标定义；不同环境可能使用不同名称和统计口径。

优化时可以先做受控比较：保持相近请求类型与吞吐，在相同软件版本下对照不同位置或不同隔离规格，记录业务指标和资源指标。若只有更换位置后恢复，应继续结合共享资源和平台事件判断，避免把相关性当成最终原因。若提高实例规格有效，也要确认改善来自可用算力、内存余量，还是规格附带的网络能力变化。

对订单 API，一个可解释的选择是为在线副本设置必要余量，将批处理放到单独资源池或受限时段，并验证宿主机失效后的剩余容量。这个选择会减少部分表面利用率，却对应明确的延迟与恢复要求。非关键任务则可接受较高共享程度。平台方案需要把成本、性能目标和失败时行为放在同张决策表上，不能只追求某个利用率数字。

6 常见坑：把 vCPU 当独占核

vCPU 是实例看到的虚拟处理器单位，不能仅凭数量推断它始终独占相同数量的物理 CPU 核。底层可能采用共享执行、硬件线程映射或专用资源配置，具体要看平台与实例类型的定义。4 vCPU 表示实例具有相应的虚拟执行资源规格，但不自动等于 4 个专属物理核，更不自动保证不同机器上的应用吞吐完全一致。

由此产生的常见误判是线性估算：2 vCPU 能处理某个请求量，4 vCPU 就必定翻倍。应用可能受到数据库连接数、锁等待、网络或串行代码限制；即使 CPU 是主要瓶颈，底层处理器与共享条件也会影响结果。正确做法是先找到限制资源，再以代表性负载验证扩容收益。规格是实验输入，业务表现才是方案验收依据。

另一个坑是把“CPU 使用率 100%”直接翻译成平台故障。这可能说明应用持续需要更多执行资源，也可能涉及配额、突发额度耗尽或指标分母不同。反过来，低使用率也不能证明资源充足：应用可能阻塞在数据库或网络上。排查前应确认指标统计的是实例可见资源、宿主机资源，还是某类配额，并把时间窗口与应用请求记录对齐。

还要避免只盯 CPU。订单 API 内存不足时，垃圾回收或分配失败可能拖慢请求；网络能力受限时，加 vCPU 未必改善；连接池过小又可能让空闲 CPU 等待外部响应。实例规格通常是一组资源配置，调整时应写清要解决哪种瓶颈，并保留变更前后的证据。否则扩容成功只是“换了更大的盒子”，未必知道为什么有效。

选择专用资源也需要准确表达。专用宿主机、专用 CPU 或性能保底可能分别描述不同承诺，不能混用。询问时应聚焦具体问题：哪些资源不与其他租户共享，是否有保留容量，维护与故障如何处理，哪些指标可用于验证。安全隔离、执行份额与故障独立性需要分别确认。后续即使更换平台，也可以沿这组问题理解规格。

7 案例：宿主机故障拖垮整组

某订单服务部署了 3 个无状态 API 副本，入口配置了健康检查，数据库独立运行。平时流量不大，团队看到副本数量为 3，便认为可以承受单个计算节点失效。某次宿主机掉电，3 个副本同时不可达，入口很快报告没有健康后端。数据库仍然正常，用户却无法创建订单。这次故障暴露的是副本位置与恢复容量的问题。

事件发生后，先记录用户影响和时间线，再收集实例状态变化、健康检查结果与平台故障通知。应用日志在接近时刻同时中断，可以支持“共同外部事件”的怀疑，但不能单独证明宿主机故障。进一步从平台支持信息确认 3 个副本属于相同宿主机故障域，才把共同失效与具体位置关联起来。证据不完整时，应保留假设，避免先宣布根因再寻找佐证。

平台随后尝试在其他位置恢复实例，但剩余资源不足，部分实例长时间等待。即使调度服务与重建流程正常，也无法凭空提供容量。团队原先只按正常流量配置总资源，没有为宿主机失效后的接管预留空间。因此此次中断包含 2 个相连因素：副本共享了故障域，恢复又依赖当时无法保证的空闲资源。只修复其中某个因素仍可能再次长时间中断。

短期处理是使用可用资源恢复足够副本，核对入口健康状态，并确认订单重试没有重复提交。恢复期间要限制流量或排队时，应通过已有业务机制执行，不能在资源紧张时无限重试。中期修复包括设置适当的强制分散规则，确认规则实际生效，建立接管容量策略，并把实例待调度与副本不足纳入告警。数据库正常不能替代对计算层恢复的验证。

最后进行受控演练：在允许的维护窗口中模拟失去某个宿主机故障域，记录剩余健康副本、业务延迟、错误率和恢复时间。若租户无法直接操作宿主机，可用平台支持的故障演练能力或经确认的等效方式验证部分路径，并明确覆盖范围。停止单个应用进程只能验证进程恢复，不能冒充完整的宿主机失效测试。演练结论必须与实际触发的故障相匹配。

8 把计算隔离写进平台方案

计算隔离要求应从业务后果开始表达。对于订单提交接口，可先说明需要在某个宿主机失效后继续接单，再推导副本分散、剩余容量和入口健康检查要求。对于批量导出任务，可以说明允许延迟完成，但不能持续挤占在线服务的关键资源。这样写，位置规则和资源限制都有清楚用途，读者也能判断调整某个配置会改变什么承诺。

接着给工作负载划分可执行的资源边界。记录实例规格、正常需求与预留余量，说明采用共享还是专用配置，以及选择依据。若允许突发能力，要写明长期可依赖的基线和额度耗尽后的预期行为。若关键规格细节由平台提供，应引用对应服务定义并记录适用范围。不要在内部文档里自行补出“始终独占物理核”等未经确认的承诺。

位置要求需同时描述目标和无法满足时的动作。例如同组在线副本必须分散到不同宿主机；容量不足时保持待调度、触发告警并升级处理。若采用偏好分散，则要标记降级状态，让值班人员知道当前风险。多可用区部署还要与入口路由、网络连通和数据库可用性共同设计，不能在计算图上画出多个区域后就宣布服务具备跨区恢复能力。

观测要求应连接业务表现与平台事件。保留实例创建、迁移、重建和放置规则状态的变化记录，同时观察请求量、错误率、延迟、CPU、内存及平台可提供的争用指标。使用统一时间基准，标注发布与扩容事件，便于区分代码变化、流量变化和底层变化。日志中不要暴露身份凭据，排查权限应通过授权流程提供。

验收也要围绕承诺设计。容量测试验证正常负载与接管负载；故障演练验证对应故障域的影响；维护测试验证连接恢复和重试行为。每项验收注明条件、通过标准与证据来源，未覆盖的场景写明后续安排。平台负责资源与机制，应用团队负责正确使用和业务恢复验证，双方共同确认依赖接口，才能把“已经配置”推进到“已经证明”。

9 从云平台内核：计算走向云平台内核：存储（C56）

计算课解决了代码在哪里执行、资源怎样共享、位置失效后怎样恢复，但实例重建后会遇到更关键的问题：数据在哪里。订单 API 可以从镜像重新启动，尚未持久化的内存状态却不能因此自动找回。若订单只写进实例临时目录，计算恢复也可能带来空白目录或缺失记录。实例恢复与数据恢复必须分开分析，再组合成业务恢复路径。

本课可以先建立最低限度的状态分类：可重建的程序与缓存、需要持久保存的业务记录，以及恢复时需要读取的配置。订单记录通常交给具有相应持久性承诺的数据系统，实例本地状态则按其实际生命周期处理。数据如何复制、确认写入、备份和恢复，将在存储课继续讨论。这里不把任何存储类型直接等同于永不丢失。

存储也会反过来约束计算位置。新宿主机即使有足够 CPU 和内存，仍需能访问所需数据，且满足挂载、权限与网络条件。某些卷或设备具有位置和连接限制，迁移与重建前必须确认。下一课分析存储时，可以沿用本课的方法：先看承诺和边界，再看故障路径，最后寻找能够验证这些承诺的证据。

在进入 C56 前，试着口头解释这个场景：3 个 API 副本已经分散，但宿主机故障后，新实例无法读到启动所需的数据。你的说明应同时包含计算位置、数据依赖、身份授权和健康检查。若能说明“实例运行”和“服务恢复”之间还缺哪些条件，就已经具备继续学习存储内核所需的基本视角。

放进方案里

为订单 API 编写计算方案时，先记录承载对象、业务延迟目标与允许的中断范围，再选择实例规格。将 vCPU、内存及网络能力作为待验证的资源条件，注明共享方式与已确认的保底承诺。容量表同时列出正常负载和宿主机失效后的接管负载，预留用于维护、突发和重建的空间，并写清扩容触发条件与负责人。

位置策略规定在线副本分散到不同宿主机故障域，注明这是强制规则还是偏好规则，并保存平台可提供的执行证据。强制规则无法满足时，实例保持待调度并告警；偏好规则降级时，服务状态应显示风险。若需要跨可用区承载，再核对入口、网络和数据依赖，按实际覆盖范围描述可用性，避免从宿主机分散推导更大的故障承诺。

将计划维护与意外失效分别写成恢复流程。维护前确认迁移适用条件和目标容量；意外失效后确认检测、入口剔除、实例重建与业务就绪的责任边界。应用配置合理超时、有限重试和订单幂等处理。临时本地数据只承载可丢失或可重建内容，业务持久状态的位置与恢复要求交由存储方案明确衔接。

验收采用代表性流量，记录吞吐、错误率、延迟分位数、资源指标和放置状态。通过受控演练检查失去目标故障域后的剩余容量与恢复时间，保留触发条件、时间线和结果。日常告警覆盖副本不足、待调度、资源压力与业务异常；出现性能波动时，先对齐发布、流量和平台事件，再以受控比较定位原因。方案中的每项隔离承诺都应对应可查看的配置、可追溯的证据或明确的服务定义。

10 小结：下一步云平台内核：存储（C56）

计算内核把资源请求变成实例位置，并在共享、维护和失效之间持续作出取舍。vCPU 数量需要结合资源承诺理解，副本数量需要结合故障域理解，恢复流程需要结合可用容量与应用依赖理解。

自测时可以回答：为什么集群资源总量充足仍无法放置实例？为什么热迁移不能替代意外故障恢复？为什么增加副本后还要检查位置？下一课将沿着实例重建后的数据去向，学习云平台内核：存储（C56）。