淘宝技术架构

淘宝团队架构1组织架构（一）淘宝店长1、负责网店整体规划、营销、推广、客户关系管理等系统经营性工作；2、负责网店日常改版策划、上架、推广、销售、售后服务等经营与管理工作;3、负责网店日常维护，保证网店的正常运作，优化店铺及商品排名；4、负责执行与配合公司相关营销活动，策划店铺促销活动方案；5、负责收集市场和行业信息，提供有效应对方案；6、制定销售计划，带领团队完成销售业绩目标；7、客户关系维护，处理相关客户投诉及纠纷问题。

（二）客服人员（前期招两名）工作职责：1.通过聊天软件，耐心回答客户提出各种问题，达成双方愉快交易，处理订货信息2.熟悉淘宝的各种操作规则，处理客户要求，修改价格，管理店铺等；3.解答顾客提问，引导顾客进行购买，促成交易。

4.为网上客户提供售后服务，并以良好的心态及时解决客户提出的问题和要求，提供售后服务并能解决一般投诉。

6.配合公司淘宝店铺和独立网站的推广宣传，在各种群和论坛发贴宣传、推广店铺；（三）网店美工（前期招一名）主要工作内容（PS合成、调色及抠图必须熟练经验要求1年以上）1•负责网络店铺视觉规划、设计，以及产品描述工作；2•负责网站产品模特后期图片的处理和排版。

应聘要求1.爱好视觉，对设计有天生的触觉。

追求完美。

2.具有网页美工设计能力和平面设计能力，一年以上的工作经验。

3.熟悉淘宝货品上架、宝贝编辑等功能；定的工作压 4. 熟悉Dreamweaver 、Photoshop 等相关设计软件5. 有良好的团队合作精神，有耐心 ，做事认真细心负责，诚实可靠，能承受6.熟练编写div/css 优先 （四）网店编辑（暂时不用，只招美工，）1、 负责网店产品上架和下架的相关工作；2、 负责网店产品的宝贝描述文字的撰写，配图文字的撰写3、 负责促销活动文案的构思和撰写；4、 负责网店产品标题的编辑和修改等；（五）产品打包员主要工作内容： 1 •按照要求对货物产品进行包装，负责发货等物流方面的事项。

浅谈淘宝类目属性体系：商品搜索背后的逻辑架构[核心提示] 淘宝拥有百万家商户和超过10亿的商品数，它如何让用户精准地找到想要的商品呢？其背后有着强大的技术支撑。

淘宝目前在线商品数超过10 亿，如何精准的帮助用户找到他想要的商品呢？经过多年的探索，淘宝通过建立一套完整的类目属性体系，终于较好的解决了这一问题，今天就跟大家一起来谈谈淘宝的类目属性体系。

一点点历史和架构2003 年淘宝刚上线时，商品量很少，没有分类。

后来，商品量上百，开始有了对商品进行单级分类，有点类似于现在的一级行业类目。

等到商品上万的时候，商品的单级分类已经不能满足需求，开始有了多级分类，就是一颗类目树了。

从06 年开始引入了属性，商家按照属性模板填写属性，用户可以按照属性筛选商品。

到了08 年，开始将前后台类目分开，用户根据前台类目筛选商品，商家将商品挂到后台类目上，前后台类目树之间建立好映射。

今天的淘宝类目属性体系主要由后台类目树、前台类目树、挂载在后来叶子类目上的商品属性模板以及管理前后台类目之间映射关系的类目管理平台组成，整体架构如下：从图中可以看出，淘宝类目属性体系是一个非常基础的数据服务，在商品发布页上商家选择后台类目上传商品信息，详情页上以面包屑的方式给用户显示商品所属的前台类目，在搜索结果页上让用户根据前台类目筛选商品。

运营同学可以通过一个管理后台来管理前后台类目之间的映射关系以及后台类目的属性模板。

后台类目后台类目面向商家，主要用于商品的分类和属性管理。

商家上传商品时见到的就是后台类目，如下图：后台类目有如下特点：后台类目树中最重要的是叶子类目，也就是类目树上不能再往下分的类目,任何商品都必须挂载到后台叶子类目上。

叶子类目挂载属性模版，商家发布商品时选择好类目之后会根据属性模版，补充必填的商品属性信息，方可成功上传商品。

后台类目相对稳定，不能随便删除，叶子类目不能重复。

前台类目前台分类面向用户，方便用户筛选查找商品，大部分时候用户见到的类目都是前台类目。

网店组织架构图(一)运营总监1、负责网店整体规划、营销、推广、客户关系管理等系统经营性工作;2、负责网店日常改版策划、上架、推广、销售、售后服务等经营与管理工作;3、负责网店日常维护,保证网店的正常运作,优化店铺及商品排名;4、负责执行与配合公司相关营销活动,策划店铺促销活动方案;5、负责收集市场与行业信息,提供有效应对方案;6、制定销售计划,带领团队完成销售业绩目标;7、客户关系维护,处理相关客户投诉及纠纷问题。

(二)运营总监助理1、负责协助运营总监完成工作;2、负责其主要论坛的优化工作;3、负责对每天销售的货品的数据分析;4、负责网店的帮派沟通协调工作。

(三)客服人员1、通过在线聊天工具,负责在淘宝上与顾客沟通,解答顾客对产品与购买服务的疑问;2、产品数据在线维护管理,登陆销售系统内部处理定单的完成,制作快递单,整理货物等;3、客户关系维护工作,在线沟通解答顾客咨询,引导用户在商城上顺利的购买,促成交易;4、负责客户疑难订单的追踪与查件,处理评价、投诉等。

(四)配送人员1、负责网店备货与物资的验收、入库、码放、保管、盘点、对账等工作;2、负责保持仓库内货品与环境的清洁、整齐与卫生工作;3、按发货单正确执行商品包装工作,准时准确完成包装任务;4、准确在网店后台输入发货单号,更改发货状态,对问题件能及时处理。

(五) 财务人员1、负责网店销售与资金到账的管理;2、负责网店与快递公司业务费用的管理;3、负责网店日常运营财务方面的处理;(六)网店美工1、负责网店产品上传宝贝的文字编辑及上传宝贝的相关工作,图片拍摄制作。

2、根据主题需要完成店铺进行整体的美化(公告栏与促销栏图片设计)。

3、根据文字需求完成网页平面设计,完成网页html编辑。

4、产品拍摄图片的美化、编辑排版;(七)策划1、负责不定期策划淘宝商城营销活动;2、负责产品的文案描述。

3、策划并制定网络店铺及产品推广方案(包括淘宝推广、SEO、论坛推广、博客营销、旺旺推广等)等营销工作;4、研究竞争对手的推广方案,向运营经理提出推广建议;5、负责对店铺与标题关键字策略优化、橱窗推荐、搜索引擎营销、淘宝直通车、淘宝客等推广工作。

淘宝技术架构演进之路1. 概述本⽂以淘宝作为例⼦，介绍从⼀百个到千万级并发情况下服务端的架构的演进过程，同时列举出每个演进阶段会遇到的相关技术，让⼤家对架构的演进有⼀个整体的认知，⽂章最后汇总了⼀些架构设计的原则。

特别说明：本⽂以淘宝为例仅仅是为了便于说明演进过程可能遇到的问题，并⾮是淘宝真正的技术演进路径2. 基本概念在介绍架构之前，为了避免部分读者对架构设计中的⼀些概念不了解，下⾯对⼏个最基础的概念进⾏介绍：分布式系统中的多个模块在不同服务器上部署，即可称为分布式系统，如Tomcat和数据库分别部署在不同的服务器上，或两个相同功能的Tomcat分别部署在不同服务器上⾼可⽤系统中部分节点失效时，其他节点能够接替它继续提供服务，则可认为系统具有⾼可⽤性集群⼀个特定领域的软件部署在多台服务器上并作为⼀个整体提供⼀类服务，这个整体称为集群。

如Zookeeper中的Master和Slave分别部署在多台服务器上，共同组成⼀个整体提供集中配置服务。

在常见的集群中，客户端往往能够连接任意⼀个节点获得服务，并且当集群中⼀个节点掉线时，其他节点往往能够⾃动的接替它继续提供服务，这时候说明集群具有⾼可⽤性负载均衡请求发送到系统时，通过某些⽅式把请求均匀分发到多个节点上，使系统中每个节点能够均匀的处理请求负载，则可认为系统是负载均衡的正向代理和反向代理系统内部要访问外部⽹络时，统⼀通过⼀个代理服务器把请求转发出去，在外部⽹络看来就是代理服务器发起的访问，此时代理服务器实现的是正向代理；当外部请求进⼊系统时，代理服务器把该请求转发到系统中的某台服务器上，对外部请求来说，与之交互的只有代理服务器，此时代理服务器实现的是反向代理。

简单来说，正向代理是代理服务器代替系统内部来访问外部⽹络的过程，反向代理是外部请求访问系统时通过代理服务器转发到内部服务器的过程。

3. 架构演进3.1 单机架构以淘宝作为例⼦。

在⽹站最初时，应⽤数量与⽤户数都较少，可以把Tomcat和数据库部署在同⼀台服务器上。

本文侧重介绍淘宝网后台的图片存储系统架构、包括TFS 集群文件系统，以及前端处理服务器架构。

解决海量并发小文件的系统噩梦对于淘宝网这类型访问量极高的电子交易网站来说，对图片系统的要求和日常的照片分享完全不在一个级别。

日常照片分享往往集中在几个有限的亲朋好友之间，访问量不会特别高，而淘宝网商铺中的商品照片，尤其是热门商品，图片的访问流量其实是非常大的。

而且对于卖家来说，图片远胜于文字描述，因此卖家也格外看重图片的显示质量、上传时间、访问速度等等问题。

根据淘宝网的流量分析，整个淘宝网流量中，图片的访问流量会占到90%以上，而主站的网页则占到不到10%。

淘宝网电子商城首页截图，淘宝网的后端系统上保存着286亿多个图片文件，淘宝网整体流量中，图片的访问流量要占到90%以上。

且这些图片平均大小为17.45KB，小于8K的图片占整体图片数量61%，整体系统容量的11%与此同时，这些图片的存储与读取还有一些头疼的要求：例如，这些图片要求根据不同的应用位置，生成不同大小规格的缩略图。

考虑到多种不同的应用场景以及改版的可能性，一张原图有可能需要生成20多个不同尺寸规格的缩略图。

淘宝整体图片存储系统容量1800TB（1.8PB），已经占用空间990TB（约1PB）。

保存的图片文件数量达到286亿多个，这些图片文件包括根据原图生成的缩略图。

平均图片大小是17.45K；8K以下图片占图片数总量的61%，占存储容量的11%。

这就给淘宝网的系统带来了一个巨大的挑战，众所周知，对于大多数系统来说，最头疼的就是大规模的小文件存储与读取，因为磁头需要频繁的寻道和换道，因此在读取上容易带来较长的延时。

在大量高并发访问量的情况下，简直就是系统的噩梦。

分析自主研发和商用系统的经济效益淘宝网成立于2003年，在整个系统的构建和规划上也做过相当多的尝试和探索。

下图是淘宝网2007年之前的图片存储系统。

淘宝网之前一直采用的商用存储系统，应用NetApp公司的文件存储系统。

电子商务网站（淘宝网）的系统架构解析淘宝网，是一个在线商品数量突破一亿，日均成交额超过两亿元人民币，注册用户接近八千万的大型电子商务网站，是亚洲最大的购物网站。

那么对于淘宝网这样大规模的一个网站，我猜想大家一定会非常关心整个网站都采用了什么样的技术、产品和架构，也会很想了解在淘宝网中是否采用了开源的软件或者是完全采用的商业软件。

那么下面我就简单的介绍一下淘宝网中应用的开源软件。

对于规模稍大的网站来说，其IT必然是一个服务器集群来提供网站服务，数据库也必然要和应用服务分开，有单独的数据库服务器。

对于像淘宝网这样规模的网站而言，就是应用也分成很多组。

那么下面，我就从应用服务器操作系统、应用服务器软件、Web Server、数据库、开发框架等几个方面来介绍一下淘宝网中开源软件的应用。

操作系统我们首先就从应用服务器的操作系统说起。

一个应用服务器，从软件的角度来说他的最底层首先是操作系统。

要先选择操作系统，然后才是操作系统基础上的应用软件。

在淘宝网，我们的应用服务器上采用的是Linux操作系统。

Linux操作系统从1991年第一次正式被公布到现在已¾¬走过了十七个年头，在PC Server上有广泛的应用。

硬件上我们选择PC Server而不是小型机，那么Server的操作系统供我们选择的一般也就是Linux，FreeBSD,windows2000 Server或者Windows Server2003。

如果不准备采用微软的一系列产品构建应用，并且有能力维护Linux或者FreeBSD，再加上成本的考虑，那么还是应该在Linux和FreeBSD之间进行选择。

可以说，现在Linux和FreeBSD这两个系统难分伯仲，很难说哪个一定比另外一个要优秀很多、能够全面的超越对手，应该是各有所长。

那么在选择的时候有一个因素就是企业的技术人员对于哪种系统更加的熟悉，这个熟悉一方面是系统管理方面，另外一方面是对于内核的熟悉，对内核的熟悉对于性能调优和对操作系统进行定制剪裁会有很大的帮助。

淘宝应对双"11"的技术架构分析双“11”最热门的话题是TB，最近正好和阿里的一个朋友聊淘宝的技术架构，发现很多有意思的地方，分享一下他们的解析资料：淘宝海量数据产品技术架构数据产品的一个最大特点是数据的非实时写入，正因为如此，我们可以认为，在一定的时间段内，整个系统的数据是只读的。

这为我们设计缓存奠定了非常重要的基础。

图1淘宝海量数据产品技术架构按照数据的流向来划分，我们把淘宝数据产品的技术架构分为五层（如图1所示），分别是数据源、计算层、存储层、查询层和产品层。

位于架构顶端的是我们的数据来源层，这里有淘宝主站的用户、店铺、商品和交易等数据库，还有用户的浏览、搜索等行为日志等。

这一系列的数据是数据产品最原始的生命力所在。

在数据源层实时产生的数据，通过淘宝自主研发的数据传输组件DataX、DbSync和Timetunnel准实时地传输到一个有1500个节点的Hadoop集群上，这个集群我们称之为“云梯”，是计算层的主要组成部分。

在“云梯”上，我们每天有大约40000个作业对1.5PB的原始数据按照产品需求进行不同的MapReduce计算。

这一计算过程通常都能在凌晨两点之前完成。

相对于前端产品看到的数据，这里的计算结果很可能是一个处于中间状态的结果，这往往是在数据冗余与前端计算之间做了适当平衡的结果。

不得不提的是，一些对实效性要求很高的数据，例如针对搜索词的统计数据，我们希望能尽快推送到数据产品前端。

这种需求再采用“云梯”来计算效率将是比较低的，为此我们做了流式数据的实时计算平台，称之为“银河”。

“银河”也是一个分布式系统，它接收来自TimeTunnel的实时消息，在内存中做实时计算，并把计算结果在尽可能短的时间内刷新到NoSQL存储设备中，供前端产品调用。

容易理解，“云梯”或者“银河”并不适合直接向产品提供实时的数据查询服务。

这是因为，对于“云梯”来说，它的定位只是做离线计算的，无法支持较高的性能和并发需求；而对于“银河”而言，尽管所有的代码都掌握在我们手中，但要完整地将数据接收、实时计算、存储和查询等功能集成在一个分布式系统中，避免不了分层，最终仍然落到了目前的架构上。