淘宝网采用什么技术架构来实现网站高负载的

淘宝网采用什么技术架构来实现网站高负载的

时间:2010-09-15

时间过得很快，来淘宝已经两个月了，在这两个月的时间里，自己也感受颇深。下面就结合淘宝目前的一些底层技术框架以及自己的一些感触来说说如何构建

一个可伸缩，高性能，高可用性的分布式互联网应用。

一应用无状态（淘宝session框架）

俗话说，一个系统的伸缩性的好坏取决于应用的状态如何管理。为什么这么说呢？咱们试想一下，假如我们在session中保存了大量与客户端的状态信息的话，那么当保存状态信息的server宕机的时候，我们怎么办？通常来说，我们都是通过集群来解决这个问题，而通常所说的集群，不仅有负载均衡，更重要的是要有失效恢复failover,比如tomcat采用的集群节点广播复制，jboss采用的

配对复制等session状态复制策略，但是集群中的状态恢复也有其缺点，那就是严重影响了系统的伸缩性，系统不能通过增加更多的机器来达到良好的水平伸缩，因为集群节点间session的通信会随着节点的增多而开销增大，因此要想做到应用本身的伸缩性，我们需要保证应用的无状态性，这样集群中的各个节点来说都是相同的，从而是的系统更好的水平伸缩。

OK，上面说了无状态的重要性，那么具体如何实现无状态呢？此时一个session框架就会发挥作用了。幸运的是淘宝已经具有了此类框架。淘宝的session框架采用的是client cookie实现，主要将状态保存到了cookie里面，这样就使得应用节点本身不需要保存任何状态信息，这样在系统用户变多的时候，就可以通过增加更多的应用节点来达到水平扩展的目的.但是采用客户端cookie 的方式来保存状态也会遇到限制，比如每个cookie一般不能超过4K的大小，

同时很多浏览器都限制一个站点最多保存20个cookie.淘宝cookie框架采用

的是“多值cookie”，就是一个组合键对应多个cookie的值，这样不仅可以防止cookie数量超过20，同时还节省了cookie存储有效信息的空间，因为默认每个cookie都会有大约50个字节的元信息来描述cookie。

除了淘宝目前的session框架的实现方式以外，其实集中式session管理来完成，说具体点就是多个无状态的应用节点连接一个session 服务器，session

服务器将session保存到缓存中，session服务器后端再配有底层持久性数据源，比如数据库，文件系统等等。

二有效使用缓存（Tair）

做互联网应用的兄弟应该都清楚，缓存对于一个互联网应用是多么的重要，从浏览器缓存，反向代理缓存，页面缓存，局部页面缓存，对象缓存等等都是缓存应用的场景。

一般来说缓存根据与应用程序的远近程度不同可以分为：local

cache 和 remote cache。一般系统中要么采用local cache，要么采用remote cache,两者混合使用的话对于local cache和remote cache的数据一致性处理会变大比较麻烦.

在大部分情况下,我们所说到的缓存都是读缓存,缓存还有另外一个类型:写缓存. 对于一些读写比不高，同时对数据安全性需求不高的数据，我们可以将

其缓存起来从而减少对底层数据库的访问,比如统计商品的访问次数,统计API

的调用量等等,可以采用先写内存缓存然后延迟持久化到数据库，这样可以大

大减少对数据库的写压力。

OK，我以店铺线的系统为例，在用户浏览店铺的时候，比如店铺介绍，店铺交流区页面，店铺服务条款页面，店铺试衣间页面，以及店铺内搜索界面这些界面更新不是非常频繁，因此适合放到缓存中，这样可以大大减低DB的负载。另外宝贝详情页面相对也更新比较少，因此也适合放到缓存中来减低DB负载。

三应用拆分（HSF）

首先，在说明应用拆分之前，我们先来回顾一下一个系统从小变大的过程

中遇到的一些问题，通过这些问题我们会发现拆分对于构建一个大型系统是如何的重要。

系统刚上线初期，用户数并不多，所有的逻辑也许都是放在一个系统中的，所有逻辑跑到一个进程或者一个应用当中，这个时候因为比较用户少，系统访问量低，因此将全部的逻辑都放在一个应用未尝不可。但是，兄弟们都清楚，好景不长，随着系统用户的不断增加，系统的访问压力越来越多，同时随着系统发展，为了满足用户的需求，原有的系统需要增加新的功能进来，系统变得越来越复杂的时候，我们会发现系统变得越来越难维护，难扩展，同时系统伸缩性和可用性也会受到影响。那么这个时候我们如何解决这些问题呢？明智的办法就是拆分（这也算是一种解耦），我们需要将原来的系统根据一定的标准，比如业务相关性等分为不同的子系统，不同的系统负责不同的功能，这样切分以后，我们可以对单独的子系统进行扩展和维护，从而提高系统的扩展性和可维护性，同时我们系统的水平伸缩性scale out大大的提升了，因为我们可以有针对性的对压力大的子系统进行水平扩展而不会影响到其它的子系统，而不会像拆分以前，每次系统压力变大的时候，我们都需要对整个大系统进行伸缩，而这样的成本是比较大的，另外经过切分，子系统与子系统之间的耦合减低了，当某个子系统

暂时不可用的时候，整体系统还是可用的，从而整体系统的可用性也大大增强了。

因此一个大型的互联网应用，肯定是要经过拆分，因为只有拆分了，系统的扩展性，维护性,伸缩性，可用性才会变的更好。但是拆分也给系统带来了问题，就是子系统之间如何通信的问题，而具体的通信方式有哪些呢？一般有同步通信和异步通信，这里我们首先来说下同步通信，下面的主题“消息系统”会说到异步通信。既然需要通信，这个时候一个高性能的远程调用框架就显得非常总要啦，因此咱们淘宝也有了自己的HSF框架。

上面所说的都是拆分的好处，但是拆分以后必然的也会带来新的问题，除了刚才说的子系统通信问题外，最值得关注的问题就是系统之间的依赖关系，因为系统多了，系统的依赖关系就会变得复杂，此时就需要更好的去关注拆分标准，比如能否将一些有依赖的系统进行垂直化，使得这些系统的功能尽量的垂直，这也是目前淘宝正在做的系统垂直化，同时一定要注意系统之间的循环依赖，如果出现循环依赖一定要小心，因为这可能导致系统连锁启动失败。

OK，既然明白了拆分的重要性，我们看看随着淘宝的发展，淘宝本身是如何拆分系统的。

首先我们来看以下这个图：

从上面的图可以看出淘宝系统的一个演变过程，在这个演变的过程中，我们所说的拆分就出现V2.2和V3.0之间。在V2.2版本中，淘宝几乎所有的逻辑都放在(Denali)系统中，这样导致的问题就是系统扩展和修改非常麻烦，并且更加致命的是随着淘宝业务量的增加，如果按照V2.2的架构已经没有办法支撑以后淘宝的快速发展，因此大家决定对整个系统进行拆分，最终V3.0版本的淘宝系统架构图如下：

从上图可以看出V3.0版本的系统对整个系统进行了水平和垂直两个方向的拆分，水平方向上，按照功能分为交易，评价，用户，商品等系统，同样垂直方向上，划分为业务系统，核心业务系统以及以及基础服务，这样以来，各个系统都可以独立维护和独立的进行水平伸缩，比如交易系统可以在不影响其它系统的情况下独立的进行水平伸缩以及功能扩展。

从上面可以看出，一个大型系统要想变得可维护，可扩展，可伸缩，我们必须的对它进行拆分，拆分必然也带来系统之间如何通信以及系统之间依赖管理等问题，关于通信方面，淘宝目前独立开发了自己的高性能服务框架HSF，此框架主要解决了淘宝目前所有子系统之间的同步和异步通信（目前HSF主要用于同步场合，FutureTask方式的调用场景还比较少）。至于系统间的依赖管理，目前淘宝还做的不够好，这应该也是我们以后努力解决的问题。

四数据库拆分（TDDL）

在前面“应用拆分”主题中，我们提到了一个大型互联网应用需要进行良

好的拆分，而那里我们仅仅说了”应用级别”的拆分，其实我们的互联网应用除

了应用级别的拆分以外，还有另外一个很重要的层面就是存储如何拆分的。因此这个主题主要涉及到如何对存储系统，通常就是所说的RDBMS进行拆分。

好了，确定了这个小节的主题之后，我们回顾一下，一个互联网应用从小变大的过程中遇到的一些问题，通过遇到的问题来引出我们拆分RDBMS的重要性。

系统刚开始的时候，因为系统刚上线，用户不多，那个时候，所有的数据都放在了同一个数据库中，这个时候因为用户少压力小，一个数据库完全可以应付的了，但是随着运营那些哥们辛苦的呐喊和拼命的推广以后，突然有一天发现，oh,god,用户数量突然变多了起来，随之而来的就是数据库这哥们受不了，它终于在某一天大家都和惬意的时候挂掉啦。此时，咱们搞技术的哥们，就去看看究竟是啥原因，我们查了查以后，发现原来是数据库读取压力太大了，此时咱们都清楚是到了读写分离的时候，这个时候我们会配置一个server为master

节点，然后配几个salve节点，这样以来通过读写分离，使得读取数据的压力分摊到了不同的salve节点上面，系统终于又恢复了正常，开始正常运行了。但是好景还是不长，有一天我们发现master这哥们撑不住了，它负载老高了，汗流浃背，随时都有翘掉的风险，这个时候就需要咱们垂直分区啦（也就是所谓的分库），比如将商品信息，用户信息，交易信息分别存储到不同的数据库中，同时还可以针对商品信息的库采用master，salve模式，OK，通过分库以后，各个按照功能拆分的数据库写压力被分担到了不同的server上面，这样数据库的压力终于有恢复到正常状态。但是是不是这样，我们就可以高枕无忧了呢？NO,这个NO，不是我说的，是前辈们通过经验总结出来的，随着用户量的不断增加，你会发现系统中的某些表会变的异常庞大，比如好友关系表，店铺的参数配置表等，这个时候无论是写入还是读取这些表的数据，对数据库来说都是一个很耗费精力的事情，因此此时就需要我们进行“水平分区”了（这就是俗话说的分表，或者说sharding）.

OK,上面说了一大堆，无非就是告诉大家一个事实“数据库是系统中最不

容易scale out的一层”，一个大型的互联网应用必然会经过一个从单一DB server,到Master/salve,再到垂直分区（分库），然后再到水平分区（分表，sharding）的过程，而在这个过程中，Master/salve 以及垂直分区相对比较容易，对应用的影响也不是很大，但是分表会引起一些棘手的问题，比如不能跨越多个分区join 查询数据，如何平衡各个shards的负载等等，这个时候就需要一个通用的DAL 框架来屏蔽底层数据存储对应用逻辑的影响，使得底层数据的访问对应用透明化。

拿淘宝目前的情况来说，淘宝目前也正在从昂贵的高端存储（小型机

+ORACLE）切换到MYSQL,切换到MYSQL以后，势必会遇到垂直分区（分库）以及水平分区（Sharding）的问题，因此目前淘宝根据自己的业务特点也开发了

自己的TDDL框架，此框架主要解决了分库分表对应用的透明化以及异构数据库之间的数据复制

五异步通信（Notify）

在”远程调用框架”的介绍中,我们说了一个大型的系统为了扩展性和伸缩

性方面的需求,肯定是要进行拆分,但是拆分了以后,子系统之间如何通信就成

了我们首要的问题,在”远程调用框架”小节中,我们说了同步通信在一个大型分

布式系统中的应用,那么这一小节我们就来说说异步通信.好了,既然说到了异步

通信,那么”消息中间件”就要登场了,采用异步通信这其实也是关系到系统的

伸缩性,以及最大化的对各个子系统进行解耦.

说到异步通信，我们需要关注的一点是这里的异步一定是根据业务特点来的，一定是针对业务的异步，通常适合异步的场合是一些松耦合的通信场合，而对于本身业务上关联度比较大的业务系统之间，我们还是要采用同步通信比较靠谱。

OK,那么下一步我们说说异步能给系统带来什么样子的好处。首先我们想想，假如系统有A和B两个子系统构成，假如A和B是同步通信的话，那么要想

使得系统整体伸缩性提高必须同时对A和B进行伸缩，这就影响了对整个系统进行scale out.其次，同步调用还会影响到可用性，从数学推理的角度来说，A同步调用B，如果A可用，那么B可用，逆否命题就是如果B不可用，那么A 也不可用，这将大大影响到系统可用性，再次，系统之间异步通信以后可以大大提高系统的响应时间，使得每个请求的响应时间变短，从而提高用户体验，因此异步在提高了系统的伸缩性以及可用性的同时，也大大的增强了请求的响应时间（当然了，请求的总体处理时间也许不会变少）。

下面我们就以淘宝的业务来看看异步在淘宝的具体应用。交易系统会与很

多其它的业务系统交互，如果在一次交易过程中采用同步调用的话，这就要求要向交易成功，必须依赖的所有系统都可用，而如果采用异步通信以后，交易系统借助于消息中间件Notify和其它的系统进行了解耦，这样以来当其它的系统不可用的时候，也不会影响到某此交易，从而提高了系统的可用性。

最后，关于异步方面的讨论，我可以推荐大家一些资源：

1 . J2EE meets web2.0

2. Ebay架构特点(HPTS 2009)

六非结构化数据存储 ( TFS,NOSQL)

在一个大型的互联网应用当中，我们会发现并不是所有的数据都是结构化的，比如一些配置文件，一个用户对应的动态，以及一次交易的快照等信息，这些信息一般不适合保存到RDBMS中，它们更符合一种Key-value的结构，另外还有一类数据，数据量非常的大，但是实时性要求不高，此时这些数据也需要

通过另外的一种存储方式进行存储，另外一些静态文件，比如各个商品的图片，商品描述等信息，这些信息因为比较大，放入RDBMS会引起读取性能问题，从而影响到其它的数据读取性能，因此这些信息也需要和其它信息分开存储，而一般的互联网应用系统都会选择把这些信息保存到分布式文件系统中，因此淘宝目前也开发了自己的分布式文件系统TFS，TFS目前限制了文件大小为2M，适合于一些小于2M数据的存放。

随着互联网的发展，业界从08年下半年开始逐渐流行了一个概念就是NOSQL。我们都知道根据CAP理论，一致性，可用性和分区容错性3者不能同时满足，最多只能同时满足两个，我们传统的关系数据采用了ACID的事务策略，而ACID的事务策略更加讲究的是一种高一致性而降低了可用性的需求，但是互联网应用往往对可用性的要求要略高于一致性的需求，这个时候我们就需要避免采用数据的ACID事务策略，转而采用BASE事务策略，BASE事务策略是基本可用性，事务软状态以及最终一致性的缩写，通过BASE事务策略，我们可以通过最终一致性来提升系统的可用性，这也是目前很多NOSQL产品所采用的策略，包括facebook 的cassandra,apache hbase,google bigtable等，这些产品非常适合一些非结构化的数据，比如key-value形式的数据存储，并且这些产品有个很好的优点就是水平伸缩性。目前淘宝也在研究和使用一些成熟的NOSQL产品。

七监控、预警系统

对于大型的系统来说，唯一可靠的就是系统的各个部分是不可靠。

因为一个大型的分布式系统中势必会涉及到各种各样的设备，比如网络交换机，普通PC机，各种型号的网卡，硬盘，内存等等，而这些东东都在数量非常多的时候，出现错误的概率也会变大，因此我们需要时时刻刻监控系统的状态，而监控也有粒度的粗细之分，粒度粗一点的话，我们需要对整个应用系统进行监控，比如目前的系统网络流量是多少，内存利用率是多少，IO，CPU的负载

是多少，服务的访问压力是多少，服务的响应时间是多少等这一系列的监控，而细粒度一点的话，我们就需对比如应用中的某个功能，某个URL的访问量是多，每个页面的PV是多少，页面每天占用的带宽是多少，页面渲染时间是多少，静态资源比如图片每天占用的带宽是多少等等进行进一步细粒度的监控。因此一个监控系统就变得必不可少了。

前面说了一个监控系统的重要性，有了监控系统以后，更重要的是要和预警系统结合起来，比如当某个页面访问量增多的时候，系统能自动预警，某台Server 的CPU和内存占用率突然变大的时候，系统也能自动预警，当并发请求丢失严重的时候，系统也能自动预警等等，这样以来通过监控系统和预警系统的结合可以使得我们能快速响应系统出现的问题，提高系统的稳定性和可用性。

八配置统一管理

一个大型的分布式应用，一般都是有很多节点构成的，如果每次一个新的节点加入都要更改其它节点的配置，或者每次删除一个节点也要更改配置的话，这样不仅不利于系统的维护和管理，同时也更加容易引入错误。另外很多时候集群中的很多系统的配置都是一样的，如果不进行统一的配置管理，就需要再所有的系统上维护一份配置，这样会造成配置的管理维护很麻烦，而通过一个统一的配置管理可以使得这些问题得到很好的解决，当有新的节点加入或者删除的时候，配置管理系统可以通知各个节点更新配置，从而达到所有节点的配置一致性，这样既方便也不会出错。

淘宝技术框架分析报告

淘宝技术框架分析报告 淘宝作为国内首屈一指的大型电子商务网站，每天承载近30亿PV的点击量，拥有近50PB的海量数据，那么淘宝是如何确保其网站的高可用的呢？本文将对淘宝在构建大型网站过程中所使用到的技术框架做一个总结，并结合吉林银行现有技术框架进行对比分析。另外，本文还会针对金融互联网以及公司未来技术发展方向给出个人看法。 淘宝技术分析 CDN技术及多数据中心策略 国内的网络由于运营商不同（分为电信、联通、移动），造成不同运营商网络之间的互访存在性能问题。为了解决这个问题，淘宝在全国各地建立了上百个CDN节点，当用户访问淘宝网站时，浏览器首先会访问DNS服务器，通过DNS解析域名，根据用户的IP将访问分配到不同的入口。如果客户的IP属于电信运营商，那么就会被分配到同样是电信的CDN节点，并且保证访问的（这里主要指JS、CSS、图片等静态资源）CDN节点是离用户最近的。这样就将巨大的访问量分散到全国各地。另外，面对如此巨大的业务请求，任何一个单独的数据中心都是无法承受的，所以淘宝在全国各主要城市都建立了数据中心，这些数据中心不但保证了容灾，而且各个数据中心都在提供服

务。不管是CDN技术还是多个数据中心，都涉及到复杂的数据同步，淘宝很好的解决了这个问题。吉林银行现在正在筹建两地三中心，但主要目的是为了容灾，数据中心的利用率差，而淘宝的多个数据中心利用率为100%。 LVS技术 淘宝的负载均衡系统采用了LVS技术，该技术目前由淘宝的章文嵩博士负责。该技术可以提供良好的可伸缩性、可靠性以及可管理型。只是这种负载均衡系统的构建是在Linux操作系统上，其他操作系统不行，并且需要重新编译Linux操作系统内核，对系统内核的了解要求很高，是一种软负载均衡技术。而吉林银行则通过F5来实现负载均衡，这是一种硬负载均衡技术。 Session框架 Session对于Web应用是至关重要的，主要是用来保存用户的状态信息。但是在集群环境下需要解决Session共享的问题。目前解决这个问题通常有三种方式，第一个是通过负载均衡设备实现会话保持，第二个是采用Session复制，第三个则是采用集中式缓存。第二种方式严重制约了集群环境的可伸缩性，不利于集群的横向扩展，即使是采取两两复制也会造成集群内部网络负载严重，更别说采用广播的方式，会造成网络垃圾。淘宝采用了第三种方式，因为第一种方式对于淘宝来说成本比较高，而且他们已经采用了LVS的负载均衡技术。吉

淘宝技术架构发展总结

从个人网站到淘宝网仰观Java时代淘宝的技术发展(1)引言 光棍节的狂欢 “时间到，开抢！”坐在电脑前早已等待多时的小美一看时间已到2011年11月11日零时，便迫不及待地投身于淘宝商城一年一度的大型网购促销活动——“淘宝双11购物狂欢节”。小美打开早已收藏好的宝贝——某品牌的雪地靴，飞快的点击购买，付款，一回头发现3000双靴子已被抢购一空。 小美跳起来，大叫一声“欧耶！” 小美不知道，就在11日零点过后的这一分钟内，全国有342万人和她一起涌入淘宝商城。当然，她更不知道，此时此刻，在淘宝杭州的一间办公室里，灯火通明，这里是“战时指挥部”，淘宝技术部的一群工程师，正在紧盯着网站的流量和交易数据。白板上是他们刚刚下的注，赌谁能最准确地猜中流量峰值和全天的交易总额。他们的手边放着充足的食物和各类提神的饮料。 一阵急促的电话声响起来，是前线部门询问数据的，工程师大声报着：“第1分钟，进入淘宝商城的会员有342万”。过一会工程师主动拿起电话：“交易额超过1亿了，现在是第8分钟。”接下来，“第21分钟，刚突破2亿”。“第32分钟，3亿了”。“第1个小时，亿”。这些数据随后出现在微博上，引起一片惊呼。 “完蛋了！”突然有人大喝一声，所有的眼睛都紧张的盯着他，只见他挠挠头，嘿嘿的笑道“我赌的少了，20亿轻松就能过了，我再加5亿”，他跑去白板边上把自己的赌注擦去，写上25，接下来有人写上28，有人写上30，有人跑到微博上开下盘口，同事们纷纷转载下注。接下来的这24个小时，战时指挥部的工程师们都不能休息，他们盯着网站的各种监控指标，适时的调整机器和增减功能。顶住第一波高峰之后，这些人开始忙里偷闲的给自己买东西，大家互相交流着哪家买的移动硬盘靠谱，哪家衣服适合自己的女朋友，不时的有人哀嚎宝贝被人抢了、信用卡额度不够了。同时，旁边白板上的赌注越下越大。 11月11日，这个棍子最多的日子被网民自我调侃的变成了一个节日——“光棍节”。而淘宝网又用疯狂的折扣促销给它赋予了另外一个意义——“购物狂欢节”。2011年11月11日这一天，淘宝商城与淘宝网交易额之和突破52亿，这个数字是“购物天堂”香港一天零售总额亿的6倍。

淘宝技术架构发展总结

引言 光棍节的狂欢 “时间到，开抢！”坐在电脑前早已等待多时的小美一看时间已到2011年11月11日零时，便迫不及待地投身于淘宝商城一年一度的大型网购促销活动——“淘宝双11购物狂欢节”。小美打开早已收藏好的宝贝——某品牌的雪地靴，飞快的点击购买，付款，一回头发现3000双靴子已被抢购一空。 小美跳起来，大叫一声“欧耶！” 小美不知道，就在11日零点过后的这一分钟内，全国有342万人和她一起涌入淘宝商城。当然，她更不知道，此时此刻，在淘宝杭州的一间办公室里，灯火通明，这里是“战时指挥部”，淘宝技术部的一群工程师，正在紧盯着网站的流量和交易数据。白板上是他们刚刚下的注，赌谁能最准确地猜中流量峰值和全天的交易总额。他们的手边放着充足的食物和各类提神的饮料。 一阵急促的电话声响起来，是前线部门询问数据的，工程师大声报着：“第1分钟，进入淘宝商城的会员有342万”。过一会工程师主动拿起电话：“交易额超过1亿了，现在是第8分钟。”接下来，“第21分钟，刚突破2亿”。“第32分钟，3亿了”。“第1个小时，亿”。这些数据随后出现在微博上，引起一片惊呼。 “完蛋了！”突然有人大喝一声，所有的眼睛都紧张的盯着他，只见他挠挠头，嘿嘿的笑道“我赌的少了，20亿轻松就能过了，我再加5亿”，他跑去白板边上把自己的赌注擦去，写上25，接下来有人写上28，有人写上30，有人跑到微博上开下盘口，同事们纷纷转载下注。接下来的这24个小时，战时指挥部的工程师们都不能休息，他们盯着网站的各种监控指标，适时的调整机器和增减功能。顶住第一波高峰之后，这些人开始忙里偷闲的给自己买东西，大家互相交流着哪家买的移动硬盘靠谱，哪家衣服适合自己的女朋友，不时的有人哀嚎宝贝被人抢了、信用卡额度不够了。同时，旁边白板上的赌注越下越大。 11月11日，这个棍子最多的日子被网民自我调侃的变成了一个节日——“光棍节”。而淘宝网又用疯狂的折扣促销给它赋予了另外一个意义——“购物狂欢节”。2011年11月11日这一天，淘宝商城与淘宝网交易额之和突破52亿，这个数字是“购物天堂”香港一天零售总额亿的6倍。 网民感受到的是疯抢的喜悦，而网站的技术人员感受到的却是“压力山大”。就如同你家办酒席，宴请左邻右舍，这个办起来容易。倘若宴请十里八乡所有的人，吃饭的人自然开心，但却不是一般人家能够办得起来的。能办得起来如此盛宴者，需要强大的财力物力、组织能力、技术实力（例如做这么多菜，你的炒

马云的淘宝网结构介绍

马云淘宝网结构介绍 背景：阿里巴巴宣布注资1亿元创办淘宝网的时候，互联网冬天的阴影还很沉重，淘宝网 的投资实际上是整个冬天之后互联网业界的第一次大规模投资。与此同时，易趣已经占领了中国80%以上的市场份额，而eBay已在2002年以3000万美元的代价，收购了易趣三分之一的股份，并在2003年以1.5亿美元的价格收购了易趣余下的股份，并允诺继续增加对中国市场的投入，以增强其在中国市场的绝对领先地位。阿里巴巴的CEO马云在这样的时刻选择进入C2C领域被当时的一些媒体形容为“非理智”、“疯狂”和“豪赌”。 马云当时的做法让很多人难以理解，但是对于阿里巴巴自己人讲，却习以为常，马云经常讲，“在大家都觉得是一个机会的时候，我们不会去凑热闹。而越在大家都还没有开始准备，甚至避之不及的时候，往往正是最大的机会所在。” 投资淘宝的想法诞生在2003年年初，是时马云认为个人电子商务市场开始逐渐成熟，而且阿里巴巴的业务已经相对稳固，需要做更长远的打算。“eBay易趣当时在中国的确做得很大，但我们发现它有很多弱点。客户对它的抱怨很多，这就是我们的机会。”孙彤宇当时正是淘宝网项目的负责人。他所说的弱点，其中的重要一点是eBay易趣坚持的收费原则。“在那个时候就采取收费模式，我们觉得在时间上并不适合。所以我们在去年一直呼吁大家以培育市场为目的，不要急着去收钱。”孙彤宇说。 在瞄准对手弱点之后，短短的120天之后，孙彤宇就完成了从详细的市场调研到组建10人团队的“创业”过程。在前期没有进行任何市场推广的情况下，2003年5月10日，淘宝网正式上线。20天后，淘宝网迎来第1万名注册用户。2003年7月7 日，阿里巴巴正式宣布投资1亿元开办淘宝网。 组织结构：2010年淘宝的交易额高达4000亿元人民币，这是一个让人惊叹的数字。网 购的巨大市场无疑会吸引更多的人在淘宝开店。然而今天要在淘宝成功闯出一片天地，难度却比以往大得多。自从淘宝商城出现后，大大小小的个人卖家除了相互之间的激烈竞争，还要面对无论资金、人力、物力，还是可信度都比个人店强得多的品牌店的竞争，生存的空间势必越来越小。可以说，一个人撑起一个皇冠店的时代已经成了过去式。要在当今激烈的电子商务竞争中生存下来并且盈利，必须依靠团队的力量。那么，运营一家成功的淘宝网店，需要一个什么样的团队呢？ 我们认为，一个高效的淘宝网店团队应该至少配备以下人员：一个营运经理，负责整个店铺的统筹和营运管理；一个策划人员，负责产品的文案描述，网店的推广以及各种促销活动的策划；一个美工，负责店铺的视觉美化；一个财务人员，负责财务管理；此外，还需要配备与销售规模相应的客服人员与物流人员，负责销售与售后配送的工作。 人力资源管理：（一）运营经理1、负责网店整体规划、营销、推广、客户关系管理 等系统经营性工作；2、负责网店日常改版策划、上架、推广、销售、售后服务等经营与管理工作；3、负责网店日常维护，保证网店的正常运作，优化店铺及商品排名；4、负责执行与配合公司相关营销活动，策划店铺促销活动方案；5、负责收集市场和行业信息，提供有效应对方案；6、制定销售计划，带领团队完成销售业绩目标；7、客户关系维护，处理相关客户投诉及纠纷问题。 (二)客服人员1、通过在线聊天工具，负责在淘宝上和顾客沟通，解答顾客对产品和购

淘宝服务端技术架构详解

淘宝服务端技术架构详解

目录 一、前言 (3) 二、单机架构 (4) 三、多机部署 (4) 四、分布式缓存 (5) 五、Session 共享解决方案 (7) 六、数据库读写分离 (9) 七、CDN 加速与反向代理 (10) 八、分布式文件服务器 (11) 九、数据库分库分表 (11) 十、搜索引擎与NoSQL (13) 十一、后序 (13)

一、前言 以淘宝网为例，简单了解一下大型电商的服务端架构是怎样的。如图所示 最上面的就是安全体系系统，中间的就是业务运营系统，包含各个不同的业务服务，下面是一些共享服务，然后还有一些中间件，其中ECS 就是云服务器，MQS 是队列服务，OCS 是缓存等等，右侧是一些支撑体系服务。除图中所示之外还包含一些我们看不到的，比如高可用的体现。淘宝目前已经实现多机房容灾和异地机房单元化部署，为淘宝的业务也提供了稳定、高效和易于维护的基础架构支撑。这是一个含金量非常高的架构，也是一个非常复杂而庞大的架构，当然这个架构不是一天两天演进成这样的，也不是一开始就设计并开发成这样的，对于初创公司而言，很难在初期就预估到未来流量千倍、万倍的网站架构会是怎样的状况，同时如果初期就设计成千万级并发的流量架构，也很难去支撑这个成本。因此一个大型服务系统，都是从小一步一步走过来的，在每个阶段找到对应该阶段网站架构所面临的问题，然后不断解决这些问题，在这个过程中，整个架构会一直演进，同时内含的代码也就会演进，大到架构、小到代码都是在不断演进和优化的。所以说高大上的项目技术架构和开发设计实现不是一蹴而就的，这是所谓的万丈高楼平地起。

二、单机架构 从一个小网站说起，一般来说初始一台服务器就够了，文件服务器、数据库以及应用都部署在一台机器上。也就是俗称的 allinone 架构。这篇推荐看下：厉害了，淘宝千万并发，14 次架构演进… 三、多机部署 随着网站用户逐渐增多，访问量越来越大，硬盘、cpu、内存等开始吃紧，一台服务器难以支撑。看一下演进过程，我们将数据服务和应用服务进行分离，给应用服务器配置更好的cpu、内存等等，而给数据服务器配置更好、更快的大的硬盘，如图所示用了三台服务器进行部署，能提高一定的性能和可用性。

淘宝数据魔方技术架构解析

淘宝数据魔方技术架构解析 淘宝网拥有国内最具商业价值的海量数据。截至当前，每天有超过30亿的店铺、商品浏览记录，10亿在线商品数，上千万的成交、收藏和评价数据。如何从这些数据中挖掘出真正的商业价值，进而帮助淘宝、商家进行企业的数据化运营，帮助消费者进行理性的购物决策，是淘宝数据平台与产品部的使命。 为此，我们进行了一系列数据产品的研发，比如为大家所熟知的量子统计、数据魔方和淘宝指数等。尽管从业务层面来讲，数据产品的研发难度并不高;但在“海量”的限定下，数据产品的计算、存储和检索难度陡然上升。本文将以数据魔方为例，向大家介绍淘宝在海量数据产品技术架构方面的探索。 淘宝海量数据产品技术架构 数据产品的一个最大特点是数据的非实时写入，正因为如此，我们可以认为，在一定的时间段内，整个系统的数据是只读的。这为我们设计缓存奠定了非常重要的基础。 图1 淘宝海量数据产品技术架构 按照数据的流向来划分，我们把淘宝数据产品的技术架构分为五层(如图1所示)，分别是数据源、计算层、存储层、查询层和产品层。位于架构顶端的是我们

的数据来源层，这里有淘宝主站的用户、店铺、商品和交易等数据库，还有用户的浏览、搜索等行为日志等。这一系列的数据是数据产品最原始的生命力所在。 在数据源层实时产生的数据，通过淘宝主研发的数据传输组件DataX、DbSync 和Timetunnel准实时地传输到一个有1500个节点的Hadoop集群上，这个集群我们称之为“云梯”，是计算层的主要组成部分。在“云梯”上，我们每天有大约40000个作业对1.5PB的原始数据按照产品需求进行不同的MapReduce计算。这一计算过程通常都能在凌晨两点之前完成。相对于前端产品看到的数据，这里的计算结果很可能是一个处于中间状态的结果，这往往是在数据冗余与前端计算之间做了适当平衡的结果。 不得不提的是，一些对实效性要求很高的数据，例如针对搜索词的统计数据，我们希望能尽快推送到数据产品前端。这种需求再采用“云梯”来计算效率将是比较低的，为此我们做了流式数据的实时计算平台，称之为“银河”。“银河”也是一个分布式系统，它接收来自TimeTunnel的实时消息，在内存中做实时计算，并把计算结果在尽可能短的时间内刷新到NoSQL存储设备中，供前端产品调用。 容易理解，“云梯”或者“银河”并不适合直接向产品提供实时的数据查询服务。这是因为，对于“云梯”来说，它的定位只是做离线计算的，无法支持较高的性能和并发需求;而对于“银河”而言，尽管所有的代码都掌握在我们手中，但要完整地将数据接收、实时计算、存储和查询等功能集成在一个分布式系统中，避免不了分层，最终仍然落到了目前的架构上。 为此，我们针对前端产品设计了专门的存储层。在这一层，我们有基于MySQL 的分布式关系型数据库集群MyFOX和基于HBase的NoSQL存储集群Prom，在后面的文字中，我将重点介绍这两个集群的实现原理。除此之外，其他第三方的模块也被我们纳入存储层的范畴。

揭秘淘宝286亿海量图片存储与处理架构

【IT168 专稿】8月27日下午，在IT168系统架构师大会存储与系统架构分论坛上，淘宝网技术委员会主席，淘宝网核心工程师章文嵩向我们详细介绍了淘宝网图片处理与存储系统的架构。章文嵩博士的演讲日程包括了淘宝的整个系统架构、淘宝图片存储系统架构，淘宝网独立开发的TFS集群文件系统，前端CDN系统以及淘宝网在节能服务器方面的应用和探索。 本文侧重介绍淘宝网后台的图片存储系统架构、包括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公司的文件存储系统。随着淘宝网的图片文件数量以每年2倍(即原来3倍)的速度增长，淘宝网后端NetApp公司的存储系统也从低端到高端不断迁移，直至2006年，即时是NetApp公司最高端的产品也不能满足淘宝网存储的要求。

淘宝网技术架构

淘宝网的开源架构 淘宝网，是一个在线商品数量突破一亿，日均成交额超过两亿元人民币，注册用户接近八千万的大型电子商务网站，是亚洲最大的购物网站。那么对于淘宝网这样大规模的一个网站，我猜想大家一定会非常关心整个网站都采用了什么样的技术、产品和架构，也会很想了解在淘宝网中是否采用了开源的软件或者是完全采用的商业软件。那么下面我就简单的介绍一下淘宝网中应用的开源软件。 对于规模稍大的网站来说，其IT必然是一个服务器集群来提供网站服务，数据库也必然要和应用服务分开，有单独的数据库服务器。对于像淘宝网这样规模的网站而言，就是应用也分成很多组。那么下面，我就从应用服务器操作系统、应用服务器软件、Web Server、数据库、开发框架等几个方面来介绍一下淘宝网中开源软件的应用。 操作系统 我们首先就从应用服务器的操作系统说起。一个应用服务器，从软件的角度来说他的最底层首先是操作系统。要先选择操作系统，然后才是操作系统基础上的应用软件。在淘宝网，我们的应用服务器上采用的是Linux操作系统。Linux 操作系统从1991年第一次正式被公布到现在已经走过了十七个年头，在PC Server上有广泛的应用。硬件上我们选择PC Server而不是小型机，那么Server 的操作系统供我们选择的一般也就是Linux，FreeBSD, windows 2000 Server 或者Windows Server 2003。如果不准备采用微软的一系列产品构建应用，并且有能力维护Linux或者FreeBSD，再加上成本的考虑，那么还是应该在Linux和FreeBSD之间进行选择。可以说，现在Linux和FreeBSD这两个系统难分伯仲，很难说哪个一定比另外一个要优秀很多、能够全面的超越对手，应该是各有所长。那么在选择的时候有一个因素就是企业的技术人员对于哪种系统更加的熟悉，这个熟悉一方面是系统管理方面，另外一方面是对于内核的熟悉，对内核的熟悉对于性能调优和对操作系统进行定制剪裁会有很大的帮助。而应用全面的优化、提升性能也是从操作系统的优化开始的。 应用服务器 在确定了服务器的硬件、服务器的操作系统之后，下面我们来说说业务系统的构建。淘宝网有很多业务系统应用是基于JEE规范的系统。还有一些是C C++构建的应用或者是Java构建的Standalone的应用。那么我们要选择一款实现了JEE规范的应用服务器。我们的选择是JBoss Applcation Server。JBoss AS是RedHat的一个开源的支持JEE规范的应用服务器。在几年前，如果采用Java技术构建互联网应用或者企业级应用，在开源软件中的选择一般也就是Apache组织的Tomcat、JBoss的 JBoss AS和Resin。严格意义上讲，Tomcat和Resin并

淘宝技术架构发展总结

从个人到淘宝网仰观Java时代淘宝的技术发展(1) 引言 光棍节的狂欢 “时间到，开抢！”坐在电脑前早已等待多时的小美一看时间已到2011年11月11日零时，便迫不及待地投身于淘宝商城一年一度的大型网购促销活动——“淘宝双11购物狂欢节”。小美打开早已收藏好的宝贝——某品牌的雪地靴，飞快的点击购买，付款，一回头发现3000双靴子已被抢购一空。 小美跳起来，大叫一声“欧耶！” 小美不知道，就在11日零点过后的这一分钟，全国有342万人和她一起涌入淘宝商城。当然，她更不知道，此时此刻，在淘宝的一间办公室里，灯火通明，这里是“战时指挥部”，淘宝技术部的一群工程师，正在紧盯着的流量和交易数据。白板上是他们刚刚下的注，赌谁能最准确地猜中流量峰值和全天的交易总额。他们的手边放着充足的食物和各类提神的饮料。 一阵急促的声响起来，是前线部门询问数据的，工程师大声报着：“第1分钟，进入淘宝商城的会员有342万”。过一会工程师主动拿起：“交易额超过1亿了，现在是第8分钟。”接下来，“第21分钟，刚突破2亿”。“第32分钟，3亿了”。“第1个小时，4.39亿”。这些数据随后出现在微博上，引起一片惊呼。 “完蛋了！”突然有人大喝一声，所有的眼睛都紧的盯着他，只见他挠挠头，嘿嘿的笑道“我赌的少了，20亿轻松就能过了，我再加5亿”，他跑去白板边上把自己的赌注擦去，写上25，接下来有人写上28，有人写上30，有人跑到微博上开下盘口，同事们纷纷下注。接下来的这24个小时，战时指挥部的工程师们都不能休息，他们盯着的各种监控指标，适时的调整机器和增减功能。顶住第一波高峰之后，这些人开始忙里偷闲的给自己买东西，大家互相交流着哪家买的移动硬盘靠谱，哪家衣服适合自己的女朋友，不时的有人哀嚎宝贝被人抢了、信用卡额度不够了。同时，旁边白板上的赌注越下越大。

淘宝网店组织架构

网店组织架构图 （一）运营总监 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、产品拍摄图片的美化、编辑排版;

淘宝的核心技术及演变

淘宝的核心技术(国内乃至国际的Top，这还是2011年的数据)： 拥有全国最大的分布式Hadoop 集群(云梯，2000左右节点，24000核CPU，48000GB 内存，40PB 存储容量) 全国分布80+CDN 节点，能够自动找寻最近的节点提供服务，支持流量超过800Gbps 不逊于百度的搜索引擎，对数十亿商品进行搜索，全球最大的电商平台 顶尖的负载均衡系统，顶尖的分布式系统，顶尖的互联网思想，功能多样运行极其稳定丰富的生态产业以及先进的数据挖掘技术 ……很多很多 下面来看看淘宝技术演变过程。 马总在2003年4月7日秘密叫来阿里巴巴的十位员工，来到杭州一个隐秘的毛坯房，要求他们在一个月左右的时间内做出一个C2C 网站。结果当然还是直接买的快，一个基于LAMP 架构的网站，原名是PHPAuction，老美开发的一个拍卖网站。当然必须要做修改才能用。 2003年底，淘宝注册用户23万，PV 31万/day，半年成交额3371万。 很显然MySQL 无法撑得起如此大的访问量，数据库瓶颈出现了。幸好阿里的DBA 队伍足够强大，他们使用Oracle 替代了MySQL。Oracle 那时就已经有了强大的并发性访

问设计——连接池，从连接池取连接的耗费比单独建立连接少很多。但是PHP 当时并没有官方提供支持语言连接池特性，于是多隆前辈用Google(不会是Baidu)搜到了一个开源的SQL Relay，于是数据库软件方面的瓶颈暂时解决了。 随之而来的是面临硬件性能瓶颈，阿里买了EMC 的SAN 存储设备，加上Oracle 高性能RAC，硬件容量也暂时没问题了。 因为SQL Relay 的问题实在过于严重，2004年于是淘宝终于做出了跨时代的决策——使用Java重写网站。 淘宝请了Sun 的高级工程师来帮忙做Java 架构。那么他们是如何做到修改编程语言而不改变网站使用呢——模块化替换，今天写好了A 模块，另开一个新域名，将连接指向该模块，同时别的模块不变，等到全部模块完成的时候，原域名放弃。Sun 公司坚持使用EJB 作为控制层，加上使用iBatis 作为持久层，一个可扩展且高效的Java EE 应用诞生了。 送走Sun 的大牛们之后，阿里的数据存储又遇到了瓶颈，于是忍痛买了一台IBM 小型机，也就有了IOE(IBM + Oracle + EMC)这样的传说。 2004年底，淘宝注册用户400万，PV 4000万/day，全网成交额10个亿。 2005年Spring 诞生了，早闻Spring 框架在Web 应用不可或缺，而在淘宝网，Spring 也达到了Rod Johnson 设计它的目的——替代EJB。 2005年底，淘宝注册用户1390万，PV 8931万/day，商品数目1663万个。

淘宝网高性能可伸缩架构技术探秘

淘宝网高性能可伸缩架构技术探秘今天我们继续大型网站探秘，一起来探秘淘宝网的架构技术。作为国内最大的B2C网站，淘宝网的网站架构一直承载着数据量告诉增长压力，要保证良好的负载和流程的使用体验，一个可伸缩性的高性能网站架构必不可少。 一、应用无状态 一个系统的伸缩性的好坏取决于应用的状态如何管理。试想一下，假如我们在session中保存了大量与客户端的状态信息的话，那么当保存状态信息的server 宕机的时候，我们怎么办?通常来说，我们都是通过集群来解决这个问题，而通常所说的集群，不仅有负载均衡，更重要的是要有失效恢复failover,比如tomcat 采用的集群节点广播复制，jboss采用的配对复制等session状态复制策略，但是集群中的状态恢复也有其缺点，那就是严重影响了系统的伸缩性，系统不能通过增加更多的机器来达到良好的水平伸缩，因为集群节点间session的通信会随着节点的增多而开销增大，因此要想做到应用本身的伸缩性，我们需要保证应用的无状态性，这样集群中的各个节点来说都是相同的，从而是的系统更好的水平伸缩。 上面说了无状态的重要性，那么具体如何实现无状态呢?此时一个session框架就会发挥作用了。幸运的是公司已经具有了此类框架。公司的session框架采用的是client cookie实现，主要将状态保存到了cookie里面，这样就使得应用节点本身不需要保存任何状态信息，这样在系统用户变多的时候，就可以通过增加更多的应用节点来达到水平扩展的目的.但是采用客户端cookie的方式来保存状态也会遇到限制，比如每个cookie一般不能超过4K的大小，同时很多浏览器都限制一个站点最多保存20个cookie.公司cookie框架采用的是"多值cookie"，就是一个组合键对应多个cookie的值，这样不仅可以防止cookie数量超过20，同时还节

51-电子商务网站(淘宝网)的系统架构解析

电子商务网站（淘宝网）的系统架构解析 淘宝网，是一个在线商品数量突破一亿，日均成交额超过两亿元人民币，注册用户接近八千万的大型电子商务网站，是亚洲最大的购物网站。那么对于淘宝网这样大规模的一个网站，我猜想大家一定会非常关心整个网站都采用了什么样的技术、产品和架构，也会很想了解在淘宝网中是否采用了开源的软件或者是完全采用的商业软件。那么下面我就简单的介绍一下淘宝网中应用的开源软件。 对于规模稍大的网站来说，其IT必然是一个服务器集群来提供网站服务，数据库也必然要和应用服务分开，有单独的数据库服务器。对于像淘宝网这样规模的网站而言，就是应用也分成很多组。那么下面，我就从应用服务器操作系统、应用服务器软件、Web Server、数据库、开发框架等几个方面来介绍一下淘宝网中开源软件的应用。 操作系统 我们首先就从应用服务器的操作系统说起。一个应用服务器，从软件的角度来说他的最底层首先是操作系统。要先选择操作系统，然后才是操作系统基础上的应用软件。在淘宝网，我们的应用服务器上采用的是Linux操作系统。Linux操作系统从1991年第一次正式被公布到现在已??走过了十七个年头，在PC Server上有广泛的应用。硬件上我们选择PC Server而不是小型机，那么Server的操作系统供我们选择的一般也就是Linux，FreeBSD,windows2000 Server或者Windows Server2003。如果不准备采用微软的一系列产品构建应用，并且有能力维护Linux或者FreeBSD，再加上成本的考虑，那么还是应该在Linux和FreeBSD之间进行选择。可以说，现在Linux和FreeBSD这两个系统难分伯仲，很难说哪个一定比另外一个要优秀很多、能够全面的超越对手，应该是各有所长。那么在选择的时候有一个因素就是企业的技术人员对于哪种系统更加的熟悉，这个熟悉一方面是系统管理方面，另外一方面是对于内核的熟悉，对内核的熟悉对于性能调优和对操作系统进行定制剪裁会有很大的帮助。而应用全面的优化、提升性能也是从操作系统的优化开始的。 应用服务器 在确定了服务器的硬件、服务器的操作系统之后，下面我们来说说业务系统的构建。淘宝网有很多业务系统应用是基于JEE规范的系统。还有一些是C C++构建的应用或者是Java 构建的Standalone的应用。那么我们要选择一款实现了JEE规范的应用服务器。我们的选择是JBoss Applcation Server。JBoss AS是RedHat的一个开源的支持JEE规范的应用服务器。在几年前，如果采用Java技术构建互联网应用或者企业级应用，在开源软件中的选择一般也就是Apache组织的Tomcat、JBoss的JBoss AS和Resin。严格意义上讲，Tomcat和Resin并不能算是一个应用服务器，他们是实现了部分J2EE规范的一个容器。而商业软件的选择就是IBM 的WebSphere和BEA的WebLogic。到了现在，除了JBoss AS外，Apache的Geronimo，Sun的Glassfish也都是很优秀的JEE应用服务器。也给现在的开发人员提供了更多的选择。具体对于目前JEE应用服务器的比较。这边就不在赘述。 在应用服务器前端，我们采用了Web Server做了一次转发，我们选择的Web服务器是大

《淘宝业务发展及技术架构》分享

主持人：今天我们特别请来淘宝资深技术专家范禹给我们分享《淘宝业务发展及技术架构》，接下来时间交给范禹，大家欢迎！ 范禹：大家下午好，首先感谢刘警给我这个机会跟大家做技术交流，接下来我开始讲一下，花名叫范禹，现在在淘宝技术研发部产品技术业务平台团队，今天的主要内容分为下面几块，因为主题叫淘宝业务与技术发展，前面业务会简单提一下，然后介绍一下淘宝前期技术发展过程，然后是最近几次比较大的技术结构上的变化，还有当前面临的挑战和问题，最后是讨论时间。 淘宝业务很多，我们有主站交易，有搜索，有广告，数据平台等很多相关业务，我是做主站交易平台，主要是JAVA系统，我更多是讲这块，其他像开放平台、搜索、广告不大会涉及到，我看问题中有位同学问我P4P广告如何定位到目标用户的，这个我不太知道，如果有兴趣可以邀请相关同学给大家做一个交流。 淘宝是03年成立的，这是淘宝03年的页面，UED的同学发给我淘宝历年的首页，这个页面我第一次看到觉得还不错，很有欧美网站的风格，这就是03年淘宝刚创立时候的样子，里面像买家通道、卖家通道、淘宝者联盟，淘宝者联盟可能并不是现在的淘客，应该是那时候的一个社区，03年5月份的时候淘宝推出，那时候的页面是这样子，当时是比较简单的购物网站。 （Taobao@2004）接下来就到了04年，从右上角导航上看，其实主体框架已经定下来，我要买、我要卖、我的淘宝，这几块

功能这么多年来都没有大的变化，可能是交互或者说用户体验上的改变，但是它的功能可能并没有特别大的变化。 04年在业务上我认为有两块比较重要的东西，一个是旺旺从贸易通改造成淘宝IM工具，成为方便买卖购物交流的IM工具，这是我认为业务上比较大变化的东西。另外支付宝从淘宝慢慢发展，成为独立的一家公司。 我印象中04年业务上关注的PV跟UV比，就是每个用户在淘宝上停留的时间，因为以前淘宝刚成立的时候，很多门户网站跟Ebay签了排他协议，淘宝不能在大的网站上投广告，可能找一些网站联盟，他们是弹窗式的广告，平均每个用户在淘宝待几个页面，当时目标就是让用户多看几个页面。 （Taobao@2005）到了2005年，页面上跟现在越来越像了，也是越来越丰富，05年比较大的业务变化，一个是跟一拍的整合，因为当年阿里巴巴跟雅虎的一个合作，然后一拍并入到淘宝，另外在一些方面做了尝试，比如说“我的淘宝”改造。 （Taobao@2006）这是2006年的淘宝，这个上面的导航看上去更像了，最右边有一个新功能叫团购，当时花很大力气做了个团购项目，可能是时机没到，不然的话可能就没有现在的拉手什么这么多网站了，当时我们做的是一个卖家发起的团购，但是因为淘宝本身就是一个充分竞价的平台，价格都是很透明的，团购感觉效果不是很明显。06年还做了一个很重大的尝试，招财进宝项目，就是淘宝的P4P，后来大家有听说过，看到历史的介绍，

淘宝店铺团队人员架构

淘宝团队架构 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．按照要求对货物产品进行包装，负责发货等物流方面的事项。 2、较强的服务客户的意识及团队合作精神 3、能吃苦、蹋实、细心、能长期稳定的合作。 职责描述： 1、负责商品出库，发货包装。 2、准确无误的核对面单与商品货号、数量等。 3、登记商品出库记录。 （注：范文素材和资料部分来自网络，供参考。只是收取少量整理收集费用，请预览后才下载，期待你的好评与关注）

淘宝网采用什么技术架构来实现网站高负载的

淘宝网采用什么技术架构来实现网站高负载的 时间:2010-09-15 时间过得很快，来淘宝已经两个月了，在这两个月的时间里，自己也感受颇深。下面就结合淘宝目前的一些底层技术框架以及自己的一些感触来说说如何构建 一个可伸缩，高性能，高可用性的分布式互联网应用。 一应用无状态（淘宝session框架） 俗话说，一个系统的伸缩性的好坏取决于应用的状态如何管理。为什么这么说呢？咱们试想一下，假如我们在session中保存了大量与客户端的状态信息的话，那么当保存状态信息的server宕机的时候，我们怎么办？通常来说，我们都是通过集群来解决这个问题，而通常所说的集群，不仅有负载均衡，更重要的是要有失效恢复failover,比如tomcat采用的集群节点广播复制，jboss采用的 配对复制等session状态复制策略，但是集群中的状态恢复也有其缺点，那就是严重影响了系统的伸缩性，系统不能通过增加更多的机器来达到良好的水平伸缩，因为集群节点间session的通信会随着节点的增多而开销增大，因此要想做到应用本身的伸缩性，我们需要保证应用的无状态性，这样集群中的各个节点来说都是相同的，从而是的系统更好的水平伸缩。 OK，上面说了无状态的重要性，那么具体如何实现无状态呢？此时一个session框架就会发挥作用了。幸运的是淘宝已经具有了此类框架。淘宝的session框架采用的是client cookie实现，主要将状态保存到了cookie里面，这样就使得应用节点本身不需要保存任何状态信息，这样在系统用户变多的时候，就可以通过增加更多的应用节点来达到水平扩展的目的.但是采用客户端cookie 的方式来保存状态也会遇到限制，比如每个cookie一般不能超过4K的大小， 同时很多浏览器都限制一个站点最多保存20个cookie.淘宝cookie框架采用 的是“多值cookie”，就是一个组合键对应多个cookie的值，这样不仅可以防止cookie数量超过20，同时还节省了cookie存储有效信息的空间，因为默认每个cookie都会有大约50个字节的元信息来描述cookie。 除了淘宝目前的session框架的实现方式以外，其实集中式session管理来完成，说具体点就是多个无状态的应用节点连接一个session 服务器，session 服务器将session保存到缓存中，session服务器后端再配有底层持久性数据源，比如数据库，文件系统等等。 二有效使用缓存（Tair）

淘宝的架构

淘宝的架构 淘宝用的是JBoss，框架是iBATIS，缓存服务器是自己开发的，基本遵循SNA架构，水平扩展，数据库是Oracle，阿里集团的DBA几乎是国内最强悍的。目前淘宝的系统架构正在重构，计划用两到三年时间重写，目标有两个： 1、水平扩展已经不满足需求了，还需要水平加垂直扩展 2、开放API，让店家可以把外部网站资源集成到淘宝，不必直接在淘宝开店 淘宝首席架构师是原来JBoss的Ben Wang，现在正在招募技术高手加盟，从事这项很有挑战性的工作：设计下一代开放性、支撑数十亿访问量的在线电子商务网站 淘宝架构更详细的情况就不方便透露了。 淘宝网，是一个在线商品数量突破一亿，日均成交额超过两亿元人民币，注册用户接近八千万的大型电子商务网站，是亚洲最大的购物网站。那么对于淘宝网这样大规模的一个网站，我猜想大家一定会非常关心整个网站都采用了什么样的技术、产品和架构，也会很想了解在淘宝网中是否采用了开源的软件或者是完全采用的商业软件。那么下面我就简单的介绍一下淘宝网中应用的开源软件。 对于规模稍大的网站来说，其IT必然是一个服务器集群来提供网站服务，数据库也必然要和应用服务分开，有单独的数据库服务器。对于像淘宝网这样规模的网站而言，就是应用也分成很多组。那么下面，我就从应用服务器操作系统、应用服务器软件、Web Server、数据库、开发框架等几个方面来介绍一下淘宝网中开源软件的应用。 操作系统 我们首先就从应用服务器的操作系统说起。一个应用服务器，从软件的角度来说他的最底层首先是操作系统。要先选择操作系统，然后才是操作系统基础上的应用软件。在淘宝网，我们的应用服务器上采用的是Linux操作系统。Linux操作系统从1991年第一次正式被公布到现在已? ? 走过了十七个年头，在PC Server 上有广泛的应用。硬件上我们选择PC Server而不是小型机，那么Server的操作系统供我们选择的一般也就是Linux，FreeBSD, windows 2000 Server或者Windows Server 2003。如果不准备采用微软的一系列产品构建应用，并且有能力维护Linux或者FreeBSD，再加上成本的考虑，那么还是应该在Linux和 FreeBSD 之间进行选择。可以说，现在Linux和FreeBSD这两个系统难分伯仲，很难说哪个一定比另外一个要优秀很多、能够全面的超越对手，应该是各有所长。那么在选择的时候有一个因素就是企业的技术人员对于哪种系统更加的熟悉，这个熟悉一方面是系统管理方面，另外一方面是对于内核的熟悉，对内核的熟悉对于性能调优和对操作系统进行定制剪裁会有很大的帮助。而应用全面的优化、提升性能也是从操作系统的优化开始的。 应用服务器 在确定了服务器的硬件、服务器的操作系统之后，下面我们来说说业务系统的构建。淘宝网有很多业务系统应用是基于JEE规范的系统。还有一些是C C++构建的应用或者是Java构建的Standalone的应用。那么我们要选择一款实现了JEE规范的应用服务器。我们的选择是JBoss Applcation Server。JBoss AS是RedHat的一个开源的支持JEE规范的应用服务器。在几年前，如果采用Java技术构建互联网应用或者企业级应用，在开源软件中的选择一般也就是Apache组织的Tomcat、JBoss的 JBoss AS和Resin。严格意义上讲，Tomcat和Resin并不能算是一个应用服务器，他们是实现了部分J2EE规范的一个容器。而商业软件的选择就是 IBM的WebSphere和BEA的WebLogic。到了现在，除了JBoss AS外，Apache的Geronimo，Sun的Glassfish也都是很优秀的JEE应用服务器。也给现在的开发人员提供了更多的选择。具体对于目前JEE应用服务器的比较。这边就不在赘述。 在应用服务器前端，我们采用了Web Server做了一次转发，我们选择的Web服务器是大名鼎鼎的Apache。几年前，Apache几乎是Linux系统上开源Web Server的唯一选择。那个时候虽然也有一些其他的开源的Web Server，但是从功能和稳定性上来说都无法和Apache相对。在今天来说，Lighty也会是一个非常好的选择。Lighty是一个非常轻量级、占用内存资源也比较少的Web Server。虽然功能上没有Apache强大，但是在不少场景下，性能是非常出色、强于Apache的。而微软的IIS，就只能工作在Windows的系统上了。并且使用IIS的话，基本上也就是选择了ISAPI、ASP或者https://www.sodocs.net/doc/b311497966.html,进行Web应用的开发了。 数据库 说完了我们采用的操作系统、应用服务器、WebServer后，下面就来谈谈我们的数据库。在淘宝网的应用