当前位置：首页 > news >正文

读书笔记：淘宝十年产品与技术演进史

news 来源：原创 2025/7/7 3:44:09

作者：大淘宝技术

原文地址：读书笔记：淘宝十年产品与技术演进史

本文是对《淘宝十年产品事》与《淘宝技术这十年》两本书的阅读笔记总结。通过回顾淘宝过去十年在产品、技术、架构、中间件及开放平台等方面的发展历程，展现了其从初期到成熟阶段所经历的关键决策、问题解决策略以及创新设计。文章不仅梳理了淘宝在电商生态中的角色演变，还深入探讨了业务与技术之间的相互驱动关系。通过对历史的探究，我们得以了解前人的智慧与经验，为未来的发展提供启示与借鉴。

前言

“考古”是一个很有意思的事情，因为可以通过一些材料，去回想当时人们的生活环境，遇到的问题，以及如何解决，可以了解前人的智慧，汲取力量。产品、技术上的考古也是如此，我们的“大厦”并非一蹴而就，对历史的探究，其实也在探寻：是什么力量在驱动我们前行？我们的初心和使命到底是什么？本文就是对淘宝前十年故事的两本书的阅读笔记，期望能够进入前人的问题域，了解他们的思考，获得进一步的启迪。

《淘宝十年产品事》

▐ 序

最近读了《淘宝十年产品事》这本书，感觉还是很有触动的，没想到2013的时候淘宝对电商的理解和对市场的认知就很有沉淀和故事了。

现在在复杂的电商生态中看不到破局的思路，但是和之前的产品快照联系起来后，才发现大盘可能早已确定，我们都是在各个细分市场、各个生态位浮浮沉沉、反反复复，令人思绪万千。

▐ 整体视角

一个买家的淘宝之旅如下所示：

营销基本模块如下图所示：

交易平台化架构如下图所示：

▐ 基础概念

淘宝用户越来越多，流量也越来越大，需要精耕细作。这些变化产生了导购产品的分类：

第一是首页类产品，如淘宝首页、各种垂直市场首页（又分纵向和横向的全球购、二手等）。
第二是营销类产品，有长期的频道，如天天特价、淘金币。
第三是社区类产品，如早期的论坛、爱逛街、U站等。

商品相关的一些概念：

SPU：相当于标准化的产品，通过关键属性确定，就确定一个SPU，苹果的iPhone5S 就是一个SPU。
第商品：与SPU区别在于与卖家有关，如果是独立的B2C，一个SPU不存在多个卖家的情况，直接分成SKU就可以了。
SKU：Stock Keeping Unit，库存量单位，可理解为“最小购买单位”。

类目属性的细分：

关键属性：像服装的话，品牌和货号，这两个属性值组合起来，能够形成唯一确定的产品——SPU。苹果的iPhone5S 就是一个SPU。
销售属性：认为 iPhone5S 不管是白的还是黑的，因为跟 SPU 只是一个属性上的差别，而不是本质上的差别，所以就没有把它们当作两个SPU。颜色、尺码等，就成了现在的销售属性。
商品属性：有一些属性，比如新旧程度、保修方式、附加服务等，跟SKU、SPU都没有关系，和卖家有点关系。

淘宝搜索的首要目标就是：让用户尽可能地找到适合自己需求的商品，它也是一种典型的导购产品。

DSR动态评分‌（Detail Seller Rating）是电商平台上的一种评价体系，主要用于评估卖家在宝贝与描述相符、卖家的服务态度、物流服务质量等方面的表现。

广告的一些模式：

CPT（Cost Per Time），即一种以时间来计费的广告。
CPM（Cost Per Thousand Impression），按照展示次数付费。
CPC（Cost Per Click），根据广告被点击次数收费。
CPS（Cost Per Sales），以实际销售产品数量来计算广告费用。

电商生态角色：

淘客站：通过简单的导购，把访客引导到特定商品的站点，类似导航站，其自身需要有较大的流量，利用流量到销量的转化，赚取“雁过拔毛”的淘客佣金。
淘品牌：从淘宝开店的零售商做起，做大了以后，不满足于买别人的货了，因为在货源、定价、同质竞争方面都受到牵制，所以开始自建品牌，可以自己定价、做营销。
代运营：主要是指帮助一些希望做电商的传统企业开展网上销售的公司。
天猫旗舰店：商家以自有品牌（商品为R或TM状态）入驻天猫开设的店铺，类似于线下的品牌直营店。
天猫专卖店：商家持品牌授权文件在天猫开设的店铺，类似于线下的品牌加盟专卖店。
天猫转营店：经营天猫同一招商大类下两个及以上品牌商品的店铺，类似于线下的小型、多品牌、专业卖场。
独立B2C：比较像线下的百货公司，传统的大型零售商，卖很多品牌的商品，全链路自己控制较多，从选品、进货、仓储、推广、销售、发货到服务等，各个环节都做。
B2C平台：类似商业地产，万象城是类似模式。平台方提供场地、各种经营服务，零售商入驻开店，天猫就是典型的B2C平台。
C2C平台：类似实体经济的夜市、跳闸市场，商品种类极其丰富，淘宝最早就是一个纯粹的C2C平台。
......

聚划算的生长打破了淘宝既有的环境特点：

第一，淘宝一直以来都不主张推单品单店。
第二，淘宝的类目是垂直化运营的，而团购的商品丰富度是需要跨类目来解决的。

阿里集团参谋长曾鸣认为，电子商务未来如果用一个词概括，就叫C2B，未来的商业模式是以消费者为中心的大规模定制的模式，不是B2C。

购物车是非常有必要的，有了购物车，才有“订单”的概念；否则一个商品就一条交易。毫不夸张地说，没有购物车，就没有营销工具团队。没有购物车的时候，卖家们一个商品一个交易，很难促销。打折不是促销，而是立减。买家很少会因为单纯打折额外购买其他东西，而促销是为了促进买家买更多的东西。有了购物车，可以多个商品合并订单，于是就可以做“满就减、满就送”、“搭配套餐”...... 空间突然打开了。

库存扣减模式如下：

拍下减库存：

好处：可以提前锁定库存。
坏处：有人恶意占用库存，其他人无法购买。

付款减库存：

好处：可以确保购买意愿。
坏处：出现超卖，付款时可能被告知缺货，让卖家恼火。

拍卖模式的三个特点：

拍卖必须要两个以上的买主；
拍卖必须有不断变动的价格；
拍卖必须有公开竞争的行为。

▐ 问题案例

好的问题更让人深思，知道如何更好前进，下面是书中提到的一些问题案例：

主题	问题	解决方案
类目/属性	商品数量众多，如何分类	出现多级类目，形成一棵类目树
类目/属性	商品越来越多，类目树越来越深，越来越难找	通过类目+属性来解决
类目/属性	相同概念的属性，数据库的属性值ID可能不一，同一个品牌格式也不一样	进行属性的归一，同时采用中性化手段，如将品牌的输入让一个小二统一管理
类目/属性	小二处于导购运营需求不断调整类目属性，商家需要频繁跟着填写商品属性	按照用户群体拆分，卖家通过后台类目发布商品，买家通过前台类目选择商品
商品	商品发布需要挂在SPU上，没有SPU或者找不到的时候，会中断商品SPU流程，先去发布SPU。影响卖家发布效率。	判断是否有SPU，没有就自动挂一个。从严还是从宽的问题。
搜索	开始按下架时间排序，期望规则固定公平。但是有商家开始利用规则进行重复上下架，来提升搜索。	开始把“公平vs效率”的天平向右侧倾斜，推出了“橱窗推荐”。借助每个卖家帮忙筛选优质商品。
搜索	线上有很多线下难以披露的数据，但是没有很好利用起来，如：历史销量、浏览量、评价。不利用起来，就难以降低买家的挑选成本。	搜索建设“人气排序”，转化率高、销量高的优质宝贝更容易排名靠前，获得更多的流量。
搜索	“人气排序”会形成马太效应，让大卖家占据较大流量，小商家没有什么机会。同时也很造成商品覆盖率低。影响整个生态。	提出“阿基米德”，主要有两个特点：一是将人气排序和时间轮播结合起来；另一个是增加卖家服务质量的因素。
搜索	“阿基米德”第一版借助机器学习，可以保证数据效果，但是难以解释。难以解释，商家就不知道该如何优化。	上线“规则版”排序，把因素明确出来，让排序做到可解释、可指导卖家向哪个方向努力。
搜索	商家为了匹配流量，会刷销量、标题滥用、类目放错等，而且手段多样。	反作弊团队从处理商品到处理卖家。提出了卖家质量分的概念。
搜索	标品在选择的时候，既要选择型号，也要选择卖家，比较纠结。	将标品的导购过程拆分为：“先选产品（SPU），再选卖家”，是一淘网的雏形。
搜索	搜索结果比较固定，难以匹配用户精准需求。	进行用户细分、商品/卖家细分，提供搜索的精细化和个性化能力。重要的是建设丰富、准确的商品特征库，搜索自己做不完，依赖生态系统。
广告	招财进宝项目，将影响搜索结果，相当于做广告。引起商家不满，大规模抗议。	当时决定不能因小失大，不要急于商业化。
商业	预售商品，需要避免卖家提前虚假发货，引起系统默认收货，以致卖家骗钱成功。	做一些定制，比如在约定发货时间提前三天才能发货。
商业	最初淘宝学eBay，买家与卖家直接交易，但是国内骗子较多，会有：买家打钱卖家不发货，卖家提前发货后买家不付钱的情况。	提供“担保交易”这种第三方托管资金的办法。
商业	当时商品系统在淘宝，交易系统在支付宝。用户从导购到下单的过程中，页面风格不停变换。	把交易功能拿回淘宝，支付宝专心做支付。
商业	当时宝贝只能卖一个价格，宝贝修改了之后，之前订单的价格也会受到影响。	引入了“宝贝快照”。
交易	商品只能单件购买的时候，如果购买五件宝贝，可能发一个包裹，运费模版就没有意义了，往往需要卖家改邮费。	解决的策略是增加购物车，让多个商品可以合并下单，也就有了真正的“订单”，同时可以玩各种促销了。
营销	最早，卖家想做促销，往往有几种方式：1）详情提示买家联系卖家改价；2）卖家直接修改“一口价”价格；3）发布新的宝贝，把链接给买家下单。这些方式都很“人肉”。	提供了第一代营销工具，上线了“满就减”、“搭配减价”、“限时打折”等能力。
营销	卖家需对会员有精准营销的诉求	做了ecrm的个性化项目——图腾，开启卖家个性化营销时代。
营销	需要解决卖家长尾需求，深入垂直市场，玩法层出不穷，产品和研发望洋兴叹。	采用平台化思路，放弃控制，众包，大家一起来共建。诞生了营销平台。
交易	买家“恶拍”，其他人无法购买。	1）增加付款超时时间；2）限制购买。
交易	付款减库存可能造成“超卖”，卖家被投诉。	1）付款流程过程增加校验；2）导购页面增加提示；3）设置安全库存。
交易	早期虚拟交易需要卖家填写充值码，这样很容易被盗，而且卖家运营效率有限。	充值让渠道商基于 API 接口自动化完成。
交易	拍卖过程中可能出现买家恶拍；卖家恶意太高价格的场景。	增加拍卖保证金。
交易	卖家为了抢流量，将商品价格设置很低（如1元），但是运费很高（如50元），从而获得流量，实际价格并不低。	增加业务策略“拍卖宝贝包邮”。
交易	交易形态越来越多，交易线产品支持得很辛苦。	进行交易平台化，即将交易拆分为三种对象：交易规则库（规则）、交易接口库（操作）、页面/流程定制库（信息）。
交易	售后保障是整个消费者服务的症结，比如假一赔三服务，平台缺少鉴定能力。	尝试引入第三方专业的鉴定公司。
评价	早期，拍下后就可以评价，有很多卖家注册买家账户刷评价。	改成在交易成功后15天内可以互相评价。
申诉	早期，买卖家产生纠纷后，只能打电话进线。	后面建设申诉产品，虽然成本很高，但是它能够感受用户在真实交易过程中遇到的麻烦，来找到究竟什么阻碍了用户价值的增长。
旺旺	垃圾消息一直是旺旺发展过程中一个挥之不去的阴影	采用离线系统、准实时系统和在线系统三个解决方案

《淘宝技术这十年》

▐ 序

在读了《淘宝十年产品事》这本书之后，又读了一下《淘宝技术这十年》这本书。感觉技术的发展，虽然是业务驱动，但底层更多的是“量级”驱动，也就是核心业务的发展驱动。这两本书结合起来看，感觉技术和业务的关系是很微妙，在重要节点上是相互制约和相互发展的关系。

本文就是《淘宝技术这十年》的一些笔记。

▐ 系统架构演进

本文就是《淘宝技术这十年》的一些笔记。

1.0 版本

2003年5月 - 2004年1月

LAMP 架构的网站：Linux + Apache + MySQL + PHP。淘宝早期系统架构如下图所示。其中，pear DB 是一个PHP模块，复杂数据访问层。

淘宝早期网站架构

1.1 版本

2004年1月 - 2004年5月

由于数据量增大，Mysql 逐渐替换为 Oracle。因为 Oracle 容量大、稳定、安全、性能高，还有人才储备。PHP 语言需要解决数据库链接问题，因此架构中引入了 SQL Realy 组件，这是一个开源的可以提供连接池代理服务的组件。

数据库从mysql到Oracle

2.0 版本

2004年2月 - 2005年3月

为了解决数据库链接的问题，更好地使用Oracle数据库，需要进一步切换编程语言。同时，Java是当时最成熟的开发框架，人才较多，后续维护成本也很低。整体的架构开始切换为以Java语言为主。其中MVC框架是阿里的WebX，控制层用了 EJB，未来环境查询压力，引入了搜索引擎。

语言从PHP到Java

2.1版本

2004年10月 - 2007年1月

在业务发展的过程中，进行了数据分库、放弃EJB、引入Spring、加入缓存、加入CDN等工作，形成了进一步优化的架构。

进一步优化的架构

TFS之后版本

为了解决大量小文件的存储问题、查询性能问题，创造了 TFS 和 Tair ，之后整个系统的架构如下图所示。

引入TFS之后的架构

2.2.6 系统拆分

到 2008 年初，整个主站系统（有了机票、彩票系统之后，把原来的系统叫做主站）的容量已经到了瓶颈，商品数在一个亿以上，PV在2.5亿个以上，会员超过了5000万个。这时 Oracle 的连接池数量都不够用了，数据库的容量到了极限，即使上层系统加机器也无法继续扩容，只有把底层的基础服务继续拆分，从底层开始扩容，上层才能扩展，才能容纳以后三五年的增长。

整个项目名称为“五彩石”（女娲炼石补天用的石头），这是继2004年从LAMP架构到Java架构之后的第二次脱胎换骨。

基础业务服务包括：

UIC：用户信息中心（User Information Center）
Forest：类目属性服务（森林，与类目属性有点神似）

其中核心业务系统的名词如下，这些中心级别的服务只提供原子级的业务逻辑，如根据ID查找商品、创建交易、减少库存等操作：

TC：交易中心（Trade Center）
IC：商品中心（Item Center）
SC：店铺中心（Shop Center）

再往上一层是业务系统：

TM：交易业务（Trade Manager）
IM：商品业务（Item Manager）
SM：店铺业务（Shop Manager，后来改名叫 SS，即 Shop System）
Detail：商品详情

系统拆分后的架构

系统拆分后，系统交互就变得比较复杂了，具体如下图所示。这进一步推动了事实调用中间件 HSF、异步消息中间件 Notify、多系统会话中间件 Session 等中间件的发展。

系统拆分后的系统关系

▐ 中间件发展

淘宝文件系统-TFS

时间	问题背景	解决方案
2007年前	淘宝有很多文件要存储，如图片、商品描述、交易快照，这些文件读取需要频繁寻道和换道，读取延迟延时较高	采用商用存储系统，应用 NetApp 公司的文件存储系统
2007年	淘宝网的图片文件数量以每年3倍的速度增长，NetAPP公司的文件存储系统难以满足淘宝发展	借鉴GFS（Google File System）的设计论文，开发出了淘宝文件存储系统（TaoBao File System, TFS）的1.0版本
2009年	持续优化，如：改善心跳和同步的性能，对元数据存储和清理磁盘空间也做了优化	形成了 TFS 1.3版本

淘宝KV 缓存系统-Tair

时间	问题背景	解决方案
2004年	需要解决页面端静态片段的缓存	使用了 ESI（Edge Side Includes）的缓存（Cache）
	需要解决一些动态数据的缓存，如浏览量，是否可以从内存里面取？	提供了一个基于 Berkeley DB 的缓存系统，叫 TBstore。
2007年	独立了用户中心 UIC（User Information Center），用户访问 UIC 量级很高，需要使用缓存	为 UIC 写了缓存系统 TDBM，TDBM 抛弃了 Berkeley DB 的持久功能，数据全部存放在内存中。
2009年	内存利用率和吞吐量上可以进一步提升	参考了 memcached 的内存结构，改进了 TDBM 的集群分布方式，推出了 TDBM 2.0。
	TDBM、TBstore 的数据接口和用途都很相似	开发团队把二者合并，推出了淘宝自创的 Key-value 缓存系统 -- Tair（TaoBao Pair 的意思，Pair 即 Key-Value 数据对）

高性能服务框架 HSF

时间	问题背景	解决方案
2008年左右	原来同步服务很多，有Jar包模式、Hessian接口、WebService、Socket、甚至HTTP请求等。系统拆分之后，系统越来越多，系统之间需要提供统一的同步服务	建设统一的同步服务 HSF（High-Speed Service Framework）。HSF 是一个分布式的标准 Service 方式的 RPC 框架。

消息中间件 Notify

时间	问题背景	解决方案
2005年	支付宝和银行之间交互，有时需要通过异步通知进行，但是消息很难保证不丢失、也很容易重复通知。	使用 MQ（Message Queue）的方式来解决这个问题，并通过存放数据库来保证消费需求
2008年左右	系统拆分之后，系统间也需要异步通知。消息量级整体又增加了一个层次，需要更强大的消息中间件。	建设消息中间件 Notify。Notify 是一个分布式的消息中间件系统，支持消息的订阅、发送和消费。

分布式数据访问层 TDDL

时间	问题背景	解决方案
早期	商品库切分的时候，就需要提供统一访问能力	基于 ibatis 进行很浅的封装，形成 CommonDAO 的组件
2009年左右	Oracle 成本较高，需要对一部分数据使用 MySQL，需要对外提供统一数据访问。	建设 TDDL 1.0 版本（Taobao Distributed Data layer）,有人取外号“头都大了”
	随着TDDL的业务越来越多，TDDL开始进入“评价”、“商品”等核心业务。	完善异构数据源增量复制、解决容量压力测试等问题，形成TDDL 2.0 时代。
	进入“交易”后，一些功能受到业务挑战“不需要的功能为什么要放到流程里”？	产生了TDDL 3.0 版本：将代码逻辑进行了节分，将单机主备切换、数据源管理独立出来。同时开始做工具，数据库运维平台的组件被提了出来。
2013年左右	建设更多的数据工具来提效	进入工具平台时代：建设了“愚公”数据迁移平台；以内部开源方式提出了“精卫”数据增量复制平台。

Seesion 框架

时间	问题背景	解决方案
	客户端与服务端交互需要保持会话。Http协议本身是无状态的，需要通过 Session 来解决服务端和浏览器保持状态的述求。	早期使用 Cookie
	Cookie 带来了流量传输成本，网络流量成本越来越高。	采用了集中式的缓存区Session。发展为 Tbsession，解决 Session 的这些问题：1）客户端存储；2）服务端存储；3）配置统一管理；4）动态更新

▐ 开放平台

2006年底，阿里巴巴提出了 Work at Alibaba 的战略，要为中小企业提供一个工作平台。工作平台需要是一个开放的平台，因为卖家需要是长尾的。因此，需要做一个支持二次开发的工作平台，半开放式地满足卖家的长尾管理需求。

时间	主题	主要内容
2006年	起点	开始做原型
2007年	萌芽	SOA 盛行的年代，内部架构服务化成为开放的第一步，如：淘宝的HSF（OSGI）。
2008年	雏形	平台开放淘宝服务30个，主要解决三个问题：1）服务路由；2）服务接口标准化；3）授权。
2009年	产品化	平台开放服务100多个，卖家工具成为服务市场的主流。主要基于性能问题牵引，提供更好的技术方案。
2010年	平台化	开放服务300多个，SNS热潮的兴起带动了淘江湖的买家应用。API 的开放包装由开放平台交还给业务自身，平台提供更快的接入能力。同时需要考虑资源的使用隔离。
2011年	市场化	开放服务758个，营销工具崭露头角，淘宝客成为开放新宠。开始重点考虑开放的安全性。
2012年	垂直化	平台开放淘宝服务900多个，无线乘势而起。业务开始主动要开放，开放后开始运营服务，培育ISV市场。平台侧开始建设 JS SDK 和无线 SDK（IOS，安卓）；同时启动“聚石塔”项目，提供弹性计算和存储能力及可靠的安全网络环境给 ISV。

总结

我们现在很多日常的讨论可能还会出现在本文的问题列表中，可见“解决的策略”是可以不断被打磨完善的，同时方案也会受到市场的变化而反反复复，在曲折中前进。

在这个过程中，业务和技术是什么关系呢？从关键节点的角度看，我感觉是两朵大浪在双向奔赴，在某个交织点进行碰撞形成融合，然后各自回落再次蓄能。而这个势能则来源于重要的业务变化，背后是在满足市场需求的过程中，产生了累加的创造性的设计，形成了新的模式。

总的来说，历史已过，未来还在书写，如何吸收好这些前人策略，走好未来的路，还取决于大家的思考，路在大家的脚下。但是，隐约中，感觉有一股传承之流在流淌~

淘宝文件系统-TFS

淘宝KV 缓存系统-Tair

高性能服务框架 HSF

消息中间件 Notify

分布式数据访问层 TDDL

相关文章：