近刚看完李智慧的这本《大型网站技术架构》觉得写的非常好，干货满满，特此整理下来，消化一下方便以后查阅。
篇为概述，先讲述了一个大型网站的架构演变过程。然后分析一下大型网站的架构模式及包括哪些核心要素，主要有五个，然后全书从这五个要素一个个展开剖析。后又拿阿里的架构演变化为例，还有wiki百科、秒杀系统等为例去讲架构。后又附录了一些作者工作中的一些tips及遇到的问题的解决方案等。包括对于架构师的一些忠告。这里主要是先记录一下网站的架构演变过程及架构的五个核心要素展开，及简要的拿书的例子做几点概括。
- 大型网站架构演变
2.0版本就是将应用服务器和文件服务器、数据库服务器分离，可以解决一台服务器访问越来越差，甚至空间不足的情况。
但是随着用户逐渐增多，网站又一次面临挑战：数据库压力太大导致访问延迟，进而影响整个网站的性能，用户体验受到影响。这时需要对网站架构进一步优化。
3.0版本 网站使用缓存，网站访问的特点和现实世界财富分配一样遵循二八定律：80%的业务访问集中在20%的数据上。无论是淘宝还是百度搜索或微博都是集中在少部分数据访问上。那我们就可以对这少部分数据进行缓存，减少访问数据库的压力。从而提高网站的数据访问速度，改善数据库的写入性能。
这里缓存又分为两种：一种是缓存在本地服务器，一种是缓存在专门的分布式缓存服务器上的远程缓存。缓存在本地会受空间限制，而缓存在专门的分布式缓存服务器可以理论是不受空间限制。如图所示：
但是问题又来了：单一应用服务器能够处理的请求连接有限，在网站 访问高峰期，应用服务器成为整个网站的瓶颈。
4.0版本 应用服务器集群改善网站的并发处理能力。通过负载均衡调度服务器，可将来自用户浏览器的访问请求分发到应用服务器集群中的任何一台服务器上，如果有更多的用户，就在集群中加入更多的应用服务器，使应用服务器在负载压力不再成为整个网站的瓶颈。
但是问题又来了：网站在缓存后，绝大部分数据读操作访问都可以不通过数据库就能完成，但是仍有一部分读操作（缓存访问不命中，缓存过期）和全部写操作需要访问数据库，在网站用户达到一定规模后，数据库因为负载压力过高而成为网站的瓶颈。
5.0版本 数据库读写分离
应用服务器在写数据时，访问主数据库，主数据库通过主从复制机制将数据更新到从数据库，这样当应用服务器读数据的时候，就可以通过从数据库获得数据。
但是问题又来了：随着用户的规模越来越大，由于中国复杂的多线程环境，不同地区访问网站时，速度差别也极大。有研究表明，网站访问延迟和用户流失率正相关，网站访问越慢，用户越容易失去耐心而离开。
6.0版本 使用CDN和反向代理
使用CDN和反向代理目的都是尽早的返回数据给用户，一方面加快用户访问速度，另一方面也减轻后端服务器的负载压力。
但是问题又来了：随着网站业务的发展，数据库从一台拆分成两台服务器，也不能满足需求。这时候需要使用分布式数据库。文件系统也是一样，需要使用分布式文件系统。
7.0版本 使用分布式文件系统和分布式数据库系统 网站更常用的是数据库拆分手段是业务分库，将不同业务的数据库部署在不同的物理服务器上，其次才是数据库拆分。
但是问题又来了：随着网站 业务的发展，业务越来越复杂，对数据库存储和检索的需求也越来越复杂，网站需要彩一些非关系数据库技术如NOSQL和非数据库查询技术如搜索引擎。
8.0版本
随着业务的复杂，便有业务拆分，比如根据产品线划分，将一个网站拆分成许多不同的应用，每个应用独立部署维护。应用之间通过一个超链接建立关系，也可以通过消息队列进行数据分发，当然多的还是通过访问同一个数据存储系统来构成一个关联的完整系统。如图
但是问题又来了，当服务器达到数万时，这些连接的数目是服务器规模的平方，数据库连接资源不足，拒绝服务。既然每一个应用系统都需要执行许多相同的业务操作，比如用户管理、商品管理，那么可以将这些共同的业务拆分，独立部署。通过分布式服务器调用共同业务逻辑服务完成具体业务操作。
到此为止，基本上常见的问题都可以解决了，具体遇到问题再具体解决。以上为大体的网站架构演变史。总之世界没有哪个网站从诞生就是大型网站，也没有哪个网站 次发布就拥有庞大的用户，高并发的访问，海量的数据，大型网站都是从小型网站发展而来的。所以具体根据业务的发展而进行改造。
比如12306问题，有很多人提出各种方案，但是12306真正的问题其实不在于它的技术架构，而在于它的业务架构：12306根本就不应该在几亿中国人一票难求的情况下以窗口售票的模式在网上售票（零点开始出售若干天后的车票），12306需要重构不仅是它的技术架构，更重要的是它的业务架构：调整业务需求，换一种方式卖票，而不是去搞促销秒杀这种噱头式的游戏。
后来证明12306确实也是朝着这个方向发展的：在售票方式上引入排队机制，整点售票调整为分时段售票。其实如果能够控制并发访问的量，很多棘手的技术问题也就不是问题了。
