架構設計的幾個心得：
一，不要過設計：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快取，簡單快速為好。。
快取帶來的問題是什麼？是程式的複雜度上公升，因為資料散布在多個程序，所以同步就是乙個麻煩的問題，加上集群，複雜度會進一步提高，在實際運用中，採用怎樣的同步策略常常需要和業務繫結
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列在下面
Web架構設計的經驗分享
一 不要過設計 never over design 這是乙個常常被提及的話題，但是只要想想你的架構裡有多少功能是根本沒有用到，或者最後廢棄的，就能明白其重要性了，初涉架構設計，往往傾向於設計 大而化一的架構，希望設計出具有無比擴充套件性，能適應一切需求的增加架構web開發領域是個非常動態的過程，我們...
架構設計經驗分享
不是的，以上所說的架構演變順序只是針對某個側面進行單獨的改進在實際場景中，可能同一時間會有幾個問題需要解決，或者可能先達到瓶頸的是另外的方面，這時候就應該按照實際問題實際解決。如在 類的併發量可能不大，但業務可能很豐富的場景，高併發就不是重點解決的問題，此時優先需要的可能會是豐富需求的解決方案。對於...
web工程師的web架構設計經驗分享
本人作為一位web工程師，著眼最多之處莫過於效能與架構，本次幸得參與sd2.0大會，得以與同行廣泛交流,於此二方面，有些架構設計的心得，不敢獨享，與眾友分享，本文是這次參會與眾同撩交流的心得.架構設計的幾個心得 一，不要過設計 never over design 這是乙個常常被提及的話題，但是只要想...