网站从单机迁移到多节点，不能只问“CPU能否升级”。可扩展性同时取决于数据库、会话、存储、网络与回滚能力。下面给出可落地的评估方法。
先测当前瓶颈，而不是先买更大的主机
记录真实业务的峰值每秒请求数、p95 响应时间、CPU占用、内存剩余、磁盘 IOPS 与数据库慢查询。持续负载下，先区分 CPU 计算瓶颈、数据库锁等待和外部接口耗时；把单机配置翻倍却没有改善数据库串行查询，升级收益可能很小。
纵向扩容与横向扩容的取舍
纵向扩容是增加单台实例的 vCPU、内存或磁盘，迁移步骤少，但可能需要重启，也有规格上限。横向扩容是增加应用节点，前提是会话放在共享缓存或令牌中、用户上传文件不依赖本地磁盘、数据库与缓存能承受新增连接。负载均衡器需要健康检查与连接耗尽处理。
图示：服务器扩容与容量验证——整体结构或执行步骤（原创信息图，须结合实际条件核验）。
扩容测试应覆盖故障，而非只测吞吐
准备与生产一致的测试环境，以逐级增加的并发和真实读写比例施压；记录扩容触发时刻、实例就绪时间、5xx比率和恢复时间。再人为摘除一个应用节点，验证业务能否继续访问。所有测试应有可回退的配置与数据库备份。
采购表怎么填写
把“可在线扩盘”“可修改实例规格”“是否允许跨可用区部署”“公网流量与负载均衡是否额外计费”逐项列出；不能把云平台宣传的弹性能力视为所购具体套餐必有的功能。
用一个容量不足的场景区分扩容方向
假设网站的 CPU 仍有余量，但高峰期数据库慢查询显著增加，单纯从 2 核升级到 8 核不能保证响应时间改善。应先用应用追踪定位耗时占比，查看慢查询执行计划、锁等待和连接池；若数据库与应用同机且磁盘队列持续升高，再评估拆分数据库或优化索引。扩容前后须使用同一业务脚本、相同数据集与相同并发阶段，否则结果不可比较。
扩容设计要把文件上传与登录会话单独处理：只有把本地文件改为共享对象存储或共享卷，并确保多节点读取同一用户状态，增加应用节点才不会出现“在A节点上传、B节点找不到文件”。生产变更前预留数据库快照，明确何种错误率上升触发回滚。
| 观测现象 | 先验证的假设 | 优先措施 |
|---|---|---|
| CPU持续满载且队列增长 | 计算饱和或CPU配额限制 | 对照实例CPU基线，优化热点后升级 |
| CPU不高但接口响应慢 | 数据库、锁、外部API | 查慢查询、调用链与连接池 |
| 扩容后偶发掉登录 | 会话绑定单节点 | 共享会话并核对负载均衡策略 |
图示：服务器扩容与容量验证——采购核查与技术验收清单（原创信息图，须结合实际条件核验）。
上线或采购前的最终检查
- 采集一次真实峰值与p95延迟
- 分别执行容量扩展和单节点故障演练
- 核对扩容操作是否需要停机
- 核算负载均衡及跨区流量费用
注意：扩容并不自动带来零停机；有状态组件要单独设计一致性与迁移。
进一步阅读
与当前问题相关的延伸内容：企业高可用网络架构怎么搭：故障域、负载均衡与灾备。
官方资料与参考依据
- AWS建议通过持续负载测试评估工作负载扩容是否满足需求。：AWS建议通过持续负载测试评估工作负载扩容是否满足需求。
- AWS建议在接近真实生产规模的环境中验证可扩展性及性能要求。：AWS建议在接近真实生产规模的环境中验证可扩展性及性能要求。
