楚楚街 11.11：特色移动电商的大促技术演进之路

本次 11.11 策划，我们邀请了移动电商楚楚街来分享他们关于大促的经验，另外，在本次 ArchSummit 全球架构师峰会北京站，设置了《电商专题：系统架构如何应对业务爆发式增长》《阿里双11 技术架构突破》专题，来深入解读双11 等大促背后的技术故事，大会将于2016 年12 月2 日-3 日在北京国际会议中心召开，欢迎关注。

本文作者：李顺，楚楚街商城研发技术总监。

楚楚街是以90 后用户人群为主的特色移动电商，目前楚楚街只做移动端。平台目前用户数近亿规模，每日流量千万级别。

楚楚街早期以“9 块9 包邮”切入到电商业务，尽管目前平台已经转型为全品类高性价比的年轻用户喜欢的商品，但“9 块9”早已深入人心。从2015 年开始，楚楚街将9 月9 日定义为“楚楚节”，简称“99 大促”。每年的9 月9 日，对于楚楚街来说，其流量和业务成交都是与双十一比肩的。所以，对于楚楚街的技术人员来说，在双十一的准备方面有特殊之处：做好了99 的考卷，双十一的压力就抗过了一大半。而这一份考卷不是模拟卷，而是真实的考试卷。

今年9 月9 日~11 日，楚楚街的99 大促顺利完成，抗住了峰值订单数为平时订单数100 倍、流量峰值为平常峰值的50 倍的压力。99 大促的顺利进行不仅为双十一大促打下了良好的基础，也收获了很多宝贵的经验。大促的顺利进行离不开技术的支持，本文来介绍一下，楚楚街针对今年的两场大促，做了哪些技术上的优化升级。

一、系统拆分

楚楚街自营商城于2014 年年底上线，上线后业务增长迅猛。与很多创业型公司面临的技术问题一样，早期的架构从底层数据到上层的web 服务器全都耦合太强，所以从2015 年7 月开始，为了甩掉系统的历史包袱，开始做技术优化。而优化的核心就一个字——“拆”。

拆分我们主要按照如下几个阶段来做：

1、按照业务将落到服务器层的流量进行拆分。

2、业务层代码的拆分。

3、数据层的垂直拆分和服务化。

第一阶段的拆分，我们主要是梳理业务，将业务进行合理的划分，将原始耦合在业务中的如短信、push、物流、ERP 等抽象出平台级系统。其余核心业务如订单、商品、购物车、用户等系统，梳理好业务边界和接口，在最上层按照域名进行流量的切分，这样切分后，各个业务系统的边界清晰了，当大促等大流量活动期，也不会因为某一个业务流量过大引起整体业务雪崩，保证了部分业务可以正常运转。

第二阶段主要是做代码的拆分，将过去耦合在一起的代码仓库根据第一阶段的拆分情况进行代码拆分，在拆分的基础上将冗余代码进行清理，可以有效提高系统的性能，增加了代码的可读和可维护性，各系统之间人员垂直，可以大大提升迭代能力。

第三阶段也是整个过程中最关键的阶段，那就是将业务下沉到服务，然后这个过程做 DB 的垂直的拆。垂直拆分完成后，核心业务抽象成服务，将核心接口收拢，保证了有限的服务接口，提供了可分布扩展的性能，存储层可以根据服务接口解耦，并有效的保证了 SQL 等质量，保证了业务的稳定。

下面两图描述了我们拆前和拆后的一个架构对比。

拆之前的架构

拆后的架构

在拆的过程中抽象了很多基础系统：如分布式消息流、数据库中间层、基础业务服务化（用户服务、订单服务等），等等。

作为创业公司，“拆”的过程不允许耽误业务的发展。在业务发展中寻求技术优化，不耽误业务，与业务发展寻求一个契合点，需要有很强的业务理解力和技术把控力。目前，我们还走在整体服务化的路上。

二、多级缓存架构

多级缓存架构在大促这种大流量期间，针对于大量的“读”接口是意义巨大的，也是保证了大促期间业务稳定的重中之重，我们以商品详情页为例作一下介绍。

电商的流量大入口除了首页等导流页面外，商品详情页无疑是流量的集中点。而双十一、99 等大促，详情页的访问量又达到历史之最。

详情页看似简单，但其有很多的业务逻辑：比如商品改价、库存变更、SKU 变更、评论评价等各类与数据强相关的业务逻辑。而详情页有一个非常大的特点，就是基本以读请求为主，因此，针对详情页这类的业务，我们创建了多级缓存架构。

多级缓存架构根据业务流量的变化，是一个漏斗模型的系统架构，下层的流量越小，系统就越稳定，目前我们多级缓存架构主要是三层。

第一层是 CDN，这一层主要缓存的是大促期间的主会场、分会场、秒杀商品的静态页、商品的富文本详情页、商品属性页等。这部分页面都是大促期间流量最大的，也是最要求速度和体验的，放到 CDN，用户根据就近节点进行访问，大大加快了访问速度，并且减少了服务器层的压力。

第二层，我们用 Nginx＋Lua＋OpenResty 做了代理层缓存，这层缓存主要缓存住了提供给客户端的 api 接口的数据，这层缓存根据商品的业务需要，会在活动规定时间内决定其缓存有效性，一旦商品所在的活动失效，才会走到下一个层次——业务层；而 99% 以上的流量都在这一层给抗住了。

下图是本层的一个过程图。

第三层，我们在业务层添加了 Memcached 和 Redis 的 cache，这一层缓存了 DB 或者服务化接口拉取出来的数据，这层缓存的主要都是商品 ID 等纬度的业务数据，根据业务流转情况，保证这层的缓存数据都是实时的，确保了到 DB 层的量几乎很少。

最后流量才到数据库。数据库所起的作用是数据的持久化以及部分缓存失效的主动更新。根据这个架构，到达数据库的流量很少。

这套架构模型，让我们的详情页访问时间从早期的 100ms 左右，降到了 20ms 以内。同时单机能承载的详情页请求数量增加了 100 倍以上。

下图是此架构服务器部署的一个概述

三、流量预估和压测

3.1 流量预估和压测的意义

在每次有新系统上线，或者技术驱动的系统优化完成后，我们会进行系统压力测试。系统压力测试能非常清楚得知道：

1. 系统短板。是计算短板、网络短板还是存储短板，根据短板的情况再做优化或者机型升级。
2. 系统水位上限。当系统的 tps 到达多少峰值，系统扛不住，需要加机器。

对系统的压力有了预期，那么我们可以根据大促流量的情况，提前准备好机器。根据大促的流量如何，我们会对系统进行调整。

3.2 如何进行流量预估

如何进行流量预估，流量预估其实是一个很难的问题。难点来自于以下 2 个问题：

1. 今年楚楚街跟去年对比，大促有多少用户量的提升？
2. 大促的业务形态：有多少业务和活动是瞬时流量？峰值流量预期多少？

针对第一个问题，我们会看总体运营数据和电商的行业总体情况来预估今年大促的用户量级。所以我们会抽取 2015 年大促的访问日志来做大规模用户行为分析，大致得出大促会场页、商品详情页、购物车、下单等的访问比例和峰值。

针对第二个问题，我们会提前跟业务团队同步大促要进行的活动内容，包括活动预热和大促当天。通过业务的理解来折算系统的峰值。

3.3 如何压测

有了流量预估，就要对我们的性能进行压测。压测分为测试环境压测和线上生产环境的压测。我们更侧重于拥有流量链路的生产环境的压测。为什么流量链路的生产环境压测更为重要呢？因为业务其实一直是在变化的，生产环境的机器硬件环境也好、网络情况和整体业务链路都跟测试环境模拟出来的相差较大，当然压测出来的结果也是有所差异。

压测的方法，业内比较常见。我们采用了以下几个方法：

1. 用 JMeter 来压系统的最大请求数。模拟同比例的请求数，就能模拟出大促量级的系统反馈。这个在测试环境、生产环境、单服务器、服务粒度都会进行。
2. 用去年的日志，在系统真实压力最低的时候（凌晨 3、4 点），用 1 倍到几倍的访问压力，看真实的线上系统反馈。

3.4 总结

拿到压测结果，对于性能的短板，我们便开始进行性能改造提升。并且根据每一个服务的机器状况，在云端提前进行机器购买和刻录，为大促做好准备。

四、监控和预案

监控

楚楚街开发了一套自动化运维系统 CMDB。CMDB 实现了线上服务器的实时水位监控、业务服务监控、机器自动上下线、代码自动化部署等常见运维功能。根据机器、服务、业务的不同粒度，CMDB 在监控和运维的功能描述如下：

监控

运维

业务粒度

• 商城、社区、大数据等不同业务整体使用状态

• waf 防火墙

• 紧急预案切换

• 云服务账单

服务粒度

• 平均响应时间

• 请求量

• 错误数

• 针对不同服务的个性化监控

• 机器整体水位状态

• 运维 API 接口

• 灰度 / 内测 / 压测 环境区分

• 安全审计

• SQL 审核

• 代码自动发布和回滚

• 版本管理

• 域名管理

机器粒度

• 连接数

• CPU

• 内存

• 数据库

• 缓存

• 机器内核、软件版本等参数调优

• 系统个性化定制模板

• Autoscale 自动伸缩系统

• ZooKeeper 服务器管理系统

在大促期间，运维同学根据业务线实时监控以及各类报警，能在第一时间发现有问题的业务、机器或者服务。根据不同问题的粒度，通过事前准备的预案，第一时间在 CMDB 上触发切换预案。

预案

双 11 的流量非常大，就算评估和扩容再好，也有可能出现底层服务、部分机器出问题的情况，这种情况是允许并且不可避免的。因此，根据不同的需求，我们准备了服务、机器、业务三种不同粒度的降级预案。

预案 1：服务级别降级

线上系统的服务之间有调用和被调用的关系。一旦下游服务出现不响应，那上游服务要做实时降级。

以详情页评论评价为例。详情页一般都会展示评论评价，评论评价在整个链路里其实并不是一个核心链路，如果评论评价的服务接口挂掉，就算是设置了接口超时时间，由于瞬时流量很大，也依然会将整个交易系统拖死。所以针对非核心链路业务，我们进行了梳理，将非必要服务化接口做了熔断处理，如果接口失败，或者失败达到一定阈值，就不再调用评论评价这个服务，直接返回空数据，这样尽管评论评价不能显示，但正常的核心链路还是可以正常运转的。这是我们常说的有损服务。

预案 2：机器预案

楚楚街目前使用 ZooKeeper 做服务管理。一旦服务宕机，会自动切换可用机器。同时，我们会根据 CMDB 反馈的水位情况，快速唤醒虚拟机并且进行对于服务的挂载。这体现了云服务的一个优势，尽早储备好虚拟机并且刻录好业务，服务器的增加是秒级别的操作。

预案 3：业务级别的降级

在大促期间的高峰下单时间点，在业务允许范围内，我们会对业务进行降级。比如，在大促 0 点下单的高峰期，我们会禁用商家实时查看详细用户购买订单以减轻线上订单服务的压力；我们会在流量高峰期，将新用户注册发送优惠券的逻辑从在线逻辑切换到离线数据流逻辑，用户拿到优惠券的时间会比预期晚，但极大的减少了线上的压力。

五、总结

99 前的一个月，多级缓存的上线，让线上压力大大减少，因此我们有精力去更关注其他服务的优化。

这次 99，我们的业务降级、服务器快速部署上线，在大促 0 点的时候起到了很关键的作用，用户在 0 点时候的下单体验仅有几秒的时间有轻微延迟，其余时间都体验流畅。

99 的成功，是双十一之前的强心剂。双十一，楚楚街推出了很多新的业务形式，比如直播、预售等玩法，我们针对这些业务也做了详细的技术预案，但万变不离其宗：垂直业务 + 多级缓存 + 流量预估 + 监控降级， 这条路我们还会继续走下去。