大促前临时加几台主机，不一定能解决问题：商品页可能正常，结账时却因数据库连接耗尽而失败。跨境电商大促期间的主机资源规划，应先找出流量会经过哪些服务，再按峰值准备容量，并验证扩容和回退是否有效。
先把促销流量换算成容量目标
不要只用日均访问量估算。广告投放、邮件发送和时区差异，可能让访问集中在短时间内；浏览商品、搜索、加入购物车和提交订单，对资源的消耗也不同。先整理近几次促销的访问曲线、订单数、接口响应时间和故障记录；缺少历史数据时，可按活动计划、投放节奏和当前转化漏斗建立保守估算，并标明假设。
- 把流量拆成商品浏览、搜索、购物车、结账等关键路径，区分页面请求和写入请求。
- 估算预计峰值请求量，并在预估值上设置测试余量。压测可从预计峰值的约1.2至1.5倍开始，具体比例应依据业务不确定性、预算和测试环境调整，不代表生产环境一定能承受该流量。
- 记录每条路径的响应时间、错误率、CPU、内存、磁盘 I/O 和数据库连接数，确定先触及的瓶颈。
按瓶颈安排主机与依赖资源
主机数量不是唯一容量指标。CPU持续偏高可能与应用计算或流量过大有关；内存不足会引发缓存失效或进程退出；磁盘 I/O 紧张则可能拖慢日志和数据库操作。先在监控中确认瓶颈，再扩对应层，避免只扩应用主机、却把压力转移到数据库。
| 资源层 | 规划重点 | 适用做法与限制 |
|---|---|---|
| 应用主机 | 实例规格、可用实例数、启动耗时 | 弹性伸缩适合流量有明显波峰的无状态服务；需预留启动和健康检查时间。AWS EC2 Auto Scaling、阿里云 ECS 弹性伸缩都是可评估的产品，选型要看现有架构与部署区域。 |
| 静态内容 | 图片、脚本、样式文件的回源压力 | CDN可将可缓存内容从边缘节点交付，降低源站请求；动态结账接口不能因缓存配置不当而返回过期数据。 |
| 入口与数据库 | 连接数、查询延迟、写入能力 | 负载均衡可分配应用请求，但不会自动提升数据库写入能力。先检查慢查询、索引和连接池，再决定是否增加只读副本或调整数据库规格。 |
商品浏览通常更容易通过缓存分担，而库存扣减、付款状态和订单创建涉及一致性，不能简单复制缓存来代替数据库校验。跨境部署还要检查应用主机与数据库之间的网络延迟，以及故障时请求会落到哪个区域。
大促前按步骤演练
- 冻结变更窗口：提前约定高风险配置和代码变更的截止时间，保留紧急修复通道。
- 准备扩容规则：根据压测结果设置扩容触发条件和实例上限，并确认账号配额、镜像、启动脚本与健康检查可用。
- 分层压测：先测商品浏览，再测搜索、购物车和下单链路；逐步增加并发，观察响应时间、错误率和数据库连接，不要只看主机 CPU。
- 验证回退：演练关闭新功能、切回稳定版本、限制非核心任务等措施，并确认订单记录和库存处理符合业务规则。
- 活动期间值守：集中查看主机、负载均衡、CDN和数据库告警；每次扩容或限流后记录时间与影响，便于判断措施是否有效。
成本和安全边界也要提前确定
常驻高规格主机简单直接，但活动结束后可能长期闲置；按需扩容更灵活，却要考虑启动时间、配额和费用上限。可以让基础容量覆盖常态需求，把经过演练的弹性容量用于峰值，并为数据库等难以快速扩展的依赖预留余量。非关键报表、批处理任务可在高峰时段延后；支付、库存和订单服务则应优先保障。
跨境电商大促期间的主机资源规划，最终应落实为一份可执行清单：预估峰值与假设、各层扩容上限、关键告警阈值、值守负责人和回退步骤。活动结束后对照实际流量复盘，更新下一次促销的容量依据。
常见问题
主机应该提前多久扩容？
取决于实例启动、数据预热和验证所需时间。先在预发布环境测出完整耗时，再按活动安排提前准备；不要把自动扩容当成唯一保障。
能否只靠 CDN 应对大促？
不能。CDN适合缓存静态内容，动态搜索、购物车和结账仍会访问应用及数据库，需要单独压测。
没有往年数据，如何确定峰值？
结合投放计划、当前访问转化数据和业务团队提供的活动预期设定多个情景，分别压测，并明确每个估算的假设；活动中再用真实监控校正。