网站架构结构的变迁史

    前些天看到一篇不错的文章[1]，讲的是网站架构的发展历史，这种综述的文章每每很可贵，这里进行一个简化诉述和我我的的解读，详细的信息能够参看Ref的链接。首先，我先给一个通俗的理解，网站架构发展的驱动力是用户数和数据量的膨胀，压力瓶颈在websever链接和database之间来回切换，解决问题的三板斧：加缓存（精益求精地作缓存。。。）、加机器（多搞搞分布式，一台不行多台）和功能分离（读写分离、业务分离、动静分离等等）。下面是所读那篇文章的主要思路。

    网站架构的演变主要经历了以下几个阶段：

    一、物理分离webserver和数据库

 

    比较直观，再也不赘述。

    二、增长页面缓存

    目的是减少数据库链接的资源竞争以及对数据库读访问的压力，此时会采用squid等机制将更新周期相对较长的静态页面作缓存，从而减小对webserver和databse的压力。

    三、增长页面片断缓存

    采用前端页面缓存相似的技术，不过这里更进一步将动态页面中相对静态的部分也作了缓存，使用ESI之类的页面片断缓存策略。进一步缓解database的读压力。

    四、数据缓存

    一样的思路，不过这里是将数据库中常常访问的、重复获取的数据放到缓存里，也就是数据缓存，进一步缓解数据库压力。因而可知，在网站发展的开始阶段，你们提升网站性能的主要途径就是加缓存，另外，在这些阶段，database的IO始终是限制并发和性能瓶颈。

    五、增长webserver

    随着系统访问量的进一步增长，websever上的压力徒增，在高峰时没法保证稳定链接，这是为了解决可用性问题，避免单点，引入了多机。sever集群的介入带来一些新问题，也诞生了一些新技术：负载均衡问题（Apache自带的负载均衡或者lvs），可靠性问题（主备技术，heart-beat等），状态信息同步问题（用户session同步和共享技术、状态信息广播），缓存信息的同步（分布式缓存，缓存同步等），多机系统文件功能的保持（共享文件、共享存储等等） 

    六、分库

    此时应对的数据量的膨胀，数据库须要进行分库和调优，database也分摊到多机上面。

 

    七、分表、DAL和分布式缓存

    数据量继续大幅增加，因而出现了通用的框架来实现分库分表的数据访问（例如ebay架构中对一个的DAL），而且因为数据量过大，不太可能再缓存在本地，因而采用了分布式缓存。动态hash算法、一致性hash以及DAL技术获得了普遍的应用。

    八、增长更多的server

    当上面的技术缓解了database的压力时，webserver又成为瓶颈，尤为是面临愈来愈多的链接请求，太高的请求数会被apache服务器阻塞排队，从而响应速度变慢。此时就须要进一步的增长websever的数量，这带来了新的挑战，例如以前的负载均衡方法hold不住了（硬件负载，如F五、Netsclar、Athelon之类的开始成为选择，但价格昂贵，或者采用逻辑分类的方法，将请求分散到不一样的软负载集群）、文件共享瓶颈（分布式文件系统迎来了大规模应用）

 

    九、数据读写分离和廉价存储方案

    websever链接的问题获得缓和了，数据库又出问题了，此时分析数据库的压力状况，发现其读写比很高，所以想到了读写分离方案，另外编写一些更为廉价的存储方案，例如BigTable。

     十、大型分布式应用时代和廉价服务器群的时代

    这时作的主要事情是将系统进行业务职责才分，造成大型的分布式应用，这个步骤至关艰难和耗时，主要挑战有（下面三点摘的原话）：

    1）、拆成分布式后须要提供一个高性能、稳定的通讯框架，而且须要支持多种不一样的通讯和远程调用方式；

      2）、将一个庞大的应用拆分须要耗费很长的时间，须要进行业务的整理和系统依赖关系的控制等；

      3）、如何运维（依赖管理、运行情况管理、错误追踪、调优、监控和报警等）好这个庞大的分布式应用。

 

Ref：

[1] http://www.blogjava.net/BlueDavy/archive/2008/09/03/226749.html