到处都是什么大规模啊，高流量啊，高性能之类的网站架构设计，这类文章一是满足人们好奇心，但看过之后也就看过了，实际收益可能并不大；另外一个副作用是容易让人心潮澎湃，没学走先学跑，在很多条件仍不具备的情况下，过度设计、过度扩展（高德纳大爷也说过，“过早优化是万恶之源”），所以，这里反弹琵琶，讨论一下小规模、低性能、低流量的网站该如何搞法。8 [; U% d' q2 D, J; C
# f/ i& J; i3 x( a 如果站点起步阶段可能就是一台机器（或是一台虚拟机，比如JobsDigg.com），这个时候，去关注什么数据拆分啊，负载均衡啊，都是没影子的事情。很多大站点的经验绝不能照搬，辩证的参考才是硬道理。, o/ J( l& r- j7 F' i6 b; s4 U7 r
1 C6 Y5 g$ _# p# g, g
拥抱熟知的技术 A5 W, l" s" K* R
6 K, v7 M% N! J$ U m& P
动手构建站点的时候，不要到处去问别人该用什么，什么熟悉用什么，如果用自己不擅长的技术手段来写网站，等你写完，黄花菜可能都凉了。所以，有现成的软件组件可用，就不要自己重新发明轮子。人家说Python牛，但自己只懂PHP，那就PHP好了，如果熟悉.net？，那也不错。用烂技术不是丢人的事情，把好技术用烂才丢人。# p4 D8 }# l: c' R7 Q0 R( l
+ v" Y; H( n" b/ ]" g6 h9 l* E6 ~1 F
架构层次清晰化
0 E& s; _7 I* u9 ] Y & z( O0 T# P1 g, {2 G C( D" e8 J! b
起步的阶段应该清楚的确定下来架构的层次。如果都搅和在一起，业务一旦扩增开来，如果原有的一堆东西拆不开就是非常痛苦的事情。
C9 Z6 R' r$ X- ? j' v6 |0 L% R/ f. R
WebServer《--》（AppServer）《--》Cache（eg.Memcached）《--》DB
. U) |# n, o7 c! B+ p7 A, u4 a + A3 o4 m) v3 a+ [5 O
层次清晰化的一个体现是（以LAMP架构为例）：即使只有一台机器，也应该起个Memcached的实例，效果的确非常好--一般人儿我不告诉他。。.不要把什么都压到DB上，DB一旦I/O压力走到磁盘上，问题要暴露出来是很快的。没错，DB本身也会利用自己的Cache，但DB的Cache和Memcached设计出发点毕竟不一样。) j8 {1 c% Q% D
# U, d4 i8 p- e9 G
数据冗余？有必要
( c6 J# C4 a. j- B1 g" x M 0 J& b1 i; C4 F/ r8 V: a
很多人并不是数据库设计专家，如果应用要自己设计表结构什么的，基本都是临时抱佛脚，但三个范式很多人倒是记得牢，这是大多数小型Web站点遇到的一个头疼事儿，一个小小的应用搞了几十个表。忘掉范式这个玩意儿！记住，尽可能的冗余数据，你在数据层陷入的时间越多，你在产品上投入的就会越少。用户更关心的是产品的设计。
- L7 j0 J' t! v1 Y5 X + d: {& o* E l/ h: | l9 w7 U# u; I& r
前端优化很重要
K s8 ]0 C$ q$ x. N3 i
" `7 \7 J) c! a6 c& o- Y+ k- y0 f 因为流量低，访客可能也不多，这时候值得注意的是页面不要太大，多数流量低的站点吃亏就在于一个页面动辄几兆（我前两天看到一个Startup的首页有4M之大，可谓惊人），用户看个页面半分钟都打不开，你说咋发展？先把基本的条件满足，再去研究前端优化。
- C+ T$ x' ~: Z0 E1 z1 D! R; n - }& h( l, p0 s9 B( B; ]
http://www.120gc.cn/编辑
\0 f6 J. G; w5 j5 ?$ z N7 I 7 z5 U4 p. f9 a0 l: O
|
