本人作為一位web工程師，著眼最多之處莫過于 性能與架構(gòu)，本次幸得參與sd2.0大會，得以與同行廣泛交流,于此二方面，有些心得，不敢獨享，與眾博友分享，本文是這次參會與眾同撩交流的心得，有興趣者可以查看視頻
架構(gòu)設計的幾個心得：
一，不要過設計：never over design
這是一個常常被提及的話題，但是只要想想你的架構(gòu)里有多少功能是根本沒有用到，或者最后廢棄的，就能明白其重要性了，初涉架構(gòu)設計，往往傾向于設計大而化一的架構(gòu)，希望設計出具有無比擴展性，能適應一切需求的增加架構(gòu)，web開發(fā)領域是個非常動態(tài)的過程，我們很難預測下個星期的變化，而又需要對變化做出最快最有效的響應。。
ebay的工程師說過，他們的架構(gòu)設計從來都不能滿足系統(tǒng)的增長，所以他們的系統(tǒng)永遠都在推翻重做。請注意，不是ebay架構(gòu)師的能力有問題，他們設計的架構(gòu)總是建立舊版本的瓶頸上，希望通過新的架構(gòu)帶來突破，然而新架構(gòu)帶來的突破總是在很短的時間內(nèi)就被新增需求淹沒，于是他們不得不又使用新的架構(gòu)
web開發(fā)，是個非常敏捷的過程，變化隨時都在產(chǎn)生，用戶需求千變?nèi)f化，許多方面偶然性非常高，較之軟件開發(fā)，希望用一個架構(gòu)規(guī)劃以后的所有設計，是不現(xiàn)實的
二，web架構(gòu)生命周期：web architecture‘s life cycle
既然要杜絕過設計，又要保證一定的前瞻性，那么怎么才能找到其中的平衡呢？希望下面的web架構(gòu)生命周期能夠幫到你
設計的架構(gòu)需要在1－10倍的增長下，通過簡單的增加硬件容量就能夠勝任，而在5－10倍的增長期間，請著手下一個版本的架構(gòu)設計，使之能承受下一個10倍間的增長
google之所以能夠稱霸，不完全是因為搜索技術(shù)和排序技術(shù)有多先進，其實包括baidu和yahoo，所使用的技術(shù)現(xiàn)在也已經(jīng)大同小異，然而，google能在一個月內(nèi)通過增加上萬臺服務器來達到足夠系統(tǒng)容量的能力確是很難被復制的
三，緩存：Cache
空間換取時間，緩存永遠計算機設計的重中之重，從cpu到io，到處都可以看到緩存的身影，web架構(gòu)設計重，緩存設計必不可少，關于怎樣設計合理的緩存，jbosscache的創(chuàng)始人，淘寶的創(chuàng)始人是這樣說的：其實設計web緩存和企業(yè)級緩存是非常不同的，企業(yè)級緩存偏重于邏輯，而web緩存，簡單快速為好。。
緩存帶來的問題是什么？是程序的復雜度上升，因為數(shù)據(jù)散布在多個進程，所以同步就是一個麻煩的問題，加上集群，復雜度會進一步提高，在實際運用中，采用怎樣的同步策略常常需要和業(yè)務綁定
老錢為搜狐設計的帖子設計了鏈表緩存，這樣既可以滿足靈活插入的需要，又能夠快速閱讀，而其他一些大型社區(qū)也經(jīng)常采用類此的結(jié)構(gòu)來優(yōu)化帖子列表，memcache也是一個常常用到的工具
錢宏武談架構(gòu)設計視頻 http://211.100.26.82/CSDN_Live/140/qhw.flv
Cache的常用的策略是：讓數(shù)據(jù)在內(nèi)存中，而不是在比較耗時的磁盤上。從這個角度講，mysql提供的heap引擎（存儲方式）也是一個值得思考的方法,這種存儲方法可以把數(shù)據(jù)存儲在內(nèi)存中,并且保留sql強大的查詢能力,是不是一舉兩得呢?
我們這里只說到了讀緩存，其實還有一種寫緩存，在以內(nèi)容為主的社區(qū)里比較少用到，因為這樣的社區(qū)最主要需要解決的問題是讀問題，但是在處理能力低于請求能力時，或者單個希望請求先被緩存形成塊，然后批量處理時，寫緩存就出現(xiàn)了，在交互性很強的社區(qū)設計里我們很容易找到這樣的緩存
四，核心模塊一定要自己開發(fā)：DIY your core module
這點我們是深有體會，錢宏武和云風也都有談到，我們經(jīng)常傾向于使用一些開源模塊，如果不涉及核心模塊，確實是可以的，如果涉及，那么就要小心了，因為當訪問量達到一定的程度，這些模塊往往都有這樣那樣的問題，當然我們可以把問題歸結(jié)為對開源的模塊不熟悉，但是不管怎樣，核心出現(xiàn)問題的時候，不能完全掌握其代碼是非常可怕的
五，合理選擇數(shù)據(jù)存儲方式：reasonable data storage
我們一定要使用數(shù)據(jù)庫嗎，不一定，雷鳴告訴我們搜索不一定需要數(shù)據(jù)庫，云風告訴我們，游戲不一定需要數(shù)據(jù)庫，那么什么時候我們才需要數(shù)據(jù)庫呢，為什么不干脆用文件來代替他呢？
首先我們需要先承認，數(shù)據(jù)庫也是對文件進行操作。我們需要數(shù)據(jù)庫，主要是使用下面這幾個功能，一個是數(shù)據(jù)存儲，一個是數(shù)據(jù)檢索，在關系數(shù)據(jù)庫中，我們其實非常在乎數(shù)據(jù)庫的復雜搜索的能力，看看一個統(tǒng)計用的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 ..............................................
我們可以看出需要數(shù)據(jù)庫關聯(lián)，排序的能力，這個能力在某些情況下非常重要，但是如果你的網(wǎng)站的常規(guī)操作，全是這樣復雜的邏輯，那效率一定是非常低的，所以我們常常在數(shù)據(jù)庫里加入許多冗余字段，來減小簡單查詢時關聯(lián)等操作帶來的壓力，我們看看下面這張圖，可以看到數(shù)據(jù)庫的設計重心，和網(wǎng)站(指內(nèi)容型社區(qū))需要面對的問題實際是有一些偏差的
同樣其他一些軟件產(chǎn)品也遇到同樣的問題所以具我了解，有許多特殊的運用都有自己設計的特殊數(shù)據(jù)存儲結(jié)構(gòu)與方法，比如有的大型服務程序采取樹形數(shù)據(jù)存儲結(jié)構(gòu)，lucene使用文件來存儲索引和文件
從另外一個角度上看，使用數(shù)據(jù)庫，意味著數(shù)據(jù)和表現(xiàn)是完全分離的（這當然是經(jīng)典的設計思路），也就是說當需要展示數(shù)據(jù)時，不得不需要一個轉(zhuǎn)換的過程，也可以說是綁定的過程，當網(wǎng)站具備一定規(guī)模的時候，數(shù)據(jù)庫往往成為效率的瓶頸，所以許多網(wǎng)站也采用直接書寫靜態(tài)文件的方法來避免讀取操作時的綁定
這并不是說我們從今天起就可以把我們親愛的數(shù)據(jù)庫打入冷宮，而是我們在設計數(shù)據(jù)的持久化時，需要根據(jù)實際情況來選擇存儲方式，而數(shù)據(jù)庫不過是其中一個選項
六，搞清楚誰是最重要的人：who's the most important guy
在用例需求分析的時候常常講到涉眾，就是和你的設計息息相關的人，在web中我們一定以為最重要的涉眾莫過于用戶了。，在一個傳統(tǒng)的互動社區(qū)開發(fā)中，最重要的東西是內(nèi)容，用戶產(chǎn)生內(nèi)容，所以用戶就是上帝，至于內(nèi)容挑選工具，不就是給坐我后面三排的妹妹們用的嗎？湊或行了，實在有問題我就在數(shù)據(jù)里手動幫你加得了。。這大概是眼下許多小型甚至中型網(wǎng)站技術(shù)人員的普遍想法。錢宏武在他的講座里談到了這個問題：實際上網(wǎng)站每天產(chǎn)生的內(nèi)容非常的多，普通人是不可能看完的，而編輯負責把精華的內(nèi)容推薦到首頁上，所以很多用戶讀到的內(nèi)容其實都依賴于編輯的推薦，所以設計讓編輯工作方便的工具也是非常重要，有時甚至是最重要的。
七，不要執(zhí)著于文檔：don't be crazy about document
web開發(fā)的文檔重要嗎？什么文檔最重要？我的看法是web開發(fā)中交流>文檔，
現(xiàn)在大的軟件公司比較流行的做法是：
注重產(chǎn)品設計文檔，在這種方法里，產(chǎn)品文檔非常詳盡，并且沒有歧義，開發(fā)人員基于設計文檔開發(fā)，測試人員基于設計文檔制定測試方案，任何新人都可以通過閱讀產(chǎn)品設計文檔來了解項目的概況
而web項目從概念到實現(xiàn)的時間是非常短的，而且越短越好，并且由于變化迅速，要想寫出完整的產(chǎn)品和需求文檔是幾乎不可能的，大多數(shù)情況是等你寫出完備的文檔，項目早就是另外一個樣子，但是沒有文檔的問題是，如果團隊發(fā)生變化，添加新成員怎樣才能了解軟件的結(jié)構(gòu)和概念呢，一種是每個人都了解軟件的整個結(jié)構(gòu)，除非你的團隊整體消失，否則任何一個人都能夠擔當培養(yǎng)新人的責任，這種face2face交流比文檔有效率很多。
于是就有了前office開發(fā)者，現(xiàn)任yahoo中國某產(chǎn)品開發(fā)負責人的劉振飛所感覺到的落差，他說，我們的項目是吵出來的，我聽完會心一笑
八，團隊：team
不要專家團隊，而要外科手術(shù)式的團隊,你的團隊里一定要有清道夫，需要有弓箭手，讓他們和項目一起成長，才是項目負責人的最大成就
總結(jié)：
0)架構(gòu)是一種權(quán)衡
1)web開發(fā)的特點是是：沒有太復雜的技術(shù)難點，一切在于迅速的把握需求，其實這正式敏捷開發(fā)的要旨所在，一切都可以非常快速的建立，非常快速的重構(gòu)，我們的開發(fā)工具，底層庫和框架，包括搜索引擎和web文檔提供的幫助，都提我們供給了敏捷的能力。
2)此外，相應的，最有效率的交流方式必須留給web開發(fā)，那就是face2face（面對面），不要太擔心你的設計不能被完備的文檔所保留下來，他們會以交流，代碼和小卡片的方式保存下來
3)人的因素會更加重要，無論是對用戶的需求，還是開發(fā)人員的素質(zhì)。
另：有關web效率，有著名的14條規(guī)則，由yahoo性能效率小組所總結(jié)，并廣為流傳。業(yè)已出現(xiàn)相關插件（YSlow），針對具體網(wǎng)頁按彼規(guī)則評分，這次該小組負責人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里即可)我們可以看到你的網(wǎng)頁根據(jù)下面的規(guī)則的評分,這是我在博客園博客首頁的評分截圖,上面D表示總分,下面是單項評分,A最好F最差,不知道還有沒有G :)
文章來源： http://blog.csdn.net/yizhu2000/archive/2007/12/04/1915554.aspx
相關連接
yahoo性能團隊:http://developer.yahoo.com/performance/
程序開發(fā)是一方面，系統(tǒng)架構(gòu)設計（硬件+網(wǎng)絡+軟件）是另一方面。
中國的網(wǎng)絡分南北電信和網(wǎng)通，訪問的ip就要區(qū)分南北進入不同的網(wǎng)絡；
然后是集群，包括應用服務器集群和web服務器集群，應用服務器集群可以采用apache+tomcat集群和weblogic集群等，web服務器集群可以用反向代理，也可以用NAT的方式，或者多域名解析都可以；
軟件架構(gòu)方面，做網(wǎng)站首先需要很多web服務器存儲靜態(tài)資源，比如圖片、視頻、靜態(tài)頁等，千萬不要把靜態(tài)資源和應用服務器放在一起；
頁面數(shù)據(jù)調(diào)用更要認真設計，一些數(shù)據(jù)查詢可以不通過數(shù)據(jù)庫的方式，實時性要求不高的可以使用lucene來實現(xiàn)，即使有實時性的要求也可以用lucene，lucene+compass還是非常優(yōu)秀的；
不能用lucene實現(xiàn)的可以用緩存，分布式緩存可以用memcached，如果有錢的話用10來臺機器做緩存，>10G的存儲量相信存什么都夠了；如果沒錢的話可以在頁面緩存和數(shù)據(jù)緩存上下功夫，多用OSCACHE和EHCACHE，SWARMCACHE也可以，不過據(jù)說同步性不是很好；
然后很重要的一點就是數(shù)據(jù)庫，大型網(wǎng)站要用oracle，數(shù)據(jù)方面操作盡量多用存儲過程，絕對提升性能；同時要讓DBA對數(shù)據(jù)庫進行優(yōu)化，優(yōu)化后的數(shù)據(jù)庫與沒優(yōu)化的有天壤之別；同時還可以擴展分布式數(shù)據(jù)庫，以后這方面的研究會越來越多；
新聞類的網(wǎng)站可以用靜態(tài)頁存儲，采用定時更新機制減輕服務器負擔；首頁每個小模塊可以使用oscache緩存，這樣不用每次都拉數(shù)據(jù)；
最后是寫程序了，一個好的程序員寫出來的程序會非常簡潔、性能很好，一個初級程序員可能會犯很多低級錯誤，這也是影響網(wǎng)站性能的原因之一。
本博客為學習交流用，凡未注明引用的均為本人作品，轉(zhuǎn)載請注明出處，如有版權(quán)問題請及時通知。由于博客時間倉促，錯誤之處敬請諒解，有任何意見可給我留言，愿共同學習進步。