两种扩展方向
垂直扩展（scale up）提升单机规格：CPU、内存、磁盘更快更大，改造量小、短期见效快，但受单机规格上限约束，且往往需要停机或重启，也不解决单点问题。水平扩展（scale out）增加实例数量：具备弹性与容灾能力，但前提是把服务改造成无状态或处理好状态共享，同时要面对数据分布、会话共享与跨节点协调带来的复杂度。现实中常见的路径是先用垂直扩展争取时间，同时推进无状态化，再切换到水平扩展。
基本信息
| 垂直 | 改造量小；受单机上限约束；仍是单点；成本随规格上升 |
|---|---|
| 水平 | 需要无状态化改造；弹性与容灾好；受分片与协调成本约束 |
| 判断依据 | 业务增长曲线、停机窗口、状态依赖程度与团队运维能力 |
| 组合方式 | 先垂直争取时间，同时推进无状态化，再切换水平扩展 |
典型使用场景
- 数据库扩容：优先垂直提升规格，再考虑读写分离与分片
- 无状态 Web 服务：直接水平扩容最直接，配合负载均衡
- 有状态服务拆分：把会话与状态外置后才能安全水平扩展
- 突发峰值：用水平扩展临时加实例，峰后收回控制成本
- 单点风险消除：为只有单实例的关键服务补齐多实例部署
维度
| 维度 | 垂直 | 水平 |
|---|---|---|
| 改造量 | 小 | 需要无状态化改造 |
| 上限 | 单机规格上限 | 受分片与协调成本约束 |
| 容灾 | 仍为单点 | 天然多副本 |
| 成本曲线 | 随规格上升 | 规模效应更优 |
水平扩展前的检查项
水平扩展前的检查项
1. 会话是否外置（缓存或数据库），还是存放在本机内存
2. 本地文件与临时目录是否被依赖（上传、导出、缓存文件）
3. 定时任务是否会随着实例增加而重复触发
4. 本地缓存一致性：多实例下是否需要失效通知或版本号
5. 下游连接数与配额随实例数放大，是否已设上限
# 任一项未处理，水平扩展都会带来数据不一致或重复执行使用要点
- 长期依赖垂直扩容会撞上单机规格上限，且每次升级都需要停机窗口
- 水平扩展未解决会话共享，用户状态丢失，表现为随机被登出
- 本地文件、定时任务与本地缓存是水平扩展的常见隐性依赖
- 扩容前按实际瓶颈类型判断：CPU 型、内存型还是 IO 型，规格选择差别很大
- 两种方式可以叠加：先垂直提升数据库，同时水平扩展应用层
常见路径是先垂直争取时间，同时推进无状态化，再切换水平扩展；把无状态化排进迭代计划，而不是等到必须扩容时才开始。
垂直扩容会改变单机规格，压测结论与调优参数（连接池大小、线程数、堆大小）需要同步复核，直接沿用旧参数常导致新规格下表现不如预期。