公司官网突然上了热搜，访问量翻了十倍，原本跑得好好的服务开始卡顿，页面加载慢得像老牛拉车。运维小李盯着监控面板直冒冷汗，CPU 使用率全线飘红，数据库连接池被打满。这时候，光靠重启服务已经没用了，唯一的出路就是——扩容。
什么时候该考虑集群扩容？
不是一出问题就马上加机器。常见的扩容信号包括：持续高负载、响应延迟上升、自动伸缩组频繁触发、数据库主从延迟变大。比如你运营一个电商站点，大促前一周流量逐步上涨，系统资源使用曲线稳步攀升，这就是典型的扩容窗口期。
垂直扩容 vs 水平扩容
垂直扩容就是给单台服务器“升配”：换更强的 CPU、加内存、上 SSD。简单直接，适合短期内快速应对压力。但物理机总有上限，而且停机维护会影响业务，风险不小。
水平扩容是加机器，把压力分摊到多个节点上。比如原来 3 台应用服务器，现在变成 6 台，配合负载均衡器一起工作。这种方式扩展性强，容错能力好，是现代集群的主流选择。
以 Nginx + Tomcat 为例的扩容实践
假设你当前用 Nginx 做反向代理，后端接了 4 个 Tomcat 实例。现在要扩容到 7 个，操作步骤其实并不复杂：
- 在云平台创建新的 ECS 实例，部署相同版本的 Tomcat 和应用包
- 确认新实例的防火墙、安全组允许 8080 端口通信
- 将新实例 IP 添加到 Nginx 的 upstream 配置中
- 重载 Nginx 配置（nginx -s reload），不中断服务
关键点在于配置一致性。如果每个节点的应用版本或依赖库不一样，很容易出现“这个能用那个不行”的诡异问题。建议把部署流程写成脚本，一键执行。
upstream backend {
server 192.168.1.10:8080;
server 192.168.1.11:8080;
server 192.168.1.12:8080;
server 192.168.1.13:8080;
server 192.168.1.14:8080; # 新增节点
server 192.168.1.15:8080; # 新增节点
server 192.168.1.16:8080; # 新增节点
}别忘了数据库这道坎
应用层扩容容易，数据库往往是瓶颈。如果你的 MySQL 主库扛不住写请求，光加 Web 节点也没用。这时候可以考虑读写分离，把查询请求导到从库。或者引入中间件如 MyCat、ShardingSphere，做分库分表。
另一种思路是改用支持分布式架构的数据库，比如 TiDB 或 OceanBase。虽然迁移成本高一点，但长远来看更省心。
自动化才是长久之计
手动一台台加机器，迟早会出错。成熟的扩容方案应该结合 CI/CD 流程和基础设施即代码（IaC）。比如用 Terraform 定义服务器模板，配合 Ansible 批量部署，再通过 Prometheus + Alertmanager 自动触发扩容脚本。
某内容平台就设定了规则：当平均响应时间超过 800ms 并持续 5 分钟，自动增加 2 个应用节点。等流量回落，空闲节点还会自动下线，节省成本。
小步快跑，避免一步到位
扩容不是越大越好。曾经有团队一口气从 5 台扩到 20 台，结果发现新节点缓存未预热，反而导致大量缓存穿透，数据库差点崩掉。建议每次扩容控制在原有规模的 30%~50%，观察 1~2 小时再决定是否继续。
上线前做个简单的压测，用 ab 或 JMeter 模拟真实请求，确认新增节点能正常承接流量。别等到用户投诉了才去查配置。