《大型网站技术架构》序

推荐序一

（1）传统企业应用于大型网站应用的区别

1. 传统的企业应用系统主要面对的技术挑战是处理复杂凌乱、干变万化的所谓业务逻辑；而大型网站主要面对的技术挑战是处理超大量的用户访问和海量的数据处理；
2. 前者的挑战来自功能性需求，后者的挑战来自非功能性需求；
3. 功能性需求也许还有“人月神话”聊以自慰，通过增加人手解决问题，而非功能需求大多是实实在在的技术难题，无论有多少工程师，做不到就是做不到。

IT 系统应用于企业管理已有超过半个世纪的历史，人们在这方面积累了大量的知识和经验（架构模式，领域分析，项目管理），而真正意义上大型网站从出现至今不过短短十多年的时间，很多技术挑战还在摸素阶段。市面上关于传统企业应用开发的书籍汗牛充栋，而真正能够深入全面地阐述大型网站技术架构的图书寥寥无几。所以很多人就很困惑：为什么很多看起来不是很复杂的网站，比如Facebook、淘宝，都需要大量顶尖高手来开发呢？

（2）本书的作用

值得庆幸的是，作者为我们带来了这本《大型网站技术架构：核心原理与案例分析》，比较全面地阐述了大型网站的主要技术挑战和解决方案。宏观层面上，将网站架构的演化发展、架构模式、核心要素一一道来；微观层面上，将网站架构常用的分布式缓存、负载均衡、消息队列、分布式服务、甚至网站如何发布运维都逐一进行了阐述。大型网站的技术之道尽在于此。

作者在阿里巴巴工作期间，一方面参与基础技术平台产品开发，一方面参与网站架构设计，这些经历使作者能够比较全面地从理论和实践两个视角去看待和描述网站架构。书中的技术内容基本都从为什么(Why）要这么做和如何去做(How）两个层面进行表述。读者可知其然并知其所以然。

阅读本书也许不能使你就此掌握大型网站架构设计的屠龙之术，但至少使你对网站架构的方法和思维方式能有全面了解。

开卷有益，应该指的就是这样的书。

推荐序二

这些年互联网技术蓬勃发展，各种成熟的组件、工具、框架越来越丰富，各种理论逐渐发展成熟，各大公司公开的理论和实践资料也越来越多，在各个领域都有比较成熟的解决方案，但是研究领先互联网公司的架构，无论是 Google、 Facebook、Amazon 还是淘宝、支付宝、腾讯、百度，都各有其独特的地方。

各个环节都有成熟的产品或者方案，为什么这么多互联网公司的架构还有如此明显的差异呢？是不是照着 Google、 Facebook、淘宝的架构做，就能做好一个“大型的互联网应用”呢？

正如本书中所言：“好的设计绝对不是模仿、不是生搬硬套某个模式，而是在对问题深刻理解之上的创造与创新，即使是“微创新’，也是让人耳目一新的似曾相识。山寨与创新的最大区别不在于是否抄袭、是否模仿，而在于对问题和需求是否真正理解与把握。”

这些大型的互联网应用是设计出来的？还是演化出来的？在设计的过程中需要考虑哪些因素？演化过程中都会面临哪些问题，哪些挑战？

本书从性能、可用性、伸缩性、扩展性、安全性几个网站核心架构要素切入，全面地介绍了这些核心要素面临的问题域、理论基础及应对方案；对这几个方面进行系统地分析，结合目前成熟的解决方案，以及作者自己的工作经验，理论联系实际，踏实细致地提出合理的解决方案，非常值得我们学习和借鉴。

作者-序

高手定律

这个世界只有遇不到的问题，没有解决不了的问题，高手之所以成为高手，是因为他们遇到了常人很难遇到的问题，并解决了。

1. 所以百度有很多广告搜索的高手，
2. 淘宝有很多海量数据的高手，
3. QQ 有很多高并发业务的高手，原因大抵如此。

一个100 万用户的网站，不会遇到1亿用户同时在线的问题；一个拥有100万件商品网站的工程师，可能无法理解一个拥有10亿件商品网站的架构。

我想写一本关于网站架构方面的书源起于 2011 年年末至 2012 年年初发生的两件事。

2011 年末，京东网图书促销，在打5折的基础上再满一百送一百，作为一个爱买书胜过爱读书的人，我对这种促销活动根本没有免疫力，于是兴致勃勃地在活动当天登录www.360buy.com，准备将收藏夹里的图书一网打尽。

往购物车里尽情地塞了一堆书后，点击“购买”按钮，但是浏览器迟迟没有响应，预感到京东的服务器可能因为并发访问量过高，超过了系统的最大负载能力，果然过了一会，浏览器页面显示 “Service is too busy"。我不甘心，返回购物车页面继续点击“购买”按钮，浏览器继续显示 “Service is too busy”。

于是我猜测：能够正常访问购物车，却不能成功购买，问题应该是出在订单系统，B2C 网站生成一个订单需要经历扣减库存、扣减促销资源、更新用户账户等一系列操作，这些操作大多是数据库事务操作，没有办法通过缓存等手段来减轻数据库服务器负载压力，如果事前没有设计好数据库伸缩性架构，那么京东的技术团队将遇到一个大麻烦。

当天晚上，我登录新浪微博，看到京东的大老板刘强东发布了一条微博：“我已经紧急采购了 10 台服务器，增强网站后台，明天继续促销一天，一定让大家买到书”。即使在有成熟数据库伸缩性架构设计的前提下，进行一次数据库扩容也是件辣手的事，而京东只需要一个晚上就能搞定，让我对京东的技术实力刮目相看。

第二天一上班，我的第一件事就是登录 www.360buy.com，点击“购买”按钮后悲剧地发现页面还是 “Service is too busy*。当天晚上，刘强东又发布了一条微博：“请信息部的同事喝茶”。还配了一张照片：一张大桌子，只有一杯茶，旁边放了一把刀⋯⋯

我想京东信息部的同事绝对不是有意要捉弄他们的老板和客户，很可能是他们错误地判断了系统的瓶颈及伸缩性架构的困难，对老板做出了过度承诺，而这背后折射出的是他们对网站架构的本质缺乏了解。

另一件事发生在2012 年年初，当时的中国铁道部官方售票网站 www.12306.cn 在春运期间因为大量用户访问而崩溃，无法有效访问。12306 作为一个运营不久的网站，缺乏大规模并发访问处理的经验，遇到一些问题其实不奇怪，不管花多少钱，经验教训都需要经历时间和挫折才能得到。奇怪的是，12306 的架构师似乎对这种可能发生的大规模并发访问产生的问题完全没有一点概念，系统好像根本没有经过任何高并发场景下的性能评估和性能测试，就那么干脆利落地崩溃了，趴在那里长时间起不来。

这两件事情促使我想写一本关于网站架构的书，阐述网站技术架构最基本的驱动力，基础的架构设计原理，以及架构方案选择的价值观。希望软件工程师们在解决问题之前，能够认真思考自己面对的真正问题究竟是什么，有哪些技术方案可以选择，其基本原理是什么。所以这本书里没有高深的算法和聱牙诘屈的公式，也很少有程序代码。读者可以把本书当作网站架构设计的科普书，即使对网站架构没有什么了解，也能够比较轻松地阅读。

在本书的写作过程中（2012 年下半年)，没有再看到京东促销宕机的新闻，12306 也逐渐稳定成熟。我们虽然无法猜测京东“信息部的同事”和 12306 网站的工程师们付出了多少努力，但能在相对比较短的时间里解决这些技术问题，也说明了网站架构其实并不难，真正能解决问题的技术一定是简单的。