促销保障并不难，架构设计轻松学

买买买的背后

每年的“双十一”或者各种促销和秒杀”会给电商系统带来很多挑战，比如：1. 集中，不论是哪个时间点，一旦有抢购开始，所有的人都集中在那个时间段； 2. 瞬时，每个抢购的东西发放出来之后，会在很短的时间内被抢购到；3. 拥堵，抢购活动在支付的时候经常会出现拥堵现象。那么系统的压力也分为几个层面：页面访问压力，比如“双十一”期间，www.taobao.com的页面访问压力是最大的；业务逻辑处理压力，当我们看到自己想要了解的商品，需要点进去查看商品信息的时候或者去下单的时候，还有查询优惠券、库存的时候系统就会面临这种压力；数据处理压力，最终提交订单的时候将面临数据处理压力。

在构建一些垂直电商平台的时候一般要通过一些促销活动来吸引人流，那我们怎么确保整个系统的稳定性？特别是我们做促销的时候需要扛得住压力。

为了解决上述问题，我们需要抓住最核心的两个问题： 1.如何评估系统承载力。 无论是用物理机、虚拟机还是阿里云，我们如何评估系统能够承载的压力？ 2. 如何进行架构设计和性能优化，当面临的业务压力超过承载压力时，如何将承载较少访问量的系统优化成能够承载较多访问量的系统？

老庙黄金案例

这个案例是驻云科技与阿里云、老庙黄金一起合作的。老庙黄金在春晚的时候做了一个促销活动，与其他电商购物的逻辑相比相对简单些，具体逻辑是：用户通过手机来访问活动的页面，同时在页面上点击抢红包，服务端会根据点击的时间点和所在地区等做一些判断，如果符合规则服务端会生成优惠券再返回到客户手机上。

压力估算

在做前期的并发峰值估计的时候，有一个常用的依据是TPS（有时候也用QPS），即每秒处理的事务数量。但是这个词对于业务部门显得过于专业，业务部门不能准确说出每秒需要处理多少个用户，但是业务部门可以告诉我们在做促销的时候大概会有多少的在线用户数。我们可以通过一个简单的公式估算出TPS：TPS=在线用户数*20%*20%*20。在线的用户里，大约有20%是活跃的用户，活跃的用户里有大约20%是正在下单的，在“秒杀”的时候不能够用普通逻辑去考虑，“秒杀”开始的前五分钟的压力大约是平时的20倍，所以最后乘以20来得到并发峰值。这是一个核心的数据，得到这个数据之后，我们就知道了后期压力测试和性能评估的方向和目标在哪里。

访问请求比例。根据整个电商系统的访问量和业务逻辑判断，我们得到了一个经验值的比例，即浏览量：下单量：交易量=16:4:1。所以，我们可以根据APP或者网站每天的访问请求数量估算出压力。

数据压力。当我们下单后，会在数据库里面把某些数据固化。

架构设计

秒杀业务特点

恐怖的峰值并发，并发/TPS/QPS一般都是在数万甚至十万；

时效性非常强，活动一般都在固定的时间或者事件触发，错过了就没有了；

稳定性要求高，只许成功不许失败，怎么样用技术支撑业务；

系统压力未知性，访问量、用户量、并发量的不可预测。

从图中可以看到，在春晚活动时，CDN峰值带宽1.5Gbps，峰值QPS达到3.2万，远远高于平时。实际上，基本上所有的电商促销活动的技术曲线图都是这样的。

一个系统是否能够稳定，是否能够支撑我们的业务最重要的是架构设计。一般，在电商的促销活动中，架构设计需要主要考虑以下几点：

基础设施选型

现在，云计算无论是从带宽，包括计算资源、存储的弹性扩展等方面来看，基本是一个最优的选择。如果一个电商系统不在云上，一般说明这个电商系统的访问量不会很高。以下是选择阿里云的理由：

资源弹性扩展：特别是带宽方面，以前放到数据中心里面，带宽需要扩增不容易实现，但是在云端，资源弹性扩展变得非常便捷。

快速交付：前面案例中，从系统开发上线到活动的最终执行只需要20天。

综合成本：促销活动的周期都比较短，短时间内需要大量的带宽、计算和存储，综合成本需要考虑。

应用架构设计

一般有以下几层：

接入层：使用CDN和负载均衡的方式把压力分担到多个系统上，SLB提升可用性，增加扩展性。

应用层：Pypy+Tornado+Nginx作为后端服务。

数据层：云数据库Memcache+RDS MySQL持久化，提升系统稳定性。

雪崩效应和限流措施

当实际超过预估时，限流措施就显得极为重要。雪崩效应会导致系统的全面瘫痪，解决思路是冗余和限流。

网络架构设计

用户量越多对网络带宽的需求量越大，需要采用高可用的设计。阿里云上有一个多可用区的概念，如下图所示，比如在北京我们有可用区A和可用区B分别放着不同的机器，如果可用区A因为线路或者其他一些原因无法访问的话，整个系统依然能按照右图正常运行。

弹性扩展设计

网络层按量付费；应用层ESS；缓存层在线升级。

安全架构

在安全方面DDos攻击是电商系统经常面临的安全风险。建议大家在做活动或者日常就开启仿Ddos攻击功能。

压力测试

台上一分钟，台下十年功。做活动的时间可能很短暂，十几分钟，一个小时，但是实际上的准备工作可能持续一个月甚至更久。压力测试考虑的东西很多，包括分布式架构、服务器、应用缓存等。

运维护航

在运维护航的过程主要包含下面6个部分：

1.7*24 监控；

2.应急方案，比如带宽不够了怎么去应对？数据库压力太大如何应对？

3.参数调优化；

4.上线及缓存预热，在上线前的几个小时把数据预热，这样可以确保用户大量涌进来的时候，已经有很多的数据在缓存里面；

5.自动化部署

6.弹性扩展

总结和讨论

从网络层到接入层、应用层、数据层、运维监控，包括Ansible用于自动化部署，这其实是一个稍微复杂的电商架构。

本文根据驻云科技COO肖凯在2016云栖大会•北京峰会上的演讲整理而成。

更多深度技术内容，请关注云栖社区微信公众号：yunqiinsight。