我正在使用Ruby开发的现有Web应用程序和MySQL后端，但我认为通用硬件拓扑问题将适用于各种服务器体系结构。
我正在寻找一个文档/networking资源来解释和详细说明当前有关在服务器场中组织硬件的最佳做法，以便在数据库后端交付基于Web的应用程序。
目前的架构如下;
HTTP Server (Apache) | Application Servers x 8 (Unicorn / Ruby-on-Rails) | MySQL Back-end (Master) \ \ MySQL Slave (primarily for performing backups) 所提出的体系结构需要比以上更具可扩展性，包括在多个HTTP服务器之前的负载平衡器，在HTTP服务器之间，多个MySQL从服务器到服务器只读请求之间分离应用服务器（将通过改变来控制在应用软件内）
主要目标是通过使用目前的最佳实践来build立一个更有弹性的系统，这是迄今为止所提出的。
但是，如果任何人都可以在这种types的环境中build议一个最佳实践的资源，或者提出一个能够赋予我们以后的弹性，性能和可伸缩性的体系结构，我将不胜感激:)
戴夫
可伸缩性超越了硬件层，进入了应用层。 一个环境发展成为大型企业的能力在很大程度上取决于各层软件处理故障的能力，并在整个环境中保持一致的状态。 如果驱动整个环境的数据库不能被分割，那么通过使用该数据库引入了可伸缩性限制。 那种事。
亚马逊有一些白皮书正在开发他们的云，其中一些通常适用于任何可扩展的基础架构。
http://aws.amazon.com/whitepapers/
在缩放时需要记住一些高级原则：
不要只使用一个负载平衡器，使用三个负载平衡器作为一个单一的负载均衡器，以便如果任何一个失败，其他人可以拿起负载。
Web /应用程序服务器应该在所有节点上提供用户状态，因此如果用户被推送到另一个Web /应用程序服务器，他们的会话将被保留。 最好的情况是，所有的服务器都可以提供所有的状态。
你的networking应该有冗余的路由器，所以你可以在不停止所有stream量的情况下下载一个路由器。 HSRP是一个协议来实现这一点。
您的数据库计划必须包括在开始分片之前您将扩展一台数据库服务器的程度，并且一旦您接近这一点就开始考虑分片。
由于性能原因，在您的环境中可能需要caching图层（memcached）。
一旦你的规模足够大，你需要通过Anycast或GeoIP来计划如何从多个不同的地点（如美国西部和美国东部，或美国西部和欧洲）托pipe你的环境。 在不同地点之间移动数据将是一个挑战，而且一旦您接近需要单独的位置，则需要开始针对这一假设进行开发。
Ruby本身也存在一些扩展问题，主要集中在利用服务器上多个处理器的能力（或不能）。 这些function在那里，而是在开发社区还没有很好理解的新的（或者我收集）。 随着Ruby的成熟，其中一些问题将会消失。
感谢您的好解释; 在关系数据库的情况下，通过数据库负载平衡器可以降低可伸缩性的问题。 它可以线性扩展，并在响应时间的一小部分支持更多的并发用户，所有这些都不需要对应用程序进行任何更改，因此这些非常适合基于Web或Web的应用程序。