读书札记 二 《大型网站技术架构：核心原理与案例分析》
第一章 大型网站架构演化
演化过程依次为：
- 应用程序、数据库、文件等所有资源都在一台服务器上
- 应用服务与数据服务分离
- 应用服务器：处理大量业务逻辑 更快更强CPU
- 文件服务器：存储用户上传大量文件 更大硬盘
- 数据库服务器：快速磁盘检索和数据缓存 更快磁盘+更大内存
- 使用缓存改善网站性能
遵循二八定律：80%的业务访问集中在20%的数据上
增加分布式缓存服务器集群 - 使用应用服务器集群改善网站的并发处理能力
- 数据库读写分离
使用主从热备功能 - 使用反向代理和CDN加速网站响应
二者基本原理都是缓存- CDN：部署在网络提供商的机房，使用户在请求网站服务时，可以从距离自己最近的网络提供商机房获取数据
- 反向代理：部署在网站的中心机房，当用户请求到达中心机房后，首先访问的服务器是反向代理服务器，如果反向代理服务器中缓存着用户请求的资源，就将其直接返回给用户。
- 使用分布式文件系统和分布式数据库系统
- 使用NoSQL和搜索引擎
采用非关系数据库技术和非数据库查询技术 - 业务拆分
分成不同的产品线，分归不同的业务团队负责，通过访问同一个数据存储系统来构成一个关联的完整系统。 - 分布式服务
将每个应用系统的共用业务提取出来，独立部署。由这些可复用的业务连接数据库，提供共用业务服务，而应用系统只需要管理用户界面，通过分布式服务调用共用业务服务完成具体业务操作。
网站架构设计误区中，常常出现的是
企图用技术解决所有问题。案例有12306:其真正的问题不在于技术架构，而是它的业务架构，这才是要重构的重点：调整业务需求，换一种方式售票。后来证明12306确实是朝这个方向发展的：在售票方式上引入了排队机制、整点售票调整为分时段售票。其实如果能控制住并发访问量，很多棘手的技术问题也就不是什么问题了。
第二章 大型网站架构模式
大型网站面临的挑战：
- 高并发访问
- 海量数据处理
- 高可靠运行
技术架构目标：
- 高性能
- 高可用
- 易伸缩
- 可扩展
- 安全
分层
分成应用层、服务层、数据层。而应用层可再细分为视图层（美工负责）和业务逻辑层（工程师负责）；服务层也可再细分为数据接口层（适配各种输入和输出的数据格式）和逻辑处理层。
分割
将上述的一层中分割成不同的应用，让不同的团队负责，部署在不同的服务器上。
分布式
分布式方案：
- 分布式应用与服务
- 分布式静态资源
- 分布式数据和存储
- 分布式计算
集群
将独立部署的服务器集群化，即多台服务器部署相同的应用构成一个集群，通过负载均衡设备共同对外提供服务。
缓存
- CDN
- 反向代理
- 本地缓存
- 分布式缓存
异步
高效的系统解耦合手段，业务之间的消息传递不是同步调用，而是将一个业务操作分成多个阶段，每个阶段之间通过共享数据的方式异步执行进行协作。
1. 在单一服务器内部可通过多线程共享内存队列的方式实现异步，处在业务逻辑操作前面的线程将输出写入到队列，后面的线程从队列中读取数据进行处理；
2. 在分布式系统中，多个服务器集群通过分布式消息队列实现异步，分布式消息队列可以看作内存队列的分布式部署。
冗余
数据冗余备份，以应对某台服务器宕机。
自动化
- 发布过程自动化
- 自动化代码管理
- 自动化测试
- 自动化安全测试
- 自动化部署
- 自动化监控
- 自动化报警
- 自动化失效转移
- 自动化失效恢复
- 自动化降级：拒绝部分请求 + 关闭部分不重要的服务
- 自动化分配资源
新浪微博系统架构：
第三章 大型网站核心架构要素
伸缩性：通过不断向集群中加入服务器的手段来缓解不断上升的用户并发访问压力和不断增长的数据存储需求。
扩展性：在网站增加新的业务产品时，是否可以实现对现有产品透明无影响，不需要任何改动或者很少改动既有业务功能就可以上线新产品。
第四章 瞬时相应：网站的高性能架构
性能测试曲线：
并发用户访问响应时间曲线：