阶段一：单应用架构
在网站创建初期，经常把所有的东西都在一台机器上部署，这个时候的架构是单应用架构，优点是效率非常高
阶段二：应用服务器和数据库服务器分离
网站上线了，随着时间推移，访问量开始逐渐增大，服务器逐渐的就扛不住了，这个时候就要考虑加机器了，这就进入了第二阶段。
这个阶段增加机器的主要目的是将web服务器和数据库服务器进行拆分，这样不仅提高了单机的负载能力，也提高了容灾能力
第三阶段：应用服务器集群
然而随着访问量的持续增加，单台服务器已经无法满足需求。假设数据库服务器的还未遇到性能问题
此时可以增加应用服务器，这就进入第三阶段——应用服务器集群。
在这个阶段有些问题就逐渐显现出来了，比如：
（1）用户的请求该由哪一台机器进行处理？ ——负载均衡(F5/apache/nginx)
（2）如果用户每次请求的机器不同，那么session如何维护？
1、session同步
2、通过第三方存储(redis等)存储session
3、跳过容器对象
这样架构就变为了以下模式。
阶段四：数据库读写分离
随着业务量进一步增加，数据库服务器的I/O能力会存在瓶颈。
首先考虑的是加机器，但是如果直接一分为二，每次读写还要额外判断数据应该在哪台机器上。
基于电商系统数据库读多写少的特点，可以将一个服务器作为写库，另一个库设为读库，
并设置主从同步进行复制。
这样也会带来数据库不一致的问题，这个问题后期有时间会单独讨论。
实际上，如果读库的量远大于写库的访问量，需要设置多个读库时，可以采取以下的结构
阶段五：引入缓存机制
对于热点数据，没必要每次都去数据库中读取，应该使用 redis、memcache等将这些数据缓存起来
至此，分布式架构的基本框架已经形成。
阶段六：数据库的水平、垂直拆分
数据库永远是最容易造成瓶颈的地方之一，例如阿里巴巴09年“去IOE运动”就是为了解决数据库扩展性瓶颈问题。
在整个架构的编号过程中，所有的数据还是在同一个数据库中的，因此我们可以考虑对数据进行拆分
其中：
垂直拆分就是把不同业务的数据拆分到不同的数据库中