到處都是什麼大規模啊，高流量啊，高性能之類的網站架構設計，這類文章一是滿足人們好奇心，但看過之後也就看過了，實際收益可能並不大；另外一個副作用是容易讓人心潮澎湃，沒學走先學跑，在很多條件仍不具備的情況下，過度設計、過度擴展(高德納大爺也說過，"過早優化是萬惡之源")，所以，這裏反彈琵琶，討論一下小規模、低性能、低流量的網站該如何搞法。
如果站點起步階段可能就是一臺機器(或是一臺虛擬機，比如 JobsDigg.com )，這個時候，去關注什麼數據拆分啊，負載均衡啊，都是沒影子的事情。很多大站點的經驗絕不能照搬，辯證的參考纔是硬道理。
擁抱熟知的技術
動手構建站點的時候，不要到處去問別人該用什麼，什麼熟悉用什麼，如果用自己不擅長的技術手段來寫網站，等你寫完，黃花菜可能都涼了。所以，有現成的軟件組件可用，就不要自己重新發明輪子。人家說 Python 牛，但自己只懂 PHP ，那就 PHP 好了，如果熟悉 .net ?，那也不錯。用爛技術不是丟人的事情，把好技術用爛才丟人。
架構層次清晰化
起步的階段應該清楚的確定下來架構的層次。如果都攪和在一起，業務一旦擴增開來，如果原有的一堆東西拆不開就是非常痛苦的事情。
Web Server <--> (AppServer)<-->Cache(eg. Memcached)<-->DB
層次清晰化的一個體現是(以 LAMP 架構爲例)：即使只有一臺機器，也應該起個 Memcached 的實例，效果的確非常好--一般人兒我不告訴他...不要把什麼都壓到 DB 上，DB 一旦 I/O 壓力走到磁盤上，問題要暴露出來是很快的。沒錯，DB 本身也會利用自己的 Cache，但 DB 的Cache 和 Memcached 設計出發點畢竟不一樣。
數據冗餘? 有必要
很多人並不是數據庫設計專家，如果應用要自己設計表結構什麼的，基本都是臨時抱佛腳，但三個範式很多人倒是記得牢，這是大多數小型 Web 站點遇到的一個頭疼事兒，一個小小的應用搞了幾十個表... 忘掉範式這個玩意兒! 記住，儘可能的冗餘數據，你在數據層陷入的時間越多，你在產品上投入的就會越少。用戶更關心的是產品的設計。
前端優化很重要
因爲流量低，訪客可能也不多，這時候值得注意的是頁面不要太大，多數流量低的站點吃虧就在於一個頁面動輒幾兆(我前兩天看到一個Startup的首頁有4M之大,可謂驚人)，用戶看個頁面半分鐘都打不開，你說咋發展? 先把基本的條件滿足，再去研究前端優化。
功能增加要謹慎
不是有個 80/20 原則麼? 把最重要的精力放在最能給你帶來商業價值的地方。有些花裏胡哨的功能帶來很大的開銷，反而收效甚微。記住，小站點，最有價值的是業務模式，而不是你的技術有多牛。技術是爲業務服務的，不要炫技。
有些網站不停的添加功能，恰恰是把這些新功能變成了壓死自己的稻草。
從開始考慮性能
這一點是可選的，但也重要。設計應用的時候在開始就應考慮 Profile 這件事情。一套應用能否在後期進行有效優化和擴展，很大的程度限制在是否有比較合適的 Profile 機制上。需要補充的是，對性能的考慮必然要把有關的歷史數據考慮進來。另請參見網站運維之道的容量規劃以及其它小帖子。
好架構不是設計出來的
這是最後要補充的一點。好的架構和最初的設計有關係，但最重要的是發展中的演化：
發展-->發現問題-->反饋-->解決問題(執行力)--> 改進->進化到下一階段--新問題出現(循環)
有些站點到了某個階段停足不前，可能卡在執行力這個地方，來自用戶的反饋意見上來了之後，沒有驅動力去做改進。最後也是死豬不怕開水燙了。最怕聽到的就是"業務不允許"的託詞，試想如果不改進業務都沒了，那業務還允許麼? 其實就是一層心理障礙。
這篇文章有濃重的山寨風格，所以，你不要太認真。如果在用短、平、快的方式構建某些山寨網站的話，可參考其中對你有益的點，不贊同的地方可以直接忽視掉，就沒必要費力留言進行爭論了。
--EOF--
-
好的業務模式(產品) + 很好的技術 = 大賺錢
-
好的業務模式(產品) + 能用的技術 = 也賺錢
-
差的業務模式(產品) + 好的技術 = 賺吆喝(現在的SNS就差不多這樣了)
-
差的業務模式(產品) + 差的技術 = 自己浪費資源