我正在使用用 Ruby 开发的带有 MySQL 后端的现有 Web 应用程序，但我认为通用硬件拓扑问题将适用于各种服务器架构。
我正在寻找一份文档/网络资源，解释并详细介绍有关组织服务器场内的硬件以提供带有数据库后端的基于 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 从属服务器以处理只读请求（这将由应用程序软件内的更改控制）
主要目标是利用当前的最佳实践来建立一个更具弹性的系统，这就是迄今为止所建议的。
但是，如果有人能建议在这种环境中的最佳实践资源，或者提出一种能够提供我们所追求的弹性、性能和可扩展性的架构，我将不胜感激:)
戴夫
答案1
可扩展性不仅限于硬件层，还延伸到应用层。环境能否发展到如此规模，很大程度上取决于各层软件处理故障和维持整个环境一致状态的能力。如果驱动整个环境的数据库无法分片，则使用该数据库会阻碍可扩展性。诸如此类。
亚马逊有一些关于其云计算开发的白皮书，其中一些通常适用于任何可扩展的基础设施。
扩展时需要牢记一些高级原则：
- 它必须能够承受任何单个组件的故障，并且无需人工干预。
- 它应该能够动态响应高负载，无需人工干预。
不要仅仅使用一个负载均衡器，而要使用作为单个 LB 呈现的三个负载均衡器，以便如果任何一个出现故障，其他负载均衡器可以承担负载。
Web/应用服务器应在所有节点上提供用户状态，因此如果用户被推送到另一个 Web/应用服务器，他们的会话将被保留。最佳情况下，所有状态都可以从所有服务器提供。
您的网络中应该有冗余路由器，这样您可以关闭一个路由器而不停止所有流量。HSRP 是实现此功能的一种协议。
您的数据库计划必须包括在开始分片之前您将如何扩展一个数据库服务器，并且一旦接近该点就开始考虑分片进行开发。
出于性能原因，您的环境可能需要缓存层（memcached）。
一旦规模足够大，您就需要规划如何通过 Anycast 或 GeoIP 从多个独立位置（例如美国西部和美国东部，或美国西部和欧洲）托管您的环境。在不同位置之间移动数据将是一项挑战，一旦您接近需要独立位置，您就需要根据这一假设开始开发。
Ruby 本身存在一些扩展问题，主要集中在它能否利用服务器上的多个处理器。它有这些功能，但还比较新，因此开发社区还不太了解它（至少我是这么认为的）。随着 Ruby 的成熟，其中一些问题将会消失。
答案2
感谢您的精彩解释；关系数据库的可扩展性问题可以通过以下方式减少：数据库负载均衡器。它可以线性扩展，并以极短的响应时间支持更多并发用户，而无需对您的应用程序进行任何更改，因此非常适合基于 Web 或 Web 的应用程序。