目录 » 十二月, 2008

架构设计的几条原则

@转载 http://blog.csdn.net/21aspnet/archive/2008/12/19/3558455.aspx
一,不要过设计:never over design
这是一个常常被提及的话题,但是只要想想你的架构里有多少功能是根本没有用到,或者最后废弃的,就能明白其重要性了,初涉架构设计,往往倾向于设计大而化一的架构,希望设计出具有无比扩展性,能适应一切需求的增加架构,web开发领域是个非常动态的过程,我们很难预测下个星期的变化,而又需要对变化做出最快最有效的响应。。
ebay的工程师说过,他们的架构设计从来都不能满足系统的增长,所以他们的系统永远都在推翻重做。请注意,不是ebay架构师的能力有问题,他们设计的架构总是建立旧版本的瓶颈上,希望通过新的架构带来突破,然而新架构带来的突破总是在很短的时间内就被新增需求淹没,于是他们不得不又使用新的架构
web开发,是个非常敏捷的过程,变化随时都在产生,用户需求千变万化,许多方面偶然性非常高,较之软件开发,希望用一个架构规划以后的所有设计,是不现实的
二,web架构生命周期:web architecture‘s life cycle

既然要杜绝过设计,又要保证一定的前瞻性,那么怎么才能找到其中的平衡呢?希望下面的web架构生命周期能够帮到你
 [attach=43]
所设计的架构需要在1-10倍的增长下,通过简单的增加硬件容量就能够胜任,而在5-10倍的增长期间,请着手下一个版本的架构设计,使之能承受下一个10倍间的增长
google之所以能够称霸,不完全是因为搜索技术和排序技术有多先进,其实包括baidu和yahoo,所使用的技术现在也已经大同小异,然而,google能在一个月内通过增加上万台服务器来达到足够系统容量的能力确是很难被复制的
–待添加

提高web效率的14条规则

web效率,yahoo性能小组总结的这14条规则
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
 

翻译下?太多E了,有些看不懂,回头找词典翻一下

所谓的技术难点

终于领略那一句话了,所有的技术屏障都有解决的办法_
1、问题的重要性
2、解决得办法
3、造成的后果
思考和行动是相互的,如果我们的行动需要迅速,那么留给我们思考的余地很少,唯一能做的是在已经出现的办法前面选择一个或者尽快想一个最快的办法来迅速的投入行动中去。同理,如果我们需要谨慎行事,那么我们就需要将思维扩散出去,把所有的情况容纳进来,利用“负载均衡”的原理来考虑下一步的行动。
如果没有比当前更好的办法,我们要做的是选择。而一旦有比目前要好的方法,我们要做的是应用,如果留给我们充足的时间,我们要做的是超越。

关键字说明一切_外:如何优化