大型网站架构演化 发展历程
网站的挑战来自庞大的用户，高并发的访问和海量数据；大型网站架构主要就是解决这里问题的
1 初始阶段的网站架构
大多数网站都是小型开始的，网站架构也一样从小型网站架构慢慢的演化；
最开始的阶段没有啥人访问，只需要一台服务器就绰绰有余了；这时候结构如下图；
【图片】
只需要一台服务器就可以了(应用程序，数据库，文件等所有资源都在这台服务器)
服务器通常是Linux，数据库Mysql/pgSql；
很多小型网站都是基于一台廉价的服务器就开张的；
2 应用服务和数据服务分离
新问题：随着业务发展，一台服务器逐渐不能满足需求了，随着用户的增多；会出现网站性能越来越差；越来越多的数据导致储存空间不足的情况；
这时候就需要应用和数据分离；
网站根据需求分为三个方面的服务器；
【如图】
- 应用服务器
- 文件服务器
- 数据库服务器
三台服务器对硬件资源的要求各不相同，
- 应用服务器：需要处理大量的业务逻辑，需要更快更强大的CPU
- 文件服务器：需要储存大量用户上传的文件，因此需要更大的硬盘
- 数据库服务器：需要快速磁盘检索和数据缓存，因为需要更快的硬盘和更大的内存；
不同特性的服务器承担不同的服务角色，网站的兵法处理能力和数据存储空间得到很大的改善；
3 使用缓存改善网站性能
新问题：随着用户的逐渐增多，网站又一次面临挑战；数据库压力太大导致访问延迟，进而影响整个网站的性能，用户体验受到影响；
网站访问的特点和现实世界的财富分配一样的：80%的业务访问集中在20%的数据上；
- 淘宝买家浏览商品几种在少部分成交数多，评价良好的商品上；
- 百度搜索关键词集中在少部分热门词汇上；
- 只要经常登陆的用户才会发微博，看微博；
既然大部分的业务集中在小部分数据上，如果把这一小部分数据缓存在内存中，是不是就可以减少数据库的访问压力，提高整个网站的数据访问速度，改善数据库的写入性能呢？
网站使用的缓存可以分为两种：
- 缓存在应用服务器上的本地缓存
- 本地缓存：访问速度更快，但是受应用服务器内存限制，其缓存数据量有限，而且会出现和应用程序争内存的情况
- 缓存在专门分布式服务器上的远程缓存
- 远程分布式缓存：可以使用集群的方式，部署大内存的服务器作为专门的缓存服务器，可以在理论上做到不受内存容量限制的缓存服务
【如图】
使用缓存后，数据库访问压力得到有效缓解
4 使用应用服务器集群改善网站的并发处理能力
新问题：单一应用服务器能够处理的请求链接有限，在网站访问高峰期，应用服务器成为整个网站的瓶颈；
使用集群是网站解决高并发，海量数据问题的常用手段；
当一台服务器的处理能力，储存空间不足的时候，不要企图去换更强大的服务器，对大型网站而言，不管多强大的服务器都满足不了持续增长的业务需求；这种情况下，更恰当的做法是增加一台服务器分担原有服务器的访问和储存压力
对于网站架构而言，只要能够通过一台服务器的方式改善负载压力，就可以同样的方式持续增加服务器不断改善系统性能，从而实现系统的可伸缩性；从而实现系统的可伸缩性，应用服务器实现集群是网站可伸缩集群架构设计中较为简单成熟的一种；
【如图】
通过负载均衡调度服务器，可将来自用户浏览器的访问请求分发到应用服务器集群中的任何一台服务器上，如果有更多的用户，就在急群众加入更多的应用服务器，使应用服务器的负载压力不再成为网站的瓶颈；
5 数据库读写分离
新问题：网站使用缓存后，绝大部分数据读取操作访问都可以不通过数据库就能完成，但是仍有一分部读取操作（缓存访问未命中，缓存过期）和全部的写操作需要访问数据库，在网站的规模打到一定规模后，数据库因为负载压力过高而成为网站的瓶颈。
目前大部分的主流数据库都提供主从热备功能，通过配置两台数据库主从关系，可以将一台数据库服务器的数据更新同步到另一台服务器上；网站利用数据库的这一功能，实现数据库读写分离，从而改善数据库负载压力；
【如图】
应用服务在写数据的时候，访问著数据库，著数据库通过主从复制机制将数据更新同步到从数据库，这样当应用服务器读数据的时候，就可以通过从数据库获得数据；
为了方便应用程序访问读写分离后的数据库，通常在应用服务器端使用专门的数据访问模块，使数据库读写分离对应用透明；
6 使用反向代理和CDN加速网站响应
新问题：由于复杂的网络环境，不同地区速度差别大，网站访问速度慢
可以使用 CND和反向代理；
基本原理都是缓存，区别在于
- CDN部署在网络提供商机房
- 用户在请求网站时候，可以从距离自己最近的网络提供商机房获取数据
- 反向代理部署在网站的中心机房
- 当用户请求到达中心机房后，首先访问的服务器是方向代理服务器；如果方向代理服务器缓存着用户请求资源，就将其直接返回给用户；
【如图】
使用CDN和反向代理的目的都是尽早返回数据给用户，
- 一方面加快用户访问速度
- 另一方面也减轻后端服务器的负载压力
7 使用分布式文件系统和分布式数据库系统
如果上面操作还满足不了业务需求，就需要使用 分布式文件系统和分布式数据库系统 了；
分布式数据库是网站数据库拆分的最后手段，只有在单表数据库规模非常庞大的时候才使用；
不到万不得已，网站更常用的数据库拆分手段是业务分库，将不同业务的数据库部署在不同的物理服务器上；
【如图】
8 使用NoSQL和搜索引擎
随着网站业务越来越复杂，对数据存储和检索的需求也越来越复杂，网站需要采用一些非关系数据库技术；
如NoSQL和非数据库查询技术如搜索引擎；
【如图】
NoSQL和搜索引擎都是源自互联网的技术手段，对可伸缩的分布式特性具有更好的支持；
应用服务器通过一个统一数据访问模块访问数据，减轻应用程序管理诸多数据源的麻烦
9 业务拆分
大型网站为了应对日益复杂的业务场景，通过使用业务拆分应对压力；
比如购物网站将首页/店铺/订单/买家/卖家拆分成不同的产品线（每个应用独立部署维护，应用之间通过超链接连接），分归不同业务团队负责；
10 分布式服务
随着业务拆分越来愈小，储存系统越来越庞大，应用系统的整体复杂度呈现指数级递增，部署维护越来越困难；
由于所有应用要和所有数据库系统连接，在数万台服务器规模的网站中，这些连接的数目是服务器规模的平方，导致存数据库资源不足，拒绝服务；
既然每一个应用系统都需要执行许多相同的业务操作，比如用户管理，商品管理等，那么可以将这些公用的业务提取出来，独立部署；
由这些可复用的业务连接数据库，提供公用业务服务，而应用系统只需要管理用户界面，通过分布式服务调用公共业务服务完成具体业务操作；
【如图】
大型网站的架构演化到这里，基本上大多数的技术问题都得以解决，侏儒跨数据库中心的实时数据同步和具体网站业务相关的问题也都可以通过组合改进现有技术架构来解决
