可伸缩性Web服务关注性能优化，但一味注意优化也并非是其关键所在。Tom Killalea，Amazon负责基础设施与分布式系统的技术副总裁在近期的ACM queue上发表了一篇关于构建可伸缩性Web服务的文章。 他概述了构建可伸缩性Web服务的指导原则并举了许多现实世界的实际案例，其核心主题是“只构建你所需要的”。
警惕：过早优化
花费在优化可伸缩性上面的时间和资源不如花费在改进用户体验和吸引流量上。
采纳：他人的成果
他解释到，学习他人在框架与基础设施方面的工作可以减短上市时间，帮助将重点转移到提供客户价值上。
三个重要的进展从不同的方面对降低门槛作出了贡献：迈向SOA的趋势(面向服务的架构)，云计算基础设施服务的涌现，以及ASP.NET，Django，Rails和Spring等等Web应用框架的可用性。
警惕：过度优化
他引用了Nicholas Nassim Taleb在高度非概然性不可测事件所产生的重大影响方面所做的工作，并建议使用冗余作为提高可用性的策略；使用冗余作为负载平衡而不仅仅是故障恢复机制这一想法比起对于低概率的可能性事件进行过度优化来说，显然更加有成本效率。
采纳：云
Tom给出了Animoto的例子，这一通过Amazon.com的EC2基础设施托管的社交Web应用是如何随需应变的快速平面伸缩(scale out)的，甚至扩展到3500个实例。同样的情况在非云的基础设施里，为了保证尖峰时刻的流量将会花费巨大的成本。
警惕：目标驱动的优化
对于期望的流量进行建模然后构建精确的伸缩性计划以满足这一目标是***风险的。好的模型难于构建，并且会因为简化或者是降低变因的乐观估计而受到影响。[…]如果你的Web服务是成功的，你最终会遇到比目标模型更大的需求——也许不是这个黑色的星期一或者超级碗周末，但有可能是很快以后，在你所没想到的时间范围内。
采纳：扯下翅膀
“除了分析哪部分会***个出问题以及其原因以外”，Tom谈到“我们会查看给定的应用或者服务在没有出问题或缺少这部分的情况下会有怎样的表现，并且重新进行测试，以找下一个出问题的部分”。
Tom这样总结了他的文章“构建一个可伸缩的Web服务所面临的最困难的挑战就是在出现故障以及高度的并发访问械的情况下,如何去处理持续性，可靠性，性能以及成本效率之间的折衷。”。
除了Tom的这篇文章，2008年10号还有其它的关于构建可伸缩性Web服务的精彩文章。
【编辑推荐】
