在中文網織年會上和啄木鳥老大HD討論了一下好看簿的架構問題，而后老黃寫了一個blog entry：
架構考量-選擇的難度
里面談到了架構一個高支撐能力的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/