李智慧，曾在阿里巴巴担任技术专家，参与阿里巴巴基础技术平台开发和架构设计。目前就职英特尔亚太研发中心从事云计算与大数据方面的研发工作。

　　《大型网站技术架构：核心原理与案例分析》通过梳理大型网站技术发展历程，剖析大型网站技术架构模式，深入讲述大型互联网架构设计的核心原理，并通过一组典型网站技术架构设计案例，为读者呈现一幅包括技术选型、架构设计、性能优化、Web安全、系统发布、运维监控等在内的大型网站开发全景视图。

　　★这是我看过的接地气的一本介绍互联网架构的书籍，深入阐述了大型网站所面临的各种架构问题及解决方案，内容通俗易懂，而且对架构师的领导艺术进行了介绍，很值得从事互联网的技术人员学习和参考。
　　——种新华IBM咨询经理

　　★此书读来亲切，能用不到300页的篇幅将网站架构的过去及未来说得如此通俗易懂，与作者多年的亲身实践分不开，并由此想到一个问题：当此书人手一本的时候，阿里、腾讯、京东……的面试官们怎么办呢？
　　——付银海 Oracle资深工程师

　　★智慧同学，人如其名，在阿里巴巴，人称“教授”，可见其博学多才。《大型网站技术架构：核心原理与案例分析》一书更是其多年积淀厚积薄发之作，涵盖构建大型互联网应用所需的关键技术，兼具实用性和前瞻性，无论是高并发、高性能还是海量数据处理、Web前端架构，都有针对性的解决之道。尤其难得的是此书还对架构师的内涵及技术管理有比较深刻地阐述，实在是同类书籍中难得一见的。作为互联网应用的开发者、架构师和创业者的你，一定不要错过本书，本书足以解决你的技术之忧。
　　——陈斌 拓维信息平台研发总监

　　★教授（本书作者在阿里巴巴的昵称）曾在知名的大型互联网公司第一线浴血多年，经验不可谓不丰富，然而更难得的是他不仅博闻强记，更用行云流水的幽默文风，将现代大型互联网的内部要害一一庖解。也许各家细节略有不同，但大部分的大型互联网站基本都可以用这样的视角去解读。相信本书不仅对程序员，甚至对很多架构师也有参考价值，尤其值得关注的是教授在书中颇多技术之外的考量思索，我愿意称之为互联网基因。
　　——曹文炯 堆糖网技术合伙人

　　★有幸拜读了这本《大型网站技术架构：核心原理与案例分析》，本书从多个层面说明了如何构建一个高可用、高性能、高可扩展性的网站系统，并结合了阿里巴巴及其他互联网企业先进的架构实践经验进行案例分析，讲述非常全面且具指导意义。本书从网站的架构设计、快速开发、高效部署、业务监控、服务治理、运维管理等多个角度描述了架构设计的相关重点，涉及的核心技术包括前端优化、CDN、反向代理、缓存、消息队列、分布式存储、分布式服务、NoSQL存储、搜索、监控、安全等一系列保证大型网站安全可靠运行的关键技术点。本书还提供了网站如何从小型网站伴随用户成长，逐步扩展到大型网站的架构演进思路，是互联网架构师们不可多得的一本技术参考书。
　　——钱煜明 中兴通讯总工程师

　　★设计和规划一个网站的总体架构涉及方方面面的东西，备选的方案也很多，如何在五花八门，纷繁复杂的技术中构建适合用户的网站架构，变成了一件极具争议和挑战性的工作。一个好的架构可以以低的成本，在满足用户需求的同时，满足整个网站的架构灵活性；同样，一个糟糕的架构可能会让你的客户在花费了大量金钱后，得到一堆笨重、复杂且不切实际的东西，或是由于系统过于复杂，故障不断，或是由于架构不够灵活，阻碍业务的发展等等。
　　回顾网站架构的发展历程，我们可以发现任何大型网站架构的发展都非一蹴而就的，同自然界生物物竞天择的自然进化规律一样，大型网站的架构发展和演变也基本遵循着类似的规律。我们可能无法想象几年后网站架构的样子，因为在互联网行业快速变化的当下，你甚至很难准确地预测未来一年网站的产品演变方向，甚至网站流量规模。于是，产品设计师和工程师们提得多的是迭代和演变，这在一个网站系统架构设计过程中显得尤为重要，因为我们永远无法像传统行业一样，去精确地估算，并按预先精确设计好的图纸去完成我们的产品。那是不是网站的架构设计和规划就毫无规律及章法可循了呢？答案显然不是，在互联网快速发展的今天，随着搜索引擎、电子商务、社交类等互联网产品逐步应用到每个人的身边，大型网站的架构及很多关键技术的发展，在逐步走向成熟。在构建一个大型网站过程中可能面临一些问题，人们正在尝试逐渐总结并积累出一些具有通用性的、经过验证的且成熟的局部解决方案，这也是本书将呈现给大家的内容。本书中，作者以自己多年大型互联网网站的架构经验，尝试总结当下这些互联网行业中相对成熟且经过大量案例检验的技术和方案。
　　相信通过阅读本书，您可以一窥大型网站架构的全貌。
　　——余俊 技术专家

　　★循序渐进，娓娓道来，语言生动，举重若轻。
　　——李文兆 高级专家

　　1.4 网站架构设计误区
　　在大型网站架构发展过程中有如下几个容易出现的误区。
　　1.4.1 一味追随大公司的解决方案
　　由于大公司巨大成功的光环效应，再加上从大公司挖来的技术高手的影响，网站在讨论架构决策时，最有说服力的一句话就成了“淘宝就是这么搞的”或者“Facebook就是这么搞的”。
　　大公司的经验和成功模式固然重要，值得学习借鉴，但如果因此而变得盲从，就失去了坚持自我的勇气，在架构演化的道路上迟早会迷路。
　　1.4.2 为了技术而技术
　　网站技术是为业务而存在的，除此毫无意义。在技术选型和架构设计中，脱离网站业务发展的实际，一味追求时髦的新技术，可能会将网站技术发展引入崎岖小道，架构之路越走越难。
　　1.4.3 企图用技术解决所有问题
　　最典型的例子就是2012年年初12306故障事件后，软件开发技术界的反应。
　　各路专业和非专业人士众说纷纭地帮12306的技术架构出谋划策，甚至有人提议帮12306写一个开源的网站，解决其大规模并发访问的问题。
　　12306真正的问题其实不在于它的技术架构，而在于它的业务架构：12306根本就不应该在几亿中国人一票难求的情况下以窗口售票的模式在网上售票（零点开始出售若干天后的车票）。12306需要重构的不仅是它的技术架构，更重要的是它的业务架构：调整业务需求，换一种方式卖票，而不要去搞促销秒杀这种噱头式的游戏。
　　后来证明12306确实是朝这个方向发展的：在售票方式上引入了排队机制、整点售票调整为分时段售票。其实如果能控制住并发访问的量，很多棘手的技术问题也就不是什么问题了。
　　技术是用来解决业务问题的，而业务的问题，也可以通过业务的手段去解决。
　　1.5 小结
　　时至今日，大型网站的架构演化方案已经非常成熟，各种技术方案也逐渐产品化。许多小型网站已经慢慢不需要再经历大型网站经历过的架构演化之路就可以逐步发展壮大，因为现在越来越多的网站从建立之初就是搭建在大型网站提供的云计算服务基础之上，所需要的一切技术资源：计算、存储、网络都可以按需购买，线性伸缩，不需要自己一点一点地拼凑各种资源，综合使用各种技术方案逐步去完善自己的网站架构了。
　　所以能亲身经历一个网站从小到太的架构演化过程的网站架构师越来越少，虽然过去有这种经历的架构师也很少（从小型网站发展成大型网站的机会本来就极少），但是将来可能真就没有了。
　　……

第1篇 概述
1 大型网站架构演化
1.1 大型网站软件系统的特点
1.2 大型网站架构演化发展历程
1.2.1 初始阶段的网站架构
1.2.2 应用服务和数据服务分离
1.2.3 使用缓存改善网站性能
1.2.4 使用应用服务器集群改善网站的并发处理能力
1.2.5 数据库读写分离
1.2.6 使用反向代理和CDN 加速网站响应
1.2.7 使用分布式文件系统和分布式数据库系统
1.2.8 使用NoSQL和搜索引擎
1.2.9 业务拆分
1.2.10 分布式服务
1.3 大型网站架构演化的价值观
1.3.1 大型网站架构技术的核心价值是随网站所需灵活应对
1.3.2 驱动大型网站技术发展的主要力量是网站的业务发展
1.4 网站架构设计误区
1.4.1 一味追随大公司的解决方案
1.4.2 为了技术而技术
1.4.3 企图用技术解决所有问题
1.5 小结
2 大型网站架构模式
2.1 网站架构模式
2.1.1 分层
2.1.2 分割
2.1.3 分布式
2.1.4 集群
2.1.5 缓存
2.1.6 异步
2.1.7 冗余
2.1.8 自动化
2.1.9 安全
2.2 架构模式在新浪微博的应用
2.3 小结
3 大型网站核心架构要素
3.1 性能
3.2 可用性
3.3 伸缩性
3.4 扩展性
3.5 安全性
3.6 小结

第2篇 架构
4 瞬时响应：网站的高性能架构
4.1 网站性能测试
4.1.1 不同视角下的网站性能
4.1.2 性能测试指标
4.1.3 性能测试方法
4.1.4 性能测试报告
4.1.5 性能优化策略
4.2 Web 前端性能优化
4.2.1 浏览器访问优化
4.2.2 CDN 加速
4.2.3 反向代理
4.3 应用服务器性能优化
4.3.1 分布式缓存
4.3.2 异步操作
4.3.3 使用集群
4.3.4 代码优化
4.4 存储性能优化
4.4.1 机械硬盘vs. 固态硬盘
4.4.2 B+树vs.LSM 树
4.4.3 RAIDvs.HDFS
4.5 小结
5 万无一失：网站的高可用架构
5.1 网站可用性的度量与考核
5.1.1 网站可用性度量
5.1.2 网站可用性考核
5.2 高可用的网站架构
5.3 高可用的应用
5.3.1 通过负载均衡进行无状态服务的失效转移
5.3.2 应用服务器集群的Session 管理
5.4 高可用的服务
5.5 高可用的数据
5.5.1 CAP 原理
5.5.2 数据备份
5.5.3 失效转移
5.6 高可用网站的软件质量保证
5.6.1 网站发布
5.6.2 自动化测试
5.6.3 预发布验证
5.6.4 代码控制
5.6.5 自动化发布
5.6.6 灰度发布
5.7 网站运行监控
5.7.1 监控数据采集
5.7.2 监控管理
5.8 小结
6 永无止境：网站的伸缩性架构
6.1 网站架构的伸缩性设计
6.1.1 不同功能进行物理分离实现伸缩
6.1.2 单一功能通过集群规模实现伸缩
6.2 应用服务器集群的伸缩性设计
6.2.1 HTTP 重定向负载均衡
6.2.2 DNS 域名解析负载均衡
6.2.3 反向代理负载均衡
6.2.4 IP 负载均衡
6.2.5 数据链路层负载均衡
6.2.6 负载均衡算法
6.3 分布式缓存集群的伸缩性设计
6.3.1 Memcached 分布式缓存集群的访问模型
6.3.2 Memcached 分布式缓存集群的伸缩性挑战
6.3.3 分布式缓存的一致性Hash 算法
6.4 数据存储服务器集群的伸缩性设计
6.4.1 关系数据库集群的伸缩性设计
6.4.2 NoSQL 数据库的伸缩性设计
6.5 小结
7 随需应变：网站的可扩展架构
7.1 构建可扩展的网站架构
7.2 利用分布式消息队列降低系统耦合性
7.2.1 事件驱动架构
7.2.2 分布式消息队列
7.3 利用分布式服务打造可复用的业务平台
7.3.1 Web Service 与企业级分布式服务
7.3.2 大型网站分布式服务的需求与特点
7.3.3 分布式服务框架设计
7.4 可扩展的数据结构
7.5 利用开放平台建设网站生态圈
7.6 小结
8 固若金汤：网站的安全架构
8.1 道高一尺魔高一丈的网站应用攻击与防御
8.1.1 XSS 攻击
8.1.2 注入攻击
8.1.3 CSRF 攻击
8.1.4 其他攻击和漏洞
8.1.5 Web 应用防火墙
8.1.6 网站安全漏洞扫描
8.2 信息加密技术及密钥安全管理
8.2.1 单向散列加密
8.2.2 对称加密
8.2.3 非对称加密
8.2.4 密钥安全管理
8.3 信息过滤与反垃圾
8.3.1 文本匹配
8.3.2 分类算法
8.3.3 黑名单
8.4 电子商务风险控制
8.4.1 风险
8.4.2 风控
8.5 小结

第3篇 案例
9 淘宝网的架构演化案例分析
9.1 淘宝网的业务发展历程
9.2 淘宝网技术架构演化
9.3 小结
10 维基百科的高性能架构设计分析
10.1 Wikipedia 网站整体架构
10.2 Wikipedia 性能优化策略
10.2.1 Wikipedia 前端性能优化
10.2.2 Wikipedia 服务端性能优化
10.2.3 Wikipedia 后端性能优化
11 海量分布式存储系统Doris 的高可用架构设计分析
11.1 分布式存储系统的高可用架构
11.2 不同故障情况下的高可用解决方案
11.2.1 分布式存储系统的故障分类
11.2.2 正常情况下系统访问结构
11.2.3 瞬时故障的高可用解决方案
11.2.4 临时故障的高可用解决方案
11.2.5 永久故障的高可用解决方案
12 网购秒杀系统架构设计案例分析
12.1 秒杀活动的技术挑战
12.2 秒杀系统的应对策略
12.3 秒杀系统架构设计
12.4 小结
13 大型网站典型故障案例分析
13.1 写日志也会引发故障
13.2 高并发访问数据库引发的故障
13.3 高并发情况下锁引发的故障
13.4 缓存引发的故障
13.5 应用启动不同步引发的故障
13.6 大文件读写独占磁盘引发的故障
13.7 滥用生产环境引发的故障
13.8 不规范的流程引发的故障
13.9 不好的编程习惯引发的故障
13.10 小结

第4篇 架构师
14 架构师领导艺术
14.1 关注人而不是产
14.2 发掘人的优秀
14.3 共享美好蓝图
14.4 共同参与架构
14.5 学会妥协
14.6 成就他人
15 网站架构师职场攻略
15.1 发现问题，寻找突破
15.2 提出问题，寻求支持
15.3 解决问题，达成绩效
16 漫话网站架构师
16.1 按作用划分架构师
16.2 按效果划分架构师
16.3 按职责角色划分架构师
16.4 按关注层次划分架构师
16.5 按口碑划分架构师 206
16.6 非主流方式划分架构师

附录A 大型网站架构技术一览
附录B Web开发技术发展历程
后记