架构考量-选择的难度
昨天在中文网志年会上遇到了之前的同事，他在帮助一个web 2.0的网站做整个系统的优化和重构的工作。这里面他遇到了很多的选择。看来他在选择时遇到了很多决定的难题，我发现大家在面对架构时第一个面对的就是选择了。
为什么选择这么难？是因为大家都有着不同的基础，同时在选择时每个人都不由自主的去收集各种各样的信息，在信息极大丰富时，杂乱的噪音会让大家失去方向。这个同事跟我提过两个选择上的问题，一个是文件系统，一个是交换机。我记下一些我们的谈话，希望能有更多的提示。
在这个web 2.0的系统中遇到了第一个问题，他们的数据会集中的存储在一起，因为他们准备使用多台squid来扩展web的访问能力。要知道之前必竟一台机器不够了，数据库、web的静态内容、web的动态程序分开让第一步走的很轻松。但是如果想让更多的web静态内容服务器一起工作，为了节省存储必然让更多的web服务器使用相同的存储。用什么样的方法来做这件事呢？我这位同事和他的朋友大脑中出现很多有价值的名词：NFS、SQUID、Cache、NFSv4，我甚至听到他在说MogileFS！看来他们去看了很多国外的经验，希望能在好的经验基础上有一个实践。不谈他最终的选择，来看看有什么样的选择罢。 :)
需要什么样的扩展？来看看需求：
1.图片是静态内容，使用cache快速扩展访问支持能力
2.图片需要的存储比较大，不可能一个cache带着所有的图片，所以需要集中存储
3.要靠谱，也就是说要稳定
怎么做呢？有什么方法呢？先看看最简单的方法
这个加入cache的方法是让你的系统变动最小的方法。但是代价是你的web server有可能被浪费（当然，你可以把一部分流量分给web server，这样就不会被浪费了）。
再看看还有什么想法，分散开的协议也可以不是HTTP，我们使用文件存储的协议：
Web Server可以使用众多的网络协议来使用File Server上的文件，可以是NFS或是CIFS，甚至可以是SAN（当然，这东东比较贵的说）。显然，这样做有一个非常大的好处是使用了一个更轻的访问协议，http很难以达到nfs的数百近千的iops能力。
当然，也有人使用更有意思的分布式文件来取代File Server。什么样的架构最好？我想没什么最好，只有哪个可以在相对应的环境中适用。其实我非常想推荐给我的朋友第一种方案。因为它对系统的改动最小，而且很结实，很经济。 :)
引用通告 (0)
下面所列出的是引用这篇文章: 架构考量-选择的难度 的Blog链接.
这篇文章的引用通告URL: http://mt.opensource.org.cn/cgi-bin/mt/mt-tb.cgi/176
老大，中文网志年会的那个站不厚道！
1. 它的“http://” 没有这个“:”；
2. 把您老名字写错……（难道还有另外一个参加的名字缩写也是HD？）。
:-)
呵呵，写错的多了去了，不用太在意，这是一个2.0的年代 :)
HD, 我有一个问题: 在django环境下,如果已经使用lighttpd向外界提供静态文件, 在前段再添加一个squid, vanish这样的反向代理, 性能会有提高吗?
squid和lighttpd在静态文件，特别是较大的文件的处理上没有什么差别。也就是说，反向代理不可能在相同的机器上提供比lighttpd强的多的性能（当然有一些优化的手段，让你看上去好一些）。通常加入squid是因为你需要简单的扩展你的系统的访问能力。也就是说在你的静态图片系统中应该有三层： L4/L7层负载分切 -> squid -> web server。web srver可能使用带有大量磁盘的服务器，这个机器是存储稳定第一。squid应该分组，提高cache命中率。前面的L4/L7负载可以多种方法，一种是使用相关的设备，还有最简单的就是在图片引用时就使用不同组的image组好了。 最后的效果一定是web存了大量的图片，但是只有不到10%（我认为到5%会更合理）的访问会到这层，而squid应该有90%以上的命中率，跑起流量来。如果squid挂了马上从组里拿走，如果web server挂了，要想办法保住里面的数据。试试ZFS? :)
非常不好意思，今天检查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所说的，你有无数选择，这些选择造成了噪音，然后在你四处碰壁的时候，你可能选择了第一个可以用的方案去实施。而实际上你会很快发现更好的方案……架构的重构代价是可怕的……所以有了更好的方案可能也不会实施，或者要很久以后再实施。所以，这个经验是需要年头的，也许，也许，很多的方案都让被实施者称为了学徒练手的冬瓜，脑袋上的伤口只有冬瓜自己知道。虽然我作为学徒……看着也疼。我发誓，下次我一定做到更好！
记得前段时间有人说在纸上耍把式的人怎么怎么不好，其实工作中思考与动手同样重要。不一定是要想多全面，有时能按正确的需求正确的完成本身就很难了。
xfs在处理大量小文件的时候,性能能接受么?
处理小文件，reiserfs更强些 :)