到處都是什么大規(guī)模啊，高流量啊，高性能之類的網(wǎng)站架構(gòu)設(shè)計(jì)，這類文章一是滿足人們好奇心，但看過之后也就看過了，實(shí)際收益可能并不大；另外一個(gè)副作用是容易讓人心潮澎湃，沒學(xué)走先學(xué)跑，在很多條件仍不具備的情況下，過度設(shè)計(jì)、過度擴(kuò)展（高德納大爺也說過，“過早優(yōu)化是萬惡之源”），所以，這里反彈琵琶，討論一下小規(guī)模、低性能、低流量的網(wǎng)站該如何搞法。

如果站點(diǎn)起步階段可能就是一臺(tái)機(jī)器（或是一臺(tái)虛擬機(jī)，比如 JobsDigg.com ），這個(gè)時(shí)候，去關(guān)注什么數(shù)據(jù)拆分啊，負(fù)載均衡啊，都是沒影子的事情。很多大站點(diǎn)的經(jīng)驗(yàn)絕不能照搬，辯證的參考才是硬道理。

擁抱熟知的技術(shù)

動(dòng)手構(gòu)建站點(diǎn)的時(shí)候，不要到處去問別人該用什么，什么熟悉用什么，如果用自己不擅長的技術(shù)手段來寫網(wǎng)站，等你寫完，黃花菜可能都涼了。所以，有現(xiàn)成的軟件組件可用，就不要自己重新發(fā)明輪子。人家說 Python 牛，但自己只懂 PHP ，那就 PHP 好了，如果熟悉 .net ？，那也不錯(cuò)。用爛技術(shù)不是丟人的事情，把好技術(shù)用爛才丟人。

架構(gòu)層次清晰化

起步的階段應(yīng)該清楚的確定下來架構(gòu)的層次。如果都攪和在一起，業(yè)務(wù)一旦擴(kuò)增開來，如果原有的一堆東西拆不開就是非常痛苦的事情。

Web Server <--> (AppServer)<-->Cache(eg. Memcached)<-->DB

層次清晰化的一個(gè)體現(xiàn)是（以 LAMP 架構(gòu)為例）：即使只有一臺(tái)機(jī)器，也應(yīng)該起個(gè) Memcached 的實(shí)例，效果的確非常好（除非內(nèi)存小）--一般人兒我不告訴他。不要把什么都?jí)旱?DB 上，DB 一旦 I/O 壓力走到磁盤上，問題要暴露出來是很快的。沒錯(cuò)，DB 本身也會(huì)利用自己的 Cache，但 DB 的Cache 和 Memcached 設(shè)計(jì)出發(fā)點(diǎn)畢竟不一樣。

數(shù)據(jù)冗余？有必要

很多人并不是數(shù)據(jù)庫設(shè)計(jì)專家，如果應(yīng)用要自己設(shè)計(jì)表結(jié)構(gòu)什么的，基本都是臨時(shí)抱佛腳，但三個(gè)范式很多人倒是記得牢，這是大多數(shù)小型 Web 站點(diǎn)遇到的一個(gè)頭疼事兒，一個(gè)小小的應(yīng)用搞了幾十個(gè)表。忘掉范式這個(gè)玩意兒！ 記住，盡可能的冗余數(shù)據(jù)，你在數(shù)據(jù)層陷入的時(shí)間越多，你在產(chǎn)品上投入的就會(huì)越少。用戶更關(guān)心的是產(chǎn)品的設(shè)計(jì)。

前端優(yōu)化很重要

因?yàn)榱髁康停L客可能也不多，這時(shí)候值得注意的是頁面不要太大，多數(shù)流量低的站點(diǎn)吃虧就在于一個(gè)頁面動(dòng)輒幾兆（我前兩天看到一個(gè)Startup的首頁有4M之大，可謂驚人），用戶看個(gè)頁面半分鐘都打不開，你說咋發(fā)展？ 先把基本的條件滿足，再去研究前端優(yōu)化。

功能增加要謹(jǐn)慎

不是有個(gè) 80/20 原則么？ 把最重要的精力放在最能給你帶來商業(yè)價(jià)值的地方。有些花里胡哨的功能帶來很大的開銷，反而收效甚微。記住，小站點(diǎn)，最有價(jià)值的是業(yè)務(wù)模式，而不是你的技術(shù)有多牛。技術(shù)是為業(yè)務(wù)服務(wù)的，不要炫技。

有些網(wǎng)站不停的添加功能，恰恰是把這些新功能變成了壓死自己的稻草。

從開始考慮性能

這一點(diǎn)是可選的，但也重要。設(shè)計(jì)應(yīng)用的時(shí)候在開始就應(yīng)考慮 Profile 這件事情。一套應(yīng)用能否在后期進(jìn)行有效優(yōu)化和擴(kuò)展，很大的程度限制在是否有比較合適的 Profile 機(jī)制上。需要補(bǔ)充的是，對性能的考慮必然要把有關(guān)的歷史數(shù)據(jù)考慮進(jìn)來。另請參見網(wǎng)站運(yùn)維之道的容量規(guī)劃以及其它小帖子。

好架構(gòu)不是設(shè)計(jì)出來的

這是最后要補(bǔ)充的一點(diǎn)。好的架構(gòu)和最初的設(shè)計(jì)有關(guān)系，但最重要的是發(fā)展中的演化：

發(fā)展-->發(fā)現(xiàn)問題-->反饋-->解決問題（執(zhí)行力）--> 改進(jìn)->進(jìn)化到下一階段--新問題出現(xiàn)（循環(huán)）

有些站點(diǎn)到了某個(gè)階段停足不前，可能卡在執(zhí)行力這個(gè)地方，來自用戶的反饋意見上來了之后，沒有驅(qū)動(dòng)力去做改進(jìn)。最后也是死豬不怕開水燙了。最怕聽到的就是“業(yè)務(wù)不允許”的托詞，試想如果不改進(jìn)業(yè)務(wù)都沒了，那業(yè)務(wù)還允許么？ 其實(shí)就是一層心理障礙。

這篇文章有濃重的山寨風(fēng)格，所以，你不要太認(rèn)真。如果在用短、平、快的方式構(gòu)建某些山寨網(wǎng)站的話，可參考其中對你有益的點(diǎn)，不贊同的地方可以直接忽視掉，就沒必要費(fèi)力留言進(jìn)行爭論了。

--EOF--

好的業(yè)務(wù)模式（產(chǎn)品） + 很好的技術(shù) = 大賺錢

好的業(yè)務(wù)模式（產(chǎn)品） + 能用的技術(shù) = 也賺錢

差的業(yè)務(wù)模式（產(chǎn)品） + 好的技術(shù) = 賺吆喝（現(xiàn)在的SNS就差不多這樣了）

差的業(yè)務(wù)模式（產(chǎn)品） + 差的技術(shù) = 自己浪費(fèi)資源