超群.com的博客

构建可扩展网络应用的七个步骤

本博客所有原创文章采用知识共享署名-非商业性使用-相同方式共享，转载请保留链接http://chaoqun.17348.com/2008/09/7-stages-scaling-of-web-apps/

几天前看到The 7 Stages of Scaling Web Apps，觉得很是不错，想写点什么，奈何一直很忙，整天忙着那些quick&dirty的项目，让人也堕落了许多。

今天找到报告的原文看了一下，内容丰满了许多。

要构建一个可扩展的网络应用,大多是数据库分表分库、分布式缓存、负载均衡、统一存储，诸如此类，前面我也翻译了一些国外网站架构文章，John Engales的文章高明之处是分7个步骤阐述了一个网络应用从简单到高度可扩展的构建过程。对比这七个步骤，想想我们的应用处在第几步呢？

报告的一开始解释了Performance（性能）和Scalability（扩展性）的区别，里面有两幅图片很好的诠释了，高性能就是买个好车（高配服务器）在高速公路（充足带宽）跑，高扩展性是一堆车跑在立交桥N通道上，不一定跑的很快，至少不会堵车。

第一步：开始阶段

简单的结构：防火墙＋负载均衡、一对服务器、数据库服务器、内部存储，结构简单，没有冗余，维护成本低，很是适合开始阶段。

这样的应用结构应该撑个50W～100W的访问没问题吧，一般的应用话。

很多的应用可能还不到这个水平，一台服务器扔在托管机房里，应用和数据库跑在同一台服务器上，这样的应该是“第零步”吧，如果要扩展这样的应用，升级到第一步吧，应该对程序和数据库不需要怎么修改，效果可能还会不错（如果你的应用不是特别大的话）。

第二步：和第一步一样，只是规模大了些

应用很成功，加更多防火墙、负载均衡，增加更多的应用服务器，找个DBA来优化一下数据库，增加数据库存储备份，把数据库存到SAN或者DAS（这个不太赞同，有几个有这个钱的啊），仍然是个简单的应用。

第二步也很有用，估计能撑到300W左右。如果钱能解决的问题，都不是问题，访问量大了，有钱了，多买点服务器能解决问题何乐而不为？

第三步：痛苦的开始

访问量大了，加个Squid或者Varnish做反向代理吧，或者更高级的负载均衡，以缓存静态内容。加更多的应用服务器，数据库做个Master-Slave，一台Master负责写操作，N台Slave负责读操作，可能会需要做一些代码修改。

到这一步就有点像模像样了，这应该是硬件方面能做到的极限吧，估计撑了500W左右问题不大。

第四步：更加痛苦了

访问量更大了，做个memcache分布式缓存吧，数据库主从复制出现问题了，大量的写堆积到一台服务器上，复制时间过长（数据库从服务器不能即时同步），然后可以做做数据库分区（或者分表），内容统一存储，需要大量重构应用和数据库结构。

终于引入memcache了，可以大大减轻服务器硬盘读取的负载，当数据库（数据库表）变的过大的时候，再多服务器都不管用，想想你的一个数据表有100G，索引有10个G，服务器内存才4个G，光放索引都放不下。这个时候分表会是一个不错的选择，简单的分表可以自定义一个hash函数或者按照ID主键分表，只是这种固定的分表方法将来数据迁移会费事很多，还是推荐Flickr的中心数据库做法，后面会讲到。

到第四步的规模，估计1000W问题不大了

第五步：真正的痛苦开始了

开始恐慌了，开始考虑整个应用模式了，仅仅是通过业务分区还不够，可以通过地理位置啊（比如北方的用户都用北京的服务器），用户ID啊什么的分服务器分区，建立服务器集群，对于每个集群，所有功能都是可用的（这样可以很好的做数据迁移以及冗余），使用一个hash结构或者主服务器来判断用户属于哪个服务器集群（^_^中心数据库）

第五步？估计很多应用都到不了这一步，已经分完善了，估计5000W左右都没问题。

第六步：一点点痛苦

扩展应用和数据库架构，提高性能，增加新功能，优化代码，访问还在增长，但是可控。

比较惬意的阶段了，1个亿的访问量轻松应对吧。

第七步：进入未知的领域

开始找系统的瓶颈了，电源、存储、CDN什么的，更多的数据中心，可能难题是夸地区的数据复制。

呵呵，这个应该是Google考虑的问题了.

想想我们的应用瓶颈在那里，不要一下子什么都想想全了，一步到位的做法是不存在的，知道那里不足，解决它，发现其他的不足，再解决，无休止的循环，直到你失业（什么问题都没有，还要你做什么啊）或者退休（该歇歇了）。

Tags: Arch, scaling, web