开考前就绪：扩容与安全替换 Web 节点——NovaCommerce 第二篇

两个应用池提供了扩容空间。更难的是确认新节点可用、让旧节点排空，并保持服务版本兼容。

作者

Anichur Rahaman

1 个月前5 分钟阅读223 次浏览

第 2 部分，共 5 部分

从单服务器到考试日就绪

系列内容

前端切换 DNS 一小时后，旧服务器仍收到约 36% 的记录流量。团队已经将 TTL 降为 300 秒，并通过 hosts 文件测试新路径。迁移后依然有两个入口，因此保持旧入口可用比宣布 DNS 切换完成更重要。

NovaCommerce 是课程与考试平台的匿名名称。第二篇保留 2026 年 9–10 月的既有案例观察，不是 StoreConsole 基准，也不是本次重新运行的测试。第一篇区分了限流身份、Valkey 连接压力和后端 CPU；本篇跟进应用层。

把需要独立决策的层分开

当时的实现是前端一套负载均衡器与扩容池，后端另一套，DNS 名称原本就已分开。不同节点规格、健康检查和替换策略适合这种划分，但不能据此要求所有应用使用两个均衡器。

后端用标签发现替代固定 Droplet ID 列表，新节点可加入相应池并获得防火墙规则。标签是配置，不是应用就绪或用户授权证据。两台均衡器合计每月 $48 是历史预算，不是现行报价。

计算健康容量，而不是申请的机器

两个池均配置 2–10 节点。前端每节点 2 vCPU/4 GB，nginx 后运行两个 Next.js 容器；后端为 4 vCPU/8 GB，运行 nginx/PHP-FPM。这是该部署的选择。单个 JavaScript 事件循环不代表其他 CPU 空闲，原生操作和工作线程池也会消耗资源。

历史前端测试中，双节点约 356 requests/s，p95 0.05 s，报告错误为零，CPU 55–60%。这支持试用更便宜的共享 CPU，不能证明所有路由、宿主机资源争用或答案写入容量。每节点每月 $28/$56 也只是历史规划输入。

历史配置	前端	后端
池范围	2–10 节点	2–10 节点
每节点	2 vCPU / 4 GB；2 个 Next.js 容器	4 vCPU / 8 GB；PHP-FPM
CPU 目标	70%	70%，后改为 55%
健康检查边界	检查 Next.js 响应	仅 nginx；应用就绪另测
其他状态	协调公共缓存	池外单一固定工作节点

按开考时间预扩容

10 月 5 日 21:17–21:33 的 k6 测试重放 GET 请求：300–450 requests/s，随后约 750 持续六分钟。两层均从两节点扩至三节点。报告的服务器错误和超时为零，但约 4% 请求因共享测试 IP 得到 HTTP 429。合法请求被拒绝仍是业务失败；这不是完整业务流程通过，也没有验证答案的持久写入。

整体 p95 为 132–153 ms，API p95 为 320–705 ms。该案例记录了 5–8 分钟指标延迟，另一轮中后端 CPU 达到 99% 后约七分钟才出现额外节点。这些是特定配置观察，不是供应商统一时间保证。团队在考试前约 45 分钟预扩容并确认健康容量。Kubernetes 仅考虑过，未实施，也不能保证应用瞬间就绪。