系統架構設計經驗分享

本人做爲一位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

相關鏈接

yahoo性能團隊:http://developer.yahoo.com/performance/

原文： http://www.solo168.com/post/20100513168.html