大型网站架构演进历程

Web1.0 静态网站

大型网站都是从小型网站发展起来的
网站架构也是一样
网站刚开始搭建处于雏形阶段，访问量小，一台服务器完全够用
也是大部分企业级应用的选择
所有的网站都是静态的网站，没有和用户的交互，都是单向的

Web2.0

在1.0版本基础上增加了数据库
现在用户和服务器之间可以说是双向的交互
用户可以查询、增加、删除一个数据，这些数据都会保存到数据库里面

应用程序，数据库，文件都部署在一台服务器的

应用服务和数据分离

​随着业务的发展，一台服务器不能满足业务需求：
越来越多的用户访问导致性能越来越差
越来越多的数据导致服务器存储空间不足
这就需要将应用和数据分离
应用和数据分离后整个网站使用两（三）台服务器，应用服务器，文件服务器，（数据库服务器）

应用和数据分离后
不同特性的服务器承担不同的服务角色
网站的并发处理能力和数据存储都得到了很大的改善，支持业务的进一步发展
但是随着业务的增多，访问量增大，网站又一次面临挑战
数据库压力太多导致访问延迟，进而影响整个网站的性能，用户体验收到影响

使用缓存改善网站性能

网站访问特点和现实世界的财富分配通常符合二八定律: 80%的业务访问集中在20% 的数据上
淘宝买家浏览的商品集中在少部分成交数多、评价良好的商品上
百度搜索的关键词集中在少部分热门词汇上，搜索出来的词条你也会浏览前两页的内容。
既然大部分的浏览都只会放在一小部分数据上
那么就能把这些数据缓存起来放在内存中
就可以减少数据库的压力
从而提高整个网站的数据访问速度
改善数据库的写入性能

使用缓存后，有效的改善了数据库访问的压力，
但是单一应用程序的服务器能够处理的连接有限
在网站访问的高峰期间，应用服务器会成为网站的瓶颈

使用应用服务器集群改善网站的并发处理能力

使用集群是解决高并发，海量数据问题的关键手段
当一台服务器的处理能力、存储空间不足的时候，不要尝试去更换一台存储量更大的服务器
而是考虑集群部署
因为对于大型网站而言，不管多么强大的服务器，都满足不了网站持续增长的业务

应用服务器集群部署，使用负载均衡服务器做负载控制
能够改善流量峰值对应用服务器的压力
避免单一服务器承担更多的请求压力
如果还有更多的请求，那么就在现有的基础上增加更多的应用服务器。

数据库读写分离

使用缓存后，能够改善一部分的数据库访问压力
使绝大多数数据读操作访问不用通过数据库就能完成
但是仍有一部分读(缓存访问不命中，缓存过期)和全部的写操作都会直接访问数据库
在网站到达一定的规模后，也会增大数据库的压力
​目前大部分主流数据库都提供主从热备功能
通过配置两台数据库搭建主从关系
可以将一台数据库服务器的数据更新同步到另一台服务器上
网站可以利用这一特性，实现数据库的读写分离的功能，从而改善数据库的压力。

应用在写数据的时候，访问主服务器
在读数据的时候，访问从服务器
主数据库通过主从复制的功能将数据同步更新到从服务器
这样当有读操作的时候，就会直接访问从服务器
当有写操作的时候，会直接访问主服务器
为了便于应用程序访问读写分离后的数据库
通常在应用服务器端使用专门的数据访问模块，使数据库读写分离对应用透明

使用搜索引擎

随着网站业务的扩大，对数据存储和检索的要求也越来越高，网站需要采用一些非关系型数据库技术如NoSQL和非数据库查询技术和搜索引擎

NoSQL和搜索引擎都是源自互联网的技术手段，对可伸缩的分布式特性具有更好的支持。应用服务器则通过一个统一数据访问模块访问各种数据。减轻应用程序管理诸多数据源的麻烦

业务拆分

​大型网站为了应对日益繁杂的业务场景
通过使用分而治之的方式将整个网站的业务拆分成不同的产品线
如大型购物交易网站就会将首页、商铺、订单、买家、卖家等拆分成不同的产品线
分归不同的业务部门负责管理

分布式服务

随着业务拆分越来越小，存储系统越来越大，应用系统的整体复杂度呈指数增长，部署越来越困难
由于所有的应用都要和数据库系统连接
在数万台服务器规模的网站中，这些连接的数目是服务器规模的平方
导致存数据库连接资源不足，拒绝服务。
​ 既然每一个应用系统都需要执行许多相同的业务操作，可以把相同的业务提取出来
由这些可服用的业务连接数据库。提供公用业务服务。

大型网站演化到这里，基本上大多数的技术问题都可以解决
诸如跨数据中心的实时数据同步和具体网站业务相关的问题都可以通过组合改进现有的技术架构来解决。