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