淘宝购物车5年技术升级与沉淀 下

简介: 淘宝购物车5年技术升级与沉淀


业务支撑路上的沉淀

淘宝购物车各种业务场景的创新尝试离不开技术的探索与突破,当然技术的发展也一定是为业务服务,以业务先赢为目标。但是,购物车作为基础链路上少有的增删改查全部具备的列表翻页场景,客观存在特有的一些技术开发难点。那么本部分内容就来分析下购物车业务开发的技术难点,以及如何一一突破来支撑业务发展,并沉淀通用可扩展能力进行业务提效。


 技术突破支撑业务发展


  • 技术架构


首先先用一张大图描述下淘宝购物车的技术架构,有个全局的认识


image.gif图片.png


  • 购物车开发技术难点分析


购物车业务场景特点


  1. 流量大,稳定性以及产品可用性永远是前提和基础;
  2. 列表形式业务场景,包含增删改查,购物车容量虽有克制,但一定是不断增长的;
  3. 调出型代表应用,依赖多(优惠、商品、库存、限购等等下游);
  4. 基础产品,体验第一(不能随着业务的复杂性提高降低用户体验);


购物车开发技术难点


基于购物车业务场景的特点,以及近些年开发购物车的经验,我认为淘宝购物车业务开发最大的技术难点有二;


  • 交易核心链路引入营销导购/算法等场景


  1. 每一年用户购买力和诉求都在增长,业务在不断发展,营销导购/算法类的业务诉求越来越多,但下游依赖不断增多,核心链路耗时增长,再加上购物车是一个列表形式,任何复杂度都会随着商品列表增加成倍增加,对稳定性和用户体验都是巨大的挑战。但无论业务如何发展,稳定性及用户体验永远排在首位。最终导致的局面是用户侧的rt体验没有提升,营销导购/算法类的业务无法落地。
  2. 那么是否可以重新定义一下购物车的核心数据与非核心数据?核心数据保持一个比较稳定的数据量级以及复杂度,非核心数据来完成业务的增长;对于购物车场景来说,区别是否核心应当是两个维度,第一,数据量级的维度,即购物车列表,按照顺序排列后是否每一个坑位对于用户进入购物车都是核心数据(不止是分页)?第二,信息丰富度,例如购物车商品基本数据和营销数据,或者说下单需要的数据和利益表达的数据;


  • 购物车分页渲染场景与全局内容感知这一诉求之间的矛盾


  1. 即如何在购物车分页渲染(用户主动翻页驱动)的前提下,提前感知、聚合用户购物车全部商品的信息进行某些氛围的表达,一直以来购物车的很多诉求都与之相关:第一版惊喜券飘条透出、筛选入口透出逻辑、tab提示等等;这里对全局商品的感知诉求又包含两个层次,基础商品标志(id等)、商品IC基本信息(商品标签等)、复杂商品信息(具有购物车场景语义的优惠、失效等);不同层次对购物车的依赖不同;


  • 技术突破带来的业务升级


购物车筛选能力


2020年双十一之前,淘宝购物车是没有任何商品筛选功能的。而商品筛选分类,提高发现效率一直是用研报告中,top级别的用户诉求点。

image.gif图片.png

  • 难点分析


  1. 分页模式:购物车为分页查询,筛选商品可能分布在不同的页面中(例如极端情况下,希望筛选出的商品在购物车分页查询中的最后一页);
  2. 合并结算:各个筛选“页面”下的商品勾选操作在切换过程中需要保留,底部动态计算结果需要保留(例如在筛选浮层下筛选出的商品在购物车分页查询中的最后一页,且被用户勾选参与动态计算。关闭浮层回到后商品勾选保留,动态计算结果保留);
  3. 用户的操作体验要求,例如底部价格不能出现跳变等;


  • 技术方案选型


方案类型

方案描述

优势

劣势

客户端筛选

用户刷新购物车,查询第一页以及预加载,渲染50个商品;点击凑单筛选,用户购物车剩余商品完整信息全部一次性拉出;由服务端对商品等组件打筛选标,客户端根据组件标做显示/隐藏实现商品的筛选 客户端筛选,筛选浮层勾选态可一直保留,不会存在回到大购物车滑动,结算栏跳动问题;点击凑单筛选拉回全部商品,避免客户端串行依次请求带来的各种时序等异常流问题,异常流某种程度导致用户购物车页面结构错乱;一次下发全部商品,后续筛选可由客户端完成,基本不存在对服务端的再次调用;后续能力可复用,例如预售筛选; 部分流量,加载商品数大于40个,存在rt过高,端上体验较差以及带给服务端性能压力问题(可参考后面压测流量评估,高峰降级)(需要评估rt时间看端上体验问题)

服务端筛选

点击筛选,服务端只下发跨店满减商品;点击关闭,由于需要保留勾选态,因此需要下拉用户购物车其他剩余商品完整信息;再次点击筛选/关闭,保持和客户端筛选方案一致的逻辑,做客户端筛选; 沉淀能力,后续筛选能力可复用 相对于客户端筛选方案流量没有减少(性能压力没有减小),依次点击关闭,反而多了一次调用;第一次打开,关闭的时候,会出现rt过高用户体验差的问题;


  • 最终的技术方案


最终结合项目具体诉求我们选择客户端筛选的方式,方案时序如下图所示:
图片.png

客户端筛选的本质,实际上从客户端的角度来看,是根据各个组件的筛选标以及当前筛选页对组件进行显示/隐藏,实现最终的商品筛选。例如当前购物车主要组件如下:
image.gif图片.png

那么对于各个筛选页面来说,各筛选态的结构如下:image.gif

图片.png

结合购物车分页渲染商品列表的场景,使用客户端筛选方案,实现分页场景下勾选态保留的购物车筛选能力,在独立购物车、筛选入口方式、筛选项策略维度均具备扩展性;并支撑大促凑单筛选、预售筛选、多Tab等业务上线;
image.gif图片.png

  • 应用的业务场景


淘宝沉淀的客户端筛选方案最终支持多个业务落地,包括跨店满减、预售等浮层筛选,以及NewCart中降价、常购等多Tab模式筛选:
image.gif图片.png


交易核心如何引入算法导购链路


这里我们依旧以淘宝惊喜券项目为例,项目背景直接阅读“惊喜券项目”部分


惊喜券项目伴随业务发展最终沉淀技术架构如下图所示:


图片.png


项目落地的过程中,主要围绕以下两个挑战与命题进行探索与沉淀:

  1. 【技术挑战一】:大数据量活动商品(百万)情况下,如何完成购物车(交易)核心链路对用户所有购物车商品的筛选;
  2. 【技术挑战二】:如何在购物车(交易)核心链路场景,面向用户保障导购营销业务的确定性以及人货匹配的精准度(算法接入);

挑战一:活动商品的筛选
  1. 【问题定义】:
    图片.png
    业务上氛围的透出面向用户购物车全部商品,以及购物车分页查询的事实意味着商品的筛选只能依靠基础商品id信息,那么大数据量活动商品id的存储和过滤的性能,在购物车核心链路便成为第一项技术挑战;
  2. 【解决方案描述】

图片.png

如上图所示,三个业务阶段的发展,对应三种不断优化的核心链路商品筛选方式,从diamond、到内存布隆过滤到最终选择的tairBloom方案,他具备以下优势:

(1)使用RDB存储规模级活动商品信息,打破购物车内存限制对参与活动商品量级的要求;

(2)由定时推送大文件数据到购物车机器,改为对远程RDB存储信息进行实时维护,降低对购物车应用自身稳定性风险的同时进一步提高业务的确定性;


挑战二:核心链路业务确定性及算法接入
  1. 【问题定义】:上述阶段一、二方案在业务表现上存在弊端,主要表现如下:
  • 业务确定性:由于无法在核心链路引入拉菲等导购依赖,只能依靠前置商品筛选过滤,存在时延,营销利益点氛围透出用户侧表现具有不确定性,体验较差;
  • 人货匹配的精准度:阶段二方案在购物车同步链路中使用基础规则针对用户进行商品营销氛围的透出,而人与货的匹配在交易核心链路由于rt稳定性等要求,无法引入算法进行计算获取最优解;
  1. 【解决方案描述】
  • 将导购链路依赖通过异步链路下发,保障核心链路稳定性的同时获取业务的准确性及算法接入的能力:


image.gif图片.png


氛围的渲染从同步链路解耦,既保障核心链路稳定性,同时保障了业务的确定性并提供了算法接入可能,帮助业务逐步追求最优解;


核心结果


  • 购物车转化业务效果数据
  • 规模:保障稳定性基础上支持近几十万商品报名活动;
  • 券核销率:18年到21年券核销率提升超过50%;
  • 沉淀购物车异步能力:沉淀基础链路异步能力,将复杂业务逻辑与核心链路剥离,降低代码耦合,缩短核心接口耗时,保障核心系统稳定性。给业务场景扩展、快速迭代提供更多可能性;
  • 技术演进诞生nextRpc架构(新一代核心与非核心数据分段式混合响应框架)产生并在下单换购业务中落地;


📢 最后关于算法,再聊一些题外话,实际上近两年购物车有一个非常明显的变化,即业务与算法结合的场景越来越多了,这是大流量营销场景发展必然的诉求。同时更多大胆的技术突破与尝试为业务发展也带来了可能。目前购物车与算法结合的场景有:降价商品push推送、购物车常购、省心凑等。当下购物车链路中涉及算法以及异步的场景链路如下:

图片.png


但我认为基础链路与算法的更合理、正确的合作模式依旧需要进一步的探索。做基础链路业务时间长了,有一个很难扭转的意识,即我们更多关注功能的正确性,很容易忽视算法的准确度,以及最终项目数据中算法的价值体现。例如常购和省心凑,实际上最终决定这两个功能是不是好用,利用率是不是高,除了操作功能正确性外,更重要的是算法推荐的个性化与精准度,购买决策核心永远都是商品本身。算法的准确度如何衡量、算法的结果价值如何评判,如何推送业务更好的迭代,是需要我们业务开发和pd一起往前探索的重要一步。


 能力沉淀赋能更多业务


实际上这些年在支撑淘宝业务发展的同时,也在不断沉淀通用的能力,赋能更多的独立购物车或者其他垂直业务快速迭代,例如:购物车优惠明细开发规范、购物车领券结算开发规范、购物车分组结算开发规范、购物车凑单氛围开发规范、购物车筛选能力开发规范、购物车商品卡片氛围开发规范、购物车上下游传参说明、奥创开发相关知识。


购物车的未来在哪

近一年,淘宝购物车在提升转化和体验上,都有业务上的突破以及技术上的升级。例如从平台促转化来说,FY22财年以前,如果说我们都在找寻用户购物车内部商品的促转化点,提升购物车商品的流通的话(例如唤醒低转化商品激活购买欲、筛选商品提升购买决策等),那么FY22财年,我们开始尝试与算法进行合作,探索一些精准符合用户预期的购物车外的转化场景,例如常购、例如省心凑(凑单推荐),在提升用户体验的同时,获得购物车外的GMV场景。再例如体验上,FY22财年是第一次开始逐步关注用户体验的一年,购物车作为一个具备强烈工具属性的业务场景,用户体验应当永远放在第一位,FY22财年,淘宝购物车在价格体验上做了不少事情,例如高峰期算价不降级,和下单的价格计算一致性,购物车算价明细表达优化等。

那今天以后的淘宝购物车方向在哪里?购物车是一个提供商品管理、凑单合并结算能力的基础工具,围绕两个核心:「人」和「商品」,目标依旧是提升用户使用体验及下单决策效率;


  1. 【商品管理方面】
  • 加购链路更顺畅;
  • 提升用户浏览、查找商品的效率;
  • 从根本上解决用户容量问题,让用户购物车商品「流动」起来;
  1. 【凑单算价方面】
  • 继续提升价格体验,包括购物车算价和上下游的一致性、优惠表达的清晰度等;
  • 提升凑单效率,在筛选、推荐的基础上,更进一步,例如推荐用户最佳凑单搭配等;


团队介绍

我们来自大淘宝技术-淘宝交易平台,负责淘宝业务的商品详情、购物车、下单、订单、物流、退款等从购前、购中到购后履约的基础链路相关业务。这里有百亿级别的数据、有超过百万QPS的高并发流量、有丰富的业务场景,服务于10亿级的消费者,支撑淘宝天猫前后端各种行业的基础业务、玩法、规则及业务拓展。这里有巨大的挑战等着你来,若有兴趣可将简历发至lican.lc@alibaba-inc.com,期待您的加入!

相关文章
|
7月前
|
人工智能 缓存 文字识别
在淘宝,商品技术团队每天都在干什么?
在淘宝,商品技术团队每天都在干什么?
180 0
带你读《2022技术人的百宝黑皮书》——淘宝购物车5年技术升级与沉淀(17)
带你读《2022技术人的百宝黑皮书》——淘宝购物车5年技术升级与沉淀(17)
|
双11
带你读《2022技术人的百宝黑皮书》——淘宝购物车5年技术升级与沉淀(5)
带你读《2022技术人的百宝黑皮书》——淘宝购物车5年技术升级与沉淀(5)
|
算法 UED
带你读《2022技术人的百宝黑皮书》——淘宝购物车5年技术升级与沉淀(15)
带你读《2022技术人的百宝黑皮书》——淘宝购物车5年技术升级与沉淀(15)
|
双11
带你读《2022技术人的百宝黑皮书》——淘宝购物车5年技术升级与沉淀(11)
带你读《2022技术人的百宝黑皮书》——淘宝购物车5年技术升级与沉淀(11)
带你读《2022技术人的百宝黑皮书》——淘宝购物车5年技术升级与沉淀(12)
带你读《2022技术人的百宝黑皮书》——淘宝购物车5年技术升级与沉淀(12)
|
缓存 监控 安全
天猫淘宝卡券包演进史
卡券包整体分为PC端以及无线端两大部分,最开始的卡券包是PC版,随着PC向无线化转型的大潮,无线端卡券包也同步产生。
313 0
天猫淘宝卡券包演进史
|
存储 算法 数据挖掘
淘宝购物车5年技术升级与沉淀 上
淘宝购物车5年技术升级与沉淀
696 0
|
移动开发 weex 双11
淘宝购物车5年技术升级与沉淀 中
淘宝购物车5年技术升级与沉淀
455 0
|
存储 机器学习/深度学习 分布式计算