《大型网站技术架构》读书笔记（一）

《大型网站技术架构》

大型互联网应用有以下特点：

• 高并发，大流量：日均访问量数以亿计
• 高可用：24小时不间断服务
• 海量数据：存储，管理海量数据
• 用户分布广泛，网络情况复杂
• 安全环境恶劣：容易被攻击
• 需求快速变更，发布频繁
• 渐进式发展：从小型网站慢慢发展成大型网站

演化过程

1 初始阶段

初始阶段.png

所有的业务集中在一起，网站，数据库和文件都放在一个服务器中，典型的LAMP架构
2 应用服务和数据服务分离
随着业务的发展，网站用户越来越多，一台服务器逐渐不能应对需求（存储空间越来越少，性能越来越差）；此时需要将应用和数据分离分别放在3台服务器上：

应用数据分离.png

三者分工不同，对相应的数据库性能要求也不一样：应用程序服务器处理大量业务逻辑，它对CPU的性能要求较高；数据库服务器要快速检索数据和数据缓存，因而对内存和硬盘要求较高；文件服务器要存储大量文件（用户上传的图片等），要求更大的硬盘容量。

三个服务器各司其职，暂时解决了第一阶段的存储容量问题，也提高了并发处理能力。
3 缓存
随着用户的增加，数据库的压力越来越大，用户的每一次登录都要访问数据库，导致响应缓慢，影响用户体验，我们分析发现：

网站访问特点和现实世界的财富分配一样遵循二八定律：80%的业务访问集中在20%的业务上

我们只需将这20%的业务做一下缓存就可以缓解数据库压力大的问题。
网站使用的缓存有两种：1.放在应用服务器上的本地缓存（速度快但是会占用应用程序的内存）；2.放在专门的分布式缓存服务器上的远程缓存（可以用多台服务器做集群，实现大内存容量的缓存服务）。

缓存.png

4 应用服务起集群
此时的应用程序服务器只有一个，它能处理的请求连接有限，在网站访问高峰期应用程序服务器的压力会很大，导致访问排队，响应等待时间长。于是我们要对应用服务器做集群，通过负载均衡调度服务器分发请求给应用程序服务器，多个服务器来处理请求，每一个应用程序服务器的压力都不会太大。

应用服务器集群.png

5 数据库读写分离
现状是加完缓存，大部分数据访问可以不通过数据库，但还有少量的数据读取（未作缓存的数据，缓存过期和缓存未命中的数据）以及全部的数据写入都要访问数据库。随着用户量的增长，数据库的压力越来越明显，逐渐成为网站的瓶颈。

目前大部分的主流数据库都提供主从热备功能，通过配置两台数据库主从关系，可以将一台数据库服务器的数据更新同步到另一台服务器上。网站利用数据库的这一功能，实现数据库读写分离，从而改善数据库负载压力。

数据库读写分离.png

应用程序的写操作访问主数据库服务器，将数据写入；为保证数据一致性，主数据库通过主从复制机制将数据更新同步到从数据库服务器；应用程序的读取数据访问从数据库服务器就可以获取。

为了便于应用程序访问读写分离后的数据库，通常在应用服务器端使用专门的数据访问模块，是数据库读写分离对应用透明。

6 反向代理和CDN
为了让网络环境不是很好的区域的用户也能很好的访问我们的网站，网站需要加速网站的访问速度，此时就会用到反向代理和CDN。

CDN和反向代理.png

CDN和反向代理的基本原理都是缓存，区别在于CDN部署在网络提供商的机房，使用户在请求网站服务是，可以从距离自己最近的网络提供商机房获取数据；而反向代理则部署在网站的中心机房，当用户请求到达中心机房后，首先访问的服务器是反向代理服务器，如果反向代理服务器中缓存这用户请求的资源，就将其直接返回给用户。

这一阶段的目的就是尽快将数据返回给用户，此时的架构一方面加快了用户的访问速度，另一方面也缓解了后端服务器的负载压力。
7 分布式文件系统和分布式数据库
当业务发展到一定程度，数据量十分庞大的时候，两台数据库服务器已经无法满足需求，此时要做分布式数据库和分布式文件系统。
将数据库按照业务进行拆分，将不同业务的数据库部署在不同的物理服务器上。

分布式数据库&分布式文件系统.png

8 NoSql和搜索引擎
随着业务越来越复杂，对数据的存储和检索的需求也变得复杂起来，此时需要使用非关系数据技术（如NoSql）和非数据库查询技术（如搜索引擎）来帮忙。

NoSql和搜索引擎.png

NoSql和搜索引擎都是源自互联网的 技术手段，对可伸缩的分布式特性具有更好的支持。

9 业务拆分
为应对日益复杂的业务场景，将网站以业务为模块进行拆分然后交给不同的业务团队负责管理，达到分治的目的。
具体来说就是将应用服务依业务拆分成一个个小系统（包括商品管理系统，支付系统，订单系统等），然后每个系统独立部署维护。各系统之间通过超链接建立联系，也可以通过消息队列进行数据分发。但都会访问同一个数据存储系统来构成一个完整的网站系统。

业务拆分.png

10 分布式服务
上一阶段每个业务系统都访问数据库资源，随着业务发展必然会导致数据库资源不足，系统的维护也更加困难。分析发现有很多公共业务（如 用户管理，商品管理等），将其提取出来做成公共服务，可以有效缓解上一阶段造成的问题。

分布式服务.png

此时的网站总体架构：

网站架构.png

网站架构演化的价值观

• 大型网站架构技术的核心价值是随网站所需灵活应对（LAMP技术开发小 网站足够，随着业务逐步发展演化）
• 驱动大型网站技术发展的主要力量是业务发展（高并发，多用户驱动集群和分布式）

网站架构设计误区

• 一味追随大公司的解决方案（可以学习借鉴，但不要盲从）
• 为了技术而技术（业务为主，技术为辅）
• 企图用技术解决所有问题（业务问题要从业务的调整来解决）