BlogJava-Tin's Blog-随笔分类-Djangohttp://www.blogjava.net/iamtin/category/26583.htmlYou are coming a long way, baby~Thinking, feeling, memory...zh-cnWed, 28 Nov 2007 21:17:53 GMTWed, 28 Nov 2007 21:17:53 GMT60Re:架构考量-选择的难度http://www.blogjava.net/iamtin/archive/2007/11/28/reply_architecture_debate_of_haokanbu.htmlTinTinWed, 28 Nov 2007 14:39:00 GMThttp://www.blogjava.net/iamtin/archive/2007/11/28/reply_architecture_debate_of_haokanbu.htmlhttp://www.blogjava.net/iamtin/comments/163835.htmlhttp://www.blogjava.net/iamtin/archive/2007/11/28/reply_architecture_debate_of_haokanbu.html#Feedback0http://www.blogjava.net/iamtin/comments/commentRss/163835.htmlhttp://www.blogjava.net/iamtin/services/trackbacks/163835.html 架构考量-选择的难度
里面谈到了架构一个高支撑能力的Web 2.0应用需要考虑的架构选型问题，对我很有帮助。我也回复一下他的建议：

非常不好意思，今天检查google reader才发现HD老大记录了这个谈话。而我都没有在blog里面记录这个事情。不过和HD老大的谈话回来我还是仔细消化了一下。关于交换机的事情我已经反思了，后来在切换服务器的时候的确发现了百兆和千兆的区别，rsync在百兆网络下的确造成了我们的切换宕计时间变长。当时我们停止服务15分钟，如果是千兆网络估计5分钟以内就可以了，所以如HD所说，我们也许应该选择HW的千兆。
关于文件服务的问题，我想目前的关键还是需要看看是否有热点数据。不过对于网站来说，由于首页和离首页深度比较近的页面被访问的可能性要明显的高，所以如果使用squid做反向代理肯定可以减轻静态文件服务的压力。但是问题也在这里，一定要流量对静态文件有压力的时候再加Squid。
其实本次切换的主要问题是将动态服务与静态服务分开。因为没有选择纯磁盘阵列用光纤或者iSCSI的方式挂在到动态服务器（因为原先的2950充当了文件服务器），所以为了不浪费计算资源我们将动态服务器（8G内存，Raid1和15k rpm硬盘）和静态服务器（8G内存，Raid5和750G X 6的7200 rpm硬盘）分开处理，这样动态服务器跑Django，静态服务器跑Lighttpd。他们之间只需要一个读写的通讯，因为是内部通讯，所以用http是没有意义的。用NFS可能是最直接的方法。用SAN或者iSCSI的方式其实也是可行的，前者是成本问题，而后者是浪费计算资源的问题，所以我们自然的按HD的意思上了NFSv4。
然后又引出MogileFS的问题。其实这是个大文件存储的真谛问题。如果数据量达到一定程度，单个节点不可以承受的时候，那么我们只能选择数据分片，可以时髦的叫做shard，如google做的map reduce的GFS。或者干脆就自己写个简单的数据索引，然后路由分区一下，这个概念就是MogileFS。MogileFS就是利用多个有自己的计算资源的静态服务器来分区存储并管理它们的一个准分布式文件系统（因为MogileFS不支持随机访问，只是整存整取，所以说是准文件系统），它已经能解决我们Web 2.0应用的问题了，Flickr也是这么干的……选用它或者自己做是个看起来和做起来都挺简单的问题，只是它比什么都不需要改变的NFS还是稍微麻烦一点。所以这个作为未来的一种被选方案。其实呼应一下HD在方案分析里面说的应付流量压力的目标，MogileFS只是用来解决存储压力的一个方式。
关于FS，我最近也作了Research，发现这还真是一个坑呀，非常大的坑。XFS、JFS、nb的ZFS都是好方案，但是大文件系统还要考虑分区表格式，MBR已经成了限制，用GPT吧你还不好引导（因为如果你都是大硬盘的话，单弄一个小的上MBR引导，其它再分GPT，势必要浪费一块硬盘，非常不划算），然后LVM解决引导问题吧用起来还不踏实（毕竟它的条带化不是硬件的Raid那样可靠），然后你又需要去对比那几个FS，反正头大。最后还是硬着头皮上了XFS。
我觉得架构考量就像HD所说的，你有无数选择，这些选择造成了噪音，然后在你四处碰壁的时候，你可能选择了第一个可以用的方案去实施。而实际上你会很快发现更好的方案……架构的重构代价是可怕的……所以有了更好的方案可能也不会实施，或者要很久以后再实施。所以，这个经验是需要年头的，也许，也许，很多的方案都让被实施者称为了学徒练手的冬瓜，脑袋上的伤口只有冬瓜自己知道。虽然我作为学徒……看着也疼。我发誓，下次我一定做到更好！

相关的好看簿故事，我把好看簿服务器升级的过程用照片故事的形式记录下来了，欢迎大家参观：
http://www.haokanbu.com/story/2991/

还有关于中国网志2007的记录
http://www.haokanbu.com/story/3022/



Tin 2007-11-28 22:39 发表评论
]]>