用户增加，功能扩展时系统如何升级 架构改变

1.百万以下下用户： 系统可以scale up方式来升级。 或者简单系统横向扩展。

2.1-2百万账户： 系统按照垂直分割模式设计，将个业务系统分开包括其中的数据库。 譬如用户中心（包括登录), 积分系统，博客，相册等。 按业务逻辑分开是必须的，但是有些信息必须是共享的。 譬如单点登录功能，腾讯的QQ号登录后，各个打通的子系统都可以自动登录。

3. 3百万时：  垂直切分的话，即使各个子系统发展不均衡，也可以独立发展。 但是对于那些需要共享的系统，必须特别处理，甚至开发专门的系统。 譬如技术中间件（文件系统、锁系统、key-value系统),  中间业务系统（session server）。  Myspace系统的话重新打乱系统， 按照注册名 hash，让没一台服务器服务100W个用户，这里我个人不敢苟同。  且不说服务器扩展后的数据迁移，如果业务扩展了，原来能支持100W的机器现在只能支持50W了，那么数据会频繁迁移啊。

4. 1千万时： myspace的存储层使用SAN这种企业级架构的方法非常昂贵而且分布式不灵活的架构是个偷懒的做法。 互联网企业的流量均衡、应用分布式、跨多个数据中心不适合使用SAN这种架构， SAN这种架构一般局限在单个数据中心内，多个数据中心时非常昂贵而且不灵活。 

5. 近2千万： 这个时候才使用缓存，我觉得不可思议啊。 早该用了。 各个层面的。客户端层、应用层和数据层。

6. 2千六百万：数据库服务器 4G内存换成64G，这种依赖硬件升级的办法不是长久的。 另外也提到了，停电造成 SAN 瘫痪，然后再其他城市也建立SAN去解决问题，但是SAN系统不够灵活啊， 互联网企业要少用SAN。

总之，大型网络企业面临业务类型众多、流量巨大、地理跨度光、各个业务交叉逻辑多，所以技术系统需要一个公司层面的架构。 google 就这样一个典型的企业，它全球部署一个spanner实例就可以看出。