【IT168 评论】每年双十一,不仅是剁手族的狂欢节,更是各大电商技术团队技术水平与技术创新实践检验的舞台,不断创新高的销售额、交易峰值、支付峰值,这些惊人数字的背后都离不开强力的技术支撑。IT168希望通过技术报道的形式向读者揭秘各大电商平台在双十一这一“超级工程”背后的巨额投入与技术创新,让更多人了解技术,尊重技术,促进同行业之间的技术交流分享,推动提高行业整体技术水平。
本文摘要:
2017年11月1日,苏宁易购在线上线下率先引爆双十一全民购物狂欢节,线上销售不到110秒就已突破亿元,11月3日展开的线下超级团购日,销售额突破历史单日最高销售记录,客流量暴增126%,可谓在今年的双十一前哨战中打响了“开门红”的第一炮。
经历了8年疯狂发展的双十一,对各大电商平台来说已经不再只是单纯的消费数字比拼,背后技术实力的较量才是真正的重头戏。但技术上的准备不是一蹴而就的,需要长期的积累和演变。历经多年大促洗礼的老兵苏宁在双十一技术准备方面已然变得游刃有余,本文以会员系统为例,回首过去会员系统经历了哪些变迁,展望未来会员系统又将向着哪些方向迈进?
作者:孙迁 龚钢
孙迁,苏宁云商 IT总部总监,拥有十多年 IT 系统规划及研发工作,其中包括多年互联网平台的建设和研发管理经验。前期主要负责企业内部内控系统的建设以及包括企业集成总线、短信平台、监控平台、以及基础技术组件的研发工作。后续负责支撑销售的核心交易系统的研发工作,其中包括购物车、订单、价格、库存、会员、促销、寻源等系统。在高并发及大数据系统设计、运维及研发管理方面有丰富的经验。
龚钢,拥有十多年软件开发和架构设计经验,曾任IBM顾问时服务于苏宁易购,现担任苏宁云商IT总部高级架构师,全面负责苏宁O2O会员融合的中台系统。亲历了苏宁前中后台架构分离及会员系统垂直切分的演变,推动参与了会员中台、商品中台、订单中台及统一支付系统的建设工作。在架构设计、系统切换演进、系统平台化方面有很深的思考和领悟,现正和研发团队一起建设会员相关平台系统的多活部署,持续优化系统性能,保障系统稳定。
正文:
1990年创业至今的28年间,苏宁不仅完成了从线下零售商向O2O互联网企业的转型,而且拥有云商、置业、文创、金融、投资、体育产业集团。苏宁始终坚持“店商+电商+零售服务商”的概念,以云技术为支撑,以开放平台为架构,全力打造融合线上线下,开放前台后台的云商模式。
与以往的双十一不同,今年的双十一不仅是苏宁智慧零售从概念到落地的第一次大考,也是一场线上线下融合、六大产业协同的“大阅兵”。而会员系统作为全产业融合的核心,自然也就站在了双十一技术保障排头兵的位置上。
为了保障双十一大促期间的业务,苏宁会员系统做了以下筹备工作:根据预估的业务量、历年访问行为及压力分布等情况对系统进行容量评估,并进行扩容;进行生产环境全链路性能测试,发现并解决各种潜在的性能瓶颈;持续更新并完善应急预案,以应对各种异常场景;对参与大促监控的人员进行全面培训及实战,精简汇报线,减少异常处理时间。
任何的技术准备都不是一蹴而就的,需要长期的积累和演变,苏宁会员系统也不例外。随着业务的不断快速发展,2005年上线的苏宁会员系统也在这10多年间经历了从初期架构到易购会员系统,再到系统垂直切分,以及现在同城双活这四个阶段的不断演进。
▲图1:苏宁会员系统架构演进
目前苏宁会员业务模块主要由账号资料、等级、账户、云钻引擎以及会员报表组成 。
▲图2:苏宁会员业务架构
支持线下门店,苏宁会员系统的初期架构
苏宁的业务初期主要集中在线下门店,门店销售系统采用的是CS架构,各门店安装客户端软件,服务端使用IIS作为应用服务器。基于windows平台提供可视化界面进行操作,客户端通过TCP协议与服务端通信,服务端再通过ODBC协议与sybase数据库进行交互。同时服务端应用也分为给客户端提供服务的前台模块和提供给系统管理员使用的后台模块。
▲图3苏宁会员系统初期架构
该架构支撑了苏宁早期的线下门店销售,但是随着门店数量的增加,该架构逐渐出现性能瓶颈。与此同时,苏宁开始拓展了线上销售业务,交易量的增加导致系统压力急速增加。而此时的系统已经很难进行扩展和改造,对业务的支撑举步维艰,直接限制了业务的增长。
会员系统只是整个POS系统中的一个模块,需要与其他模块紧密耦合在一起,所以对会员系统的任何一处调整都要考虑对其他模块的影响。由于涉及面很广,所以有时只需发布一个很小的功能,却不得不进行测试的全场景回归,并发布整个系统,不仅需求的响应周期很长,同时研发团队的运作效率也很低。
另外,由于各模块对应的业务功能不同,无可避免的会出现模块之间访问量的差异,呈现到系统层面就是模块对硬件资源需求的差异,所以不得不根据资源消耗最大的模块来决定整个系统所需的资源,直接导致了硬件资源的浪费。
基于上述问题,苏宁必须对整套销售及其关联系统进行重构,同时独立构建新的会员系统,并使用高扩展、高性能的技术和框架实现业务功能。但此时苏宁的IT技术能力比较薄弱,不足以独立搭建理想的系统,所以选择了与外部厂商进行合作,购买其硬件设备和软件系统,并与其开发人员合作共同研发新交易系统,新的会员系统也在此时应运而生。
引入外部厂商,易购会员系统诞生
易购会员系统是苏宁与外部厂商合作搭建完成的,主要设计思路如下图所示:
▲图4:易购会员系统设计思路
1.通过与外部厂商合作,引入E-Commerce、ECIF等软件框架,采用WebSphere Application Server(以下简称WAS)作应用服务器,DB2数据库服务器来构建新交易系统。
2.新会员系统通过ESB(企业服务总线)对外围系统提供实时服务,使用MQ实现异步通信。
3.新会员系统主要分通信适配器、交易处理、广播服务、后台批处理以及后台管理五大模块,各个模块分别负责不同的业务或者集成场景;
4.部署架构方面,前台应用使用WAS集群部署,通过ESB连接F5负载均衡器,轮询访问WAS集群,使用高可靠的小型机作为数据库服务器。
但是随着近年来苏宁业务量的急剧增长,这套系统架构也很快就暴露出了问题。首先,商业化套件在一定程度上限制了业务的快速变化,新业务的支持和研发周期特别长,应对业务的变化能力很弱。
其次,由于代码框架的限制,只能访问单数据源,当小型机配置升级到顶配后,数据库性能无法再提升,只能通过优化索引、调整业务、数据归档、定期清理等手段优化数据库。架构方面虽然做了读写分离,并且尽可能多的将变化不频繁的数据放到redis缓存中,但是数据的访问压力仍然很大。
总体来说,系统的横向扩展能力很弱。
值得庆幸的是,当时苏宁的前中后台架构搭建已初具规模,同时也积累了一定的技术能力。为了降低总体研发成本及研发效率,苏宁引入了开源的技术和服务,并从融入平台化思想、业务垂直拆分和去商业化三个方面对会员系统重新进行架构设计,逐渐形成了易购平台会员系统群。
自研技术加持,苏宁会员系统垂直切分
苏宁会员系统的第三阶段主要是按功能模块垂直切分系统,根据业务模块拆分出前置组合、等级、账号资料、账户和会员报表几个子系统。其中前置组合系统,提供跨等级系统、账户系统、账号资料系统的组合服务,并提供别名、属性名映射会员编号功能。等级、账号资料、账户系统对应管理各自业务,会员报表通过大数据平台实现。
在技术实现方面均使用苏宁自主研发的Suning Framework(SNF)框架,数据访问层使用Data Access Layer(DAL)组件;系统间交互使用Remote Service Framework(RSF)做实时访问组件,ActiveMQ、kafka等做异步消息中间件;使用Suning Configuration Management(SCM)做统一配置管理,实现配置修改实时生效;对redis和日志操作进行API封装,使代码调用更加便捷;后台管理使用了User Account and Authentication(UAA)做统一登录验证;定时任务通过Unification Task Server(UTS)进行管理和触发执行。
部署架构方面,前后台应用分别部署到各自集群,使用Wildfly作为应用服务并搭建集群,Mysql作为数据库,每组一主两从,多组构成数据库集群,并按照业务功能和特点的不同分为公共库、业务库和索引库。
▲图5系统垂直切分架构
从第二阶段易购会员系统过渡到第三阶段系统垂直切分面临很多困难:
·系统对外提供的接口很多,其中每个接口又有很多调用方系统,每个调用方系统使用的技术各不相同,而且新平台使用的接口协议与老系统不同,各个外围调用方系统都需要根据各自的版本排期进行切换,不能同时切换;
·所有老系统在生产环境中一直运行着,系统切换时要尽量保证不能停机;
·数据需要进行迁移,新系统与老系统使用的数据库类型不同,数据模型存在差异,分库分表的规则也不同;
·新系统上线可能存在各种bug,需要考虑如何降低切换风险以及如何修复数据;
针对以上难点,苏宁做出了以下应对方案:
▲图6:数据迁移技术实施
在数据迁移方面选择了spark及相关技术实施,每类表(有多张分表的为一类表)对应一套任务,具体步骤如下:
使用spark程序,把DB2中所有分表的全量数据抽到Hive数据库A类表;
将A类表数据分类,分别放入B、C、D类表,其中B为无效数据;C为按过滤条件过滤后的干净数据;D为被过滤出来的数据;
将B类表数据迁移插入新系统对应的历史表;
C类表数据根据转换逻辑的复杂度进行判断:逻辑简单的表直接拼sql插入新系统;逻辑复杂的表将转换后的数据写hive数据库 E类表,用另一个任务查询后拼sql插入新系统;
修复指定会员数据时,先删除新系统里这些会员的相关数据,重新转换后再进行插入。
在系统切换方面,以老系统做路由,在不影响外围系统的情况下,先完成系统内部的路由切换,再引导外围系统切换直接调用新系统,同时保留老系统路由链路,直到所有调用方切换调用新系统后再废弃。
内部新老系统的路由切换,使用灰度切换和功能切换两种方式组合,整体可分为两个步骤:
步骤一:切换实时性要求不高的查询类接口(如图7所示):
▲图7:切换实时性要求不高的查询类接口
老系统的创建/更新(含删除)操作在老系统成功后,记录待处理数据表;
创建时间在记表时间之前的全量数据,通过spark和hive任务初始化到新系统;
完成数据对比验证后,开启定时任务,处理待处理数据表的记录,按会员维度并行处理(一个会员如果有一条数据处理失败,则该会员的所有后续请求都会积压在待处理数据表中),根据新老系统的接口映射关系,转换调用新系统的创建/更新接口;
监控待处理数据表,同时监控新系统的接口和日志,对各种异常进行分析和处理,如果是新系统的bug,先修复代码,然后通过指定会员覆盖迁移方式进行新系统中错误数据的修复;
追平数据后,再次进行数据对比验证,通过按照会员号区间段逐步放大路由调用新系统的查询接口。
步骤二:切换实时性要求的查询类接口和创建/更新类接口(如图8所示):
▲图8 切换实时性要求的查询类接口和创建/更新类接口
第一步,切换新系统产生会员的所有接口:
根据时间段打开路由开关,在新系统生成会员编号(与老系统生成的会员编号隔开一定的号段,防止灰度切换过程中生成的会员编号冲突),同时这些会员的所有接口都路由调用新系统;
打开的时间段开始可以设置为几分钟或几小时,通过监控新系统的接口和日志、外围系统的反馈、内部人员使用验证以及数据对比验证等方式发现问题,并修复新系统bug和数据(数据不回写老系统,在新系统产生的会员数据必须在新系统里进行修复),多次反复此步骤,直到路由开关一直打开。
第二步,切换老系统存量会员的所有接口。考虑到新系统的所有接口功能在前面的步骤中均已得到验证,故老系统中的存量会员一次性全部路由切换到新系统,从而完成新老系统内部路由切换。后续在保留原有调用链路的情况下,引导外围系统逐步切换调用新系统的接口服务。
单机房的资源始终是有限制的,随着业务量的持续高速增长,系统扩容受到机房内基础设施的限制。此外单机房的单点问题也逐渐暴露,一旦基础设施层面出现问题,对业务的影响是灾难性的。所以在这样的背景下,苏宁会员系统的架构进一步向多活方面进行演进。
摆脱单机房,苏宁会员系统实现同城双活
▲图9同城双活设计思路
多机房部署需要一个过程,所以苏宁首先进行了同城双活。将现有机房做为主机房,同时承担子机房A的角色,对现有系统分批进行多活改造。会员相关系统属于基础服务系统,所以首批进行了改造。易购会员系统,即第二阶段的会员中心系统,由于外围系统尚未全部切换调用账号资料、等级、账户三个新平台系统,并且系统不具备多活改造条件,所以只在主机房保留其路由功能。
新建备机房,同时承担子机房B的角色,账号资料、等级、账户三个新平台系统经过改造后,同时在两个机房部署,对外围系统直接提供服务。
账号资料系统包含竞争服务、共享服务、独占服务、后台服务和变更服务,其中竞争服务和后台服务只在主机房被激活使用;账户系统和等级系统类似,都只包含独占服务、后台服务和变更服务,其中后台服务只在主机房被激活。
两个机房之间可以路由调用RSF接口服务,但对于一个系统接口服务的内部逻辑处理,原则上不允许跨机房调用,特例场景(如会员注册)可以跨机房调用。
底层数据库通过binlog同步数据进行备份。
展望未来,苏宁会员系统将继续朝着异地多活迈进
同城双活只是苏宁实现异地双活的第一步,未来,苏宁会员系统会继续朝着异地双活迈进。会员数据全量同步到所有机房,所有机房都是子机房,并且可以无限扩展,根据路由规则处理各自的独占型会员数据,其中有两个机房同时还作为主/备机房,出现故障时互相切换。
除此之外,苏宁会员系统还将延续平台化发展,与更多的会员平台进行会员融合或账号打通,打造大苏宁会员体系。同时还将向第三方可租用的会员云平台发展,实现苏宁会员平台的开放。
“双十一超级工程”系列专题下期预告:
双十一大促活动的本质就是低价,当你摩拳擦掌等在电脑前,不断刷新页面,准备抢几张优惠券,并相信这次收藏的商品志在必得时,但即使整点刷新,优惠券还是瞬间消失,心爱的商品库存秒变为0。感到无比郁闷的同时,你是不是很疑惑:why?这是因为同样坐在电脑跟你拼手速的,除了正常用户外,还有一批专业的羊毛党。全民消费狂欢日的当前,电商平台应该如何应对羊毛党大军,且看《网易双11“超级工程”:反欺诈系统应用实践解析》。