12 | 
13 |
14 |
15 |
10 |
11 |
12 |
13 |
14 |
15 |
16 | 在线阅读 >>
17 |
18 |
19 | 速览手册
20 | ·
21 | 代码实践
22 | ·
23 | 参考资料
24 |
25 |
40 |
45 |
46 |
47 |
64 |
97 |
116 |
117 |
118 |
119 |
120 |
121 |
122 |
123 |
124 |
125 |
126 |
127 |
128 |
129 |
130 | -->
131 |
132 |
133 |
144 |
145 |
146 |
147 |
156 |
157 |
158 |
--------------------------------------------------------------------------------
/02~编程大师/Robert C. Martin.md:
--------------------------------------------------------------------------------
1 | Robert C. Martin，世界级编程大师，设计模式和敏捷开发先驱，敏捷联盟首任主席，C++ Report 前主编，被后辈程序员尊称为“Bob 大叔”。20 世纪 70 年代初成为职业程序员，后创办 Object Mentor 公司并任总裁。
2 |
3 | 
4 |
5 | Robert C. Martin
6 |
7 | Martin 还是一名多产的作家，至今已发表数百篇文章、论文和博客文章。著有《代码整洁之道》《代码整洁之道：程序员的职业素养》《敏捷软件开发：原则、模式和实践》《UML：Java 程序员指南》等。
8 |
9 | 著名的对象范型和 C++专家考帕里安(James O. Coplien)曾这样评价 Bob 大叔：
10 |
11 | 那班求索者多年来并肩奋斗，不但是为求一己之进步，更将他们的知识通过和你手上正在做的事一般的工作奉献给这个行业，使得编程世界略有改善。
12 |
13 | **天才少年 Bob 的成长之路**
14 |
15 | 1964 年，12 岁的 Bob 写下人生第一行代码。
16 |
17 | 1965 年，Bob 开启了人生中算得上专业的第一次合作，与小搭档 John Marchese 一起造电脑，Bob 思考，John 动手，两个人忙活了数百个小时，捣鼓出了不少看着相当有型的家伙，上面装着继电器、按钮、小灯，甚至还安装了一个电传打字机！虽然这些电脑没法用，但是看起来真的很棒，他们也确实很用心，这对于两个 13 岁的小朋友来说，相当了不起了！
18 |
19 | 
20 |
21 | 电动打字机
22 |
23 | 1968 年，在中学第一年认识了新的小伙伴 Tim Conrad，开始了新一轮的造电脑工程，这次由 Tim 思考，Bob 动手，Tim 还教给了 Bob 一些电子学知识，Tim 也是第一个给 Bob 介绍 PDP-8 的人。他们用了一些很基础的元器件，真的造出了一台可以工作的 18 位二进制计算器，能够进行加减乘除的运算，他们兴奋极了，那年他们把所有的假期都投了进去。
24 |
25 | 后来，他们还自学了计算机课程，在那个年代，这是一个相当不容易的事情，但他们做到了。他们特别找来了有关 PDP-8 汇编器、FORTRAN、COBOL、PL/1，他们就像海绵一般在书中汲取知识，并写了一堆根本根本没有可能去实际执行的程序，因为那时根本没有计算机可以供实操，但纯粹出于爱好，他们仍然孜孜不倦写了许多程序。
26 |
27 | 
28 |
29 | PDP-8 汇编器
30 |
31 | 1969 年，Tim、Bob 以及他们的伙伴 Richard Lloyd 成为了 ACS 公司的程序员，为芝加哥卡车司机工会开发实时会计系统。17 岁的他们觉得上大学是浪费时间，决定马上进入职场，在那里他们遇到了 Bill Hohri、Frank Ryder、Big Carlin 和 John Miller，他们为这些年轻人提供了学习专业编程的实战机会，Bob 在其中颇受教益。
32 |
33 | 这份工作经历也让 Bob 意识到，作为一个程序员还应该具备某些素养，例如对着你的上司，说“**YES**”和“**NO**”。
34 |
35 | 
36 |
37 | Bob 在 ASC 工作时，他的上司 Frank 是一位退役的空军上校，这位领导的处事风格雷厉风行：我发出指令、你们按时上线。初入职场的一众小年轻，包括 Bob，根本不敢看他的眼睛，更不敢抗议时间不够，最终的结果是系统按时上线，故障频发，无限次数的系统崩溃、系统重启。
38 |
39 | Bob 认为，程序员往往太容易说“YES”，总是在没有明确目标和期限的情况下，就第一时间草率地给出了确认的答复，任务交付时却无法实现自己的承诺。
40 |
41 | 有时候，获取正确决策的唯一途径，便是勇敢无畏地说出“不”字……我们要明白，委屈专业原则以求全，并不是问题的解决之道。舍弃这些原则，只会制造出更多的麻烦。
42 |
43 | 只要你愿意尝试，在工作中对着那些不合理的工作任务，主动说几次“NO”，之后你会逐渐发现：你只需要花三分的力气去拒绝那些无法完成的工作任务，就可以节省十分甚至二十分开发的时间；相反，如果在没有明确目标和期限的情况下，就草率给出了确认的答复，往往会非常被动，到最后，项目就落得著名的 IBM OS/360 操作系统的失败下场。
44 |
45 | 在 Bob 的经典书籍《代码整洁之道》中也提到，作为一个程序员不仅是懂得“NO”背后所蕴含的意义和责任，“YES”背后的意义和责任同样重要。
46 |
47 | （说“YES”时）你对自己将会做某件事做了清晰的事实陈述，而且还明确说明了完成期限。那不是指别人，而是指你自己。你陈述的是自己会去执行的一项行动，而且，你不是“可能”去做，或是“可能做到”，而是 “会”做到。
48 |
49 | 但“YES”背后常常跟着的是屡见不鲜的项目延期，绝大部分原因就是在这种不负责任的情况下说 “YES”导致的。
50 |
51 | 在 Bob 的学生时代、职业生涯中，直接导师并不多，因为他的成长的年代中并没有很多有经验的老师、程序员。Bob 在工作项目的摸索及读一些杰出人物的著作来汲取知识、积累经验，这些人包括 Grady Booch（《UML 用户指南》作者）, Tom DeMarco（《项目百态》作者）, Meilir Page-Jones（《UML 面向对象设计基础》作者）, Erich Gamma（《设计模式》作者）, Martin Fowler（《重构》作者）, Bertrand Meyer（《面向对象软件构造》作者）, Kent Beck（《测试驱动开发》作者），等等。Bob 感觉这些教导都是充满价值的。
52 |
53 | 随后 Bob 在 Teradyne 工作，他从老板、工作伙伴们的身上学到了许多他认为有价值的东西，特别是 Mike Carew，他们成为了黄金搭档，“如果你想活儿干得又快又好，就把他交给 Bob 和 Mike！“他们共事的时光充满欢乐。
54 |
55 | **糟糕的代码能让一个公司关门大吉！**
56 |
57 | 在一个项目中，某位同事花三个星期写完一串代码后离职了，在没有批注、没有规律的情况下，果然没有人能够理解这串代码，最终只能由新的同事重新撰写。这段经历让他从此对代码的整洁深感重视。
58 |
59 | 1987 年，Bob 开始和 Jim Newkirk 搭档，随后他们相继离开 Teradyne，加入了 Clear Communication。
60 |
61 | 于此同时，有家公司写了一个很流行的杀手应用，许多专业人士都买来用，包括 Bob。然后，发布周期开始拉长，缺陷总是不能修复，装载时间越来越久，崩溃的概率也越来越大，至今 Bob 还记得自己在某天沮丧地关掉那个程序，从此再不用它时的绝望心情。果不其然，在那之后不久，该公司就关门大吉了。
62 |
63 | 后来，Bob 见到那家公司的一位早期雇员，问他发生了什么事，而他的回答令 Bob 愈发恐惧起来。原来，当时他们赶着推出产品，代码写得乱七八糟，特性越加越多，代码也越来越烂，最后再也没法管理这些代码了，只好放着不管，最终，糟糕的代码毁了这家公司。这个事情更是让 Bob 确定了代码的整洁是需要引起重视的，软件质量，不但依赖架构及项目管理，而且与代码质量紧密相关，但当时的他并没有能力来改变这一切。
64 |
65 | 
66 |
67 | Robert C. Martin
68 |
69 | **99%的程序员都在为糟糕代码头痛！**
70 |
71 | Bob 和 Jim 一起在 Clear Communication 拼搏了好几年后，共同创办了 Object Mentor 公司，Bob 认为，在他有幸共事过的人中，Jim 是最率直、最严谨和最专注的人，从 Jim 身上获益良多。
72 |
73 | 直到现在，Bob 仍坚持阅读这一习惯，每天花费大量的时间阅读，甚至包括博客和文章，从中紧跟科技发展。他曾坦言自己一直都在寻找值得一读的好书。
74 |
75 | 想到那个困扰了他许久的难题，也是大部分程序员都遭遇过的难题——糟糕的代码，他本能的就想迎头而上，像他的导师们一样，像 Jim 一样，给别人带来帮助。于是，他开始写作，在**《代码整洁之道》**一书中分享了自己多年编程生涯所累积的项目实践经验，将代码整洁的多种解决办法倾囊相授，受到了广大程序员的喜爱及追捧。
76 |
77 | Bob 曾在为 ASD 所写的序中写道：
78 |
79 | 最好的软件开发人员都知道一个秘密：美的东西比丑的东西创建起来更廉价，也更快捷。
80 |
81 | 而构建、维护一个美的软件系统所花费的时间、金钱都要少于丑的系统。
82 |
83 | 美的系统是灵活、易于理解的，构建、维护它们就是一种快乐。”
84 |
85 | 如果说 ASD 中更多的是设计思想和模式精髓的阐述，那么在**《代码整洁之道》**中，Bob 为程序员们提供了更为详尽的微距视角，涉及“命名”、“函数”、“代码格式”、 “异常处理”、“单元测试”等编码主题，巨细靡遗地向软件工匠们极力传授整洁编码的艺术，进一步向软件开发社区慷慨分享了他在探索“软件之美”旅途中的参证心得。
86 |
87 | Bob 还在书中提出一种观点：代码质量与其整洁度成正比。干净的代码，既在质量上较为可靠，也为后期维护、 升级奠定了良好基础。
88 |
89 | 他认为，无论是敏捷开发流派还是传统开发流派，想要保证软件质量，不仅仅依赖架构及项目管理，更与代码质量紧密相关。
90 |
91 | 《代码整洁之道》中提到 Bob 大叔认为把代码变得整洁的，就首先要了解三个注释，即：
92 |
93 | **不恰当的信息**
94 |
95 | 让注释传达本该更好地在源代码控制系统、问题追踪系统或任何其他记录系统中保存的信息，是不恰当的。
96 |
97 | 例如，修改历史记录只会用大量过时而无趣的文本搞乱源代码文件。通常，作者、最后修改时间、 SPR 数等元数据不该在注释中出现。
98 |
99 | 注释只应该描述有关代码和设计的技术性信息。
100 |
101 | **废弃的注释**
102 |
103 | 过时、无关或不正确的注释就是废弃的注释。注释会很快过时。最好别编写将被废弃的注释。
104 |
105 | 如果发现废弃的注释，最好尽快更新或删除。
106 |
107 | 废弃的注释会远离它们曾经描述的代码，变成代码中无关和误导阅 读者的浮岛。
108 |
109 | **糟糕的注释**
110 |
111 | 值得编写的注释，也值得好好写。
112 |
113 | 如果要编写一条注释，就花时间保证写出最好的注释，字斟句酌，使用正确的语法和拼写，别闲扯，别画蛇添足，要保持简洁。
114 |
115 | **糟糕的代码最终会成为吞噬人的黑洞**
116 |
117 | 
118 |
119 | 上面的图片是**《代码整洁之道》**的封面，是用来自于哈勃望远镜那副著名的可见光相片和 Spitzer（斯比泽）轨道探测器最新红外影像组合而成的 M104：草帽星系，它坐落于处女座，离地球仅 3000 万光年，其核心是一个质量超大的黑洞，有 100 万个太阳那么重，仿佛经历了大爆炸之后碎片四溅的产物。
120 |
121 | 让人不禁联想到那些代码不整洁、风格各异且不可维护的项目，就像一个个的黑洞，存在着某天会定时爆发的风险，而当它真正爆发时，这个项目的所有人都会因此遭殃。
122 |
123 | 当你负责一个小型项目时，如果追求速度，力求快速出成果，这时可以率性而为。当项目逐渐扩大，规范就会逐步显出它的重要性。在软件开发中也是一样，归置到位的工具能提升生产力。软件质量，不但依赖于架构及项目管理，而且跟代码质量息息相关。代码质量与其整洁度成正比。干净的代码，既在质量上较为可靠，也为后期维护、升级奠定了良好的基础。
124 |
125 | **世界级软件开发大师的多重身份**
126 |
127 | 如今，Bob 除了写作，还会为 cleancoders.com 制作视频，也会技术会议上讲话，从世界级软件开发大师到畅销专业书籍作家再到台前传达专业领域知识的权威人物，Bob 给我们带来一次次惊喜。
128 |
129 | 在这个过程中，他发现自己不止在编程方面颇有心得，对于站在人前传达信息这件事也颇有天赋。
130 |
131 | 
132 |
133 | Robert C. Martin
134 |
135 | 我们觉得他“变身”了，想知道他是如何从一位职业的程序员变身成为这个领域的导师，但对他来说，这是一个缓慢的成长过程：“我花了整整 20 年来积累工作经验，又花了 20 年才做到今天的成就。‘变身’从来都不是我意料之中的事，也不是我的目的；但这个过程对我来说是一种享受”。
136 |
--------------------------------------------------------------------------------
/02~编程大师/Martin Fowler.md:
--------------------------------------------------------------------------------
1 | # Martin Fowler
2 |
3 | Martin Fowler，世界级软件开发大师，敏捷开发的开拓者和创始人全球知名的面向对象分析设计、UML、模式等专业领域的领头羊，首创敏捷开发方法论，被誉为软件开发“教父”，现任职于全球知名技术咨询公司 ThoughtWorks，首席科学家。
4 |
5 | 
6 |
7 | Martin Fowler
8 |
9 | 坊间流传着这样一句话，如果有一本编程技术类书籍能够让读者在工作或实践多年后，还在反复咀嚼玩味、爱不释手、引导着读者前进着，那个必定是 Martin Fowler 的《重构》。
10 |
11 | Martin 还是 IT 领域的知名作家，他撰写的七本有关软件开发的书广受程序员们的喜爱，包括重构、企业应用程序体系结构模式和 UML Distilled 等领域。其中《重构》风靡国内外，拥有数百万读者，国内豆瓣评分高达 9.5 分。
12 |
13 | 
14 |
15 | 
16 |
17 | Object Technology International, Inc，Erich Gamma 曾这样评价 Martin：
18 |
19 | Martin Fowler 清楚地揭示了重构过程，他为面向对象软件开发所做的贡献难以估量。他解释了重构的原理和最佳实践，并指出何时何地你应该开始挖掘你的代码以求改善。
20 |
21 | 因此，我极力推荐你试试 Martin Fowler 的重构手法，你和你的程序都将因此更美好。
22 |
23 | **软件开发“教父”的重构生涯**
24 |
25 | Martin Fowler，1963 年出生在英格兰的沃尔索耳，正是编程世界刚刚起步的年代。
26 |
27 | Martin 在 80 年代初开始接触软件行业，那时候 Smalltalk 还是一门很火的语言，大家都在学习这门语言，而 Martin 也刚开始从事软件工作——关于信息系统对象建模方面的顾问。
28 |
29 | 那个年代没有任何有关面向对象分析和设计的书籍，大家都是用一种简单的图符表示法，然后提出一个简单的建模过程，最后用几个简单的示例来加以说明。但 Martin 认为不应该把重点放在过程——即如何建模，而是把重点放在过程的结果——即模型本身，尽管这与当时大环境下的创建方式是相悖的。
30 |
31 | 
32 |
33 | 到了 90 年代初，Martin 发现，大多数程序员很难通过紧跟技术创新的脚步来享受软件工程领域的新成果。
34 |
35 | 身为一个信息系统对象建模顾问，Martin 从 Smalltalk 上学得的专业知识是远远超过这个职业所需要的，他觉得自己既然有了这些建模方面的理念，同时又对编程方面很感兴趣，所以他不单在建模方面帮助别人，还在编程方面进行指导——借助外力的帮助，精确地运用 UML。
36 |
37 | 
38 |
39 | 从建模到编程语言，他把这些都看成一件完整的、而非毫无关联的事。
40 |
41 | 这样的工作持续了近十年，1999 年，Martin 迎来了他人生中意义重大的一年。
42 |
43 | 那时 Martin 造访了客户调研的开发项目时发现，该系统的核心继承体系相当凌乱，为此，他建议负责该项目的经理将这些代码进行整理，但是项目经理认为在项目面临很大的进度压力下，只要程序看上去还可以运行就算是完成。
44 |
45 | 这种情况下，《重构：改善既有代码的设计》面世了，Martin 在这本书中揭示了重构的过程，解释了重构的原理和最佳实践方式，并给出了何时以及何地应该开始挖掘代码以求改善。
46 |
47 | 重构这个理念一经推出，受到了广大程序员的喜爱，他们觉得在不改变代码外在行为的前提下，对代码做出修改，以改进程序的内部结构是一个非常妙的事。后来，这本风靡国际 IT 行业的《重构》被引入国内，在豆瓣评分以 9.2 的高分长期霸屏程序员必读书单中。
48 |
49 | 2010 年，第五届敏捷软件开发大会“敏捷中国 2010”上，Martin 的“敏捷宣言”又一次引领了整个 IT 行业对敏捷开发的认识，从此“敏捷”二字开始风行国内 IT 领域。对程序员们来说，他就是当之无愧的先行者。
50 |
51 | 
52 |
53 | Martin Fowler
54 |
55 | 就在去年，这位先行者又全面升级了《重构》，《重构：改善既有代码的设计（第 2 版）》面世了，国内外掀起一阵抢购热潮，豆瓣评分更是高达 9.5 分。
56 |
57 | **Martin 定义的重构到底是什么？**
58 |
59 | 说起重构，还要从 1999 年发生在 Martin 身上的一件事说起。面对凌乱的系统的核心继承体系，他建议负责该项目的经理将这些代码进行整理，但是被项目经理拒绝。
60 |
61 | 随后，Martin 把自己的想法第一时间告诉了在这个继承体系上工作的程序员，程序员都很敏锐，马上就看出问题的严重性，特别是在这种需要借助外力才能发现问题。他们立刻用了两天的时间整理好这个继承体系，并删掉了其中一半代码，功能毫发无损，而且发现在继承体系中加入新的类或使用系统中的其他类都更快、更容易了，他们十分感谢 Martin。
62 |
63 | 但项目经理很不高兴，他觉得这些程序员却白白耗费了两天时间，做的工作却与未来几个月要交付的大量功能毫不相干，明明原先的代码运行起来还算正常，为什么要为了可能发生的问题去花费时间提前预防呢？
64 |
65 | 不过在 6 个月之后，这个项目还是宣告失败了，原因是代码太复杂，无法调试，也无法将性能调优到可接受的水平。再后来，这个项目重新启动，唯一的解决办法就是从头开始编写整个系统，Kent Beck 受邀做了顾问。他做了几件迥异以往的事，其中最重要的一件就是听从 Martin 的建议，坚持以持续不断的重构行为来整理代码。
66 |
67 | 那时，Martin 第一次认识到重构的重要且不可替代性。
68 |
69 | “重构”这个概念最开始来自于 Smalltalk 圈子，由于重构是框架开发中不可缺少的一部分，所以当框架设计者讨论自己的工作时，这个术语就诞生了。
70 |
71 | 当他们精炼自己的类继承体系时，当他们叫喊自己可以拿掉多少多少行代码时，重构的概念慢慢浮出水面，后来重构就进入了其他编程语言阵营之中。
72 |
73 | 说得直白一点，所谓重构（refactoring）就是这样一个过程：在不改变代码外在行为的前提下，对代码做出修改，以改进程序的内部结构。
74 |
75 | 重构是一种经千锤百炼形成的有条不紊的程序整理方法，可以最大限度地减小整理过程中引入错误的概率。本质上说，重构就是在代码写好之后改进它的设计。
76 |
77 | “在代码写好之后改进它的设计”这种说法有点儿奇怪。在软件开发的大部分历史时期，大部分人认为，应该先设计而后编码：首先得有一个良好的设计，然后才能开始编码。
78 |
79 | 但是，随着时间流逝，人们不断修改代码，于是根据原先设计所得的系统，整体结构逐渐衰弱。代码质量慢慢沉沦，编码工作从严谨的工程堕落为胡砍乱劈的随性行为。
80 |
81 | 而“重构”正好与此相反。
82 |
83 | 哪怕手上有一个糟糕的设计，甚至是一堆混乱的代码，我们也可以借由重构将它加工成设计良好的代码。重构的每个步骤都很简单，甚至显得有些过于简单：只需要把某个字段从一个类移到另一个类，把某些代码从一个函数拉出来构成另一个函数，或是在继承体系中把某些代码推上推下就行了。
84 |
85 | 但是，聚沙成塔，这些小小的修改累积起来就可以根本改善设计质量。这和一般常见的“软件会慢慢腐烂”的观点恰恰相反。
86 |
87 | 有了重构以后，Martin 发现工作的平衡点开始发生变化，例如，设计不是在一开始完成的，而是在整个开发过程中逐渐浮现出来。在系统构筑过程中，他学会了如何不断改进设计。这个“构筑-设计”的反复互动，可以让一个程序在开发过程中持续保有良好的设计。
88 |
89 | **Martin 认为，重构这东西不可能一开始就完全正确，它将随着设计者的经验成长而进化，代码被阅读和被修改的次数远远多于它被编写的次数。而保持代码易读、易修改的关键，就是重构。**
90 |
91 | 
92 |
93 | 作为一本为专业程序员编写的重构指南——《重构》，Martin 的目的是告诉所有程序员如何以一种可控且高效的方式进行重构，从而减少了开发过程中的风险。
94 |
95 | 书里提出的重构准则将帮助他们学习如何有条不紊地、一次一小步地修改代码、改进程序结构，且不会引入错误的正确的重构方式，最终得到有效的、长期可运行的代码程序，而不是去遵循那句古老的工程谚语：“如果它还可以运行，就不要动它。”
96 |
97 | **重构再度升级**
98 |
99 | 《重构》自 1999 年面世以来，已经经过 21 年了。软件行业里新的编程语言不断涌现，老的编程语言也加快迭代，而函数式编程和面向对象一样成了主流编程语言的标配。不仅软件开发技术发生了很多重要的变化，各种软件开发工具也日益现代化，对开发的更好支持也已成为主流编程语言新的核心竞争力。
100 |
101 | 而现在，“重构”这一理念已被读者广泛接纳，作为一种经千锤百炼形成的有条不紊的程序整理方法，能够最大限度地减小整理过程中引入错误的概率，成为编程的词汇表中不可或缺的部分，《重构》一书至今依旧被无数程序员奉为软件开发领域的经典之作。
102 |
103 | 但重构的扎实功夫要学起来、做起来，颇不是件轻松的事，且不说详尽到近乎琐碎的重构手法，光是单元测试一事，怕是已有九成程序员无法企及，渐渐地，“重构”成了一块漂亮的招牌，大家都愿意挂上这个名号，可实际上干的却多是“刀劈斧砍”的勾当。
104 |
105 | 就国内先如今的情况而论，“重构”概念的表里分离，大有愈演愈烈之势。随着当年的一线技术人员纷纷走上领导岗位，他们乐于将“重构”这块漂亮招牌用在更宽泛的环境下，例如系统架构乃至组织结构，都可以“重构”一下。
106 |
107 | 然而基本功的欠缺，却也一路如影随形。当年在对象中的刀劈斧砍，如今被照搬到了架构、组织的调整。于是“重构”的痛苦回忆又一遍遍重演，甚而程度更深、影响更广、危害更烈。
108 |
109 | 通过重构，现在的程序员普遍通过微增量来开发系统、编写测试用例。但 Martin 认为这远远不够，重构的影响其实应该更广泛，20 年前，他和其他先行者鼓励大家都接受重构这一概念，但是，在整个行业普及重构仍需要相当长的时间。
110 |
111 | 对于 IT 领域来说，Martin 不仅仅是一个先行者，他还是一个引路者。
112 |
113 | Martin 希望看到更多人使用他们大力推广的测试法，使用持续集成和持续交付等方法。但涉及上述概念，Martin 觉得自己只能尽量在书中，从主客观上尽可能详尽地解释这些技术，并希望这会说服更多人进行尝试，“当他们尝到甜头后就会在工作中真正用上这些方法“。
114 |
115 | [](https://www.epubit.com/bookDetails?id=N42831)
116 |
117 | 针对这一现象，Martin 推出了《重构：改善既有代码的设计（第 2 版）》，他在第 1 版的基础上做了全面修订，反映了编程领域业 20 年来发生的许多变化，但 Martin 传递的理念也始终如一：**不改变外在行为，而提高代码质量**，但将基础功夫做得更扎实。让人不禁感叹于他对“微末功夫”的执着！
118 |
119 | 很多人好奇 Martin 为什么决定将《重构》再版？Martin 给出了 3 个原因：
120 |
121 | - 第 1 版里的代码已经很陈旧了，书里面还有 Java.util.Vector；
122 | - 一些重构并非是与面向对象紧耦合在一起的；
123 | - Martin 认为 Java 是一种非常严格的面向对象编程语言，而第 1 版中所有的重构都是基于面向对象的，他想通过再版来说明每个程序员都可以用任何（编程）语言、在任何环境中、遵循书中提到的范例进行重构，这也是他决定再版《重构》的源动力。
124 |
125 | **Martin 认为重构的基本机制不会发生巨大转变，即使使用面向对象语言工作也是如此。**他觉得有一等函数很好，可以尝试许多函数式的理念，例如，写软件时大部分函数都具备引用透明性，这在面向对象系统和在函数式系统中都是好事。
126 |
127 | 所以 Martin 不像许多人那样在函数式编程和面向对象编程间画出明确界限，他认为两者有很多共同的地方，未必存在巨大差异。他鼓励程序员不要有门户之见，要用综合理念来解决问题。
128 |
129 | 对于最新版《重构》，Martin 认为有一个重构手法也许值得注意，拆分阶段（split phase）。早在几年前，当 Martin 和 Ken Beck 商谈拆分阶段的时候，Martin 第一次意识到这也是重构手法。
130 |
131 | 通过这种重构手法，Martin 将大量计算合理分为两个阶段，使用中间数据结构进行通信。其中一个例子是解析拆分阶段可有效地将 token 从解析中抽离出来，这样就得到了一个可可保存在存储器种的 token 流，可处理相关字符串、文本字符串。
132 |
133 | 
134 |
135 | Martin Fowler
136 |
137 | 而说到重构工具，Martin 和 Kent 做了很多年了，但他们从来没有意识到工具的重要性；当他们意识到这一点之后，他们感觉重构工具已经无处不在，他们认为这个内容非常重要，然后 Martin 就真把这些新内容加到新版中了。
138 |
139 | **重构的关键是理念：通过进行最细微的改变，然后将这些变化串联起来，这就是重构思维核心**。将一个大变化拆分为许多小变化，又在尽可能多进行细微变化的同时，不改变系统的整体表现，然后随时间推移，反复练习并思考如何进行拆分。Martin 在《重构 2》一书中说过，他通过重构框架思考问题的体验，尝试各种高效的重构手法并做出决定，最重要的就是通过实践进行重构。
140 |
141 | 他认为在尝试了不同的重构手法后，找出能重构手法生成理想序列，继而进行尝试识别出这种重构手法，而同样的逻辑也适用于更广泛的层面。
142 |
143 | 因此，他采用了 70 多个种可行的重构，并且把每个重构都介绍了一种经过验证的代码变换手法的动机和技术。就像软件开发的大多数工作一样，重构除了动手做，别无他法，必须反复实践，必须在项目中使用重构。
144 |
145 | Martin 始终希望，重构准则能帮助大家一步步修改自己的代码，减少了开发过程中的风险。
146 |
147 | **重构=编码**
148 |
149 | 在日新月异的 IT 技术世界里，不变的东西其实还是有的——重构。
150 |
151 | 从《重构》的英文原版引进国内，到现在已经过去 20 年了。Martin Fowler 这次对本书进行的重构，体现了近年来编程领域的一些思潮变化，既有设计，又永远有改进空间。
152 |
153 | 尽管时间是最强大的重构工具，连书里的示例语言都从 Java 变成 JavaScript 了，但书中的理念和实践的价值并没有随时间流逝。
154 |
155 | 重构早就成了软件开发从业者本能的一部分，每个 IDE 都内置了重构功能，每个程序员都定期重构自己的代码。
156 |
157 | 对于软件工程师来说，重构，并不是额外的工作，它就是编码本身。切实地读懂了《重构》的软件工程师，在能力上都会获得一个数量级的提升。
158 |
--------------------------------------------------------------------------------
/header.svg:
--------------------------------------------------------------------------------
1 |
--------------------------------------------------------------------------------
/LICENSE:
--------------------------------------------------------------------------------
1 | Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International
2 | Public License
3 |
4 | By exercising the Licensed Rights (defined below), You accept and agree
5 | to be bound by the terms and conditions of this Creative Commons
6 | Attribution-NonCommercial-ShareAlike 4.0 International Public License
7 | ("Public License"). To the extent this Public License may be
8 | interpreted as a contract, You are granted the Licensed Rights in
9 | consideration of Your acceptance of these terms and conditions, and the
10 | Licensor grants You such rights in consideration of benefits the
11 | Licensor receives from making the Licensed Material available under
12 | these terms and conditions.
13 |
14 |
15 | Section 1 -- Definitions.
16 |
17 | a. Adapted Material means material subject to Copyright and Similar
18 | Rights that is derived from or based upon the Licensed Material
19 | and in which the Licensed Material is translated, altered,
20 | arranged, transformed, or otherwise modified in a manner requiring
21 | permission under the Copyright and Similar Rights held by the
22 | Licensor. For purposes of this Public License, where the Licensed
23 | Material is a musical work, performance, or sound recording,
24 | Adapted Material is always produced where the Licensed Material is
25 | synched in timed relation with a moving image.
26 |
27 | b. Adapter's License means the license You apply to Your Copyright
28 | and Similar Rights in Your contributions to Adapted Material in
29 | accordance with the terms and conditions of this Public License.
30 |
31 | c. BY-NC-SA Compatible License means a license listed at
32 | creativecommons.org/compatiblelicenses, approved by Creative
33 | Commons as essentially the equivalent of this Public License.
34 |
35 | d. Copyright and Similar Rights means copyright and/or similar rights
36 | closely related to copyright including, without limitation,
37 | performance, broadcast, sound recording, and Sui Generis Database
38 | Rights, without regard to how the rights are labeled or
39 | categorized. For purposes of this Public License, the rights
40 | specified in Section 2(b)(1)-(2) are not Copyright and Similar
41 | Rights.
42 |
43 | e. Effective Technological Measures means those measures that, in the
44 | absence of proper authority, may not be circumvented under laws
45 | fulfilling obligations under Article 11 of the WIPO Copyright
46 | Treaty adopted on December 20, 1996, and/or similar international
47 | agreements.
48 |
49 | f. Exceptions and Limitations means fair use, fair dealing, and/or
50 | any other exception or limitation to Copyright and Similar Rights
51 | that applies to Your use of the Licensed Material.
52 |
53 | g. License Elements means the license attributes listed in the name
54 | of a Creative Commons Public License. The License Elements of this
55 | Public License are Attribution, NonCommercial, and ShareAlike.
56 |
57 | h. Licensed Material means the artistic or literary work, database,
58 | or other material to which the Licensor applied this Public
59 | License.
60 |
61 | i. Licensed Rights means the rights granted to You subject to the
62 | terms and conditions of this Public License, which are limited to
63 | all Copyright and Similar Rights that apply to Your use of the
64 | Licensed Material and that the Licensor has authority to license.
65 |
66 | j. Licensor means the individual(s) or entity(ies) granting rights
67 | under this Public License.
68 |
69 | k. NonCommercial means not primarily intended for or directed towards
70 | commercial advantage or monetary compensation. For purposes of
71 | this Public License, the exchange of the Licensed Material for
72 | other material subject to Copyright and Similar Rights by digital
73 | file-sharing or similar means is NonCommercial provided there is
74 | no payment of monetary compensation in connection with the
75 | exchange.
76 |
77 | l. Share means to provide material to the public by any means or
78 | process that requires permission under the Licensed Rights, such
79 | as reproduction, public display, public performance, distribution,
80 | dissemination, communication, or importation, and to make material
81 | available to the public including in ways that members of the
82 | public may access the material from a place and at a time
83 | individually chosen by them.
84 |
85 | m. Sui Generis Database Rights means rights other than copyright
86 | resulting from Directive 96/9/EC of the European Parliament and of
87 | the Council of 11 March 1996 on the legal protection of databases,
88 | as amended and/or succeeded, as well as other essentially
89 | equivalent rights anywhere in the world.
90 |
91 | n. You means the individual or entity exercising the Licensed Rights
92 | under this Public License. Your has a corresponding meaning.
93 |
94 |
95 | Section 2 -- Scope.
96 |
97 | a. License grant.
98 |
99 | 1. Subject to the terms and conditions of this Public License,
100 | the Licensor hereby grants You a worldwide, royalty-free,
101 | non-sublicensable, non-exclusive, irrevocable license to
102 | exercise the Licensed Rights in the Licensed Material to:
103 |
104 | a. reproduce and Share the Licensed Material, in whole or
105 | in part, for NonCommercial purposes only; and
106 |
107 | b. produce, reproduce, and Share Adapted Material for
108 | NonCommercial purposes only.
109 |
110 | 2. Exceptions and Limitations. For the avoidance of doubt, where
111 | Exceptions and Limitations apply to Your use, this Public
112 | License does not apply, and You do not need to comply with
113 | its terms and conditions.
114 |
115 | 3. Term. The term of this Public License is specified in Section
116 | 6(a).
117 |
118 | 4. Media and formats; technical modifications allowed. The
119 | Licensor authorizes You to exercise the Licensed Rights in
120 | all media and formats whether now known or hereafter created,
121 | and to make technical modifications necessary to do so. The
122 | Licensor waives and/or agrees not to assert any right or
123 | authority to forbid You from making technical modifications
124 | necessary to exercise the Licensed Rights, including
125 | technical modifications necessary to circumvent Effective
126 | Technological Measures. For purposes of this Public License,
127 | simply making modifications authorized by this Section 2(a)
128 | (4) never produces Adapted Material.
129 |
130 | 5. Downstream recipients.
131 |
132 | a. Offer from the Licensor -- Licensed Material. Every
133 | recipient of the Licensed Material automatically
134 | receives an offer from the Licensor to exercise the
135 | Licensed Rights under the terms and conditions of this
136 | Public License.
137 |
138 | b. Additional offer from the Licensor -- Adapted Material.
139 | Every recipient of Adapted Material from You
140 | automatically receives an offer from the Licensor to
141 | exercise the Licensed Rights in the Adapted Material
142 | under the conditions of the Adapter's License You apply.
143 |
144 | c. No downstream restrictions. You may not offer or impose
145 | any additional or different terms or conditions on, or
146 | apply any Effective Technological Measures to, the
147 | Licensed Material if doing so restricts exercise of the
148 | Licensed Rights by any recipient of the Licensed
149 | Material.
150 |
151 | 6. No endorsement. Nothing in this Public License constitutes or
152 | may be construed as permission to assert or imply that You
153 | are, or that Your use of the Licensed Material is, connected
154 | with, or sponsored, endorsed, or granted official status by,
155 | the Licensor or others designated to receive attribution as
156 | provided in Section 3(a)(1)(A)(i).
157 |
158 | b. Other rights.
159 |
160 | 1. Moral rights, such as the right of integrity, are not
161 | licensed under this Public License, nor are publicity,
162 | privacy, and/or other similar personality rights; however, to
163 | the extent possible, the Licensor waives and/or agrees not to
164 | assert any such rights held by the Licensor to the limited
165 | extent necessary to allow You to exercise the Licensed
166 | Rights, but not otherwise.
167 |
168 | 2. Patent and trademark rights are not licensed under this
169 | Public License.
170 |
171 | 3. To the extent possible, the Licensor waives any right to
172 | collect royalties from You for the exercise of the Licensed
173 | Rights, whether directly or through a collecting society
174 | under any voluntary or waivable statutory or compulsory
175 | licensing scheme. In all other cases the Licensor expressly
176 | reserves any right to collect such royalties, including when
177 | the Licensed Material is used other than for NonCommercial
178 | purposes.
179 |
180 |
181 | Section 3 -- License Conditions.
182 |
183 | Your exercise of the Licensed Rights is expressly made subject to the
184 | following conditions.
185 |
186 | a. Attribution.
187 |
188 | 1. If You Share the Licensed Material (including in modified
189 | form), You must:
190 |
191 | a. retain the following if it is supplied by the Licensor
192 | with the Licensed Material:
193 |
194 | i. identification of the creator(s) of the Licensed
195 | Material and any others designated to receive
196 | attribution, in any reasonable manner requested by
197 | the Licensor (including by pseudonym if
198 | designated);
199 |
200 | ii. a copyright notice;
201 |
202 | iii. a notice that refers to this Public License;
203 |
204 | iv. a notice that refers to the disclaimer of
205 | warranties;
206 |
207 | v. a URI or hyperlink to the Licensed Material to the
208 | extent reasonably practicable;
209 |
210 | b. indicate if You modified the Licensed Material and
211 | retain an indication of any previous modifications; and
212 |
213 | c. indicate the Licensed Material is licensed under this
214 | Public License, and include the text of, or the URI or
215 | hyperlink to, this Public License.
216 |
217 | 2. You may satisfy the conditions in Section 3(a)(1) in any
218 | reasonable manner based on the medium, means, and context in
219 | which You Share the Licensed Material. For example, it may be
220 | reasonable to satisfy the conditions by providing a URI or
221 | hyperlink to a resource that includes the required
222 | information.
223 | 3. If requested by the Licensor, You must remove any of the
224 | information required by Section 3(a)(1)(A) to the extent
225 | reasonably practicable.
226 |
227 | b. ShareAlike.
228 |
229 | In addition to the conditions in Section 3(a), if You Share
230 | Adapted Material You produce, the following conditions also apply.
231 |
232 | 1. The Adapter's License You apply must be a Creative Commons
233 | license with the same License Elements, this version or
234 | later, or a BY-NC-SA Compatible License.
235 |
236 | 2. You must include the text of, or the URI or hyperlink to, the
237 | Adapter's License You apply. You may satisfy this condition
238 | in any reasonable manner based on the medium, means, and
239 | context in which You Share Adapted Material.
240 |
241 | 3. You may not offer or impose any additional or different terms
242 | or conditions on, or apply any Effective Technological
243 | Measures to, Adapted Material that restrict exercise of the
244 | rights granted under the Adapter's License You apply.
245 |
246 |
247 | Section 4 -- Sui Generis Database Rights.
248 |
249 | Where the Licensed Rights include Sui Generis Database Rights that
250 | apply to Your use of the Licensed Material:
251 |
252 | a. for the avoidance of doubt, Section 2(a)(1) grants You the right
253 | to extract, reuse, reproduce, and Share all or a substantial
254 | portion of the contents of the database for NonCommercial purposes
255 | only;
256 |
257 | b. if You include all or a substantial portion of the database
258 | contents in a database in which You have Sui Generis Database
259 | Rights, then the database in which You have Sui Generis Database
260 | Rights (but not its individual contents) is Adapted Material,
261 | including for purposes of Section 3(b); and
262 |
263 | c. You must comply with the conditions in Section 3(a) if You Share
264 | all or a substantial portion of the contents of the database.
265 |
266 | For the avoidance of doubt, this Section 4 supplements and does not
267 | replace Your obligations under this Public License where the Licensed
268 | Rights include other Copyright and Similar Rights.
269 |
270 |
271 | Section 5 -- Disclaimer of Warranties and Limitation of Liability.
272 |
273 | a. UNLESS OTHERWISE SEPARATELY UNDERTAKEN BY THE LICENSOR, TO THE
274 | EXTENT POSSIBLE, THE LICENSOR OFFERS THE LICENSED MATERIAL AS-IS
275 | AND AS-AVAILABLE, AND MAKES NO REPRESENTATIONS OR WARRANTIES OF
276 | ANY KIND CONCERNING THE LICENSED MATERIAL, WHETHER EXPRESS,
277 | IMPLIED, STATUTORY, OR OTHER. THIS INCLUDES, WITHOUT LIMITATION,
278 | WARRANTIES OF TITLE, MERCHANTABILITY, FITNESS FOR A PARTICULAR
279 | PURPOSE, NON-INFRINGEMENT, ABSENCE OF LATENT OR OTHER DEFECTS,
280 | ACCURACY, OR THE PRESENCE OR ABSENCE OF ERRORS, WHETHER OR NOT
281 | KNOWN OR DISCOVERABLE. WHERE DISCLAIMERS OF WARRANTIES ARE NOT
282 | ALLOWED IN FULL OR IN PART, THIS DISCLAIMER MAY NOT APPLY TO YOU.
283 |
284 | b. TO THE EXTENT POSSIBLE, IN NO EVENT WILL THE LICENSOR BE LIABLE
285 | TO YOU ON ANY LEGAL THEORY (INCLUDING, WITHOUT LIMITATION,
286 | NEGLIGENCE) OR OTHERWISE FOR ANY DIRECT, SPECIAL, INDIRECT,
287 | INCIDENTAL, CONSEQUENTIAL, PUNITIVE, EXEMPLARY, OR OTHER LOSSES,
288 | COSTS, EXPENSES, OR DAMAGES ARISING OUT OF THIS PUBLIC LICENSE OR
289 | USE OF THE LICENSED MATERIAL, EVEN IF THE LICENSOR HAS BEEN
290 | ADVISED OF THE POSSIBILITY OF SUCH LOSSES, COSTS, EXPENSES, OR
291 | DAMAGES. WHERE A LIMITATION OF LIABILITY IS NOT ALLOWED IN FULL OR
292 | IN PART, THIS LIMITATION MAY NOT APPLY TO YOU.
293 |
294 | c. The disclaimer of warranties and limitation of liability provided
295 | above shall be interpreted in a manner that, to the extent
296 | possible, most closely approximates an absolute disclaimer and
297 | waiver of all liability.
298 |
299 |
300 | Section 6 -- Term and Termination.
301 |
302 | a. This Public License applies for the term of the Copyright and
303 | Similar Rights licensed here. However, if You fail to comply with
304 | this Public License, then Your rights under this Public License
305 | terminate automatically.
306 |
307 | b. Where Your right to use the Licensed Material has terminated under
308 | Section 6(a), it reinstates:
309 |
310 | 1. automatically as of the date the violation is cured, provided
311 | it is cured within 30 days of Your discovery of the
312 | violation; or
313 |
314 | 2. upon express reinstatement by the Licensor.
315 |
316 | For the avoidance of doubt, this Section 6(b) does not affect any
317 | right the Licensor may have to seek remedies for Your violations
318 | of this Public License.
319 |
320 | c. For the avoidance of doubt, the Licensor may also offer the
321 |
322 |
323 | Licensed Material under separate terms or conditions or stop
324 | distributing the Licensed Material at any time; however, doing so
325 | will not terminate this Public License.
326 |
327 | d. Sections 1, 5, 6, 7, and 8 survive termination of this Public
328 | License.
329 |
330 |
331 | Section 7 -- Other Terms and Conditions.
332 |
333 | a. The Licensor shall not be bound by any additional or different
334 | terms or conditions communicated by You unless expressly agreed.
335 |
336 | b. Any arrangements, understandings, or agreements regarding the
337 | Licensed Material not stated herein are separate from and
338 | independent of the terms and conditions of this Public License.
339 |
340 |
341 | Section 8 -- Interpretation.
342 |
343 | a. For the avoidance of doubt, this Public License does not, and
344 | shall not be interpreted to, reduce, limit, restrict, or impose
345 | conditions on any use of the Licensed Material that could lawfully
346 | be made without permission under this Public License.
347 |
348 | b. To the extent possible, if any provision of this Public License is
349 | deemed unenforceable, it shall be automatically reformed to the
350 | minimum extent necessary to make it enforceable. If the provision
351 | cannot be reformed, it shall be severed from this Public License
352 | without affecting the enforceability of the remaining terms and
353 | conditions.
354 |
355 | c. No term or condition of this Public License will be waived and no
356 | failure to comply consented to unless expressly agreed to by the
357 | Licensor.
358 |
359 | d. Nothing in this Public License constitutes or may be interpreted
360 | as a limitation upon, or waiver of, any privileges and immunities
361 | that apply to the Licensor or You, including from the legal
362 | processes of any jurisdiction or authority.
--------------------------------------------------------------------------------
/01~国内大厂/阿里巴巴/淘宝/99~参考资料/2012~赵超~淘宝技术发展.md:
--------------------------------------------------------------------------------
1 | > [原文地址](https://kb.cnblogs.com/page/132724/)
2 |
3 | **一、引言**
4 |
5 | **光棍节的狂欢**
6 |
7 | “时间到，开抢！”坐在电脑前早已等待多时的小美一看时间已到 2011 年 11 月 11 日零时，便迫不及待地投身于淘宝商城一年一度的大型网购促销活动 —— “淘宝双 11 购物狂欢节”。小美打开早已收藏好的宝贝 —— 某品牌的雪地靴，飞快的点击购买，付款，一回头发现 3000 双靴子已被抢购一空。
8 |
9 | 小美跳起来，大叫一声“欧耶！”
10 |
11 | 小美不知道，就在 11 日零点过后的这一分钟内，全国有 342 万人和她一起涌入淘宝商城。当然，她更不知道，此时此刻，在淘宝杭州的一间办公室里，灯火通明，这里是“战时指挥部”，淘宝技术部的一群工程师，正在紧盯着网站的流量和交易数据。白板上是他们刚刚下的注，赌谁能最准确地猜中流量峰值和全天的交易总额。他们的手边放着充足的食物和各类提神的饮料。
12 |
13 | 一阵急促的电话声响起来，是前线部门询问数据的，工程师大声报着：“第 1 分钟，进入淘宝商城的会员有 342 万”。过一会工程师主动拿起电话：“交易额超过 1 亿了，现在是第 8 分钟。”接下来，“第 21 分钟，刚突破 2 亿”。“第 32 分钟，3 亿了”。“第 1 个小时，4.39 亿”。这些数据随后出现在微博上，引起一片惊呼。
14 |
15 | “完蛋了！”突然有人大喝一声，所有的眼睛都紧张的盯着他，只见他挠挠头，嘿嘿的笑道“我赌的少了，20 亿轻松就能过了，我再加 5 亿”，他跑去白板边上把自己的赌注擦去，写上 25，接下来有人写上 28，有人写上 30，有人跑到微博上开下盘口，同事们纷纷转载下注。接下来的这 24 个小时，战时指挥部的工程师们都不能休息，他们盯着网站的各种监控指标，适时的调整机器和增减功能。顶住第一波高峰之后，这些人开始忙里偷闲的给自己买东西，大家互相交流着哪家买的移动硬盘靠谱，哪家衣服适合自己的女朋友，不时的有人哀嚎宝贝被人抢了、信用卡额度不够了。同时，旁边白板上的赌注越下越大。
16 |
17 | 
18 |
19 | 11 月 11 日，这个棍子最多的日子被网民自我调侃的变成了一个节日 —— “光棍节”。而淘宝网又用疯狂的折扣促销给它赋予了另外一个意义 —— “购物狂欢节”。2011 年 11 月 11 日这一天，淘宝商城与淘宝网交易额之和突破 52 亿，这个数字是“购物天堂”香港一天零售总额 8.5 亿的 6 倍。
20 |
21 | 网民感受到的是疯抢的喜悦，而网站的技术人员感受到的却是“压力山大”。就如同你家办酒席，宴请左邻右舍，这个办起来容易。倘若宴请十里八乡所有的人，吃饭的人自然开心，但却不是一般人家能够办得起来的。能办得起来如此盛宴者，需要强大的财力物力、组织能力、技术实力（例如做这么多菜，你的炒锅一定要是“分布式的”、“可复制的”、“可扩展的”，洗菜切菜要有“工作流引擎”，上菜的路径要用图论来计算出来，甚至连厨房的下水道都要重新设计）。
22 |
23 | 淘宝能够举办如此盛宴，网站的技术实力可见一斑。淘宝网拥有全国最大的 Hadoop 分布式计算集群之一，日新增数据 50TB，有 40PB 海量数据存储。分布在全国各地 80 多个节点的 CDN 网络，支持的流量超过 800Gbps。淘宝的搜索引擎能够对数十亿的商品数据进行实时搜索，另外还拥有自主研发的文件存储系统和缓存系统，以及 Java 中间件和消息中间件系统，这一切组成了一个庞大的电子商务操作系统。另外从商业数据上来看，Amazon 的财报显示 2011 年完成了大约 480 亿美金的交易额，eBay 2011 年财报全年完成了大约 600 亿美金的交易额（不包括其独立的汽车交易平台）。不管从交易额、商品数量、同比增速等指标上看，淘宝网均远超于此，是目前全球最大的电子商务平台。（由于淘宝非上市公司，未公布 2011 年业绩，以上内容来自淘宝网技术副总裁[@\_行癫](http://weibo.com/u/1419403675) 的微博）
24 |
25 | 以上这些技术数据可能已经让一些同学产生不适的感觉，为了让更多的人读懂这本书，我们从技术的角度来看，小美访问淘宝网的时候，网站上发生了什么事情。参考资料：《[技术普及帖：你刚才在淘宝上买了一件东西](http://kb.cnblogs.com/page/132716/)》，来自南京邮电大学孙放同学。
26 |
27 | 为了有个更直观的对比，我们说一个同行，他在 2011 年光棍节之前做促销，流量上去之后，达到 12Gbps（他们有这么大的流量，老板很高兴，在微博上面说了这个数据），这时候流量达到了极限，网站几乎挂掉，用户无法下订单。而淘宝网光棍节当天网络的流量最高达到 800 多 Gbps，带给各家银行和快递公司的流量也让他们压力山大，如临大敌（后来，他们以能够撑住淘宝带来的流量为荣而到处宣传）。另外如果你在网上购买过火车票的话，更能体会到网站能支持多大的流量有多重要。但这不是一朝一夕做出来的，也不是有钱就能办到的。
28 |
29 | 以上对比的这些网站，也许读者很容易就猜到是哪一家，这里拿出来作对比，绝对没有嘲笑人家的意思，采用通常的网站技术方案，能做到这种程度已经不错了。任何网站的发展都不是一蹴而就的，在什么样的阶段采用什么样的技术。在发展的过程中网站会遇到各种各样的问题和业务带来的压力，正是这些原因才推动着技术的进步和发展，而技术的发展又会反过来促进业务的更大提升。二者互为因果，相互促进。如今淘宝网的流量已经是全球排名第 12、国内排名第 3（美国的 eBay 全球排名 23，国内前两名是百度和腾讯）。淘宝网的系统也从使用一台服务器，到采用万台以上的服务器。本书就为大家描述淘宝网在整个发展过程中，所有的主动和被动的技术变革的前因后果，这由很多有趣的故事组成。
30 |
31 | 正如同很多人或组织成功了以后，就会为自己的出身编造一个美丽的传说。淘宝网的出身，网上也有非常多的传说，下面我们就从它的出生开始讲起。
32 |
33 | **二、个人网站**
34 |
35 | 2003 年 4 月 7 日，马云，在杭州，成立了一个神秘的组织。他叫来十位员工，要他们签了一份协议，这份协议要求他们立刻离开阿里巴巴，去做一个神秘的项目。这个项目要求绝对保密，老马戏称“连说梦话被老婆听到都不行，谁要是透漏出去，我将追杀到天涯海角”。这份协议是英文版的，匆忙之间，大多数人根本来不及看懂，但出于对老马的信任，都卷起铺盖离开了阿里巴巴。
36 |
37 | 他们去了一个神秘的据点 —— 湖畔花园小区的一套未装修的房子里，房子的主人是马云。这伙人刚进去的时候，马云给他们布置了一个任务，就是在最短的时间内做出一个个人对个人（C2C）的商品交易的网站。现在出一个问题考考读者，看你适不适合做淘宝的创业团队。亲，要是让你来做，你怎么做？
38 |
39 | 在说出这个答案之前，容我先卖个关子，介绍一下这个创业团队的成员：三个开发工程师（虚竹、三丰、多隆）、一个 UED（二当家）、三个运营（小宝、阿珂、破天）、一个经理（财神）、还有就是马云和他的秘书。当时对整个项目组来说压力最大的就是时间，怎么在最短的时间内把一个从来就没有的网站从零开始建立起来？了解淘宝历史的人知道淘宝是在 2003 年 5 月 10 日上线的，这之间只有一个月。要是你在这个团队里，你怎么做？我们的答案就是：买一个来。
40 |
41 | 买一个网站显然比做一个网站要省事一些，但是他们的梦想可不是做一个小网站而已，要做大，就不是随便买个就行的，要有比较低的维护成本，要能够方便的扩展和二次开发。那接下来就是第二个问题：买一个什么样的网站？答案是：轻量一点的，简单一点的，于是买了这样一个架构的网站：LAMP(Linux+Apache+MySQL+PHP)。这个直到现在还是一个很常用的网站架构模型。这种架构的优点是：无需编译，发布快速，PHP 功能强大，能做从页面渲染到数据访问所有的事情，而且用到的技术都是开源的，免费。
42 |
43 | 当时我们是从一个美国人那里买来的一个网站系统，这个系统的名字叫做 PHPAuction（他们的官方网站 http://www.phpauction.net，这个名字很直白，一眼就看出来这个系统是用什么语言做的、是干什么用的），PHPAuction有好几个版本，我们买的是最高版的，功能比较多，而且最重要的是对方提供了源代码。最高版比较贵，花了我们 2000 美金（貌似现在降价了，只要 946 美元）。买来之后不是直接就能用的，需要很多本地化的修改，例如页面模板改的漂亮一点，页头页脚加上自己的站点简介等，其中最有技术含量的是对数据库进行了一个修改。原来是从一个数据库进行所有的读写操作，拿过来之后多隆把它给拆分成一个主库、两个从库，读写分离。这么做的好处有几点：存储容量增加了，有了备份，使得安全性增加了，读写分离使得读写效率提升了。这样整个系统的架构就如下图所示：
44 |
45 | 
46 |
47 | 其中 Pear DB 是一个 PHP 模块，负责数据访问层。另外也用开源的论坛系统 PHPBB（http://www.phpbbchina.com ）搭建了一个小的论坛社区，虚竹负责机器采购、配置、架设等，三丰和多隆负责编码，他们把交易系统和论坛系统的用户信息打通，给运营人员开发出后台管理（admin 系统）的功能，把交易类型从只有拍卖这一种增加为拍卖、一口价、求购商品、海报商品（意思是还没推出的商品，先挂个海报出来）这四种。（PHPAuction 只有拍卖的交易，Auction 即拍卖的意思。@\_行癫在微博中提到：今天 eBay 所有交易中拍卖交易仍然占了 40%，而在中国，此种模式在淘宝几乎从一开始就未能占据优势，如今在主流的交易中几乎可以忽略不计。背后的原因一直令人费解。我大致可以给出其中一种解释，eBay 基本在发达国家展开业务，制造业外包后，电子商务的基本群体大多只能表现为零散的个体间交易。）
48 |
49 | 在经历了另外一些有趣的事情之后（这些有趣的事情包括“淘宝”这个名字的由来，[员工花名的由来](http://www.neweekly.com.cn/index/newsview.php?id=1263)等等，由于本书主要描述技术方面的故事，对这些有兴趣的可以去网上找），网站开始上线运行了。
50 |
51 | 
52 |
53 | 在接下来的大半年时间里，这个网站迅速显示出了它的生机。这里有必要提一下当时的市场环境，非典（SARS）的肆虐使得大家都不敢出门，尤其是去商场之类人多的地方。另外在神州大地上最早出现的 C2C 网站易趣也正忙的不亦乐乎，2002 年 3 月，eBay 以 3000 万美元收购了易趣公司 33% 的股份，2003 年 6 月以 1.5 亿美元收购了易趣公司剩余 67% 的股份。当时淘宝网允许买卖双方留下联系方式，允许同城交易，整个操作过程简单轻松。而 eBay 为了收取交易佣金，是禁止这么做的，这必然增加了交易过程的难度。而且 eBay 为了全球统一，把易趣原来的系统替换成了美国 eBay 的系统，用户体验一下子全变了，操作起来非常麻烦，这等于是把积累的用户拱手送给了淘宝。为了不引起 eBay 的注意，淘宝网在 2003 年里一直声称自己是一个“个人网站”。由于这个创业团队强大的市场开拓和运营能力，淘宝网发展的非常迅猛，2003 年底就吸引了注册用户 XXX，最高每日 31 万 PV，从 5 月到年底成交额 4000 万。这没有引起 eBay 的注意，却引起了阿里巴巴内部很多员工的注意，他们觉得这个网站以后会成为阿里巴巴强劲的对手。甚至有人在内网发帖，忠告管理层要警惕这个刚刚起步的网站，但管理层似乎无动于衷。（这个团队的保密工作做的真好）
54 |
55 | 在市场和运营的后方，淘宝网的技术团队也在快速的做着系统的改进和创新。这里还有个有趣的故事，eBay 和易趣早期都有员工在论坛上响应用户的需求，eBay 的论坛用粉红色背景来区分员工的发言，易趣的员工在论坛上昵称都选各种豆豆，例如黄豆豆、蚕豆豆等。淘宝在讨论运营策略的时候提到这个问题，要求所有的员工都去论坛上回答用户的问题。最早回答问题的任务落在小宝头上，那我们用什么名字好呢？“淘淘”？“宝宝”？小宝都不满意，太女性化了。讨论了很久之后，小宝灵光乍现，干脆取个名字叫“小宝”吧，小宝带七个老婆来开店，迎接各位客官，很有故事性。于是很多武侠小说中的人物开始在论坛中行侠仗义，这些昵称下面标志着“淘宝店小二”，他们回答着各种各样的问题，快速响应着用户的各种需求。如果是技术上能解决的，几个人商量一下，马上就开发、测试、发布上线。反过来对比一下，易趣被 eBay 收购之后，系统更换成了全球通用的版本，响应用户的一个需求需要层层审批，反应速度自然慢了下来。
56 |
57 | 当时淘宝第一个版本的系统里面已经包含了商品发布、管理、搜索、商品详情、出价购买、评价投诉、我的淘宝这些功能（现在主流程中也是这些模块。在 2003 年 10 月增加了一个功能节点：“安全交易”，这个是支付宝的雏形）。随着用户需求和流量的不断增长，系统上面做了很多的日常改进，服务器由最初的一台变成了三台，一台负责发送 email、一台负责运行数据库、一台负责运行 Web App。过一段时间之后，商品搜索的功能占用数据库资源太大了（用 like 搜索的，很慢），又从阿里巴巴中文站搬过来他们的搜索引擎 iSearch，起初 iSearch 索引的文件放在硬盘上，随着数据量的增长，又采购了 NetApp 服务器放置 iSearch。
58 |
59 | 如此快节奏的工作，其实大家都累得不行，有人就提议大家随时随地的锻炼身体，可是外面 SARS 横行，在一个一百多方的房子里，怎么锻炼呢？高挑美女阿珂提议大家练习提臀操，这个建议遭到男士的一致反对，后来虚竹就教大家练习倒立，这个大家都能接受。于是这个倒立的传统一直延续至今，和花名文化、武侠文化一并传承了下来。
60 |
61 | 随着访问量和数据量的飞速上涨，问题很快就出来了，第一个问题出现在数据库上。MySQL 当时是第 4 版的，我们用的是默认的存储引擎 MyISAM，这种类型读数据的时候会把表锁住（我们知道 Oracle 在写数据的时候会有行锁，读数据的时候是没有的），尤其是主库往从库上面写数据的时候，会对主库产生大量的读操作，使得主库性能急剧下降。这样在高访问量的时候，数据库撑不住了。另外，当年的 MySQL 不比如今的 MySQL，在数据的容量和安全性方面也有很多先天的不足（和 Oracle 相比）。
62 |
63 | 三、**Oracle/支付宝/旺旺**
64 |
65 | 淘宝网作为个人网站发展的时间其实并不长，由于它太引人注目了，马云在 2003 年 7 月就宣布了这个是阿里巴巴旗下的网站，随后在市场上展开了很成功的运作。最著名的就是利用中小网站来做广告，突围 eBay 在门户网站上对淘宝的广告封锁。上网比较早的人应该还记得那些在右下角的弹窗和网站腰封上一闪一闪的广告。市场部那位到处花钱买广告的家伙，太能花钱了，一出手就是几百万，他被我们称为“大少爷”。
66 |
67 | “大少爷”们做的广告，带来的就是迅速上涨的流量和交易量。在 2003 年底，MySQL 已经撑不住了，技术的替代方案非常简单，就是换成 Oracle。换 Oracle 的原因除了它容量大、稳定、安全、性能高之外，还有人才方面的原因。在 2003 年的时候，阿里巴巴已经有一支很强大的 DBA 团队了，有冯春培、汪海（七公）这样的人物，后来还有冯大辉（@fenng）、陈吉平（拖雷）。这样的人物牛到什么程度呢？Oracle 给全球的技术专家颁发一些头衔，其中最高级别的叫 ACE（就是扑克牌的“尖儿”，够大的吧），被授予这个头衔的人目前全球也只有 300 多名（名单在这里： http://apex.oracle.com/pls/otn/f?p=19297:3 ），当年全球只有十几名。有如此强大的技术后盾，把 MySQL 换成 Oracle 是顺理成章的事情。
68 |
69 | 但更换数据库不是只换个库就可以的，访问方式，SQL 语法都要跟着变，最重要的一点是，Oracle 并发访问能力之所以如此强大，有一个关键性的设计 —— 连接池。但对于 PHP 语言来说它是放在 Apache 上的，每一个请求都会对数据库产生一个连接，它没有连接池这种功能（Java 语言有 Servlet 容器，可以存放连接池）。那如何是好呢？这帮人打探到 eBay 在 PHP 下面用了一个连接池的工具，是 BEA 卖给他们的。我们知道 BEA 的东西都很贵，我们买不起，于是多隆在网上寻寻觅觅，找到一个开源的连接池代理服务 SQLRelay（ [http://sourceforge.jp/projects/freshmeat_sqlrelay](http://sourceforge.jp/projects/freshmeat_sqlrelay/) ），这个东西能够提供连接池的功能，多隆对它进行了一些功能改进之后就拿来用了。这样系统的架构就变成了如下的样子：
70 |
71 | 
72 |
73 | 数据一开始是放在本地的，DBA 们对 Oracle 做调优的工作，也对 SQL 进行调优。后来数据量变大了，本地存储不行了。买了 NAS（Network Attached Storage：网络附属存储），NetApp 的 NAS 存储作为了数据库的存储设备，加上 Oracle RAC（Real Application Clusters，实时应用集群）来实现负载均衡。七公说这实际上是走了一段弯路，NAS 的 NFS（Network File System）协议传输的延迟很严重，但那时侯不懂。后来采购了 Dell 和 EMC 合作的 SAN 低端存储，性能一下子提升了 10 几倍，这才比较稳定了。再往后来数据量更大了，存储的节点一拆二、二拆四，RAC 又出问题了。这才踏上了购买小型机的道路。在那段不稳定的时间里，七公曾经在机房住了 5 天 5 夜。
74 |
75 | 替换完数据库，时间到了 2004 年春天，俗话说“春宵一刻值千金”，但这些人的春宵却不太好过了。他们在把数据的连接放在 SQLRelay 之后就噩梦不断，这个代理服务经常会死锁，如同之前的 MySQL 死锁一样。虽然多隆做了很多修改，但当时那个版本内部处理的逻辑不对，问题很多，唯一解决的办法就是“重启”它的服务。这在白天还好，连接上机房的服务器，把进程杀掉，然后开启就可以了，但是最痛苦的是它在晚上也要死掉，于是工程师们不得不 24 小时开着手机，一旦收到“ SQLRelay 进程挂起”的短信，就从春梦中醒来，打开电脑，连上机房，重启服务。后来干脆每天睡觉之前先重启一下。做这事最多的据说是三丰，他现在是淘宝网的总裁。现在我们知道，任何牛 B 的人物，都有一段苦 B 的经历。
76 |
77 | 微博上有人说“好的架构是进化来的，不是设计来的”。的确如此，其实还可以再加上一句“好的功能也是进化来的，不是设计来的”。在架构的进化过程中，业务的进化也非常迅猛。最早的时候，买家打钱给卖家都是通过银行转账汇款，有些骗子收了钱却不发货，这是一个很严重的问题。然后这伙人研究了 PayPal 的支付方式，发现也不能解决问题。后来这几个聪明的脑袋又想到了“担保交易”这种第三方托管资金的办法。于是在 2003 年 10 月，淘宝网上面上线了一个功能，叫做“安全交易”，卖家选择支持这种功能的话，买家会把钱交给淘宝网，等他收到货之后，淘宝网再把钱给卖家。这就是现在的支付宝，在前两天（2012.2.21）年会上，支付宝公布 2011 年的交易笔数已经是 PayPal 的两倍。这个划时代的创新，其实就是在不断的思索过程中的一个灵光乍现。
78 |
79 | 当时开发“安全交易”功能的是茅十八和他的徒弟苗人凤（茅十八开发到一半去上海读 MBA 去了，苗人凤现在是支付宝的首席业务架构师），开发跟银行网关对接的功能的是多隆。当时多数银行的网站已经支持在线支付了，但多隆告诉我，他们的网关五花八门，用什么技术的都有，必须一家一家去接。而且他们不保证用户付钱了就一定扣款成功、不保证扣款成功了就一定通知淘宝、不保证通知淘宝了就一定能通知到、不保证通知到了就不重复通知。这害苦了苗人凤，他必须每天手工核对账单，对不齐的话就一定是有人的钱找不到地方了，少一分钱都睡不着觉。另外他为了测试这些功能，去杭州所有的银行都办理了一张银行卡。一堆银行卡摆在桌子上，不知道的人还以为这个家伙一定很有钱，其实里面都只是十块八块的。现在我们再一次知道，任何牛 B 的人物，都必须有一段苦 B 的经历。
80 |
81 | 有人说淘宝打败易趣（eBay 中国）是靠免费，其实这只是原因之一。如果说和易趣过招第一招是免费的话，这让用户没有门槛就愿意来，那第二招就是“安全支付”，这让用户放心付款，不必担心被骗。在武侠小说中真正的高手飞花摘叶即可伤人，他们不会局限于一招两招，一旦出手，连绵不绝。而淘宝的第三招就是“旺旺”，让用户在线沟通。其实淘宝旺旺也不是自己生出来的，是从阿里巴巴的“贸易通”复制过来的。从 2004 年 3 月开始，“叮咚、叮咚”这个经典的声音就回荡在所有淘宝买家和卖家的耳边，“亲，包邮不？”，“亲，把零头去掉行不？”，这亲切的砍价声造就了后来的“淘宝体”。有人说中国人就是爱砍价，虽然笔者体会不到砍价成功后有多少成就感，但每次我去菜市场，看到大妈们砍价砍得天昏地暗，那满足的劲头堪比捡到了钱，我就深刻的理解了淘宝旺旺在交易过程中的价值。我猜 eBay 也体会不到砍价的乐趣，他们一直不允许买卖双方在线聊天，收购了 skype 之后也没有用到电子商务中去。
82 |
83 | 旺旺在推出来没多久，就惹了一个法律方面的麻烦。有个做雪饼的厂家找上门来，说我们侵权了，他们家的雪饼很好吃，牛奶也做得不错，我们都很喜欢。然后我们就在旺旺的前面加了两个字，叫做“淘宝旺旺”。在那个野蛮生长的阶段，其实很多产品都是想到什么就做什么，例如我们还搭建过一个聊天室，但似乎淘宝网不是一个闲聊的地方，这个聊天室门可罗雀，一段时间后就关闭掉了。
84 |
85 | SQLRelay 的问题搞得三丰他们很难睡个囫囵觉，那一年开半年会的时候，公司特地给三丰颁了一个奖项，对他表示深切的安慰。但不能总这样啊，于是，2004 年的上半年开始，整个网站就开始了一个脱胎换骨的手术。
86 |
87 | **四、淘宝技术发展（Java 时代：脱胎换骨）**
88 |
89 | 我的师父黄裳@岳旭强曾经说过，“好的架构图充满美感”，一个架构好不好，从审美的角度就能看得出来。后来我看了很多系统的架构，发现这个言论基本成立。那么反观淘宝前面的两个版本的架构，你看哪个比较美？
90 |
91 | 
92 |
93 | 
94 |
95 | 显然第一个比较好看，后面那个显得头重脚轻，这也注定了它不是一个稳定的版本，只存活了不到半年的时间。2004 年初，SQL Relay 的问题解决不了，数据库必须要用 Oracle，那从哪里动刀？只有换开发语言了。换什么语言好呢？Java。Java 是当时最成熟的网站开发语言，它有比较良好的企业开发框架，被世界上主流的大规模网站普遍采用，另外有 Java 开发经验的人才也比较多，后续维护成本会比较低。
96 |
97 | 到 2004 年上半年，淘宝网已经运行了一年的时间，这一年积累了大量的用户，也快速的开发了很多功能，当时这个网站已经很庞大了，而且新的需求还在源源不断的过来。把一个庞大的网站的开发语言换掉，无异于脱胎换骨，在换的过程中还不能拖慢业务的发展，这无异于边换边跑，对时间和技术能力的要求都非常高。做这样的手术，需要请第一流的专家来主刀。现在再考一下读者，如果你在这个创业团队里面，请什么样的人来做这事？我们的答案是请 Sun 的人。没错，就是创造 Java 语言的那家公司，世界上没有比他们更懂 Java 的了。除此之外，还有一个不为人知的原因，……（此处和谐掉 200 字，完整版见 aliway）
98 |
99 | 这帮 Sun 的工程师的确很强大，在笔者 2004 年底来淘宝的时候，他们还在，有幸跟他们共事了几个月。现在摆在他们面前的问题是用什么办法把一个庞大的网站从 PHP 语言迁移到 Java？而且要求在迁移的过程中，不停止服务，原来系统的 bugfix 和功能改进不受影响。亲，你要是架构师，你怎么做？有人的答案是写一个翻译器，如同把中文翻译成英文一样，自动翻译。我只能说你这个想法太超前了，换个说法就是“too simple, sometimes naive”。当时没有，现在也没有人能做到。他们的大致方案是给业务分模块，一个模块一个模块的替换。如用户模块，老的 member.taobao.com 继续维护，不添加新功能，新的功能先在新的模块上开发，跟老的共用一个数据库，开发完毕之后放到不同的应用集群上，另开个域名 member1.taobao.com，同时替换老的功能，替换一个，把老的模块上的功能关闭一个，逐渐的把用户引导到 member1.taobao.com，等所有功能都替换完毕之后，关闭 member.taobao.com。后来很长时间里面都是在用 member1 这样奇怪的域名，两年后有另外一家互联网公司开始做电子商务了，我们发现他们的域名也叫 member1.xx.com、auction1.xx.com……
100 |
101 | 说了开发模式，再说说用到的 Java MVC 框架，当时的 Struts 1.x 是用的比较多的框架，但是用过 WebWork 和 Struts 2 的同学可能知道，Struts 1.x 在多人协作方面有很多致命的弱点，由于没有一个轻量框架作为基础，因此很难扩展，这样架构师对于基础功能和全局功能的控制就很难做到。而阿里巴巴的 18 个创始人之中，有个架构师，在 Jakarta Turbine 的基础上，做了很多扩展，打造了一个阿里巴巴自己用的 MVC 框架 WebX （http://www.openwebx.org/docs/Webx3_Guide_Book.html），这个框架易于扩展，方便组件化开发，它的页面模板支持 JSP 和 Velocity 等、持久层支持 iBATIS 和 Hibernate 等、控制层可以用 EJB 和 Spring（Spring 是后来才有的）。项目组选择了这个强大的框架，这个框架如果当时开源了，也许就没有 WebWork 和 Struts 2 什么事了。另外，当时 Sun 在全世界大力推广他们的 EJB，虽然淘宝的架构师认为这个东东用不到，但他们还是极力坚持。在经历了很多次的技术讨论、争论和争吵之后，这个系统的架构就变成了下图的样子：
102 |
103 | 
104 |
105 | Java 应用服务器是 Weblogic，MVC 框架是 WebX、控制层用了 EJB、持久层是 iBATIS，另外为了缓解数据库的压力，商品查询和店铺查询放在搜索引擎上面。这个架构图是不是好看了一点了，亲？
106 |
107 | 这帮 Sun 的工程师开发完淘宝的网站之后，又做了一个很牛的网站，叫“支付宝”。
108 |
109 | 其实在任何时候，开发语言本身都不是系统的瓶颈，业务带来的压力更多的是压到了数据和存储上。上面一篇也说到，MySQL 撑不住了之后换 Oracle，Oracle 的存储一开始在本机上，后来在 NAS 上，NAS 撑不住了用 EMC 的 SAN 存储，再然后 Oracle 的 RAC 撑不住了，数据的存储方面就不得不考虑使用小型机了。在 2004 年的夏天，DBA 七公、测试工程师郭芙和架构师行癫，踏上了去北京测试小型机的道路。他们带着小型机回来的时候，我们像欢迎领袖一样的欢迎他们，因为那个是我们最值钱的设备了，价格表上的数字吓死人。小型机买回来之后我们争相合影，然后 Oracle 就跑在了小型机上，存储方面从 EMC 低端 cx 存储到 Sun oem hds 高端存储，再到 EMC dmx 高端存储，一级一级的往上跳。
110 |
111 | 到现在为止，我们已经用上了 IBM 的小型机、Oracle 的数据库、EMC 的存储，这些东西都是很贵的，那些年可以说是花钱如流水啊。有人说过“钱能解决的问题，就不是问题”，但随着淘宝网的发展，在不久以后，钱已经解决不了我们的问题了。花钱买豪华的配置，也许能支持 1 亿 PV 的网站，但淘宝网的发展实在是太快了，到了 10 亿怎么办？到了百亿怎么办？在 N 年以后，我们不得不创造技术，解决这些只有世界顶尖的网站才会遇到的问题。后来我们在开源软件的基础上进行自主研发，一步一步的把 IOE（IBM 小型机、Oracle、EMC 存储）这几个“神器”都去掉了。这就如同在《西游记》里面，妖怪们拿到神仙的兵器会非常厉害，连猴子都能够打败，但最牛的神仙是不用这些神器的，他们挥一挥衣袖、翻一下手掌就威力无比。去 IOE 这一部分会在最后一个章节里面讲，这里先埋个千里伏笔。
112 |
113 | 欲知后事如何，且听下回分解。
114 |
115 | **五、淘宝技术发展（Java 时代：坚若磐石）**
116 |
117 | 已经有读者在迫不及待的问怎么去掉了 IOE，别急，在去掉 IOE 之前还有很长的路要走。行癫他们买回来小型机之后，我们用上了 Oracle，七公带着一帮 DBA 在优化 SQL 和存储，行癫带着几个架构师在研究数据库的扩展性。Oracle 本身是一个封闭的系统，用 Oracle 怎么做扩展？用现在一个时髦的说法就是做“分库分表”。
118 |
119 | 我们知道一台 Oracle 的处理能力是有上限的，它的连接池有数量限制，查询速度跟容量成反比。简单的说，在数据量上亿、查询量上亿的时候，就到它的极限了。要突破这种极限，最简单的方式就是多用几个 Oracle 数据库。但一个封闭的系统做扩展，不像分布式系统那样轻松。我们把用户的信息按照 ID 来放到两个数据库里面（DB1/DB2），把商品的信息跟着卖家放在两个对应的数据库里面，把商品类目等通用信息放在第三个库里面(DBcommon)。这么做的目的除了增加了数据库的容量之外，还有一个就是做容灾，万一一个数据库挂了，整个网站上还有一半的数据能操作。
120 |
121 | 数据库这么分了之后，应用程序有麻烦了，如果我是一个买家，买的商品有 DB1 的也有 DB2 的，要查看“我已买到的宝贝”的时候，应用程序怎么办？必须到两个数据库里面分别查询出来对应的商品。要按时间排序怎么办？两个库里面“我已买到的宝贝”全部查出来在应用程序里面做合并。还有分页怎么处理？关键字查询怎么处理？这些东西交给程序员来做的话会很悲催，于是行癫在淘宝的第一个架构上的作品就来解决了这个问题，他写了一个数据库路由的框架 DBRoute，这个框架在淘宝的 Oracle 时代一直在使用。后来随着业务的发展，这种分库的第二个目的 —— 容灾的效果就没有达到。像评价、投诉、举报、收藏、我的淘宝等很多地方，都必须同时连接 DB1 和 DB2，哪个库挂了都会导致整个网站挂掉。
122 |
123 | 上一篇说过，采用 EJB 其实是和 Sun 的工程师妥协的结果，在他们走了之后，EJB 也逐渐被冷落了下来。在 2005、2006 年的时候，Spring 大放异彩，正好利用 Spring 的反射（IoC）模式替代了 EJB 的工厂模式，给整个系统精简了很多代码。
124 |
125 | 上一篇还说过，为了减少数据库的压力，提高搜索的效率，我们引入了搜索引擎。随着数据量的继续增长，到了 2005 年，商品数有 1663 万，PV 有 8931 万，注册会员有 1390 万，这给数据和存储带来的压力依然山大，数据量大，性能就慢。亲，还有什么办法能提升系统的性能？一定还有招数可以用，这就是缓存和 CDN（内容分发网络）。
126 |
127 | 你可以想象，九千万的访问量，有多少是在商品详情页面？访问这个页面的时候，数据全都是只读的（全部从数据库里面读出来，不写入数据库），如果把这些读操作从数据库里面移到内存里，数据库将会多么的感激涕零。在那个时候我们的架构师多隆大神，找到了一个基于 Berkeley DB 的开源的缓存系统，把很多不太变动的只读信息放了进去。其实最初这个缓存系统还比较弱，我们并没有把整个商品详情都放在里面，一开始把卖家的信息放里面，然后把商品属性放里面，商品详情这个字段太大，放进去受不了。说到商品详情，这个字段比较恐怖，有人统计过，淘宝商品详情打印出来平均有 5 米长，在系统里面其实放在哪里都不招人待见。笔者清楚的记得，我来淘宝之后担任项目经理做的第一个项目就是把商品详情从商品表里面给移出来。这个字段太大了，查询商品信息的时候很多都不需要查看详情，它跟商品的价格、运费这些放在一个表里面，拖慢了整个表的查询速度。在 2005 年的时候，我把商品详情放在数据库的另外一张表里面，再往后这个大字段被从数据库里面请了出来，这也让数据库再一次感激涕零。
128 |
129 | 到现在为止，整个商品详情的页面都在缓存里面了，眼尖的读者可能会发现现在的商品详情不全是“只读”的信息了，这个页面上有个信息叫“浏览量”，这个数字每刷新一次页面就要“写入”数据库一次，这种高频度实时更新的数据能用缓存吗？如果不用缓存，一天几十亿的写入，数据库会怎么样？一定会挂掉。那怎么办？亲……先不回答你（下图不是广告，让你看看浏览量这个数据在哪里）
130 |
131 | 
132 |
133 | CDN 这个工作相对比较独立，跟别的系统一样，一开始我们也是采用的商用系统。后来随着流量的增加，商用的系统已经撑不住了，LVS 的创始人章文嵩博士带人搭建了淘宝自己的 CDN 网络。在本文的引言中我说过淘宝的 CDN 系统支撑了 800Gbps 以上的流量，作为对比我们可以看一下国内专业做 CDN 的上市公司 ChinaCache 的介绍 —— “ChinaCache……是中国第一的专业 CDN 服务提供商，向客户提供全方位网络内容快速分布解决方案。作为首家获信产部许可的 CDN 服务提供商，目前 ChinaCache 在全国 50 多个大中城市拥有近 300 个节点，全网处理能力超过 500Gbps，其 CDN 网络覆盖中国电信、中国网通、中国移动、中国联通、中国铁通和中国教育科研网等各大运营商。” —— 这样你可以看得出淘宝在 CDN 上面的实力，这在全世界都是数一数二的。另外因为 CDN 需要大量的服务器，要消耗很多能源（消耗多少？在前两年我们算过一笔帐，淘宝上产生一个交易，消耗的电足以煮熟 4 个鸡蛋）。这两年章文嵩的团队又在研究低功耗的服务器，在绿色计算领域也做了很多开创性的工作。淘宝 CDN 的发展需要专门一个章节来讲，想先睹为快的可以看一下笔者[对章文嵩的专访](http://qing.weibo.com/1866752224/6f4460e033000jme.html)。
134 |
135 | 回想起刚用缓存那段时间，笔者还是个小菜鸟，有一个经典的错误常常犯，就是数据库的内容更新的时候，忘记通知缓存系统，结果在测试的时候就发现我改过的数据怎么在页面上没变化呢。后来做了一些页面上的代码，修改 CSS 和 JS 的时候，用户本地缓存的信息没有更新，页面上也会乱掉，在论坛上被人说的时候，我告诉他用 Ctrl+F5 刷新页面，然后赶紧修改脚本文件的名称，重新发布页面。学会用 Ctrl+F5 的会员对我佩服的五体投地，我却惭愧的无地自容。
136 |
137 | 有些技术的发展是顺其自然的，有些却是突如其来的。到 2007 年的时候，我们已经有几百台应用服务器了，这上面的 Java 应用服务器是 WebLogic，而 WebLogic 是非常贵的，比这些服务器本身都贵。有一段时间多隆研究了一下 JBoss，说我们换掉 WebLogic 吧，于是又省下了不少银两。那一年，老马举办了第一届的“网侠大会”，会上来的大侠中有一位是上文提到的章文嵩，还有一位曾经在 JBoss 团队工作，我们也把这位大侠留下了，这样我们用起 JBoss 更加有底气了。
138 |
139 | 这些杂七杂八的修改，我们对**数据分库、放弃 EJB、引入 Spring、加入缓存、加入 CDN、采用开源的 JBoss**，看起来没有章法可循，其实都是围绕着提高容量、提高性能、节约成本来做的，由于这些不算大的版本变迁，我们姑且叫它 2.1 版吧，这个版本从构图上来看有 3 只脚，是不是稳定了很多？
140 |
141 | 架构图如下：
142 |
143 | 
144 |
145 | **六、淘宝技术发展（Java 时代：创造技术-TFS）**
146 |
147 | 在讲淘宝文件系统 TFS 之前，先回顾一下上面几个版本。1.0 版的 PHP 系统运行了将近一年的时间（2003.05~2004.01）；后来数据库变成 Oracle 之后（2004.01~2004.05，叫 1.1 版本吧），不到半年就把开发语言转换为 Java 系统了（2004.02~2005.03，叫 2.0 版本）；进行分库、加入缓存、CDN 之后我们叫它 2.1 版本（2004.10~2007.01）。这中间有些时间的重合，因为很多架构的演化并没有明显的时间点，它是逐步进化而来的。
148 |
149 | 在描述 2.1 版本的时候我写的副标题是“坚若磐石”，这个“坚若磐石”是因为这个版本终于稳定下来了，在这个版本的系统上，淘宝网运行了两年多的时间。这期间有很多优秀的人才加入，也开发了很多优秀的产品，例如支付宝认证系统、招财进宝项目、淘宝旅行、淘宝彩票、淘宝论坛等等。甚至在团购网站风起云涌之前，淘宝网在 2006 年就推出了团购的功能，只是淘宝网最初的团购功能是买家发起的，达到卖家指定的数量之后，享受比一口价更低的价格，这个功能看起来是结合了淘宝一口价和荷兰拍的另一种交易模式，但不幸没有支撑下去。
150 |
151 | 在这些产品和功能的最底层，其实还是商品的管理和交易的管理这两大功能。这两大功能在 2.1 版本里面都有很大的变化。商品的管理起初是要求卖家选择 7 天到期还是 14 天到期，到期之后就要下架，必须重新发布才能上架，上架之后就变成了新的商品信息（ID 变过了）。另外如果这个期间内成交了，之后再有新货，必须发布一个新的商品信息。这么做有几个原因，一是参照拍卖商品的时间设置，要在某日期前结束挂牌；二是搜索引擎不知道同样的商品哪个排前面，那就把挂牌时间长的排前面，这样就必须在某个时间把老的商品下架掉，不然它老排在前面；第三是成交信息和商品 ID 关联，这个商品如果多次编辑还是同一个 ID 的话，成交记录里面的商品信息会变来变去；还有一个不为人知的原因，我们的存储有限，不能让所有的商品老存放在主库里面。这种处理方式简单粗暴，但还算是公平。不过这样很多需求都无法满足，例如同样的商品，我上一次销售的时候很多好评都没法在下一个商品上体现出来；再例如我买过的商品结束后只看到交易的信息，不知道卖家还有没有再卖了。后来基于这些需求，我们在 2006 年下半年把商品和交易拆开。一个商家的一种商品有个唯一的 ID，上下架都是同一个商品。那么如果卖家改价格、库存什么的话，已成交的信息怎么处理？那就在买家每交易一次的时候，都记录下商品的快照信息，有多少次交易就有多少个快照。这样买卖双方比较爽了，给系统带来了什么？存储的成本大幅度上升了！
152 |
153 | 存储的成本高到什么程度呢？数据库方面提到过用了 IOE，一套下来就是千万级别的，那几套下来就是 ⋯⋯。另外淘宝网还有很多文件需要存储，我们有哪些文件呢？最主要的就是图片、商品描述、交易快照，一个商品要包含几张图片和一长串的描述信息，而每一张图片都要生成几张规格不同的缩略图。在 2010 年，淘宝网的后端系统上保存着 286 亿个图片文件。图片在交易系统中非常重要，俗话说“一张好图胜千言”、“无图无真相”，淘宝网的商品照片，尤其是热门商品，图片的访问流量是非常大的。淘宝网整体流量中，图片的访问流量要占到 90% 以上。且这些图片平均大小为 17.45 KB，小于 8K 的图片占整体图片数量 61%，占整体系统容量的 11%。这么多的图片数据、这么大的访问流量，给淘宝网的系统带来了巨大的挑战。众所周知，对于大多数系统来说，最头疼的就是大规模的小文件存储与读取，因为磁头需要频繁的寻道和换道，因此在读取上容易带来较长的延时。在大量高并发访问量的情况下，简直就是系统的噩梦。我们该怎么办？
154 |
155 | 同样的套路，在某个规模以下，采用现有的商业解决方案，达到某种规模之后，商业的解决方案无法满足，只有自己创造解决方案了。对于淘宝的图片存储来说，转折点在 2007 年。这之前，一直采用的商用存储系统，应用 NetApp 公司的文件存储系统。随着淘宝网的图片文件数量以每年 2 倍(即原来 3 倍)的速度增长，淘宝网后端 NetApp 公司的存储系统也从低端到高端不断迁移，直至 2006 年，即使是 NetApp 公司最高端的产品也不能满足淘宝网存储的要求。从 2006 年开始，淘宝网决定自己开发一套针对海量小文件存储的文件系统，用于解决自身图片存储的难题。这标志着淘宝网从使用技术到了创造技术的阶段。
156 |
157 | 2007 年之前的图片存储架构如下图：
158 |
159 | 
160 |
161 | 章文嵩博士总结了几点商用存储系统的局限和不足:
162 |
163 | 首先是商用的存储系统没有对小文件存储和读取的环境进行有针对性的优化；其次，文件数量大，网络存储设备无法支撑；另外，整个系统所连接的服务器也越来越多，网络连接数已经到达了网络存储设备的极限。此外，商用存储系统扩容成本高，10T 的存储容量需要几百万，而且存在单点故障，容灾和安全性无法得到很好的保证。
164 |
165 | 谈到在商用系统和自主研发之间的经济效益对比，章文嵩博士列举了以下几点经验：
166 |
167 | 1. 商用软件很难满足大规模系统的应用需求，无论存储还是 CDN 还是负载均衡，因为在厂商实验室端，很难实现如此大的数据规模测试。
168 |
169 | 2. 研发过程中，将开源和自主开发相结合，会有更好的可控性，系统出问题了，完全可以从底层解决问题，系统扩展性也更高。
170 |
171 | 
172 |
173 | 3. 在一定规模效应基础上，研发的投入都是值得的。上图是一个自主研发和购买商用系统的投入产出比对比，实际上，在上图的交叉点左边，购买商用系统都是更加实际和经济性更好的选择，只有在规模超过交叉点的情况下，自主研发才能收到较好的经济效果。实际上，规模化达到如此程度的公司其实并不多，不过淘宝网已经远远超过了交叉点。
174 |
175 | 4. 自主研发的系统可在软件和硬件多个层次不断的优化。
176 |
177 | 历史总是惊人的巧合，在我们准备研发文件存储系统的时候，Google 走在了前面，2007 年他们公布了 GFS（ Google File System ）的设计论文，这给我们带来了很多借鉴的思路。随后我们开发出了适合淘宝使用的图片存储系统 TFS（Taobao File System）。3 年之后，我们发现历史的巧合比我们想象中还要神奇，几乎跟我们同时，中国的另外一家互联网公司也开发了他们的文件存储系统，甚至取的名字都一样 —— TFS，太神奇了！（猜猜是哪家？）
178 |
179 | 2007 年 6 月，TFS 正式上线运营。在生产环境中应用的集群规模达到了 200 台 PC Server(146G\*6 SAS 15K Raid5)，文件数量达到上亿级别；系统部署存储容量：140TB；实际使用存储容量： 50TB；单台支持随机 IOPS200+，流量 3MBps。
180 |
181 | 要讲 TFS 的系统架构，首先要描述清楚业务需求，淘宝对图片存储的需求大概可以描述如下：
182 |
183 | 文件比较小；并发量高；读操作远大于写操作；访问随机；没有文件修改的操作；要求存储成本低；能容灾能备份。应对这种需求，显然要用分布式存储系统；由于文件大小比较统一，可以采用专有文件系统；并发量高，读写随机性强，需要更少的 IO 操作；考虑到成本和备份，需要用廉价的存储设备；考虑到容灾，需要能平滑扩容。
184 |
185 | 参照 GFS 并做了适度的优化之后，TFS 1.0 版的架构图如下：
186 |
187 | 
188 |
189 | 从上面架构图上看：集群由一对 Name Server 和多台 Data Serve r 构成，Name Server 的两台服务器互为双机，就是集群文件系统中管理节点的概念。
190 |
191 | 在这个架构中：
192 | • 每个 Data Server 运行在一台普通的 Linux 主机上
193 | • 以 block 文件的形式存放数据文件(一般 64M 一个 block )
194 | • block 存多份保证数据安全
195 | • 利用 ext3 文件系统存放数据文件
196 | • 磁盘 raid5 做数据冗余
197 | • 文件名内置元数据信息，用户自己保存 TFS 文件名与实际文件的对照关系 – 使得元数据量特别小。
198 |
199 | 淘宝 TFS 文件系统在核心设计上最大的取巧的地方就在，传统的集群系统里面元数据只有 1 份，通常由管理节点来管理，因而很容易成为瓶颈。而对于淘宝网的用户来说，图片文件究竟用什么名字来保存实际上用户并不关心，因此 TFS 在设计规划上考虑在图片的保存文件名上暗藏了一些元数据信息，例如图片的大小、时间、访问频次等等信息，包括所在的逻辑块号。而在元数据上，实际上保存的信息很少，因此元数据结构非常简单。仅仅只需要一个 fileID，能够准确定位文件在什么地方。
200 |
201 | 由于大量的文件信息都隐藏在文件名中，整个系统完全抛弃了传统的目录树结构，因为目录树开销最大。拿掉后，整个集群的高可扩展性极大提高。实际上，这一设计理念和目前业界的“对象存储”较为类似，淘宝网 TFS 文件系统已经更新到 1.3 版本，在生产系统的性能已经得到验证，且不断得到了完善和优化，淘宝网目前在对象存储领域的研究已经走在前列。
202 |
203 | 在 TFS 上线之前，淘宝网每个商品只允许上传一张图片，大小限定在 120K 之内，在商品详情里面的图片必须使用外站的服务。那时侯发布一件商品确实非常麻烦，笔者曾经想卖一台二手电脑，先把照片上传到 Google 相册，在发布到淘宝网之后发现 Google 相册被墙了，我的图片别人看不到，当时郁闷的不行。TFS 上线后，商品展示图片开放到 5 张，商品描述里面的图片也可以使用淘宝的图片服务，到现在为止，淘宝网给每个用户提供了 1G 的图片空间，这下大家都满足了。技术和业务就是这么互相用力的推动着，业务满足不了的时候，技术必须创新，技术创新之后，业务有了更大的发展空间。
204 |
205 | 1.3 版本的架构见阿里味（阿里巴巴内网）⋯⋯
206 |
207 | **七、淘宝技术发展（分布式时代：服务化）**
208 |
209 | 在系统发展的过程中，架构师的眼光至关重要，作为程序员，把功能实现即可，但作为架构师，要考虑系统的扩展性、重用性，这种敏锐的感觉，有人说是一种代码洁癖。淘宝早期有几个架构师具备了这种感觉。一指开发的 Webx 是一个扩展性很强的框架，行癫在这个框架上插入了数据分库路由的模块、session 框架等等。在做淘宝后台系统的时候，同样需要这几个模块，行癫指导我把这些模块单独打成了 jar 包。另外在做淘宝机票、彩票系统的时候，页面端也有很多东西需要复用，最直观的是页头和页脚，一开始我们每个系统里面复制了一份过去，但奇妙的是，那段时间页脚要经常修改，例如把“雅虎中国”改成“中国雅虎”，过一段时间又加了一个“口碑网”，再过一段时间变成了“雅虎口碑”，最后又变成了“中国雅虎”，每个系统都改一遍，折腾啊。后来我就把这部分 velocity 模版单独拿出来了，做成了公用的模块。
210 |
211 | 上面这些都是比较小的复用模块，到 2006 年我们做了一个商品类目属性的改造，在类目里面引入属性的概念。项目的代号叫做“泰山”，如同它的名字，这是一个举足轻重的项目，这个改变是一个划时代的创新。在这之前的三年时间内，商品的分类都是按照树状的一级一级的节点来分的，随着商品数量的增长，类目也变得越来越深，越来越复杂，这带给买家的就是查找一件商品要逐级类目点开，找商品之前要懂商品的分类。而淘宝运营部门管理类目的小二也发现一个很严重的问题 —— 例如男装里面有 T 恤、T 恤下面有耐克、耐克有纯棉的，女装里面也有 T 恤、T 恤下面还是有耐克、耐克下面依然有纯棉的，那是先分男女装再分款式再分品牌再分材质呢？还是先分品牌再分款式再分材质再分男女呢？晕倒了。这时候，一位大侠出来了 —— 一灯，他说品牌、款式、材质这种东东可以叫做“属性”，属性是类似 tag 的一个概念，与类目相比更加离散，更加灵活，这样也缩减了类目的深度。这个思想的提出，一举解决了分类的难题！从系统的角度来看，我们建立了“属性”这样一个数据结构，由于除了类目的子节点有属性，父节点也有可能有属性，于是类目属性合起来也是一个结构化的数据对象。这个做出来之后我们把它独立出来作为一个服务，叫做 catserver（category server）。跟类目属性密切关联的商品搜索功能，独立出来，叫做 hesper（金星），catserver 和 hesper 供淘宝的前后台系统调用。
212 |
213 | 现在淘宝的商品类目属性已经是地球上最大的了，几乎没有什么类目的商品在淘宝上找不到（除了违禁的），但最初类目属性改造完之后，我们很缺属性数据，尤其是数码类的最缺。那从哪里弄这些数据呢亲？我们跟“中关村在线”合作，拿到了很多数据，那个时候，很多商品属性信息的后边标注着：“来自中关村在线”。有了类目属性，给运营的工作带来很大的便利，我们知道淘宝的运营主要就是类目的运营，什么季节推什么商品，都要在类目属性上面做调整，让买家更容易找到。例如夏天我要用户在女装一级类目下就标出来材质是不是蕾丝的、是不是纯棉的，冬天却要把羽绒衣调到女装一级类目下，流行什么就要把什么商品往更高级的类目调整。这样类目和属性要经常调整，随之而来的问题就显现了 —— 调整到哪个类目，那类商品的卖家就要编辑一次自己的商品，随着商品量的增长，卖家的工作量越来越大，然后我们就发现卖家受不了啦。到了 2008 年，我们研究了超市里面前后台商品的分类，发现超市前台商品可以随季节和关联来调整摆放场景（例如著名的啤酒和尿布的关联），后台仓库里面要按照自然类目来存储，二者密切关联却又相互分开。然后我们就把前后台类目分开了，这样卖家发布商品选择的是自然类目和属性，淘宝前台展示的是根据运营需要而摆放的商品的类目和属性。改造后的类目属性服务取名叫做 forest（森林，跟类目属性有点神似。catserver 还在，提供卖家授权、品牌服务、关键词等相关的服务）。类目属性的服务化，是淘宝在系统服务化方面做的第一个探索。
214 |
215 | 虽然个别架构师具备了代码洁癖，但淘宝前台系统的业务量和代码量还是爆炸式的增长了起来。业务方总在后面催，开发人员不够了就继续招人，招来的人根本看不懂原来的业务，只好摸索着在“合适的地方”加一些“合适的代码”，看看运行起来像那么回事，就发布上线了。在这样的恶性循环中，系统越来越臃肿，业务的耦合性越来越高，开发的效率越来越低。借用当时比较流行的一句话“写一段代码，编译一下能通过，半个小时就过去了；编译一下没通过，半天就过去了。”在这种情况下，系统出错的概率也逐步增长，常常是你改了商品相关的某些代码，发现交易出问题了，甚至你改了论坛上的某些代码，旺旺出问题了。这让开发人员苦不堪言，而业务方还认为这帮人干活越来越慢了。
216 |
217 | 大概是在 2007 年底的时候，研发部空降了一位从硅谷来的高管，空闻大师。空闻是一位温厚的长者，他告诉我们一切要以稳定为中心，所有影响系统稳定的因素都要解决掉。例如每做一个日常修改，都必须整个系统回归测试一遍；多个日常修改如果放在一个版本里面，要是一个功能没有测试通过，整个系统都不能发布。我们把这个叫做“火车模型”，任何一个乘客没有上车，都不许发车。这样做的最直接后果就是火车一直晚点，新功能上线更慢了，我们能明显的感觉到业务方的不满，空闻的压力肯定非常大。当时我都不理解这种一刀切的做法，为了稳定牺牲了发展的速度，这跟某 Party 的“稳定压倒一切”有什么分别？
218 |
219 | 但是到现在回过头来看看，其实我们并没有理解背后的思路。正是在这种要求下，我们不得不开始改变一些东西，例如把回归测试日常化，每天晚上都跑一遍整个系统的回归。还有就是在这种要求下，我们不得不对这个超级复杂的系统做肢解和重构，其中复用性最高的一个模块 —— 用户信息模块开始拆分出来了，我们叫它 UIC（user information center）。在 UIC 里面，它只处理最基础的用户信息操作，例如 getUserById、getUserByName 等等。
220 |
221 | 在另外一个方面，还有两个新兴的业务，也对系统基础功能的拆分提出了要求。在那个时候，我们做了淘宝旅行（trip.taobao.com）和淘宝彩票（caipiao.taobao.com）两个新业务，这两个新业务在商品的展示和交易的流程上都跟主站的业务不一样，机票是按照航班的信息展示的，彩票是按照双色球、数字和足球的赛程来展示的。但用到的会员的功能和交易的功能是跟主站差不多的，当时做的时候就很纠结，在主站里面做的话，会有一大半跟主站无关的东西，重新做一个的话，会有很多重复建设。最终我们决定不再给主站添乱了，就另起炉灶做了两个新的业务系统。从查询商品、购买商品、评价反馈、查看订单这一整个流程都重新写了一套出来。现在在“我的淘宝”里面查看交易记录的时候，还能发现“已买到的宝贝”里面把机票和彩票另外列出来了，他们没有加入到普通的订单里面去。在当时如果已经把会员、交易、商品、评价这些模块拆分出来，就不用什么都重做一遍了。
222 |
223 | 
224 |
225 | 到 2008 年初，整个主站系统（有了机票、彩票系统之后，把原来的系统叫做主站）的容量已经到了瓶颈，商品数在一亿以上，PV 在 2.5 亿以上，会员数超过了五千万。这个时候 Oracle 的连接池数量都不够用了，数据库的容量到了极限，上层系统再增加机器也无法继续扩容了，我们只有把底层的基础服务继续拆分，从底层开始扩容，上层才能扩展，这才能容纳以后三五年的增长。
226 |
227 | 于是那一年我们专门启动了一个更大的项目，把交易这个核心业务模块也拆分出来了。原来的淘宝交易除了跟商品管理耦合在一起，也在支付宝和淘宝之间跳来跳去，跟支付宝耦合在一起，系统复杂，用户体验也很不好。我们把交易的底层业务拆出来叫交易中心 TC（trade center），所谓底层业务是例如创建订单、减库存、修改订单状态等原子型的操作；交易的上层业务叫交易管理 TM（trade manager），例如拍下一件普通商品要对订单、库存、物流进行操作，拍下虚拟商品不需要对物流进行操作，这些在 TM 里面完成。这个项目取了一个很没有创意的名字 —— “千岛湖”，这帮开发人员取这个名字的目的是想在开发完毕之后，去千岛湖玩一圈，后来他们如愿以偿了。这个时候还有一个项目也在搞，就是淘宝商城，之前拆分出来的那些基础服务，给商城的快速构建，提供了良好的基础。
228 |
229 | 类目属性、用户中心、交易中心，随着这些模块逐步的拆分和服务化改造，我们在系统架构方面也积累了不少的经验。到 2008 年底干脆做了一个更大的项目，把淘宝所有的业务都模块化，这是继 2004 年从 LAMP 架构到 Java 架构之后的第二次脱胎换骨。这个项目取了一个很霸气的名字，叫“五彩石”（女娲炼石补天，用的石头）。这个系统重构的工作非常惊险，有人称之为“给一架高速飞行的飞机换发动机”。
230 |
231 | 五彩石项目发布之后，这帮工程师去三亚玩了几天。他们把淘宝的系统拆分成了如下架构：
232 |
233 | 
234 |
235 | 其中 UIC 和 Forest 上文说过，TC、IC、SC 分别是交易中心（Trade Center）、商品中心（Item Center）、店铺中心（Shop Center），这些中心级别的服务只提供原子级的业务逻辑，如根据 ID 查找商品、创建交易、减少库存等操作。再往上一层是业务系统 TM（Trade Manager 交易业务）、IM（Item Manager 商品业务）、SM（Shop Manager，因为不好听，所以后来改名叫 SS：Shop System，店铺业务）、Detail（商品详情）。
236 |
237 | 拆分之后，系统之间的交互关系变得非常复杂，示意图如下：
238 |
239 | 
240 |
241 | 系统这么拆分的话，好处显而易见，拆分之后每个系统可以单独部署，业务简单，方便扩容；有大量可重用的模块以便于开发新的业务；能够做到专人专事，让技术人员更加专注于某一个领域。这样要解决的问题也很明显，分拆之后，系统之间还是必须要打交道的，越往底层的系统，调用它的客户方越多，这就要求底层的系统必须具有超大规模的容量和非常高的可用性。另外，拆分之后的系统如何通讯？这里需要两种中间件系统，一种是实时调用的中间件（淘宝的 HSF，高性能服务框架）、一种是异步消息通知的中间件（淘宝的 Notify）。另外还有一个需要解决的问题是用户在 A 系统登录了，到 B 系统的时候，用户的登录信息怎么保存？这又涉及到一个 Session 框架。再者，还有一个软件工程方面的问题，这么多层的一套系统，怎么去测试它？
242 |
--------------------------------------------------------------------------------
/99~参考资料/System Design Primer/README.md:
--------------------------------------------------------------------------------
1 | # System Design Primer
2 |
3 | 
4 |
5 | ## 性能与可扩展性
6 |
7 | 如果服务**性能**的增长与资源的增加是成比例的，服务就是可扩展的。通常，提高性能意味着服务于更多的工作单元，另一方面，当数据集增长时，同样也可以处理更大的工作单位。1
8 |
9 | 另一个角度来看待性能与可扩展性:
10 |
11 | - 如果你的系统有**性能**问题，对于单个用户来说是缓慢的。
12 | - 如果你的系统有**可扩展性**问题，单个用户较快但在高负载下会变慢。
13 |
14 | ### 来源及延伸阅读
15 |
16 | - [简单谈谈可扩展性](http://www.allthingsdistributed.com/2006/03/a_word_on_scalability.html)
17 | - [可扩展性，可用性，稳定性和模式](http://www.slideshare.net/jboner/scalability-availability-stability-patterns/)
18 |
19 | ## 延迟与吞吐量
20 |
21 | **延迟**是执行操作或运算结果所花费的时间。
22 |
23 | **吞吐量**是单位时间内（执行）此类操作或运算的数量。
24 |
25 | 通常，你应该以**可接受级延迟**下**最大化吞吐量**为目标。
26 |
27 | ### 来源及延伸阅读
28 |
29 | - [理解延迟与吞吐量](https://community.cadence.com/cadence_blogs_8/b/sd/archive/2010/09/13/understanding-latency-vs-throughput)
30 |
31 | ## 可用性与一致性
32 |
33 | ### CAP 理论
34 |
35 |
36 | 
37 |
38 | 来源：再看 CAP 理论
39 |
130 | 
131 |
132 | 来源：DNS 安全介绍
133 |
168 | 
169 |
170 | 来源：为什么使用 CDN
171 |
207 | 
208 |
209 | 来源：可扩展的系统设计模式
210 |
276 | 
277 |
278 | 资料来源：维基百科
279 |
280 |
319 | 
320 |
321 | 资料来源：可缩放系统构架介绍
322 |
356 | 
357 |
358 | 资料来源：扩展你的用户数到第一个一千万
359 |
377 | 
378 |
379 | 资料来源：可扩展性、可用性、稳定性、模式
380 |
392 | 
393 |
394 | 资料来源：可扩展性、可用性、稳定性、模式
395 |
424 | 
425 |
426 | 资料来源：扩展你的用户数到第一个一千万
427 |
445 | 
446 |
447 | 资料来源：可扩展性、可用性、稳定性、模式
448 |
589 | 
590 |
591 | 资料来源: SQL 和 NoSQL，一个简短的历史
592 |
612 | 
613 |
614 | 资料来源：图数据库
615 |
640 | 
641 |
642 | 资料来源：从 RDBMS 转换到 NoSQL
643 |
682 | 
683 |
684 | 资料来源：可扩展的系统设计模式
685 |
753 | 
754 |
755 | 资料来源：从缓存到内存数据网格
756 |
789 | 
790 |
791 | 资料来源：可扩展性、可用性、稳定性、模式
792 |
824 | 
825 |
826 | 资料来源：可扩展性、可用性、稳定性、模式
827 |
842 | 
843 |
844 | 资料来源：从缓存到内存数据网格
845 |
874 | 
875 |
876 | 资料来源：可缩放系统构架介绍
877 |
920 | 
921 |
922 | 资料来源：OSI 7层模型
923 |
953 | 
954 |
955 | 资料来源：如何制作多人游戏
956 |
977 | 
978 |
979 | 资料来源：如何制作多人游戏
980 |
1006 | 
1007 |
1008 | Source: Crack the system design interview
1009 |
1093 | 资料来源：你真的知道你为什么更喜欢 REST 而不是 RPC 吗 1094 |
1095 | 1096 | #### 来源及延伸阅读：REST 与 RPC 1097 | 1098 | - [你真的知道你为什么更喜欢 REST 而不是 RPC 吗](https://apihandyman.io/do-you-really-know-why-you-prefer-rest-over-rpc/) 1099 | - [什么时候 RPC 比 REST 更合适？](http://programmers.stackexchange.com/a/181186) 1100 | - [REST vs JSON-RPC](http://stackoverflow.com/questions/15056878/rest-vs-json-rpc) 1101 | - [揭开 RPC 和 REST 的神秘面纱](http://etherealbits.com/2012/12/debunking-the-myths-of-rpc-rest/) 1102 | - [使用 REST 的缺点是什么](https://www.quora.com/What-are-the-drawbacks-of-using-RESTful-APIs) 1103 | - [破解系统设计面试](http://www.puncsky.com/blog/2016-02-13-crack-the-system-design-interview) 1104 | - [Thrift](https://code.facebook.com/posts/1468950976659943/) 1105 | - [为什么在内部使用 REST 而不是 RPC](http://arstechnica.com/civis/viewtopic.php?t=1190508) 1106 | 1107 | ## 安全 1108 | 1109 | 这一部分需要更多内容。[一起来吧](#贡献)！ 1110 | 1111 | 安全是一个宽泛的话题。除非你有相当的经验、安全方面背景或者正在申请的职位要求安全知识，你不需要了解安全基础知识以外的内容： 1112 | 1113 | - 在运输和等待过程中加密 1114 | - 对所有的用户输入和从用户那里发来的参数进行处理以防止 [XSS](https://en.wikipedia.org/wiki/Cross-site_scripting) 和 [SQL 注入](https://en.wikipedia.org/wiki/SQL_injection)。 1115 | - 使用参数化的查询来防止 SQL 注入。 1116 | - 使用[最小权限原则](https://en.wikipedia.org/wiki/Principle_of_least_privilege)。 1117 | 1118 | ### 来源及延伸阅读 1119 | 1120 | - [为开发者准备的安全引导](https://github.com/FallibleInc/security-guide-for-developers) 1121 | - [OWASP top ten](https://www.owasp.org/index.php/OWASP_Top_Ten_Cheat_Sheet) 1122 | 1123 | ## 附录 1124 | 1125 | 一些时候你会被要求做出保守估计。比如，你可能需要估计从磁盘中生成 100 张图片的缩略图需要的时间或者一个数据结构需要多少的内存。**2 的次方表**和**每个开发者都需要知道的一些时间数据**（译注：OSChina 上有这篇文章的[译文](https://www.oschina.net/news/30009/every-programmer-should-know)）都是一些很方便的参考资料。 1126 | 1127 | ### 2 的次方表 1128 | 1129 | ``` 1130 | Power Exact Value Approx Value Bytes 1131 | --------------------------------------------------------------- 1132 | 7 128 1133 | 8 256 1134 | 10 1024 1 thousand 1 KB 1135 | 16 65,536 64 KB 1136 | 20 1,048,576 1 million 1 MB 1137 | 30 1,073,741,824 1 billion 1 GB 1138 | 32 4,294,967,296 4 GB 1139 | 40 1,099,511,627,776 1 trillion 1 TB 1140 | ``` 1141 | 1142 | #### 来源及延伸阅读 1143 | 1144 | - [2 的次方](https://en.wikipedia.org/wiki/Power_of_two) 1145 | 1146 | ### 每个程序员都应该知道的延迟数 1147 | 1148 | ``` 1149 | Latency Comparison Numbers 1150 | -------------------------- 1151 | L1 cache reference 0.5 ns 1152 | Branch mispredict 5 ns 1153 | L2 cache reference 7 ns 14x L1 cache 1154 | Mutex lock/unlock 25 ns 1155 | Main memory reference 100 ns 20x L2 cache, 200x L1 cache 1156 | Compress 1K bytes with Zippy 10,000 ns 10 us 1157 | Send 1 KB bytes over 1 Gbps network 10,000 ns 10 us 1158 | Read 4 KB randomly from SSD* 150,000 ns 150 us ~1GB/sec SSD 1159 | Read 1 MB sequentially from memory 250,000 ns 250 us 1160 | Round trip within same datacenter 500,000 ns 500 us 1161 | Read 1 MB sequentially from SSD* 1,000,000 ns 1,000 us 1 ms ~1GB/sec SSD, 4X memory 1162 | Disk seek 10,000,000 ns 10,000 us 10 ms 20x datacenter roundtrip 1163 | Read 1 MB sequentially from 1 Gbps 10,000,000 ns 10,000 us 10 ms 40x memory, 10X SSD 1164 | Read 1 MB sequentially from disk 30,000,000 ns 30,000 us 30 ms 120x memory, 30X SSD 1165 | Send packet CA->Netherlands->CA 150,000,000 ns 150,000 us 150 ms 1166 | 1167 | Notes 1168 | ----- 1169 | 1 ns = 10^-9 seconds 1170 | 1 us = 10^-6 seconds = 1,000 ns 1171 | 1 ms = 10^-3 seconds = 1,000 us = 1,000,000 ns 1172 | ``` 1173 | 1174 | 基于上述数字的指标： 1175 | 1176 | - 从磁盘以 30 MB/s 的速度顺序读取 1177 | - 以 100 MB/s 从 1 Gbps 的以太网顺序读取 1178 | - 从 SSD 以 1 GB/s 的速度读取 1179 | - 以 4 GB/s 的速度从主存读取 1180 | - 每秒能绕地球 6-7 圈 1181 | - 数据中心内每秒有 2,000 次往返 1182 | 1183 | #### 延迟数可视化 1184 | 1185 |  1186 | 1187 | #### 来源及延伸阅读 1188 | 1189 | - [每个程序员都应该知道的延迟数 — 1](https://gist.github.com/jboner/2841832) 1190 | - [每个程序员都应该知道的延迟数 — 2](https://gist.github.com/hellerbarde/2843375) 1191 | - [关于建设大型分布式系统的的设计方案、课程和建议](http://www.cs.cornell.edu/projects/ladis2009/talks/dean-keynote-ladis2009.pdf) 1192 | - [关于建设大型可拓展分布式系统的软件工程咨询](https://static.googleusercontent.com/media/research.google.com/en//people/jeff/stanford-295-talk.pdf) 1193 | --------------------------------------------------------------------------------
