因此，我在听最新的Stackoverflow播客(第19集)，而Jeff和Joel谈到了随着网站的发展而扩展服务器硬件的问题。用Joel的话说，前几步很标准：

• 一台同时运行Web服务器和数据库的服务器(当前Stackoverflow设置)
• 一台Web服务器和一台数据库服务器
• 两台负载平衡的Web服务器和一台数据库服务器

他们并没有太多谈论接下来会发生什么。我们添加更多的网络服务器吗？另一个数据库服务器？在不同的数据中心中复制此三机集群以实现冗余吗？硬件部门的网络启动从哪里去？

解决方案

回答

Joel提到添加第二个具有相同设置的数据中心，然后将用户随机分配给每个数据中心。记录数据更改并将其从一个位置发送到另一位置，以便两个位置都包含所有数据。

回答

Cal Henderson(Yahoo)在Web 2.0 Expo上谈论可伸缩Web体系结构的通用模式和方法非常有趣。我以为有视频，但是找不到。但是这是幻灯片：

http://www.slideshare.net/techdude/scalable-web-architectures-common-patterns-and-approaches

回答

下一步将是Web服务器群集(Web场)和数据库服务器群集系统(复制或者Oracle RAC等)。

回答

支持"平均" Web应用程序的合理设置可能会演变如下：

• 单个组合的应用程序/数据库服务器
• 在另一台机器上分离数据库
• 具有DNS轮询(穷人的负载平衡)或者例如珍珠岩
• 其次，复制的数据库服务器(对于读取负载，需要对应用程序逻辑进行一些更改，因此合格的数据库读取将成为从属服务器)

在这一点上，评估当前的事务状态将有助于确定更好的扩展路径。例如，如果读取负载很高并且内容不会经常更改，则最好强调缓存并引入专用的前端缓存，例如Squid可以避免不必要的数据库读取，尽管我们将需要考虑如何维护缓存一致性(通常在应用程序中)。

另一方面，如果内容合理地频繁更改，那么我们可能会希望使用更分散的解决方案。引入更多的应用程序服务器和数据库从属服务器，以帮助减轻这种影响，并使用对象缓存(如内存缓存)来避免访问数据库中的易失性内容。

对于大多数站点，这可能就足够了，尽管如果我们已成为全球性现象，那么我们可能会开始考虑在区域数据中心中使用硬件，并使用诸如地理负载平衡之类的技巧将访问者定向到最近的"集群"。 "。到那时，我们可能会聘请真正可以微调事物的工程师。

我想到的最有价值的扩展建议可能是避免过早担心它。专注于开发人们将要使用的服务，并使应用程序相当健壮。一些容易的早期优化是要确保数据库设计相当可靠，并且已建立索引，因此我们无需再费劲地做任何事情。另外，请确保应用程序发出缓存控制标头，这些标头指导浏览器如何缓存数据。在设计中尽早进行此类工作可以在以后产生收益，尤其是当我们不必重新处理整个事情来解决缓存一致性问题时。

我想提出的第二个最有价值的建议是，我们不应该假设对其他网站有效的方法对我们有效；检查日志，对流量进行一些分析，并对应用程序进行配置，以查看瓶颈所在并加以解决。

回答

大量的鱼建筑

一些有趣的视频：

YouTube可扩展性

Myspace系统架构师Dan Farino的访谈

回答

如果我们对缓存和使用.Net感兴趣，请查看企业库中的应用程序缓存块(当然，请与上面的其他要点结合使用)。