【大型网站架构二】大型网站架构的演化过程

网站系统的架构最终体现在系统的部署运行上，网站架构经历了如下阶段

 

网站服务器集中式

应用服务器、数据库存储服务器、文件服务器在一台机器上。这种部署的应用在现实中基本很少出现过，稍微有点用户规模的网站，这种部署结构的问题会立马显现。这种部署通常用于开发、写一些不会上线开放给用户用的网站。

 

应用服务器、数据库服务器、文件服务器分离

应用服务器、数据库服务器和文件服务器分离以把计算和存储分摊到三台服务器上。这种部署架构的网站存在几年的一段时间。

 

代理服务器的引入

在网站的运维过程中发现，单台web服务器的并发链接数很有限，访问web服务器的核心价值在于获取动态的数据(就Java技术而言，web服务器是一个jsp/servlet引擎)，而对于静态的资源如图片、HTML请求访问等，这不是web容器的专长，也不是web容器存在的目的。此时出现了Apache+Tomcat的模式，Apache作为代理服务器，一方面直接响应静态文件(如图片、)的请求

；另一方面把动态的jsp/servlet请求转发给它代理的Tomcat服务器，Tomcat服务器处理完后，由Apache将结果返回给用户。

 

应用服务器集群引入

代理服务器出现后，并发用户连接数得到有效缓解。但是随着用户数的增加，单台应用服务器如Tomcat、Weblogic、Websphere的负载承受能力收到挑战，此时出现了应用服务器集群以分担单台服务器的负载压力， 此时的架构是反向代理服务器+服务器集群的架构。

 

KV缓存的引入

应用服务器的集群化使得应用服务器同时能够较快响应更多用户的访问请求，但单一数据库的压力读写压力上升，此时单一的数据库已然成为性能瓶颈。为了缓解数据库的访问压力，根据网站的实际运维经验，通常80%的访问集中在20%的数据上(可称为热点数据)，如果把热点数据写入KV缓存,并控制好这些缓存的KV的更新、时效等问题，那么通过在数据库服务器之前加上这么一个屏障，数据库的访问压力QPS可以得到极大的缓解。实际中KV缓存可以有应用服务器JVM内缓存和KV缓存服务器集群，至于数据应该放在JVM缓存中还是KV缓存服务器中，要看数据的规模。

 

实际上，现在的大型网站使用缓存是解决性能问题首选的方案。

 

数据库读写分离

用户规模的持续增长，以及KV的命中失败导致数据库的读写依然压力很大，此时就出现了数据库读写分离的策略。即把数据库系统集群化以满足读的请求，对于些数据库，有一台主数据库服务器专门从来写操作，然后同步更新到从数据系统中。同步复制是异步的操作，同步复制进行的再快，也有个延迟，应该会出现刚更新，但是再次读却失败的情况。

 

分布式数据库

数据库读写分离后，数据库优化的最后一招牌是分库分表。把不用业务存储到不同的数据库中；水平分表，如果一张表非常大，则进行水平拆分，将一个表分解成多个表。

 

分库分表的麻烦在于跨数据库的写操作需要分布式事务；同数据库的多个分表关联查询以及不同数据库的多个分表关联查询，这些都会对性能产生比较大的影响。

 

 

CDN网站加速

CDN即内容分发网络，它部署在网络运行商机房，这样用户访问网站时，可以从离它最近的CDN服务器上获取静态内容，比如图片资源、视频资源等。

问题，当用户访问某个网站时，它最终找到某个CDN为他提供内容的过程是什么？？

 

 

网站技术演进路线图

 

(图片来源：http://www.cnblogs.com/me115/p/3641822.html)