如何做好电商大促的容量规划
下雪了，注意保暖
在进行整体电商架构设计过程中，关注系统的稳定性是很重要的工作，也是对架构师能力的一种考察，特别是在电商系统准备搞一次大促时，合理的对系统进行容量规划就显得尤为重要。
稳定性保障的一个难点是需要面对不同的复杂的用户模型，所以应对策略有所不同。容量规划，就是对复杂业务场景的分析，通过一定的技术手段（如压力测试），来达到对资源合理扩容、有效规划的过程。
容量规划的场景分析
不能脱离业务场景空谈技术，需要业务场景入手来分析。
对于电商来说，核心链路就是交易链路。就是用户要能登录，然后能通过浏览商品详情页下单订购，或者加购物车，通过购物车进行订购结算，这个过程中还要进行各种优惠的批价处理，库存的判断等等，形成订购之后，最终还要能够支付成功，一个完整的交易支付流程才算走完。
在大促的峰值时刻，绝大部分用户选购什么商品，早已加入到了购物车中，且各种优惠券也已经申领成功，就等着最后这个时间点直接下单完成订购。所以，在大促这个场景下，交易下单这个环节是核心中的核心。
因为这个时间点的交易流量实在是太高了，所以近两年电商也改变了一些玩法，其目的就是希望减少峰值流量，让流量在整个大促阶段更加均匀。具体的运营和玩法就不展开了。
所以大促的容量规划，就是在大促零点峰值时刻，评估好交易流量，再进一步转化一下，就是每秒的交易订单峰值。
下图常用的路径分析示例，用户首先从首页、大促会场或者微信里的分享页面转化过来，然后通过搜索、店铺、详情页以及购物车进行最后的转化，形成订购下单和最终的支付。
具体数值的评估上，可以跟产品运营团队共同讨论，整体的业务目标由运营团队给出，比如 GMV 目标收入，UV、PV、转化率、客单价以及商品单价，这些都是业务目标。通过这些业务数据，根据上图的路径逐步分解，就会逐步得出每一层的流量数据。
假设大促会场会有 500 万 UV，根据 GMV 和客单价，如果要完成目标，推导出到详情页的转化率需要达到 60%（产品运营需要努力达成这个业务目标），那详情页的 UV 就是 300 万；根据用户访问行为分析，对详情页的各个应用产生的 QPS 再做一个评估，这样单个应用的容量值就有了，然后再进一步向下转化，能够形成订购，形成加购物车的又有多少，再进行评估，最后就可以得出一个交易下单的峰值以及支付的峰值。
计算出峰值后，还要与历年评估的峰值数据，以及实际的峰值数据进行对比，根据对比情况进行调整。评估出来的这个峰值，就是系统要承诺支撑的容量，因为只有达到这个容量值，才能支撑业务完成对应的业务目标。
总结来说，这就是一个根据业务 GMV、UV 等目标，对技术上的交易下单峰值这个核心指标进行推导的过程。
接下来就根据评估的各个应用和基础服务需要承担的流量，先扩容一轮，同时开始构造数据模型和压测模型来模拟真实流量，以此验证系统是否能够达标，过程中再进行局部的扩容和优化。
一般来说，先进行单链路压测，比如购物车订购，详情页订购等场景的压测，达标后再进行多链路压测，最后再进行全链路压测，直至达成目标。为了能够保有一定的容量缓冲，最后几轮压测，会将压测流量调整到目标值的 120% 或 150%，来保证系统能够应对足够极端的场景，这样才能够游刃有余地实现 100% 的目标。
构造压测的数据模型
如何构造压测的数据模型呢？这是一个比较复杂的问题，通常情况下，可以从两方面入手。
一方面，数据模型要接近真实场景。这就需要不断地积累经验，记录早期大促的详细数据和真实场景（比如不同用户购物车里的商品数量、优惠策略、不同渠道比例等，以及各种运营活动的玩法），这样可以最大程度地模拟真实的用户访问模型。
像阿里做得比较极致，可以通过 BI 系统，将往年模型和当年模型进行分析比对，直接生成对应的数据模型，甚至是多套模型。
另一方面，数据量要接近真实场景。数据量有很多维度，比如用户数量、商品数量、店铺数量、优惠券数量等等。
一般会通过数据工厂这样的工具平台，结合运营团队给出的数据量评估，快速制造出对应量级的数据。
另一种方式就是从线上将真实数据，进行敏感信息脱敏处理后，导出到另一张影子表中，专门提供给压测使用，这样做的好处是不会污染线上运行数据。
总结
容量规划工作，单纯靠技术能力是无法解决的，需要经验和数据的积累，到了阿里这个体量就必须借助人工智能和各类分析算法这样更高级的手段才能解决。
容量问题，也不是简简单单通过资源扩容这种成本投入就可以解决的，扩容是最后的执行手段，但是怎么合理的、科学的扩容，就需要有合理的规划。
当业务体量和复杂度到达一定程度时，就要依靠技术人员对业务的深入理解。能够合理规划业务、技术和数据模型，是需要一些经验积累，以及在各类极端场景下的经历。
在如此复杂的技术体系，也只有在同样复杂的场景下才会被催生出来，才会有存在意义。
所以需要在学习借鉴时，还要从实际场景出发，慢慢积累。