比较云服务器纵向与水平扩容的应用改造、扩展上限、故障影响和完整成本。
纵向扩容是给现有节点增加 CPU、内存或更高规格资源；水平扩容是增加节点数量并分担请求。前者改造少、见效快，但受单机上限和变配影响；后者可以提高弹性与故障隔离，却要求应用能够并行、无状态化或正确管理共享状态。
默认判断：短期上涨、应用仍依赖本机状态且实例未到上限时，先小步纵向升配；持续增长、不能接受单机故障，并且会话、上传和任务已移出本机时，再做水平扩容。升配可能停机或重启，新增实例、负载均衡和共享存储都会收费。
如何快速判断
| 条件 | 纵向扩容 | 水平扩容 |
|---|---|---|
| 应用改造 | 通常较少 | 需要负载分发和状态设计 |
| 扩展上限 | 受最大规格限制 | 受架构与依赖限制 |
| 故障影响 | 单节点风险较集中 | 可通过多节点降低影响 |
| 适用阶段 | 早期、数据库单机、临时峰值 | 稳定增长与高可用生产系统 |
先排除“假容量问题”
CPU 高可能来自慢查询、死循环或锁竞争；内存高可能是泄漏；请求变慢也可能由云盘、连接池或第三方接口引起。直接扩容可能暂时掩盖问题。应先观察 CPU、内存、磁盘延迟、网络、队列和应用分段耗时。
水平扩容需要哪些前提
- 请求可以由任意健康节点处理，或者具备明确的会话策略。
- 上传文件、任务状态和锁不只存放在单个节点本地。
- 负载均衡健康检查能反映真实业务状态。
- 数据库、缓存和消息系统不会成为新的集中瓶颈。
- 发布过程支持连接排空、滚动升级和快速回滚。
常见组合方式
许多系统先纵向扩容获得时间，同时改造无状态层并逐步水平扩容；数据库则可能先优化索引和升配，再增加只读副本。纵向和水平不是必须二选一，而应分层使用。
测试与验收
- 建立单节点的吞吐、延迟和资源基线。
- 增加节点后验证吞吐是否接近预期增长。
- 主动终止一个节点，观察请求失败和恢复时间。
- 验证自动扩容的触发指标、冷启动速度和缩容安全。
- 计算负载均衡、跨区流量和闲置容量的完整成本。
边界条件
并非所有状态系统都能简单水平扩展；扩容速度也受实例库存、镜像启动、数据同步和应用预热影响。自动扩容只能响应已定义的指标，不能替代容量规划。
先证明加资源能解决瓶颈
记录 CPU、内存、磁盘延迟、网络、请求延迟、错误率和数据库连接。CPU 低但数据库锁等待高时，加 Web 服务器不会改善；内存泄漏导致的崩溃也不能靠扩容替代修复。至少覆盖一个真实高峰，区分持续不足和定时任务短峰。
| 条件 | 纵向 | 水平 |
|---|---|---|
| 应用状态 | 大量本地状态 | 状态已外置 |
| 可用性 | 可接受维护窗口 | 要容忍单节点退出 |
| 扩展上限 | 目标规格有余量 | 单机接近上限 |
| 团队能力 | 希望少改架构 | 能维护负载均衡与发布 |
水平扩容前搬走三类状态
登录会话放共享缓存或数据库，上传文件放对象存储，后台任务进入可重试队列。连接池要按“单节点连接数×最大节点数”核对下游上限。健康检查必须发现应用不可用，又不能因短暂外部依赖波动摘除全部节点。
验收与回退
纵向变配后核对实例类型、系统资源、应用启动和峰值。水平方案先加一台，小比例引流，验证版本、会话、上传、任务、日志和客户端 IP；再摘除一台旧节点，确认业务不中断。失败时摘除新节点并恢复旧容量。唯一文件或任务仍在本机时禁止自动缩容。
扩容前后必须使用同一口径
保存扩容前一周同一时段的请求量、P95/P99、错误率、CPU、内存、磁盘等待、网络和数据库指标。扩容后在相近流量下比较，不能因为当天请求变少就宣布有效。还要检查单请求成本和空闲资源；水平节点长期低利用率时，先优化最小容量而不是立即启用激进缩容。任何缩容都要等待连接排空，并保护正在执行的上传和任务。
有状态系统的特殊边界
数据库、消息队列和本地文件服务不能照搬 Web 层“加节点”。它们涉及主从角色、选主、复制延迟、仲裁和一致性。若官方产品没有明确扩容路径，应先使用快照或原生备份在隔离环境演练。单机纵向升配到极限后才发现没有迁移窗口，会比提前建立可恢复副本更危险。
发布方式也要随水平扩容改变
单机时代直接覆盖文件或在服务器内手工修改配置，增加节点后会形成版本漂移。应使用可追踪构建产物和逐批发布，确认新旧版本在过渡期兼容；数据库变更必须向前兼容，不能第一台升级后就让旧节点无法工作。监控要按实例拆分，避免平均值掩盖单台异常。
完成当前任务后继续检查
官方资料
需要核对实例变配与负载均衡能力时，可联系黑鲨云 @heishayun。
联系 Telegram 客服 