架构设计基本思路
1.架构扩展原则：
 架构的可扩展性往往和并发是息息相关，没有并发的增长，也就没有必要做高可扩展性的架构。
2.扩展的两种方式：
  Scale-up :  纵向扩展，通过替换为更好的机器和资源来实现伸缩，提升服务能力。
  Scale-out : 横向扩展,  通过加节点（机器）来实现伸缩，提升服务能力。
3.可扩展性的理想状态：
  一个服务，当面临更高的并发的时候，能够通过简单增加机器来提升服务支撑的并发度，且增加机器过程中对线上服务无影响(no down time)，这就是可扩展性的理想状态！
开发语言选择
•PHP: facebook,yahho
•Java: taobao,163
•Python: google
•Net: Myspace
开发语言不是可伸缩性的关键，架构才是关键。

V1.0 简单架构

一个简单的小型网站或者应用背后的架构可以非常简单,  数据存储只需要一个mysql instance就能满足数据读取和写入需求（这里忽略掉了数据备份的实例），处于这个时间段的网站，一般会把所有的信息存到一个database instance里面。

不改变架构的优化方法，历史数据迁移

V2.0 垂直拆分

一般当V1.0 遇到瓶颈时，首先最简便的拆分方法就是垂直拆分，何谓垂直？就是从业务角度来看，将关联性不强的数据拆分到不同的instance上，从而达到消除瓶颈的目标。以图中的为例，将用户信息数据，和业务数据拆分到不同的三个实例上。对于重复读类型比较多的场景，我们还可以加一层cache，来减少对DB的压力。

垂直拆分后团队的再细分

V3.0 读写分离

此类架构主要解决V2.0架构下的读问题，通过给Instance挂数据实时备份的思路来迁移读取的压力，在Mysql的场景下就是通过主从结构，主库抗写压力，通过从库来分担读压力，对于写少读多的应用，V3.0主从架构完全能够胜任。

垂直拆分＋读写分离后典型的数据架构图

对于V2.0 V3.0方案遇到瓶颈时，都可以通过水平拆分来解决，水平拆分和垂直拆分有较大区别，垂直拆分拆完的结果，在一个实例上是拥有全量数据的，而水平拆分之后，任何实例都只有全量的1/n的数据，以下图Userinfo的拆分为例，将userinfo拆分为3个cluster，每个cluster持有总量的1/3数据，3个cluster数据的总和等于一份完整数据（注：这里不再叫单个实例 而是叫一个cluster 代表包含主从的一个小mysql集群）。