做大促最怕的场面：活动推文刚发出去十分钟，官网打不开，小程序图片转圈，后台涌进来一排「怎么进不去」的留言。三个端共用一套系统，好处是省事，风险是压力也叠在同一个地方——多端合一建站的部署和带宽怎么配，直接决定活动日是接住流量还是被流量冲垮。
先搞清楚压力从哪来
平时日访客几百的官网，一台两核四G的云服务器绰绰有余。压力出现在瞬时峰值：活动推送发出后，几千人同一分钟涌进来，图片请求一下翻几倍。多端合一建站三端共用资源时，判断配置够不够，看三个数：带宽大小决定页面打开快慢，CPU扛图片压缩这类计算，内存撑数据库查询。多数中小企业的瓶颈在带宽，页面里那些没压缩的大图，比服务器本身更容易压垮体验。峰值压力还有个特点：来得快去得也快，活动推文发出的前半小时最凶，之后流量自然回落。所以弹性升配按小时买就够，不必为一场活动包月升配，钱要花在刀刃上。
几个花小钱办大事的配置习惯
- 图片走对象存储加CDN：静态资源分流出去，服务器只管动态请求
- 开页面缓存：内容页生成静态缓存，同样的访问量压力降一多半
- 大促前压测：用工具模拟峰值并发，提前一周发现问题提前升配
- 带宽按需弹性：平时基础带宽，活动日临时升级几小时，花的是零头
四条习惯成本加起来一个月几百块，换来的却是活动日心里不慌，这笔投入产出比怎么算都划算。
备份和监控是看不见的底座
部署方案里还有两样平时感觉不到、出事时要命的东西：数据库每日自动备份，且备份文件不在同一台机器上；资源监控带告警，CPU和带宽超过阈值提前通知，而不是等客户先发现。多端合一建站的系统架构各服务商差别不小，签约前不妨问一句：活动日流量翻十倍，你们的方案怎么扛？答得具体的一般靠谱，答「没问题」的反而要多留个心眼。问这个问题的时候顺便要一份架构简图，说不清自己架构的服务商，出事时的应变能力也堪忧，图纸都画不明白的公司，救火大概率也手忙脚乱。
两条建议：一是每次大活动前做一次压测，模拟真实峰值，问题暴露在自己手里总比暴露在客户面前强；二是把告警通知绑到手机上，出了状况第一时间知道，处理永远快人一步。比格网络给客户做大促保障时，活动前三天就开始盯资源曲线，压测报告和扩容方案一起出，客户只管专心发活动。中小企业的活动频率不高，一年三五场，每场多花半天做准备，换活动日的从容，这买卖划算，怕的是平时不动手，临场靠运气。
