本人作爲一位web工程師，着眼最多之處莫過於 性能與架構，本次幸得參與sd2.0大會，得以與同行廣泛交流,於此二方面，有些心得，不敢獨享，與衆博友分享，本文是這次參會與衆同撩交流的心得，有興趣者可以查看視頻
架構設計的幾個心得：
一，不要過設計：never over design
這是一個常常被提及的話題，但是隻要想想你的架構裏有多少功能是根本沒有用到，或者最後廢棄的，就能明白其重要性了，初涉架構設計，往往傾向於設計大而化一的架構，希望設計出具有無比擴展性，能適應一切需求的增加架構，web開發領域是個非常動態的過程，我們很難預測下個星期的變化，而又需要對變化做出最快最有效的響應。。
ebay的工程師說過，他們的架構設計從來都不能滿足系統的增長，所以他們的系統永遠都在推翻重做。請注意，不是ebay架構師的能力有問題，他們設計的架構總是建立舊版本的瓶頸上，希望通過新的架構帶來突破，然而新架構帶來的突破總是在很短的時間內就被新增需求淹沒，於是他們不得不又使用新的架構
web開發，是個非常敏捷的過程，變化隨時都在產生，用戶需求千變萬化，許多方面偶然性非常高，較之軟件開發，希望用一個架構規劃以後的所有設計，是不現實的
二，web架構生命週期：web architecture‘s life cycle
既然要杜絕過設計，又要保證一定的前瞻性，那麼怎麼才能找到其中的平衡呢？希望下面的web架構生命週期能夠幫到你
設計的架構需要在1－10倍的增長下，通過簡單的增加硬件容量就能夠勝任，而在5－10倍的增長期間，請着手下一個版本的架構設計，使之能承受下一個10倍間的增長
google之所以能夠稱霸，不完全是因爲搜索技術和排序技術有多先進，其實包括baidu和yahoo，所使用的技術現在也已經大同小異，然而，google能在一個月內通過增加上萬臺服務器來達到足夠系統容量的能力確是很難被複制的
三，緩存：Cache
空間換取時間，緩存永遠計算機設計的重中之重，從cpu到io，到處都可以看到緩存的身影，web架構設計重，緩存設計必不可少，關於怎樣設計合理的緩存，jbosscache的創始人，淘寶的創始人是這樣說的：其實設計web緩存和企業級緩存是非常不同的，企業級緩存偏重於邏輯，而web緩存，簡單快速爲好。。
緩存帶來的問題是什麼？是程序的複雜度上升，因爲數據散佈在多個進程，所以同步就是一個麻煩的問題，加上集羣，複雜度會進一步提高，在實際運用中，採用怎樣的同步策略常常需要和業務綁定
老錢爲搜狐設計的帖子設計了鏈表緩存，這樣既可以滿足靈活插入的需要，又能夠快速閱讀，而其他一些大型社區也經常採用類此的結構來優化帖子列表，memcache也是一個常常用到的工具
錢宏武談架構設計視頻 http://211.100.26.82/CSDN_Live/140/qhw.flv
Cache的常用的策略是：讓數據在內存中，而不是在比較耗時的磁盤上。從這個角度講，mysql提供的heap引擎（存儲方式）也是一個值得思考的方法,這種存儲方法可以把數據存儲在內存中,並且保留sql強大的查詢能力,是不是一舉兩得呢?
我們這裏只說到了讀緩存，其實還有一種寫緩存，在以內容爲主的社區裏比較少用到，因爲這樣的社區最主要需要解決的問題是讀問題，但是在處理能力低於請求能力時，或者單個希望請求先被緩存形成塊，然後批量處理時，寫緩存就出現了，在交互性很強的社區設計裏我們很容易找到這樣的緩存
四，核心模塊一定要自己開發：DIY your core module
這點我們是深有體會，錢宏武和雲風也都有談到，我們經常傾向於使用一些開源模塊，如果不涉及核心模塊，確實是可以的，如果涉及，那麼就要小心了，因爲當訪問量達到一定的程度，這些模塊往往都有這樣那樣的問題，當然我們可以把問題歸結爲對開源的模塊不熟悉，但是不管怎樣，核心出現問題的時候，不能完全掌握其代碼是非常可怕的
五，合理選擇數據存儲方式：reasonable data storage
我們一定要使用數據庫嗎，不一定，雷鳴告訴我們搜索不一定需要數據庫，雲風告訴我們，遊戲不一定需要數據庫，那麼什麼時候我們才需要數據庫呢，爲什麼不乾脆用文件來代替他呢？
首先我們需要先承認，數據庫也是對文件進行操作。我們需要數據庫，主要是使用下面這幾個功能，一個是數據存儲，一個是數據檢索，在關係數據庫中，我們其實非常在乎數據庫的複雜搜索的能力，看看一個統計用的tsql就知道了(不用仔細讀,掃一眼就可以了)
select c.Class_name,d.Class_name_2,a.Creativity_Title,b.User_name,(select count(Id) from review where Reviewid=a.Id) as countNum from Creativity as a,User_info as b,class as c,class2 as d where a.user_id=b.id and a.Creativity_Class=c.Id and a.Creativity_Class_2=d.Id
select a.Id,max(c.Class_name),(max(d.Class_name_2),max(a.Creativity_Title),max(b.User_name),count(e.Id) as countNum from Creativity as a,User_info as b,class as c,class2 as d,review as e where a.user_id=b.id and a.Creativity_Class=c.Id and a.Creativity_Class_2=d.Id and a.Id=e.Reviewid group by a.Id ..............................................
我們可以看出需要數據庫關聯，排序的能力，這個能力在某些情況下非常重要，但是如果你的網站的常規操作，全是這樣複雜的邏輯，那效率一定是非常低的，所以我們常常在數據庫里加入許多冗餘字段，來減小簡單查詢時關聯等操作帶來的壓力，我們看看下面這張圖，可以看到數據庫的設計重心，和網站(指內容型社區)需要面對的問題實際是有一些偏差的
同樣其他一些軟件產品也遇到同樣的問題所以具我瞭解，有許多特殊的運用都有自己設計的特殊數據存儲結構與方法，比如有的大型服務程序採取樹形數據存儲結構，lucene使用文件來存儲索引和文件
從另外一個角度上看，使用數據庫，意味着數據和表現是完全分離的（這當然是經典的設計思路），也就是說當需要展示數據時，不得不需要一個轉換的過程，也可以說是綁定的過程，當網站具備一定規模的時候，數據庫往往成爲效率的瓶頸，所以許多網站也採用直接書寫靜態文件的方法來避免讀取操作時的綁定
這並不是說我們從今天起就可以把我們親愛的數據庫打入冷宮，而是我們在設計數據的持久化時，需要根據實際情況來選擇存儲方式，而數據庫不過是其中一個選項
六，搞清楚誰是最重要的人：who's the most important guy
在用例需求分析的時候常常講到涉衆，就是和你的設計息息相關的人，在web中我們一定以爲最重要的涉衆莫過於用戶了。，在一個傳統的互動社區開發中，最重要的東西是內容，用戶產生內容，所以用戶就是上帝，至於內容挑選工具，不就是給坐我後面三排的妹妹們用的嗎？湊或行了，實在有問題我就在數據裏手動幫你加得了。。這大概是眼下許多小型甚至中型網站技術人員的普遍想法。錢宏武在他的講座裏談到了這個問題：實際上網站每天產生的內容非常的多，普通人是不可能看完的，而編輯負責把精華的內容推薦到首頁上，所以很多用戶讀到的內容其實都依賴於編輯的推薦，所以設計讓編輯工作方便的工具也是非常重要，有時甚至是最重要的。
七，不要執着於文檔：don't be crazy about document
web開發的文檔重要嗎？什麼文檔最重要？我的看法是web開發中交流>文檔，
現在大的軟件公司比較流行的做法是：
注重產品設計文檔，在這種方法裏，產品文檔非常詳盡，並且沒有歧義，開發人員基於設計文檔開發，測試人員基於設計文檔制定測試方案，任何新人都可以通過閱讀產品設計文檔來了解項目的概況
而web項目從概念到實現的時間是非常短的，而且越短越好，並且由於變化迅速，要想寫出完整的產品和需求文檔是幾乎不可能的，大多數情況是等你寫出完備的文檔，項目早就是另外一個樣子，但是沒有文檔的問題是，如果團隊發生變化，添加新成員怎樣才能瞭解軟件的結構和概念呢，一種是每個人都瞭解軟件的整個結構，除非你的團隊整體消失，否則任何一個人都能夠擔當培養新人的責任，這種face2face交流比文檔有效率很多。
於是就有了前office開發者，現任yahoo中國某產品開發負責人的劉振飛所感覺到的落差，他說，我們的項目是吵出來的，我聽完會心一笑
八，團隊：team
不要專家團隊，而要外科手術式的團隊,你的團隊裏一定要有清道夫，需要有弓箭手，讓他們和項目一起成長，纔是項目負責人的最大成就
總結：
0)架構是一種權衡
1)web開發的特點是是：沒有太複雜的技術難點，一切在於迅速的把握需求，其實這正式敏捷開發的要旨所在，一切都可以非常快速的建立，非常快速的重構，我們的開發工具，底層庫和框架，包括搜索引擎和web文檔提供的幫助，都提我們供給了敏捷的能力。
2)此外，相應的，最有效率的交流方式必須留給web開發，那就是face2face（面對面），不要太擔心你的設計不能被完備的文檔所保留下來，他們會以交流，代碼和小卡片的方式保存下來
3)人的因素會更加重要，無論是對用戶的需求，還是開發人員的素質。
另：有關web效率，有著名的14條規則，由yahoo性能效率小組所總結，並廣爲流傳。業已出現相關插件（YSlow），針對具體網頁按彼規則評分，這次該小組負責人Tenni Theurer也受邀來到此次大會，我把Tenni小姐（之前真的沒有想到她是個女孩，並且如此年輕）和她的團隊的14 rules列在下面
Make Fewer HTTP Requests
Use a Content Delivery Network
Add an Expires Header
Gzip Components
Put CSS at the Top
Move Scripts to the Bottom
Avoid CSS Expressions
Make JavaScript and CSS External
Reduce DNS Lookups
Minify JavaScript
Avoid Redirects
Remove Duplicate Scripts
Configure ETags
Make Ajax Cacheable
通過安裝firebug和YSlow這兩個firefox插件(請注意要先安裝firebug再安裝yslow,下載後拖動到firefox裏即可)我們可以看到你的網頁根據下面的規則的評分,這是我在博客園博客首頁的評分截圖,上面D表示總分,下面是單項評分,A最好F最差,不知道還有沒有G :)
本文轉自
http://blog.csdn.net/yizhu2000/archive/2007/12/04/1915554.aspx