电商大促特辑:成就 1 号店 2000 万流量下的优雅架构

  • 李东辉

2016 年 6 月 17 日

话题:架构语言 & 开发运维

博恩·崔西说过:“一个人专注于一个领域,如果投入 3 分钟,你什么也不是,但如果投入 5 年,你可以成为专家。”然而当一群人一起专注 5 年会是怎样的景象呢?他们会面对怎样的大事件?1 号店告诉你:单 Service 支持每天亿级的请求、单日全站流量超过 2000 万、国际巨头全资收购……然而这些繁荣的背后他们也要面对日渐增长的压力、异地协作的困扰、频频大促带来的高并发,光鲜亮丽的大事件背后又有怎样不平凡的架构成长故事?

2016 年 7 月 15-16 日,ArchSummit 全球架构师峰会将在深圳举行。本届大会,我们邀请了 1 号店购物流程团队负责人刘霄晖老师,前来分享《构建电商核心购物流程系统实践分享》的内容,讲述的是 1 号店在高速发展中在购物流程系统多年积累的宝贵实践经验。

现在我们就来采访刘霄晖老师,让我们尝尝这些年来 1 号店出售的“酸甜”酱和“苦辣”酱吧。

受访嘉宾介绍

刘霄晖,1 号店购物流程团队负责人。2011 年 9 月加入 1 号店,先后负责 1 号店多个核心交易系统的研发,如库存、抵用券、促销、购物流程系统等。其中抵用券系统支持亿级规模的发券及用券需求,促销服务支持每日亿级规模的调用量,购物流程服务支持每日亿级的调用量。参与了公司千万级订单、双活机房等重点技术项目。对电商交易相关的业务有深入的思考和研究,专注于高并发大型电商网站架构设计,高可用系统设计,异地团队协作管理。目前致力于打造 1 号店新一代核心购物流程系统。

InfoQ: 你加入 1 号店已经接近 5 年了,见证了 1 号店的成长与繁荣,能否谈谈这 5 年内给你留下印象最深的收获与教训?

刘霄晖:确实如你所言,我从 2011 年加入 1 号店,到现在已经 5 年了。这 5 年期间,1 号店从一个只有几百人的小公司变成了一个拥有数万名员工、仓储服务全国覆盖的大企业,我见证了 1 号店的发展与繁荣。

这 5 年里我最深的印象就是 1 号店人的努力与敬业。在 1 号店,每一个人都是非常努力的,也是最为敬业的。拿我们技术部来说,任何时间任何地点只要有需要,一个电话过来,所有人都会义无反顾地第一时间进入工作状态,而且不求任何回报。大家都有一个共同的理念:我在为自己的事业而奋斗。

努力与敬业,其实就是我在 1 号店的最大的收获。当然,结识 1 号店的这帮小伙伴,跟他们一起工作,也是我最为快乐的事情。

说到教训,对我个人来讲最大的教训有两条:

  1. 任何时候不要忽视小事件。有个说法叫做“马蹄铁效应”,即因为最微不足道的一个马蹄铁上的一颗钉子折断了,导致马蹄铁脱落、战马受伤、将军意外坠马、输掉战争、最终亡掉一个国家。同样在系统中,任何一个小事件都可能对以后酿成大事故,任何时候都不能忽视小事件。
  2. 任何时候都不要麻痹大意。当你觉得一定没问题,这么简单的事根本就不需测试就可以上线的时候,事故往往会发生。我在这上面有过惨痛的教训,这也是“自大”给我上的深刻的一课。

对于成长而言,其实出问题的时候往往就是成长最快的时候。对我也一样,在早期刚到 1 号店时,系统的很多方面都不是很稳定,我们要处理各种各样的线上问题,这个阶段是我成长最快的阶段。

InfoQ: 你先后负责 1 号店多个核心交易系统的研发,能否分别简单介绍这些系统背后的核心技术和研发痛点,你们是如何一步步解决的?

刘霄晖:我先后参与和负责过促销、抵用券、购物车及结算等系统,这些系统都非常核心,但又各自有其特点。如促销规则灵活,卡券类型丰富,系统的灵活性是它最大的要求;而购物结算系统作为整个电商系统最核心的节点,高性能与高可用是它最为核心的东西。

这里重点说一下购物车及结算系统,当时它最大的痛点就是效率,每个用户只要发生购买行为,必然绕不开这个环节。而电商的各类大促很多,更会导致用户的集中购买行为时常出现。因此,保障购物结算在大促时能够存活,保障系统在大促时能够高效的为客户服务,保证能够在几百毫秒之内给出响应,是研发上最大挑战与痛点。为了解决这些问题,我们主要做了如下几个方面的工作:

  1. 分组

    类似于船分隔舱将整个船舱分成几个相互独立的空间,彼此之间不相互影响一样,我们也对系统进行了分布、分组改造。一个分组出问题不会影响其他分组,更不会使得整个服务挂掉,而且还可以使其他分组能够非常迅速地接手挂掉的分组的工作,保障系统稳定。

  2. 引入本地缓存

    提升效率最有效的手段是使用缓存,特别是本地缓存。但是使用本地缓存之后最难于解决的是数据刷新问题。缓存与实时,几乎成了共生的硬币的两面。我们想了很多种方法来解决这个矛盾,包括通过消息机制主动刷新,借助其他动作被动刷新等等,最终完美地解决了这个问题。

  3. 减少 IO 瓶颈

    通过读写分离、分库分表等方式,减少整个链路上 IO 瓶颈的影响。

通过这些方法的综合应用,我们一步一步把核心交易流程中面临的主要问题进行了很好的解决。另外,架构是有其演化的路径的,不是一蹴而就的,如果大家有时间参加2016ArchSummit 全球架构师峰会深圳站,届时我会详细阐述 1 号店交易系统架构的演进。

InfoQ: 1 号店与沃尔玛有没有技术上的合作?对此 1 号店交易系统有没有做相应的改进与调整?你们是如何管理异地团队的,你认为多团队如何协作才能提高效率?

刘霄晖: 1 号店与沃尔玛之间有非常多的技术交流与合作,双方的技术人员也会有很多的互访学习,在一些具体项目上都会有很多合作。

比如因为业务的需要,在与沃尔玛合作上 1 号店的交易系统做了一些适应与改进。以对散货的支持为例,我们知道传统电商售卖的东西都是预包装的、标准的。如果你要买一份牛排,它就是 200g 一份包装好的,传统电商不会卖给你一份 280g 的。但线下有这样的需求,它允许客户指定说需要一份多重的牛肉,然后店里面的工作人员会帮客户切割,这要求我们的价格体系和交易体系做对应的支持,另外也会有比如商家体系的改造等等。这些适应和改进,虽然是因与沃尔玛的合作而起,但对 1 号店系统支持多类型商家入驻、支持 O2O 等都带来了很好的效果。

异地团队的管理是 1 号店面临的一个很重要的课题。1 号店拥有上海和武汉两个技术研发中心。对于异地团队管理,我们一般会从以下几个方面入手:

  1. 开展充分、有效的沟通

    对异地管理而言,最大的问题是沟通,解决了沟通问题,异地管理的核心问题就能被解决。我们有定期出差机制,我们有与武汉 office 之间非常好的视频会议系统,还有各类的 IM 软件,电话会议系统等,从硬件上保证能够有充分、有效的沟通;在方法与制度上,我们会有每天的战会、每周的周会、每个季度的全员会等,来从管理上保证充分、有效的沟通。

  2. 合理分配工作,定期进度跟进

    异地团队之间的信息畅通后,工作协作也要得力、顺滑。对于此,我们会将工作进行合理的拆分。我们采用的是快速迭代的看板模式开发,每个任务会拆分地非常细,单独的地域团队就能在迭代周期内完成工作,这样会减少工作间的相互影响。同时两地都会对进度进行定期跟进,保障任务的按时完成。

  3. 加强团队建设,减少地域隔阂

    工作好做,人难带,特别是异地团队,让大家减少地域间的隔阂非常重要。我们的团队建设会重点关注这一块,通过各种方式来加强我们团队,减少地域间的隔阂。

高效的团队协作,个人觉得有赖于三点:一是充分、有效的沟通;二是工作分配的合理,在上面都已经谈到过了;第三,也就是最重要的一点,是“用心”。首先要相互尊重和信任。沟通中多些换位思考,要对事不对人。凡事要以身作则,己所不欲、勿施于人。不要抱怨,要学会感恩。还有就是要抛弃小团队思想,从公司的大局考虑等。

InfoQ: 你谈到一个稳定的交易系统需要做到良好的伸缩性和扩展性,这能否与同时实现高并发、高可用、高性能等要求共存?你认为一个系统如何才能做好这两方面的工作?在迭代过程中优先级如何调整?

刘霄晖:设计系统要考虑其伸缩性和扩展性,目的无外乎两点:一是能够适应可能的业务的变化,让系统能够快速满足新的业务需要;二是能够满足未来业务的发展,能够很方便的水平扩展从而提高业务处理能力。从这个角度讲,良好的伸缩性和扩展性,就是为了系统具有高并发、高可用和高性能,所以两者是不矛盾的。这两方面的工作其实是一致的,是一方面的工作。

可能大家更关心的是尽快满足业务要求和对系统进行设计让其具有伸缩性和扩展性之间的关系以及我们的处理方法。这个问题确实比较难处理:一方面业务需求需要尽快满足;另一方面如果“暴力修改”会破坏掉系统架构的优雅性,并且可能会使得系统不再具备扩展的能力。对于这个问题,我们一般会从“价值”角度进行评估,这个价值包含多个纬度,如短期业务价值、短期技术价值、长期业务价值、长期技术价值等等,最终通过包括业务方、产品设计人员及技术人员都仍可的“价值”来评定和调整优先级。

实际上对开发人员的素质要求是非常高的。有句话说得好:21 世纪什么最重要?人才。为了提高开发人员的水平,我们会采取一些机制:比如我们会制定相关的技术规范、分享一些最佳实践。每个团队都定期更新产品文档、设计文档。我们团队每周都会组织分享,技术部也会定期组织一些技术专题进行分享。对于刚入职的新人我们还会指定老员工做他的 mentor,以帮他快速融入团队。

InfoQ: 用户最关心 1 号店的抵用券和促销活动,能否简单谈谈在大促时你们在抵用券系统和促销服务上做了哪些措施来保障用户体验?

刘霄晖:最近 2~3 年我已经不负责促销、抵用券系统了。后面如果有机会的话,可以请我们促销抵用券的技术负责人来分享。这边只是简单提几点:

  1. 作好分组隔离,保证核心业务的体验。
  2. 事前作好应急准备,各个业务作好“权重”定义,需要的情况下将一个低权重业务降级,保障核心业务的用户体验。
  3. 接入风控和人机识别系统,拦掉不合法用户,保证真实用户的体验。

InfoQ: 在面对大促压力时 1 号店是否在哪些方面具有别于其他友商的经验或处理方法?能否简单谈谈?

刘霄晖:在应对大促时,可能很多技术上的做法大家都英雄所见略同。比如压测、制定预案等等。我简单介绍一些个人认为可以借鉴的经验或方法:

  1. 大促报备制度

    大促前会要求业务提前进行报备,技术部经过摸索整理出了一份大促报备的模块。模板内容包括:

    • 大促的级别;
    • 大促的时间段、内容、形式;
    • 预估流量(pv/uv)、流量的入口及分配;
    • 预计的单量、客单价;
    • 促销的类型、力度(同之前比);
    • 价格的优惠程度、库存的深度等等。

    业务也会专门召开会议,对大促的规划进行细致地讲解。这些对于我们技术进行有的放矢的准备很有帮助。

  2. 大促值班制度

    到大促时,我们技术会和业务联合值班,一般会有一个 war room。各个团队的技术都有参与,业务发现什么问题,需要技术支持的,我们能很快的响应。
  3. 双值班经理制度

    值班经理制度是 1 号店一项重要的制度。每天都会有 1 名开发经理负责协调处理线上的系统问题。重要大促时,我们技术部一般会配置 2 名值班经理,一名负责解决处理线上技术问题,一名负责和业务、运营沟通协调及向管理层汇报问题处理情况。

InfoQ: 就经验来看大促当天交易系统哪个环节最容易出问题?以前大促当天是否出现过问题,你们是如何解决的?为了准备今年的大促 1 号店在交易系统上哪些方面做了优化?

刘霄晖:目前来讲我们的系统已经比较完善和稳定,问题已经较少出现了。但就历史来看,之前确实有些环节容易出问题:比如在 0 时抢时,由于瞬间交易压力非常大,很有可能导致系统响应缓慢;另外在当时的巨大压力下,数据库可能最先抗不住,出现读写缓慢。这些问题的解决在上面也谈到过,主要通过系统分组、DB 分库分表、读写分离、临时降权等手段解决。另外在出现问题时,关键是要有应对的方案,问题能得到有效及时地处理。

当出现问题时,千万不能慌,要沉着、冷静。利用我们现有的各种监控系统、预警系统、日志系统等工具来发现和定位问题。定位问题后,马上寻找应对解决方案。今年相比于往年,会将各个机房的流量更加合理的分布。

InfoQ: 能否简单介绍 1 号店新一代核心购物流程系统,它“新”在何处?与旧的购物流程系统相比它能解决哪些问题,新增了什么功能,承载了怎样的业务期望?

刘霄晖:目前我们已经着手新一代核心购物流程系统的工作了。从产品规划、技术规范、开发框架、应用架构等方面都进行重新设计。具体到购物流程系统,有以下几点:

  1. 异地多 IDC 架构下购物车数据存储的优化,目前是采用分布式缓存 +DB 的方式。后续有可能会采用分布式存储(类似 Dynamo 或 PNUTS),具体技术方案还在讨论中。
  2. 将流程、后端服务、前端页面显示进一步解耦,进行细粒度的模块化,通过配置快速完成新功能的搭建。
  3. 进一步完善权限、日志、安全、监控、预警等通用模块功能,后续某些模块可能整合至公司的通用框架内。
  4. 将购物流程中记录的用户行为数据、商品数据等大数据充分利用起来。对于新的购物流程,我们希望它能够更了解客户,能够预测客户购买行为,能够根据客户的购买习惯“量身定制”客户专属的购买服务。

InfoQ:感谢刘霄晖老师接受我们的采访。期待你在ArchSummit 全球架构师峰会上的分享。


感谢陈兴璐对本文的审校。

给 InfoQ 中文站投稿或者参与内容翻译工作,请邮件至editors@cn.infoq.com。也欢迎大家通过新浪微博(@InfoQ@丁晓昀),微信(微信号:InfoQChina)关注我们。

架构语言 & 开发运维