大型网站的特点：

• 高并发、大流量：需要面对高并发用户，大流量访问。
• 高可用：需要7 x 24小时不间断服务。
• 海量数据：数据需要存储、管理，需要大量服务器。
• 用户分步广泛、网络情况复杂：全球网络复杂，像国内还有各个运营商网络互通难的问题。
• 安全环境恶劣：互联网开放性，使得网站易受到攻击。
• 需求快速变更，发布频繁：快速迭代。
• 渐进式发展：从小网站开始，逐渐发展成大站点。

大型网站的主要技术挑战

庞大的用户，高并发的访问和海量数据。任何简单业务在处理PB级数据或数以亿计的用户时，问题就会变得棘手。

大型网站架构的演化过程

初始阶段的网站架构

大多数小项目的初期架构都是这样。随着网站业务发展，1台服务器无法满足需求：用户越来越多，网站性能越来越差，越来越多的数据导致存储空间不足。

应用、数据库、文件分离

• 应用服务与数据服务分离：提高性能，解决存储问题。【服务器专用化】
• 应用服务器：处理业务，要求CPU强
• 文件服务器：存储文件，要求存储容量大
• 数据库服务器：存储数据、缓存、磁盘检索，要求内存、硬盘速度快

随着用户量增多，数据库压力大，会成为系统瓶颈。

用缓存改善网站性能

二八定律：80%的业务访问20%的数据。所以常用数据放入缓存，可以减少数据库的压力。

缓存分为两种：

• 本地缓存：访问更快，但受应用服务器内存限制，且会出现和应用程序争用内存的情况。
• 分布式缓存：集群方式，专用服务器作为缓存服务器，理论上不受内存容量限制。

目前只有单个应用服务器，且只部署了一个实例，其能够处理的连接数有限，在网站访问高峰期时，应用服务器会变成瓶颈。

使用应用集群改善网站的并发能力

一台服务器的处理能力不足时，不要考虑去换更强大的服务器，对于大型网站而言，不管多么强大的服务器，都满足不了网站持续增长的业务需求。最好的方式是添加更多的服务器来分担原有服务器的访问。

数据库读写分离

数据库还存在的的问题：使用缓存后，依然会有部分读操作（缓存没有命中，缓存过期等）和所有的写操作需要访问数据库。在网站用户达到一定规模后，数据库依然会因为负载较高成为系统瓶颈。

解决办法：采用数据库读写分离，两台数据库配置主从关系，从主库写数据，从从库读数据，主库的数据会同步到从库中。

为了便于应用程序能够透明地访问读写分离的数据库，所以在应用程序中使用专门的数据访问模块。

使用反向代理缓存和CDN加速网站响应：网络环境复杂，缓存前端静态资源

请求访问存在的问题：随着网站持续的发展，发现不同网络环境的用户访问速度不同。

解决办法：使用反向代理缓存和CDN加速网站响应。

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

CDN和反向代理的目的：尽早返回数据给用户，一方面加快用户访问速度，另一方面减轻应用服务器的负载压力。

使用分布式文件系统和分布式数据库系统

随着网站业务发展，原有读写分离的数据库也不能支撑。另外，原有的文件服务器也无法满足需求了。

这时，需要使用分布式数据库和分布式文件系统。

分布式数据库是网站数据库拆分的最后手段，只有在单表数据规模非常庞大时才使用。

网站更常用的数据库拆分手段是业务分库，将不同的业务数据部署在不同的物理服务器上。

使用NoSQL和搜索引擎

随着业务越来越复杂，对数据存储和检索的需求也越来越复杂，网站需要采用NoSQL和非数据库查询技术比如搜索引擎。

业务拆分（分治）

网站过于复杂，将业务拆分。比如商城拆分为首页、店铺、订单、买家、卖家等产品线，归不同的业务团队负责。具体到技术，也会根据产品线划分，将一个网站拆分为多个应用，每个应用独立部署维护。

应用之间可以通过一个超链接建立关系（在首页的导航链接指向不同的应用地址），也可以通过消息队列进行数据分发，当然最多的还是通过访问同一个数据存储系统来构成一个关联的完整系统。

分布式服务

业务拆分越来越小，存储系统越来越大，应用系统整体复杂度呈指数型增加，部署维护越来越困难。由于所有应用都需要连接数据库，在数万台服务器的情况下，数据库连接会资源不足。

既然每个应用系统都需要相同的业务操作，比如用户管理、商品管理等，可以把这些共用业务抽取出来，独立部署。