内容简介

李智慧

曾在阿里巴巴担任技术专家，参与阿里巴巴基础技术平台开发和www.alibaba.com架构设计。

目前就职英特尔亚太研发中心从事云计算与大数据方面的研发工作。

作品目录

第1篇 概述
1 大型网站架构演化 2
1.1 大型网站软件系统的特点 3
1.2 大型网站架构演化发展历程 4
1.2.1 初始阶段的网站架构 4
1.2.2 应用服务和数据服务分离 4
1.2.3 使用缓存改善网站性能 5
1.2.4 使用应用服务器集群改善网站的并发处理能力 6
1.2.5 数据库读写分离 7
1.2.6 使用反向代理和CDN加速网站响应 8
1.2.7 使用分布式文件系统和分布式数据库系统 9
1.2.8 使用NoSQL和搜索引擎 10
1.2.9 业务拆分 11
1.2.10 分布式服务 11
1.3 大型网站架构演化的价值观 13
1.3.1 大型网站架构技术的核心价值是随网站所需灵活应对 13
1.3.2 驱动大型网站技术发展的主要力量是网站的业务发展 13
1.4 网站架构设计误区 14
1.4.1 一味追随大公司的解决方案 14
1.4.2 为了技术而技术 14
1.4.3 企图用技术解决所有问题 14
1.5 小结 15
2 大型网站架构模式 16
2.1 网站架构模式 16
2.1.1 分层 17
2.1.2 分割 18
2.1.3 分布式 18
2.1.4 集群 19
2.1.5 缓存 20
2.1.6 异步 20
2.1.7 冗余 21
2.1.8 自动化 22
2.1.9 安全 23
2.2 架构模式在新浪微博的应用 23
2.3 小结 25
3 大型网站核心架构要素 26
3.1 性能 27
3.2 可用性 28
3.3 伸缩性 29
3.4 扩展性 30
3.5 安全性 30
3.6 小结 31
第2篇 架构
4 瞬时响应：网站的高性能架构 34
4.1 网站性能测试 35
4.1.1 不同视角下的网站性能 35
4.1.2 性能测试指标 36
4.1.3 性能测试方法 39
4.1.4 性能测试报告 41
4.1.5 性能优化策略 41
4.2 Web前端性能优化 42
4.2.1 浏览器访问优化 42
4.2.2 CDN加速 43
4.2.3 反向代理 44
4.3 应用服务器性能优化 45
4.3.1 分布式缓存 45
4.3.2 异步操作 52
4.3.3 使用集群 53
4.3.4 代码优化 54
4.4 存储性能优化 58
4.4.1 机械硬盘vs. 固态硬盘 58
4.4.2 B+树vs. LSM树 59
4.4.3 RAID vs. HDFS 61
4.5 小结 64
5 万无一失：网站的高可用架构 66
5.1 网站可用性的度量与考核 67
5.1.1 网站可用性度量 67
5.1.2 网站可用性考核 67
5.2 高可用的网站架构 69
5.3 高可用的应用 71
5.3.1 通过负载均衡进行无状态服务的失效转移 72
5.3.2 应用服务器集群的Session管理 73
5.4 高可用的服务 76
5.5 高可用的数据 78
5.5.1 CAP原理 79
5.5.2 数据备份 82
5.5.3 失效转移 84
5.6 高可用网站的软件质量保证 85
5.6.1 网站发布 85
5.6.2 自动化测试 86
5.6.3 预发布验证 87
5.6.4 代码控制 88
5.6.5 自动化发布 90
5.6.6 灰度发布 91
5.7 网站运行监控 91
5.7.1 监控数据采集 92
5.7.2 监控管理 93
5.8 小结 94
6 永无止境：网站的伸缩性架构 95
6.1 网站架构的伸缩性设计 97
6.1.1 不同功能进行物理分离实现伸缩 97
6.1.2 单一功能通过集群规模实现伸缩 98
6.2 应用服务器集群的伸缩性设计 99
6.2.1 HTTP重定向负载均衡 100
6.2.2 DNS域名解析负载均衡 101
6.2.3 反向代理负载均衡 102
6.2.4 IP负载均衡 103
6.2.5 数据链路层负载均衡 104
6.2.6 负载均衡算法 105
6.3 分布式缓存集群的伸缩性设计 106
6.3.1 Memcached分布式缓存集群的访问模型 107
6.3.2 Memcached分布式缓存集群的伸缩性挑战 107
6.3.3 分布式缓存的一致性Hash算法 109
6.4 数据存储服务器集群的伸缩性设计 112
6.4.1 关系数据库集群的伸缩性设计 113
6.4.2 NoSQL数据库的伸缩性设计 117
6.5 小结 119
7 随需应变：网站的可扩展架构 121
7.1 构建可扩展的网站架构 122
7.2 利用分布式消息队列降低系统耦合性 123
7.2.1 事件驱动架构 123
7.2.2 分布式消息队列 124
7.3 利用分布式服务打造可复用的业务平台 126
7.3.1 Web Service与企业级分布式服务 128
7.3.2 大型网站分布式服务的需求与特点 129
7.3.3 分布式服务框架设计 130
7.4 可扩展的数据结构 131
7.5 利用开放平台建设网站生态圈 132
7.6 小结 134
8 固若金汤：网站的安全架构 135
8.1 道高一尺魔高一丈的网站应用攻击与防御 136
8.1.1 XSS攻击 136
8.1.2 注入攻击 138
8.1.3 CSRF攻击 139
8.1.4 其他攻击和漏洞 140
8.1.5 Web应用防火墙 141
8.1.6 网站安全漏洞扫描 142
8.2 信息加密技术及密钥安全管理 142
8.2.1 单向散列加密 143
8.2.2 对称加密 144
8.2.3 非对称加密 144
8.2.4 密钥安全管理 145
8.3 信息过滤与反垃圾 146
8.3.1 文本匹配 147
8.3.2 分类算法 148
8.3.3 黑名单 149
8.4 电子商务风险控制 150
8.4.1 风险 151
8.4.2 风控 151
8.5 小结 153
第3篇 案例
9 淘宝网的架构演化案例分析 156
9.1 淘宝网的业务发展历程 157
9.2 淘宝网技术架构演化 158
9.3 小结 162
10 维基百科的高性能架构设计分析 163
10.1 Wikipedia网站整体架构 163
10.2 Wikipedia性能优化策略 165
10.2.1 Wikipedia前端性能优化 165
10.2.2 Wikipedia服务端性能优化 166
10.2.3 Wikipedia后端性能优化 167
11 海量分布式存储系统Doris的高可用架构设计分析 169
11.1 分布式存储系统的高可用架构 170
11.2 不同故障情况下的高可用解决方案 171
11.2.1 分布式存储系统的故障分类 172
11.2.2 正常情况下系统访问结构 172
11.2.3 瞬时故障的高可用解决方案 173
11.2.4 临时故障的高可用解决方案 174
11.2.5 永久故障的高可用解决方案 175
12 网购秒杀系统架构设计案例分析 176
12.1 秒杀活动的技术挑战 177
12.2 秒杀系统的应对策略 177
12.3 秒杀系统架构设计 178
12.4 小结 182
13 大型网站典型故障案例分析 183
13.1 写日志也会引发故障 184
13.2 高并发访问数据库引发的故障 184
13.3 高并发情况下锁引发的故障 185
13.4 缓存引发的故障 185
13.5 应用启动不同步引发的故障 186
13.6 大文件读写独占磁盘引发的故障 186
13.7 滥用生产环境引发的故障 187
13.8 不规范的流程引发的故障 187
13.9 不好的编程习惯引发的故障 188
13.10 小结 188
第4篇 架构师
14 架构师领导艺术 190
14.1 关注人而不是产品 191
14.2 发掘人的优秀 191
14.3 共享美好蓝图 192
14.4 共同参与架构 193
14.5 学会妥协 194
14.6 成就他人 194
15 网站架构师职场攻略 196
15.1 发现问题，寻找突破 197
15.2 提出问题，寻求支持 199
15.3 解决问题，达成绩效 201
16 漫话网站架构师 203
16.1 按作用划分架构师 203
16.2 按效果划分架构师 204
16.3 按职责角色划分架构师 205
16.4 按关注层次划分架构师 205
16.5 按口碑划分架构师 206
16.6 非主流方式划分架构师 207
附录A 大型网站架构技术一览 208
附录B Web开发技术发展历程 215
后记 218
· · · · · ·

作者简介

李智慧

曾在阿里巴巴担任技术专家，参与阿里巴巴基础技术平台开发和www.alibaba.com架构设计。

目前就职英特尔亚太研发中心从事云计算与大数据方面的研发工作。

精彩摘录

一群优秀的人做一件他们热爱的事，一定能取得成功。最好的软件项目管理不是制定计划，组织资源，跟踪修正项目进展，对成员进行激励和惩罚，而是发掘项目组每个成员的优秀潜能，让大家理解并热爱软件产品最终的蓝图和愿景。每个人都是为了实现自我价值而努力，不是为了领工资而工作。一旦做到这一点，项目组每个成员都会自我驱动，自觉合作，寻找达成目标的最终路径并坚韧不拔的持续前进。。。。不需要拙劣胡萝卜和大棒，最好的奖励就是最终要达成的目标本身，最大的惩罚就是这个目标没有实现。寻找一个值得共同奋斗的目标，营造一个让大家都能最大限度发挥自我价值的工作氛围。

——引自第191页

在计算机数据存储领域，一直是关系数据库的天下，以至于传统企业应用领域，许多应用系统设计都是面向数据库设计——先设计数据库然后设计程序，从而导致关系模型绑架对象模型，并由此引申出旷日持久的业务对象贫血模型与充血模型之争。

——引自第117页