本书的作者是阿里的子柳，本书从工程师的角度讲述淘宝这个超大规模互联网系统的成长历程，及其所有主动和被动的技术变革的前因后果。书中有幕后故事、产品经验、架构演进、技术启蒙，也有大牛成长、业内八卦、失败案例、励志故事。本篇笔记仅仅记录了一些阅读过程中涉及的一部分技术知识，其中有很多的淘宝故事历史，核心人物叙述等未做记录了，本书描述的基本都在2000-2010年间的事情，虽然已过去数年，但是其中很多的设计思想和经历过程还是非常值得学习的。
技术的角度来看，网站上发生了什么样的事情。
【1】DNS服务域名转换IP地址
你发现快要过年了，于是想给你的女朋友买一件毛衣，你打开了www.taobao.com，这时你的浏览器首先查询DNS服务器，将www.taobao.com转换成IP地址。不过你首先会发现，在不同的地区或者不同的网络（电信、联通、移动）下，转换后的IP地址很可能是不一样的，这首先涉及负载均衡的第一步，通过DNS解析域名时，将你的访问分配到不同的入口，同时尽可能保证你所访问的入口是所有入口中可能较快的一个。
【2】产生PV和UV
你通过这个入口成功地访问了www.taobao.com实际的入口IP地址，这时产生了一个PV（Page View，页面访问量。每日每个网站的总PV量是形容一个网站规模的重要指标。淘宝网全网在平日（非促销期间）的PV大概是16～25亿个之间）。同时作为一个独立的用户，你这次访问淘宝网的所有页面均算作一个UV（Unique Visitor，用户访问）。
【3】LVS负载均衡
因为同一时刻访问www.taobao.com的人数过于巨大，所以，即便是生成淘宝首页页面的服务器，也不可能仅有一台，仅用于生成www.taobao.com首页的服务器就可能有成百上千台，那么你的一次访问时生成页面给你看的任务便会被分配给其中一台服务器完成。这个过程要保证公正、公平、平均（即这成百上千台服务器每台负担的用户数要差不多），这一很复杂的过程由几个系统配合完成，其中最关键的便是LVS（Linux Virtual Server，世界上最流行的负载均衡系统之一，是由目前在淘宝网供职的章文嵩博士开发的）。
【4】静态资源加载和浏览器并发连接数优化
经过一系列复杂的逻辑运算和数据处理，这次用于给你看的淘宝网首页的HTML内容便成功生成了。对Web前端稍微有点常识的人都应该知道，浏览器下一步会加载页面中用到的CSS、JS （JavaScript）、图片等样式、脚本和资源文件。但是可能相对较少的人才会知道，你的浏览器在同一个域名下并发加载的资源数量是有限的，例如IE 6和IE 7是两个，IE 8是6个，chrome各版本不大一样，一般是4～6个。我刚刚看了一下，我访问淘宝网首页需要加载126个资源，那么如此小的并发连接数自然会加载很久。所以前端开发人员往往会将上述这些资源文件分布在多个域名下，变相地绕过浏览器的这个限制，同时也为下文的CDN工作做准备。
【5】CDN服务
据不可靠消息称，在2011年“双十一”当天高峰，淘宝的访问流量最巅峰达到871GB/s，这个数字意味着需要178万个4MB/s的家庭宽带才能负担得起，也完全有能力拖垮一个中小城市的全部互联网带宽。显然，这些访问流量不可能集中在一起，并且大家都知道，不同地区、不同网络（电信、联通等）之间互访会非常缓慢，但是你却很少发现淘宝网访问缓慢，这便是CDN （Content Delivery Network，即内容分发网络的作用）。淘宝在全国各地建立了数十个甚至上百个CDN节点，利用一些手段保证你访问的（这里主要指JS、CSS、图片等）站点是离你最近的CDN节点，这样便保证了大流量的分散以及在各地访问的加速。
【6】TFS文件存储和同步
这便出现了一个问题，那就是假若一个卖家发布了一个新的宝贝，上传了几张新的宝贝图片，那么淘宝网如何保证全国各地的CDN节点中都会同步存在这几张图片供用户使用呢？这就涉及大量的内容分发与同步的相关技术。另外，淘宝上拥有海量的宝贝图片等静态文件，这些文件的总容量也达到了数PB （1PB=1024TB=1048576GB），为了快速存取这些文件，淘宝开发了分布式文件系统TFS（TaoBao File System）来处理这类问题。
【7】搜索服务，分词，购物意图分析
好了，这时你终于加载完成淘宝首页，然后习惯性地在首页搜索框中输入“毛衣”二字并按回车键，这时你又产生了一个PV，然后，淘宝网的主搜索系统便开始为你服务，它首先对你输入的内容基于一个分词库进行分词操作。众所周知，英文是以词为单位的，词和词之间靠空格隔开，而中文是以字为单位，句子中所有的字连起来才能描述一个意思。例如，英文句子“I am a student”用中文表示，则为“我是一个学生”。计算机可以很简单地通过空格知道student是一个单词，但是不太容易明白“学”、“生”两个字合起来才表示一个词。把中文的汉字序列切分成有意义的词，就是中文分词，有些人也称为切词。“我是一个学生”分词的结果是“我是一个学生”。进行分词操作之后，还需要根据你输入的搜索词进行购物意图分析。用户进行搜索时常常有如下几类意图。
● 浏览型：没有明确的购物对象和意图，边看边买，用户比较随意和感性。Query例如：“2010年10大香水排行”、“2010年流行毛衣”、“zippo有多少种类？”；
● 查询型：有一定的购物意图，体现在对属性的要求上。Query例如：“适合老人用的手机”、“500元手表”；
● 对比型：已经缩小了购物意图，具体到某几个产品。Query例如：“诺基亚E71 E63”、“akg k450 px200”；
● 确定型：已经做了基本决定，重点考察某个对象。Query例如：“诺基亚N97”、“IBM T60”。
【8】数据快照
通过对你的购物意图的分析，主搜索会呈现出完全不同的结果。之后的数个步骤后，主搜索系统便根据上述以及更多复杂的条件列出了搜索结果，这一切是由一千多台搜索服务器完成的。然后你开始逐一点击浏览搜索出的宝贝，查看宝贝详情页面。经常网购的亲们会发现，当你买过一个宝贝之后，即便是商家多次修改了宝贝详情页，你仍然能够通过“已买到的宝贝”查看当时的快照。这是为了防止商家对在商品详情中承诺过的东西赖账不认。显然，对于每年数十亿甚至上百亿笔交易的商品详情快照进行保存和快速调用不是一件简单的事情。这其中又涉及数套系统的共同协作，其中较为重要的是Tair（淘宝自行研发的分布式KV存储方案）。
【9】日志记录和行为分析
接下来，无论你是否真的进行了交易，你的这些访问行为都会如实地被系统记录下来，用于后续的业务逻辑和数据分析。这些记录中的访问日志记录便是最重要的记录之一，但是从前面我们得知，这些访问是分布在各个地区多个不同的服务器上的，并且由于用户众多，这些日志记录都非常庞大，达到TB级别也非常正常。那么，为了快速、及时、同步地传输这些日志数据，淘宝研发了TimeTunnel，用于进行实时的数据传输，然后交给后端系统进行计算报表等操作。你的浏览数据、交易数据以及其他很多数据记录均会被保留下来，使得淘宝存储的历史数据轻而易举地便达到了数十甚至更多个PB。如此巨大的数据量存储在阿里巴巴集团的数据仓库中，并且其中有些数据使用了压缩比高达1∶120的极限存储技术。之后这些数据会通过一个叫做云梯的基于Hadoop的由3000多台服务器组成的超大规模数据系统，以及一个基于阿里巴巴集团自主研发的ODPS系统的数据系统，不断地进行分析和挖掘。
支付宝的“担保交易”
微博上有人说“好的架构是进化来的，不是设计来的”。的确如此，其实还可以再加上一句“好的功能也是进化来的，不是设计来的”。
在架构的进化过程中，业务的进化也非常迅猛。最早的时候，买家打钱给卖家都是通过银行转账汇款，有些骗子收了钱却不发货，干脆逃之夭夭。这是一个很严重的问题，一个人这么干了之后，很快就有更多的人学会了（这就是传说中的“病毒传播”）。然而魔高一尺，道高一丈，淘宝网这伙人开始研究防骗子的解决方案，他们看了PayPal的支付方式，发现不能解决问题。研究了类似QQ币的东西，想弄个“淘宝币”出来，发现也不行。后来这几个聪明的脑袋把这些想法糅合起来，突然想到了“担保交易”这种第三方托管资金的办法。于是在2003年10月，淘宝网上线了一个功能，叫做“安全交易”，卖家如果选择支持这种功能，买家就会把钱交给淘宝网，等他收到货之后，淘宝网再把钱给卖家，这就是现在的“支付宝”。这个功能最早是让卖家可选的，因为这会延迟他收款的周期。但一旦卖家用了这个之后，就发现交易量猛增，一年之后，几乎所有的卖家都选择担保交易，到后来干脆所有的交易都必须走担保交易。在2012年支付宝的年会上，支付宝公布2011年的交易笔数已经是PayPal的两倍。这个划时代的创新，其实就是在不断思索过程中的一个灵光乍现。
更换PHP为JAVA开发语言
给一个网站更换开发语言，这种事情想想都恐怖，淘宝网在2004年就从PHP语言转换成了Java语言，这是怎么做到的？
到2004年上半年，淘宝网已经运行了一年的时间，这一年积累了大量的用户，也快速开发了很多功能，当时这个网站已经很庞大了，而且新的需求还在源源不断地增加。把一个庞大的网站的开发语言换掉，无异于脱胎换骨，在换的过程中还不能拖慢业务的发展，这无异于边换边跑，对时间和技术能力的要求都非常高。做这样的手术，需要请第一流的专家来主刀。现在再考一下大家：亲，如果你在这个创业团队中，请什么样的人来做这件事？我们的答案是请Sun公司的人。没错，就是创造Java语言的那家公司，世界上没有比他们更懂Java的了。除此之外，还有一个不为人知的原因，我刚才说到Java被世界上主流的大规模网站普遍采用，其中有一个网站就是eBay，那时eBay的系统刚刚从C++改到Java，而且就是请Sun的工程师给改造成Java架构的，这下你懂了吧？他们不仅更懂Java，而且更懂eBay。
Sun公司的这帮工程师的确很强大，在笔者2004年年底来淘宝的时候，他们还在，我有幸与他们共事了几个月。现在摆在他们面前的问题是用什么办法把一个庞大的网站从PHP语言迁移到Java？而且要求在迁移的过程中，不停止服务，原来系统的bugfix和功能改进不受影响。亲，你要是架构师，你怎么做？有人的答案是写一个翻译器，如同把中文翻译成英文一样，自动翻译。我只能说你这个想法太超前了，“too young，too simple，sometimes naive”。当时没有，现在也没有人能做到。
【拆分模块，渐进式替换】
他们的大致方案是给业务分模块，一个模块一个模块地渐进式替换。如用户模块，老的member.taobao.com继续维护，不添加新功能，新功能在新的模块上开发，跟老的模块共用一个数据库，开发完毕之后放到不同的应用集群上，另开一个域名member1.taobao.com，同时再替换老的功能，替换一个，就把老的模块上的功能关闭一个，逐渐把用户引导到member1.taobao.com，等所有的功能都替换完之后，关闭member.taobao.com。
从设计上来看，这个member1的二级域名应该是一个过渡状态，但我们把member域名的代码下线以后，发现很难把member1切换回member，因为有些地方把链接写死了，于是后来很长时间里我们都是在用member1.taobao. com这样奇怪的域名。一年后，有另外一家互联网公司开始做电子商务了，我们发现他们的域名也叫member1.xx.com、auction1. xx.com，复制得毫无保留，我们只能会心一笑。
多隆设计的出版搜索引擎
搜索引擎iSearch（前文说过，iSearch其实是在LAMP系统运行一段时间之后被多隆引进的，换为Oracle之后只是替换一下数据源）。其实这个搜索引擎的原理很简单，就是把数据库里的数据dump（倾倒）成结构化的文本文件后，放在硬盘上，提供Web应用以约定的参数和语法来查询这些数据。这看起来不难，难的是数以亿计的信息，怎么做到快速更新呢？这好比你做了一个网站，在百度上很快就能搜到，你一定很满意了。但如果你发布一件商品，在淘宝上过1个小时还搜不到，你肯定要郁闷了。另一个难点是如何保证非常高的容量和并发量？再往后面就要考虑断句和语义分析的问题，以及推荐算法等更加智能的问题。
备注：这本书没有详细的去介绍这个实现细节了。
商用存储系统的局限和不足
在一次架构师大会上，章文嵩博士总结了几点商用存储系统的局限和不足。
- 商用存储系统没有对小文件存储和读取的环境进行有针对性的优化；
- 文件数量大，网络存储设备无法支撑；
- 整个系统所连接的服务器越来越多，网络连接数已经达到网络存储设备的极限；第四，商用存储系统扩容成本高，10TB的存储容量需要几百万元，而且存在单点故障，容灾和安全性无法得到很好的保证。
谈到在商用系统和自主研发之间的经济效益方面的对比，章文嵩博士列举了以下几点经验。
- 商用软件很难满足大规模系统的应用需求，无论是存储、CDN还是负载均衡，在厂商实验室端，都很难实现如此大的数据规模测试。
- 在研发过程中，将开源和自主开发相结合，会有更好的可控性，若系统出了问题，完全可以从底层解决问题，系统扩展性也更高。
- 在一定规模效应的基础上，研发的投入都是值得的。下图演示的是一个自主研发和购买商用系统的投入产出比，实际上，图中交叉点的左边，购买商用系统都是更加实际和经济性更好的选择，只有在规模超过交叉点的情况下，自主研发才能收到较好的经济效果。实际上，规模化达到如此程度的公司并不多，不过淘宝网已经远远超过了交叉点。
?
第四，自主研发的系统可在软件和硬件的多个层次之间不断优化。
淘宝文件系统——TFS
说到TFS的系统架构，首先要描述清楚业务需求，淘宝对图片存储的需求大概可以描述如下：文件比较小；并发量高；读操作远大于写操作；访问随机；没有文件修改的操作；要求存储成本低；能容灾，能备份。显然，应对这种需求时要用分布式存储系统；由于文件大小比较统一，可以采用专有文件系统；由于并发量高，读写随机性强，需要更少的I/O操作；考虑到成本和备份，需要用廉价的存储设备；考虑到容灾，需要能平滑扩容。
参照GFS并做了大量的优化之后，TFS 1.0版的架构图如下。
?
从上面的架构图可看出：集群由一对Name Server和多台Data Server构成，Name Server的两台服务器互为双机，这就是集群文件系统中管理节点的概念。
在这个系统中：
●每个Data Server运行在一台普通的Linux主机上；
● 以Block文件的形式存放数据文件（一个Block的大小一般为64MB）；
● Block存储多份是为了保证数据安全；
● 利用ext3文件系统存放数据文件；
● 磁盘raid5做数据冗余；
● 文件名内置元数据信息，用户自己保存TFS文件名与实际文件的对照关系，这使得元数据量特别小。
淘宝TFS文件系统在核心设计上最大的取巧在于，传统的集群系统中元数据只有1份，通常由管理节点来管理，因而很容易成为瓶颈。而对于淘宝网的用户来说，图片文件究竟用什么名字来保存他们并不关心，因此，TFS在设计规划上考虑在图片的保存文件名上暗藏了一些元数据信息，例如，图片的大小、时间、访问频次等信息，包括所在的逻辑块号。而在实际的元数据上，保存的信息很少，因此，元数据结构非常简单。仅仅只需要一个FileID就能够准确定位文件在什么地方。由于大量的文件信息都隐藏在文件名中，整个系统完全抛弃了传统的目录树结构，因为目录树开销最大。拿掉后，整个集群的高可扩展性可极大地提高。实际上，这一设计理念和目前业界的“对象存储”较类似。
在TFS 1.3版本中，工程师们重点改善了心跳和同步的性能，最新版本的心跳和同步在几秒钟之内就可完成切换，同时进行了一些新的优化，包括元数据存储在内存中、清理磁盘空间等。性能上也做了优化，包括如下内容。
● 采用ext4文件系统，并且预分配文件，减少ext3等文件系统数据碎片带来的性能损耗；
● 单进程管理单块磁盘的方式，摒除RAID5机制；
● 带有HA机制的中央控制节点，在安全稳定和性能复杂度之间取得平衡；
● 缩减元数据大小，将更多的元数据加载入内存，提升访问速度；
● 跨机架和IDC的负载均衡及冗余安全策略；
●完全平滑扩容。
对于整个图片服务来说，仅有TFS还是不够的，整个图片服务机器的拓扑结构如下图所示。
?
整个图片存储系统就像一个庞大的服务器，有处理单元、缓存单元和存储单元。前面已经介绍过后台的TFS集群文件存储系统，在TFS前端，还部署着200多台图片文件服务器，用Apache实现，用于生成缩略图的运算。值得一提的是，根据淘宝网的缩略图生成规则，缩略图都是实时生成的。这样做的好处有两点：一是为了避免后端图片服务器上存储的图片数量过多，大大节约后台存储空间的需求，我们计算过，采用实时生成缩略图的模式比提前全部生成好缩略图的模式节约90%的存储空间。也就是说，存储空间只需要后一种模式的10%。二是，缩略图可根据需要实时生成，这样更加灵活。
图片文件服务器的前端则是一级缓存和二级缓存，前面还有全局负载均衡的设置，用于解决图片的访问热点问题。图片的访问热点一定存在，重要的是，让图片尽量在缓存中命中。目前淘宝网在各个运营商的中心点设有二级缓存，整体系统中心店设有一级缓存，加上全局负载均衡，传递到后端TFS的流量就已经非常均衡和分散了，对前端的响应性能也大大提高。根据淘宝的缓存策略，大部分图片都尽量在缓存中命中，如果缓存中无法命中，则会在本地服务器上查找是否存有原图，并根据原图生成缩略图，如果都没有命中，则会考虑去后台TFS集群文件存储系统上调取。因此，最终反馈到TFS集群文件存储系统上的流量已经被大大优化了。
淘宝网将图片处理与缓存编写成基于Nginx的模块，我们认为，Nginx是目前性能最高的HTTP服务器，代码清晰，模块化非常好。淘宝网使用GraphicsMagick进行图片处理，采用了面向小对象的缓存文件系统，前端有LVS+Haproxy将原图和其所有的缩略图请求都调度到同一台Image Server（图片服务器）。在文件定位上，内存用Hash算法做索引，最多一次读盘。另外会有很多相同的图片重复上传上来，去除重复文件也是采用Hash算法来做的。写盘方式则采用Append方式写，并采用了淘汰策略FIFO，主要考虑降低硬盘的写操作，没有必要进一步提高Cache命中率，因为ImageServer和TFS位于同一个数据中心，读盘效率还是非常高的。
高性能服务框架HSF
?
服务的提供者启动时通过HSF框架向ConfigServer注册服务信息（接口、版本、超时时间、序列化方式等），这样ConfigServer上面就定义了所有可供调用的服务（同一个服务也可能有不同的版本）；服务调用者启动的时候向ConfigServer注册对哪些服务感兴趣（接口、版本），当服务提供者的信息变化时，ConfigServer向相应的感兴趣的服务调用者推送新的服务信息列表；调用者在调用时则根据服务信息的列表直接访问相应的服务提供者，而无须经过ConfigServer。我们注意到ConfigServer并不会把服务提供者的IP地址推送给服务的调用者，HSF框架会根据负载状况来选择具体的服务器，返回结果给调用者，这不仅统一了服务调用的方式，也实现了“软负载均衡”。平时ConfigServer通过和服务提供者的心跳来感应服务提供者的存活状态。