先上图
到现在为止都是通过新增组件来获得能力的。进化到这个架构大概需要如下的过程：
- 最简单的，上传文件，应用程序和数据库都在同一台机器上
- 把这三大块分离： 应用程序可能需要更快的cpu的电脑，数据库放到内存很大磁盘很快的电脑上去， 建立单独的文件服务器需要很大的磁盘
- 用缓存改善性能，分为本地和远程，本地更快，远程更加可扩展。把集中访问的数据放到缓存上去。这样可以减少给数据库的压力
- 单服务器并发处理能力有限考虑应用服务器的集群，使用负载均衡调用服务器把请求发到不同的应用服务器上去，提高并发处理性能。这样可能会带来session共享等问题需要解决
- 因为数据库将会面临查询瓶颈，因此对数据库进行读写分离。可以使用mysql自带的主从复制功能来实现，应用层可以考虑使用独立的数据库访问模块来完成读写分离。可能会引入主从延迟的问题
加入CDN(内容分发网络)，部署在网络运营商机房，能选择最近网络提供商机房。 反向代理部署在网站中心机房，请求先查询方向代理服务器，如果有要访问的资源，则直接返回。也是缓存的一种体现
规模再变大，单服务器不够大就要使用分布式文件服务器。 数据库容量也不够，并且单纯的读写分离也满足不了查询性能就要使用业务分库分表的方式来构建分布式数据库服务器
增加搜索引擎服务器来代替传统数据库查询，增加Nosql服务器来代替关系型数据库
进行业务拆分。 把整个网站分成多个应用的组合。 应用之间通过超链接，或者消息队列，或者统一的数据库来进行沟通
- soa型服务。 因为应用变多，如果都通过数据库来关联，那么会造成连接不够用，或者更多的事务征用。因此把一些公用组件提成soa服务可以更好的支撑
误区：
- 为了技术而技术
- 迷信大公司的解决方案
- 企图用技术解决所有问题，有些问题可以再业务上解决，比如12306放弃秒杀的方式，改为排队和分时段
