所以我正在听最新的 Stackoverflow 播客(第19集),Jeff 和 Joel 讨论了随着网站的发展而扩展服务器硬件的问题。根据 Joel 的说法,前几个步骤非常标准:

  1. 一台服务器同时运行网络服务器和数据库(当前的 Stackoverflow 设置)
  2. 一台网络服务器和一台数据库服务器
  3. 两台负载平衡的网络服务器和一台数据库服务器

不过,他们并没有过多谈论接下来会发生什么。您添加更多网络服务器吗?另一个数据库服务器?将这个三机集群复制到不同的数据中心以实现冗余?网络初创公司的硬件部门将走向何方?

有帮助吗?

解决方案

支持“普通”Web 应用程序的合理设置可能会如下发展:

  1. 单一组合应用程序/数据库服务器
  2. 不同机器上的独立数据库
  3. 第二个应用程序服务器具有 DNS 循环(穷人的负载平衡),或者例如 佩尔巴尔
  4. 其次,复制数据库服务器(对于读取负载,需要进行一些应用程序逻辑更改,以便合格的数据库读取转到从属服务器)

此时,评估当前的状况将有助于确定更好的扩展路径。例如,如果读取负载很高并且内容不会经常更改,那么最好强调缓存并引入专用的前端缓存,例如 乌贼 以避免不必要的数据库读取,尽管您需要考虑如何维护 缓存一致性, ,通常在应用程序中。

另一方面,如果内容经常发生变化,那么您可能会更喜欢更分散的解决方案;引入更多的应用程序服务器和数据库从属服务器来帮助减轻影响,并使用对象缓存,例如 内存缓存 以避免访问数据库以获取易失性较小的内容。

对于大多数站点来说,这可能就足够了,尽管如果您确实成为一种全球现象,那么您可能需要开始考虑在区域数据中心配备硬件,并使用地理负载平衡等技巧将访问者引导到最近的“集群” ”。到那时,您可能能够聘请能够真正进行微调的工程师。

我能想到的最有价值的扩展建议可能是避免过早担心这一切;专注于开发人们想要使用的服务,并使应用程序相当健壮。一些简单的早期优化是为了确保您的数据库设计相当可靠,并且索引的设置是为了让您不会做任何疯狂的事情;另外,请确保应用程序发出缓存控制标头,指导浏览器如何缓存数据。在设计的早期进行此类工作可以在以后产生好处,特别是当您不必重新设计整个事情来处理缓存一致性问题时。

我想提出的第二个最有价值的建议是,您不应该假设适用于其他网站的内容也适用于您;检查您的日志,对您的流量进行一些分析并分析您的应用程序 - 查看您的瓶颈所在并解决它们。

其他提示

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

Cal Henderson(雅虎)在 Web 2.0 Expo 上的演讲《可扩展的 Web 架构常见模式和方法》非常有趣。我以为有视频,但是找不到。但这里是幻灯片:

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

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

如果您对缓存和使用 .Net 感兴趣,请查看 应用程序缓存块 在企业库中(当然将其与上面的其他点一起使用)。

许可以下: CC-BY-SA归因
不隶属于 StackOverflow
scroll top