构建可伸缩的 Web 服务

  • Dilip Krishnan
  • 黄璜

2009 年 9 月 14 日

话题:SOA架构

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 服务的精彩文章。

查看英文原文:Building Scalable Web Services

SOA架构