说到云计算，很多人第一反应是“轻”和“无处不在”。但对要扛业务压力的团队来说，更实际的问题是高峰：流量高峰、订单高峰、数据量高峰，每一次都会暴露基础设施撑不撑得住。云峰和阿里云放在一起讨论，正好落在这个问题上。这篇文章以阿里的业务经验为起点，拆几个典型场景，说说企业在云上应对峰值时可以怎么做。
从双11说起：峰值是最直接的考卷
2009年，天猫第一次举办11月11日促销，当天成交额约5000万元。之后规模一年比一年大，交易和订单的峰值也跟着刷新。这类活动难的地方通常不在平均负载，而在瞬间：下单、支付、扣库存、物流分单几乎同时发生，哪个环节慢一拍，用户马上就能感觉到。
从这类活动里，可以拿出几条对企业有用的做法：
- 容量提前算：拿去年同期的订单曲线和今年的营销排期推算，大促前两三周就要定好目标容量，而不是活动前一天临时加机器。
- 弹性扩缩容：核心服务跑在云上的资源池里，高峰前扩，峰谷过后及时释放，闲置的机器不用一直付费。
- 限流降级：流量超过承载上限时，先保下单和支付，评价、推荐这类非核心功能可以暂时让位。
- 全链路压测：在接近真实的环境里放入模拟流量，问题在大促前暴露，比大促中途修要省事得多。
这些做法的共同点，是把峰值当成日常来准备，而不是当成意外来救火。
阿里云：把峰值能力变成按需租用的资源
阿里云成立于2009年，最初是把支撑内部电商业务的计算能力对外开放。对中小企业来说，直接的好处是不必为了偶尔出现的高峰自建机房，计算、存储和网络资源按需购买即可。
举个例子。假设一家本地生活应用，周末订单量是工作日的三到四倍。如果按周末最高峰配置服务器，平日大部分机器都在空转，成本很难看。更常见的做法是分步走：
- 基础容量按日常流量配置，保证平稳运行。
- 用CPU利用率、接口响应时间、队列堆积量这些指标设定自动扩容规则。指标本身有滞后，阈值要留出余量，否则容易扩一次、抖一次。
- 周末或促销前，用定时策略提前扩好，不完全依赖指标触发。
- 活动结束后自动缩容，再把实际峰值和预估做对比，修正下一次的配置。
这套流程看上去不复杂，真正跑起来需要业务、技术和运维一起配合。云平台提供的是工具和资源，用得好不好，还是看团队的工程习惯。
一次促销后的容量复盘
下面是一个虚构但很典型的案例。某服饰品牌在阿里平台做三天的新品预售，前期预估日均访问量是平时的两倍，结果第一天就达到了预估峰值的1.6倍。
复盘时团队发现，问题不在数据库和服务器数量上，而是出在两个地方：
- 商品详情页调用了太多外部接口，其中推荐服务在高并发下变慢，连带把整个页面拖慢。
- 缓存过期时间设得过于整齐，大量缓存在同一时刻失效，数据库瞬间承压。
针对这两点，团队做了三件事：推荐接口加超时和降级，缓存过期时间加随机抖动，核心商品数据提前预热加载。下一次活动，同样量级的流量下页面响应明显变快，也没有出现连锁崩溃。
这类问题很常见。峰值下出事，往往是链路里某个原本不起眼的环节被放大。复盘要做的，就是把这些环节找出来。
给企业的几条建议
如果团队也打算借云平台应对高峰，可以先从这几件事做起：
- 先摸清业务的峰值形态。日常高峰、周期性高峰（比如每周末）和活动型高峰（比如大促）的应对方式不一样，混在一起算容易算错。
- 梳理核心链路，写清楚哪些功能必须可用，哪些在压力下可以先关掉。这一步通常要和产品一起定。
- 把弹性策略写进配置，别靠人盯着。自动化建得越早，大促当天越不用手忙脚乱。
- 每次活动后做复盘，把数据和问题记下来，作为下一次的基线。
还有一点要提醒：云上资源不是越多越好。弹性扩容的费用要提前预算，敏感数据的访问权限也要分级管理，否则省下的机器钱，可能又花在别处。
