1 为什么形态会决定扩容方式
订单 API 在平日每秒接收 800 个请求，大促预计上升到每秒 2400 个。沿着 H12 的选型路径，我们已经会从业务目标、负载特征、瓶颈与验证结果出发，估算需要多少计算、内存与存储资源。但资源总量相近，并不代表扩容动作相同。增加 4 台塔式服务器，可能需要寻找放置空间和独立电路；增加 4 台机架服务器，需要核对机柜、电源插座和交换机端口；增加 4 个刀片节点，需要先确认机箱的供电、散热和网络模块是否还有余量；增加 4 台云主机，则要检查配额、可用容量、网络限制与实例启动时间。
服务器形态描述设备如何被封装、放置、供电、散热和连接。它不是外观分类题，而是扩容时必须经过的约束集合。处理器和内存决定单机能承担多少工作，形态及其基础设施决定这些单机能否被顺利部署，并在故障时继续工作。报价单中的设备数量只是起点，真正交付的是能接入生产流量、可监控、可维护的服务容量。
先把 3 个容量分开。计算容量是经过压测、满足延迟目标时能够处理的请求量；部署容量是现场还能容纳多少设备；故障后容量是失去某个节点、电源路径或机柜后仍可提供的服务量。某台服务器压测表现优秀，却需要现场没有的高功率电源接口，它增加不了部署容量。若全部新增节点都接在同条供电路径上，平时吞吐提高，故障后的容量却可能没有达到预期。
对订单 API，应先写清目标，例如高峰每秒 2400 个请求、规定负载下 P99 延迟不超过 200 毫秒，并明确需要承受哪类故障。若每台应用节点在目标延迟下能稳定处理每秒 600 个请求，4 台只是正常情况下的算术下限；要求损失 1 台仍支撑高峰时，至少要按 5 台重新验证。这里暂时忽略数据库和外部依赖，只是为了说明：业务容量、部署位置和故障边界必须同时进入方案，不能拿处理器核数代替整套计算。
扩容也有时间维度。设备到货后还要经历上架、布线、装系统、接入监控、发布应用和预热。云主机省去了现场上架，但镜像拉取、依赖连接、服务注册和缓存预热仍需要时间。形态选择会影响扩容提前量，因此容量计划不仅要回答“增加多少”，还要回答“何时能用、由谁操作、失败时如何退回”。
2 塔式、机架、刀片：空间与线缆
塔式服务器的机箱通常直立放置，外形接近日常台式机。它适合设备数量少、没有标准机柜的办公室或边缘站点，扩展卡、磁盘和维护空间也比较直观。但塔式并不自动意味着低噪声或低功耗。多台设备散放会带来线缆交叉、进风受阻、资产难定位等问题，普通办公插排和房间空调也不能直接当作经过设计的机房设施。选塔式时，仍要落实电路容量、接地、通风、防尘和物理访问控制。
机架服务器采用标准安装宽度，设备高度常用 U 表示，1 U 为 44.45 毫米。常见机柜标注 42 U，但不能直接推导出能安装 42 台 1 U 服务器。交换机、配线、供电设备和维护布局都会占用空间，功率或散热上限也可能更早到达。机柜深度、前后门间距、导轨兼容性和承重同样要检查。某台机器虽然高度合适，仍可能因为过深、导轨不匹配或后方线缆弯曲空间不足而无法安装。
机架有利于集中布线和维护，但集中并不等于随意堆满。每台服务器至少需要电源线与网络线，管理网、存储网和多链路设计还会增加连接数。网线不仅要插得进去，也要有可用的交换机端口、匹配的速率和足够的上联带宽。双网口若接到同台交换机，可以覆盖部分网卡或线缆故障，却无法覆盖该交换机整体失效。应按照方案承诺的故障范围安排连接。
刀片服务器把多个计算节点装入共享机箱，节点通过背板或中板连接供电、网络和管理组件。它可以减少节点外部的线缆数量，在合适场景中提高部署密度。但共享机箱成为必须盘点的容量层：空槽位不一定对应足够的电力、冷却或网络带宽。新增节点可能触发电源模块、风扇模块或交换模块扩容，维护和迁移也依赖该机箱的兼容规则。
共享组件还会改变故障影响范围。单个刀片节点故障与整个机箱供电或背板故障不是同件事。订单 API 的多个副本若全部位于同个机箱，即使操作系统看见多台独立服务器，也可能同时失去服务。因此，分散部署要落到机箱、机柜和供电路径等实际边界，不能只统计实例数量。塔式、机架与刀片没有通用的优胜者，判断依据是规模、现场条件、维护方式和需要覆盖的故障。
盘点机柜时，可以把它当成多维库存：U 位、电力、冷却、重量、插座、网络端口分别记录，新增设备必须同时满足全部条件。下面的机柜立面是布局示意，不代表某种通用的配电位置；供电单元也可能安装在机柜后侧而不占用前方 U 位。实际施工应依据现场图纸和设备安装要求。
3 云主机形态：vCPU 与「看起来一样」的差异
云主机把物理设备的放置和维护交给云服务方，用户选择实例规格、镜像、磁盘和网络。控制台里的“8 vCPU、32 GiB 内存”是一组资源描述，不是完整的性能说明。vCPU 是云平台向虚拟机提供的虚拟处理器单位；它与物理核心、硬件线程的对应方式取决于平台和实例类型。不能把不同平台的 8 vCPU 直接视为相同的 8 个物理核心，也不能仅凭相同数量推断相同吞吐。
看起来一样的实例，可能运行在不同代际的处理器上，采用不同的资源共享或独占方式，并具有不同的持续性能规则。有的实例允许在积分充足时短时提高处理能力，积分消耗后可持续能力发生变化；有的提供较稳定的持续配额。短时间压测若只覆盖突发阶段，会把暂时可用的能力误写成长期容量。应明确规格承诺，并让测试覆盖预期的高峰持续时间和资源规则。
网络与存储也是云主机形态的重要部分。规格可能分别限制总带宽、每秒数据包数、连接相关指标、云盘吞吐和 IOPS。订单 API 的小请求可能先触及每秒数据包处理能力，批量导出可能先耗尽带宽，日志密集写入则可能受云盘限制。挂上更快的磁盘也未必有效，因为实例侧的总存储上限仍可能限制所有磁盘的合计表现。要区分磁盘本身的指标和实例能够向磁盘发出的总量。
云主机还要区分本地临时盘与持久化云盘。临时盘的数据生命周期和故障风险应以服务说明为准，不能因为它在操作系统里表现为磁盘，就拿来保存唯一的订单记录。不同实例类型切换时，本地盘、网卡数量、架构和启动条件也可能变化。规格变更不只是修改核数，迁移之前要确认镜像兼容、数据位置和连接方式，并安排回退。
云主机扩容免去了用户侧的机柜规划，但约束没有消失，只是变成配额、区域资源供给、实例类型可用性和故障域分布。对订单 API，可以在同个可用区内增加副本，也可以按可用性要求跨可用区部署；后者需要额外核算延迟、费用以及失去部分副本后的容量。不能把创建接口返回成功直接等同于服务容量已增加，还要等应用健康检查、预热和流量接入完成。
比较云与物理设备时，保持同套业务口径：相同应用版本、请求组成、数据规模、延迟目标和测试时长，记录可持续吞吐与总成本。物理机的可用核数和云主机的 vCPU 数量都只是输入条件，业务结果才是验收对象。若业务需要稳定性能，应把持续压测与峰值阶段的观测纳入采购或规格变更前的验证。
4 电源与冗余：单路掉电意味着什么
服务器电源模块通常称为 PSU，负责把输入电力转换为内部组件所需的电力。装有 2 个 PSU 不等于具备完整的供电冗余。必须同时检查：任意 1 个模块能否承担规定负载、设备是否按冗余模式工作、2 根电源线是否接入足够独立的路径，以及路径上游是否仍存在共同故障点。若 2 根线都接入同个插排，插排失电时，2 个模块会一起失去输入。
先区分电源额定功率和实际耗电。每个 PSU 标注 1200 W，表示其额定输出能力及相应条件，不表示服务器持续消耗 2400 W。实际输入功率随配置、负载、电源转换效率和风扇工作状态变化。预算应使用经过确认的最大运行需求或保守设计值，并通过带外管理或配电计量验证。不能把空闲时测得的功率当作大促预算，也不能只靠 PSU 铭牌相加估算日常耗电。
以每台服务器高负载输入功率 500 W 为例，2 个 PSU 在正常情况下可能分担负载；具体分配由设备策略决定。PSU A 失效后，B 需要接过相应负载，设备可能继续运行，也可能因剩余能力不足而降频或关机。单台能够切换仍不够：若同柜 10 台服务器同时失去 A 路，B 路需要承受这些服务器转移过来的总负载。正常时两路各承担约 2.5 kW，并不意味着每路只需按 2.5 kW 设计。
供电链从上游电源、配电设备、机柜 PDU 延伸到 PSU 和主板。PDU 是向机柜设备分配电力的单元。某些环节可能具有冗余，某些环节可能共享，图纸上的 A、B 标签也需要与现场路径对应。UPS 可以在规定条件下提供短时供电支持，但不能替代无限时长的电力来源；它的承载能力、持续时间和维护状态也影响可用性。应让设施人员确认实际的供电拓扑和可用容量。
对订单 API，供电演练的验收不仅是“机器没关机”，还应观察是否出现性能下降、请求超时、监控告警和其他节点过载。断电或拔线涉及真实设备和业务风险，应由授权人员按维护流程在可控窗口执行，事先确认回退和恢复步骤。课堂动画只帮助理解负载转移，不构成现场操作指令。冗余的意义在于明确覆盖范围，并验证故障后的资源仍足够。
5 散热与密度：机房约束进方案
服务器消耗的电能在持续运行时大部分转化为热，机柜的电力密度也因此决定冷却压力。把 20 台设备装进机柜并不难，难的是让它们在业务高峰时持续获得合格的进风条件。散热能力不足时，风扇会提高转速，增加耗电与噪声；温度继续升高，设备可能限制处理器功耗或频率，最终保护性关机。于是“计算性能不足”的现象，有时起点是现场热环境。
机架服务器通常按指定方向组织气流，常见形式是前方吸入冷空气、后方排出热空气，但必须以具体设备要求为准。冷热通道的目的，是减少排出的热空气重新进入进风口。空 U 位是否需要挡板、线缆是否堵住排风、设备方向是否一致，都会影响效果。不能因为房间某个温度计显示正常，就认定所有服务器进风温度都合格；机柜顶部、底部和局部区域可能存在明显差异。
密度预算应保留故障与波动余量。假设设施团队确认某柜在约定供电与冷却条件下，可用于计算设备的持续预算为 8 kW，方案再预留 20% 运行余量，规划上限就是 6.4 kW。若每台按 500 W 预算，电力维度最多容纳 12 台，因为 13 台会达到 6.5 kW。这个结果只说明功率条件，不能自动证明 12 台都可安装；还要继续检查 U 位、网络、插座和局部冷却能力。
若该 8 kW 是正常状态下两路相加的能力，而失去 1 路后只剩 4 kW，就不能用前面的 12 台作为冗余条件下的结论。必须先统一预算边界：它是正常状态还是故障状态，是否包含交换机等设备，预留比例是否已经计算。多次扣减同份余量会浪费资源，漏算故障状态则会制造风险。可交互的预算工具必须公开这些假设，避免让精确的小数掩盖口径错误。
提高密度有时能节省机柜租用和布线成本，但也会扩大单柜故障影响。如果订单 API 的全部应用节点都挤在同柜，单柜维护或热故障可能影响所有副本。将节点分散到不同机柜会增加连接和管理成本，却可能满足可用性要求。需要把每柜上限与副本放置策略共同确定，而不是先填满机柜，再寻找故障隔离的补救措施。
6 观测与盘点：资产标签、串号、位置
形态选择在采购时发生，容量信息却必须在整个使用周期中维护。资产标签是组织内部的管理标识，串号是设备制造或服务体系中的识别信息，机柜位置则告诉值班人员去哪里找设备。它们各有用途，不能互相替代。更换主板或整机后，部分硬件标识可能变化；搬迁后位置会变化；应用名称更不能长期当作物理资产身份。应建立可追踪的关联记录。
对每台物理服务器，至少记录资产标识、串号、形态、机房与机柜、U 位范围、CPU 和内存配置、盘位及已装磁盘、网卡及实际连接、A/B 供电路径、管理接口和维护状态。不是所有字段都要由人工重复输入，能从可信管理系统采集的信息应自动同步；但交换机端口、电源路径和位置仍需要现场核对。记录的更新时间与责任人能帮助判断信息是否可靠。
云主机没有用户可见的机柜位置，但同样需要资产关系：实例标识、账号或项目、区域与可用区、规格、镜像、磁盘类型、网络配置、业务归属和标签。自动伸缩产生的实例可能很短命，不能依赖人工表格逐台维护。应通过模板和标签让新实例自动关联到订单 API，并在监控中保留实例生命周期，避免销毁后丢失故障证据或遗留磁盘费用。
观测要把应用结果与基础设施状态连起来。应用侧关注请求量、错误率和延迟；主机侧关注 CPU、内存、磁盘与网络；物理侧补充输入功率、进风温度、风扇、PSU 状态与硬件告警。CPU 利用率相似而吞吐不同，可能是频率下降、请求组成不同或外部等待不同，不能只凭单个指标下结论。把资产位置加入监控关联，才容易发现“同柜多台同时变慢”这样的线索。
一次可用的盘点应能回答具体问题：某柜 A 路维护会影响哪些订单 API 副本，哪台机器仍有可用盘位，哪组节点的网卡速率与预期不符。若表格只能列出机器总数，却无法追到业务、位置和连接，它还不足以支持扩容。资产信息也含管理入口与内部拓扑，应按岗位控制访问，避免把敏感连接信息公开到普通业务页面。
7 常见坑：只看标称核数、忽略网卡与盘位
第 1 个坑是按标称核数排名。相同核数的机器可能有不同的处理器代际、频率、内存配置和功耗策略。对于订单 API，某些请求依赖较强的单线程执行能力，某些工作更容易并行；核数翻倍不保证请求量翻倍。应在相同软件和负载口径下测出满足延迟目标的吞吐，并记录是否进入降频或突发额度耗尽状态。把宣传参数直接变成容量承诺，风险很高。
第 2 个坑是把“有网口”当作“网络足够”。网口数量、协商速率、交换机端口配置和上联共享都会影响实际能力。应用可能在平均带宽不高时，就因小包处理、丢包、重传或连接压力出现延迟。双口绑定也不保证单条连接获得两倍速率，其结果取决于协议和流量分配方式。验收应覆盖实际请求大小、并发与依赖访问，并观察链路错误和交换机侧指标。
第 3 个坑是只看已有磁盘容量，忽略未来盘位与连接能力。机箱有空盘位，不代表背板、接口、控制器、电源和散热全部支持直接新增。某些位置还可能与扩展卡或其他配置互斥。方案需要说明可用扩展空间以及数据迁移方法，不能把尚未确认的盘位写成确定容量。热插拔能力也需要设备、接口和操作系统等条件共同支持，不能只凭外观判断。
第 4 个坑是把实验室结果复制到所有形态。实验环境只有 1 台机器，生产环境却在同柜放置多台并共享网络上联；单机压测没有暴露机柜功率与散热问题。云上相同的实例规格也可能因磁盘配置、持续性能规则或宿主环境而表现不同。验证要有单机基线，也要有实际部署规模下的联合负载，并检查故障后的容量，而不只是正常状态的峰值。
第 5 个坑是忽略维护路径。服务器后面没有空间拔线，故障盘缺少明确位置，管理接口无法访问，都可能让原本很短的维修变成长时间中断。采购时应同时评估安装、定位、拆装和恢复所需条件。形态选择清单的价值，正是提前把这些条件变成可确认的交付项。
8 案例：大促临时加机却插不上电
某团队准备为订单 API 新增 8 台 1 U 服务器。压测表明，应用层按计划扩容后有机会达到目标吞吐，机柜表格也显示还剩 10 U，于是团队把“空间足够”写成了“可以上架”。设备到货时，现场发现已有电源插座不足，剩余接口与新电源线也不匹配。更关键的是，即使增加连接位置，该柜的约定功率预算也无法承受全部新增负载。
事后核对发现，机柜可用于计算设备的预算为 6 kW，已有设备按峰值需求占用 4.2 kW。新增服务器每台按高负载输入功率 450 W 规划，8 台需要 3.6 kW，总需求达到 7.8 kW，尚未讨论进一步余量就已经超过预算。此前值班人员看到的 2.6 kW 是低负载瞬时读数，采购表却把它当成长期可用容量的依据。数字没有算错，错在比较了不同负载条件。
团队没有使用临时插排绕过限制，而是暂停接入，由设施和网络人员确认其他机柜的功率、冷却、插座与端口。最终把新增节点分散到 2 个满足条件的机柜，并检查这些位置的供电路径及网络上联。由于搬迁、布线与验证需要时间，团队还减少了部分非必要的促销计算任务，保留订单主链路容量。实际措施应结合依赖系统能力，不能只靠应用层加机兜底。
恢复上线前，团队重新进行联合压测，检查请求延迟、错误率、每柜功率、进风温度和网络利用率，并验证损失约定故障范围后仍有足够容量。整改后的扩容工单增加了部署前置条件：每个位置明确 U 位、设计功率、插座类型、A/B 路径、交换机端口和责任人。设备到货不再是扩容完成节点，接流量并通过验收才是。
这个案例的教训不是“多留几个插座”这么简单。空插座可能没有上游容量，空 U 位可能没有冷却能力，空网口可能共享已经拥塞的上联。扩容应逐项证明所有约束均满足，并记录证据来源。越接近业务高峰，临时寻找基础设施余量的代价越高，形态约束越应提前进入容量计划。
9 排查案例：同规格机器性能差一截
另一组订单 API 节点都标注为 16 个逻辑处理器、64 GiB 内存，应用版本相同。其中部分节点在相似请求量下 P99 延迟明显升高，满足延迟目标的吞吐比其他节点低约 30%。团队最初怀疑处理器型号不同，但没有立即更换机器，而是先确认比较条件：请求组成、数据分布、应用配置、运行时版本、预热时长和外部依赖是否一致。
他们把异常与正常节点分组，在可控流量下比较 CPU 利用率、有效运行频率、磁盘等待、网络错误和请求耗时。CPU 利用率看起来接近，但异常组的频率更低，同时风扇转速和进风温度偏高。资产记录显示，异常组集中在同个机柜的上部。进一步由现场人员检查发现，空位缺少必要挡板，后方热空气存在回流，造成局部进风条件恶化。
设施人员按现场设计调整气流组织后，团队在相同负载下复测。进风温度回落，频率和吞吐随之恢复到合理范围，订单延迟也改善。这里的证据链是位置聚集、热指标异常、频率受限、处理后结果恢复，而不是仅凭“机柜比较热”就宣布原因。持续观察还用于排除同时发生的应用配置变化，避免把偶然相关误当因果。
同规格表现不同也可能来自其他原因，例如云实例突发额度不足、网卡协商速率偏低、磁盘型号或实例侧限额不同、内存配置不一致。不能把本案例变成“性能差就查散热”的固定答案。更有效的顺序是统一负载口径，确认规格与配置，比较应用和系统指标，再沿着网络、存储、供电与温度证据缩小范围；每次改变条件后保留前后对照。
最后，团队把进风温度、PSU 状态和机柜位置接入告警关联，同时修订“同规格”的定义：除逻辑处理器和内存外，还记录处理器信息、功率策略、网络链路、存储条件和部署环境。验收继续使用业务吞吐与延迟目标。规格帮助建立候选集合，观测和可重复测试才能说明机器是否真正提供了预期容量。
放进方案里
在订单 API 容量方案中，先写业务目标、峰值持续时间、延迟要求和允许损失的故障范围。沿用 H12 的选型路径，用相同请求组成和数据规模测出单节点的可持续吞吐，再计算正常及故障后的节点需求。把应用节点、数据库和外部依赖分别验证，避免将应用层扩容视为整条订单链路的容量保证。所有结果应保留测试条件、日期和适用限制。
随后写明形态与放置方式。选择物理设备时，列出每台所占 U 位、安装深度、设计输入功率、盘位、网卡和维护条件，将节点映射到具体机柜与供电路径。由设施人员确认功率、插座和冷却预算，由网络人员确认端口、速率与上联余量。刀片方案还要补充机箱级共享资源和故障影响范围。选择云主机时，记录实例类型、持续性能规则、磁盘与网络上限、区域配额及可用区分布。
接着给出容量边界与行动条件：正常高峰可承载多少请求，损失规定节点或供电路径后还能承载多少，达到什么利用率或延迟趋势时启动扩容。预留量应说明覆盖预测偏差、性能波动还是故障，避免重复计算。扩容提前量包括采购或创建、安装配置、应用预热和验收，负责人应能依据条件启动工单，而不是等待高峰出现再找位置。
最后附上可执行的验收与回退安排。联合负载下检查吞吐、错误率、延迟、功率、温度和链路指标；按授权维护流程验证约定故障场景，并确认恢复后状态。更新资产标签、串号、位置与业务关联，保留拓扑和测量记录。若某项现场预算尚未确认，就将对应容量列为待交付条件并安排责任人，不能提前计入可用服务能力。
10 小结：形态选择清单
形态决定设备如何进入服务，也决定资源如何共享、故障如何扩散和容量如何交付。塔式适合的现场条件、机架的多维库存、刀片的共享机箱约束、云实例的资源规则，都要回到订单 API 的业务目标判断。
- 业务：目标吞吐、延迟、峰值时长和故障范围是否明确？
- 单机：处理器、内存、网络和存储是否经过相同口径验证？
- 现场：空间、承重、插座、功率、冷却与网络是否同时满足？
- 冗余：剩余 PSU、供电路径和服务副本能否承受约定故障？
- 运维：资产、位置、监控、维护入口和回退责任是否齐全？
- 交付：新增节点是否已经预热、接流量并通过业务验收？
自测时试着解释：为什么剩余 8 U 不能证明还能部署 8 台服务器？为什么 2 个 PSU 不能单独证明双路冗余？为什么相同的 vCPU 和内存不保证相同吞吐？能够分别给出空间之外的约束、供电路径与故障负载、以及持续性能与网络存储条件，就抓住了本课的核心。
下一课转向 H16 网络设备入门：把本章验收过的结论带进后续主题，写成可检查的方案约束。