什么时候开始考虑缩放?
过去几天我一直在设计一个网站,并且一直在对网站水平缩放的不同方面进行一些研究。如果事情按计划进行,几个月(几年?),我知道我需要担心扩大网站的规模,因为它最终消耗的资源是巨大的。因此,这让我想到了什么时候开始思考和设计可扩展性的最佳时机?如果你开始得太早,你可能会轻易地使你的设计复杂化,并且使其无法实际构建。你也可能会陷入细节,架构,任何事情,最终都无法完成。另外,如果你确实得到它的工作,但该网站从未起飞,你可能浪费了一大笔额外的努力。什么时候开始考虑缩放?
另一方面,你可以在路上为自己节约大量的精力。如果从头开始设计大型会使后来变得更容易,让它变得更大,并且重写很少。
我知道我正在做什么,我已经决定在缩放方面至少做出几个选择,但我不打算做一个完整的思维变化来扩大规模完全。值得注意的是,我将数据库从传统的关系设计重新设计为类似于下面链接的Reddit网站上的建议,并且我将尝试给memcache一个尝试。
因此,基本问题什么时候是开始思考或担心缩放的好时机,以及什么时候这样做的好设计,技巧等?
几件事情我一直在读,对于那些有兴趣谁:
http://www.codinghorror.com/blog/2009/06/scaling-up-vs-scaling-out-hidden-costs.html
一个良好的,虽然出,明智的架构应该允许您可以在不需要过多资源的情况下进行扩展。这应该从项目的一开始就考虑到。
现在有很好的架构和企业设计模式可以从Rails,MVC,Spring等中获得,它们允许你在一个完善的,被很好理解的基础上开发软件,它提供了必要的机制扩大。
在某种观点下,缩放技术是相当被接受和巩固的。所以相反,依靠网络链接/文章,我会在开始这个问题之前阅读有关该主题的书籍。
我建议:
- “可扩展互联网架构” - http://www.amazon.com/Scalable-Internet-Architectures-Theo-Schlossnagle/dp/067232699X/ref=sr_1_1?ie=UTF8&s=books&qid=1274462743&sr=8-1
- “的可扩展性的艺术” - http://www.amazon.com/Art-Scalability-Architecture-Organizations-Enterprise/dp/0137030428/ref=sr_1_3?ie=UTF8&s=books&qid=1274462743&sr=8-3
- “容量规划的艺术” - http://www.amazon.com/Art-Capacity-Planning-Scaling-Resources/dp/0596518579/ref=pd_bxgy_b_text_b