本博客所有原创文章采用知识共享署名-非商业性使用-相同方式共享，转载请保留链接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考虑的问题了.

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

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

前段时间，一直关注一个开源的统计系统http://www.piwik.org，有两个方面的原因，一是对统计非常有兴趣，二是这个项目构建在Zend Framework上，实在是学习ZF难得的一个样板，程序写的很优美，建议想学ZF的人可以阅读piwik源代码，好的，切入正题。

一般的网站统计系统我知道的有三种类型：

• 分析网站日子(Apache log)，代表的有
  AWStats：http://awstats.sourceforge.net/
  analog：http://www.analog.cx/
  Webalizer ：http://www.mrunix.net/webalizer/
  使用Apache log好处是高速、低开销(apache随着访问写log开销不大)，但是功能一般，比如不能记录客户端的的分辨率、色深、是否支持Java或者Flash等。
• 通过在网页中嵌入一个探针记录网站日志，piwik就是这样的典型，特点是快速、高开销(piwik是通过php直接往mysql中写记录)、功能强劲(可以记录客户端的详细信息)。
• 混合使用，代表是Google Analytics、缔元信，这些产品也是在网站中加入一个探针，然后发送一个类似http://www.google-analytics.com/__utm.gif?******的请求，其实是访问服务器上一个空白的图片文件，目的只有一个，记录http日志，这种方式的好处是集上面两种的好处：效率高、功能强。

探针的Javascript代码我们就不分析了，看一下Google Analytics最后发送的请求是什么样子的：

http://www.google-analytics.com/__utm.gif
?utmwv=4.1 //常量
&utmn=1048672819 //随机数，还记得我是怎样处理mootools ajax问题吗？
&utmhn=code.google.com //网站
&utmcs=UTF-8 //编码
&utmsr=1280×800 //分辨率
&utmsc=16-bit //色深
&utmul=zh-cn //语言
&utmje=1 //是否允许Java
&utmfl=9.0%20%20r115 //9.0 r115,Flash播放器版本
&utmdt=Google%20Code //Google Code,标题
&utmhid=594665987
&utmr=- //来源地址
&utmp=/ //目录
&utmac=UA-18071-1 //帐号
&utmcc=__utma%3D247248150.137016230.1209822741.1209822741.1209822741.1%3B%2B__utmz%3D247248150.1209822741.1.1.utmcsr%3D(direct)%7Cutmccn%3D(direct)%7Cutmcmd%3D(none)%3B // 一些加密字串

有兴趣的可以去读一下ga.js源码，入门的话看一下yahoo的统计源码，写的比较清晰，也没有作混淆。