作者:tonnyom
原载: http://www.sanotes.net/html/y2010/449.html
版权所有。转载时必须以链接形式注明作者和原始出处及本声明。
From The Art of Scalability: Scalable Web Architecture, Processes, and Organizations for the Modern Enterprise
1, 单纯认为架构可扩展性只是个技术问题
2, 调用同步处理的过度使用
3, 一个问题还没处理完毕,就开始了新的架构调整
4, 没有合理的使用数据库
5, 架构被越扩展越复杂
6, 只依赖于垂直可伸缩性,单纯地考虑硬件方面的扩容
7, 从不吸取经验教训
8, 不断的改变开发策略,简单而重复的解决问题
9, 没有及时的使用缓存,或者使用的不够
10,过分依赖于第三方,这方面可能是指基础架构的非独立性,没有针对自己业务的应用层开发等等
看到这张图，我想对性能优化的主要矛盾和次要矛盾就很明了了，这里os的优化玛法是最轻的，也告知了我们最重的2个玛法（主要矛盾）是Application和Architecture and Design，下面怎么做就了然于胸了。
btw，虽然这个是和DB相关的，但是其它应用上的优化也是完全可以套用的——自勉之！
一般来说，组成Web站点体系结构有如下几个基本元素。
浏览器
因为Web浏览器标准、简单且普遍使用，所以它可以称得上是一个接近理想状态的图形用户接口（Graphical User Interface，GUI）。
目前比较流行的浏览器有：IE，firefox，opera，safari等，所以必须要了解其的相关特性，这也利于更好的利用这些特性来做相关架构的设计。
负载均衡
最简单的莫属DNS轮询（Round Robin DNS）方式了，但是不建议使用，因为下面的三个原因迫使你特别小心：
1. Round Robin DNS无法实现真正的负载均衡，但是在一些简单情况下还是能够均衡负载。真正的负载均衡是监测服务器的使用情况，以及根据该使用情况来分配连接，以便能始终将连接分配给那些有足够的容量来处理这些连接的服务器。
当Round Robin集中的一台服务器比其他服务器慢很多时，就会产生一种称为”护航（convoying）“的特殊情况，这时用户会列队等待速度较慢的服务器，而较快的服务器则未被使用。真正的负载均衡不会出现这样的问题。
2. RRDNS不会视图解决服务器的失效问题。用户仍然会被引导到失效的服务器上。真正的负载均衡可以提高站点的可用性，因为如果一台服务器出现故障，那么其他的服务器会自动接过该服务器的负载。
3. RRDNS很难保持用户的状态，特别是使用session的业务，比如某个用户在发表文章或者回复的时候，应用程序会对该用户的session保存在当前的服务器上，但是当用户写好文章或者回复开始提交后，因为RRDNS，结果发现用户提交到了另外的服务器上，因为新的服务器上没有用户的session，提示用户未登陆等警告信息，所以会导致提交失败。
很多情况，情况当要从dns里删除失效的IP时，会发现DNS的更新非常慢，因为很多LOCAL DNS并不遵循相关规范，这样有许多用户的LOCAL DNS服务器的缓存里仍会保留这个失效的IP，而且保留的时候甚至会很久，在国内特别是小的ISP常会这么做。
IP级别的负载均衡
这里常见的软件的实现方式有LVS，值得骄傲的是LVS是由国人章文嵩开发的，其简单高效，当然也需要配合其他的HA软件来实现”三H“。通过IP级别的负载均衡可以避免上述的RRDNS弊端。
当然也可以使用硬件均衡设备。
Web服务器
目前常用开源的Web服务器有：Apache、Nginx、Lighttpd等。
Web服务器的内容和日志应当分开保存到各自专用的磁盘上，这样可以避免他们相互干扰。
中间件
任何与一端的Web服务器和另一端的数据库交互的软件都可以被成为中间件。中间件的好处可以使结构清晰简单，可以提高整体性能。
数据库
数据库表可以通过某种方式被定义、镜像、分割、部署，以使之发挥最大的性能。数据库的优化是们深奥的学问，一个好的数据库管理员（Database Administrator，DBA）身价也是不菲的。
目前常见的DB有：mysql、oracle等。
虽然Web站点体系基本上是上述几个方面，但是影响Web性能确有更多的因素，只要把握上述几个方面，逐步排除和优化，我想结果一定不会差。
lveyo 11:22 on 2009 年 07 月 24 日 链接地址
貌似应该叫砝码
iakuf 12:08 on 2009 年 07 月 31 日 链接地址
非常不错,第二次看才看明白,看来我这系统工程师没有什么好混的