所以我正在收听最新的Stackoverflow播客(episode 19),Jeff和Joel谈到了随着网站的发展而扩展服务器硬件的问题。从Joel的说法来看,前几个步骤非常标准:
他们并没有谈论下一步会发生什么。你添加更多的网络服务器?另一个数据库服务在不同的数据中心中复制这个三机群集以实现冗余?网络创业公司在硬件部门从哪里开始?
答案 0 :(得分:10)
支持“普通”Web应用程序的合理设置可能会演变如下:
此时,评估当前事态将有助于确定更好的缩放路径。例如,如果读取负载很高并且内容不会经常更改,则最好强调缓存并引入专用的前端缓存,例如: Squid以避免不需要的数据库读取,尽管您需要考虑如何维护cache coherency,通常在应用程序中。
另一方面,如果内容经常变化,那么您可能更喜欢更广泛的解决方案;引入一些应用程序服务器和数据库从属服务器来帮助减轻这些影响,并使用对象缓存(例如memcached)来避免在数据库中访问不太易变的内容。
对于大多数网站来说,这已经足够了,但如果你确实成为一个全球现象,那么你可能会想开始考虑在区域数据中心使用硬件,并使用地理负载平衡等技巧来引导访问者访问最近的“集群”。到那时,你可能会聘请能够真正微调事物的工程师。
我能想到的最有价值的扩展建议可能是为了避免担心这一切;专注于开发人们想要使用的服务,并使应用程序相当健壮。一些简单的早期优化是为了确保您的数据库设计相当稳固,并且设置了索引,这样您就不会做任何痛苦的事情。此外,请确保应用程序发出缓存控制标头,以指导浏览器如何缓存数据。在设计早期进行此类工作可以在以后产生效益,尤其是当您不必重新处理整个事情来处理缓存一致性问题时。
我想提出的第二个最有价值的建议是,你不应该假设哪些其他网站适用于你;检查您的日志,对您的流量进行一些分析并分析您的应用程序 - 查看您的瓶颈所在并解决它们。
答案 1 :(得分:3)
一些有趣的视频:
答案 2 :(得分:2)
Joel提到添加第二个数据中心,使用相同的设置,然后将用户随机分配给每个数据中心。记录对数据的更改并从一个位置发送到另一个位置,以便两个位置都包含所有数据。
答案 3 :(得分:1)
可扩展的Web架构常见模式& Cal Henderson(雅虎)在Web 2.0 Expo上的方法非常有趣。我以为有一个视频,但我找不到它。但这里有幻灯片:
http://www.slideshare.net/techdude/scalable-web-architectures-common-patterns-and-approaches
答案 4 :(得分:1)
下一步将是Web服务器集群(Web服务器场)和数据库服务器集群系统(复制或Oracle RAC等等)
答案 5 :(得分:0)
如果您对缓存和使用.Net感兴趣,请查看企业库中的application caching block(当然,请将其与上述其他内容一起使用)。