可扩展Web应用程序硬件拓扑最佳实践

Question

我正在使用现有的带有MySQL后端的Ruby应用程序，但我认为通用的硬件拓扑问题将适用于各种各样的服务器架构。

我正在寻找一个文档/ 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 (S)、多个MySQL从服务器到服务器只读请求(这将由应用程序软件中的更改控制)。

其主要目标是利用目前的最佳做法，建立一个更具弹性的系统，这就是迄今为止所建议的。

但是，如果有人能够为这类环境中的最佳实践提供资源，或者提出一种能够提供我们所追求的弹性、性能和可伸缩性的体系结构，我将非常感激:)

戴夫

Answer 1

可伸缩性不仅扩展到硬件层，还扩展到应用层。环境是否能够成长为大环境在很大程度上取决于软件在每一层处理故障并在整个环境中保持一致状态的能力。如果无法对驱动整个环境的数据库进行切分，则通过使用该数据库，您已经引入了可伸缩性阻止器。那种事。

亚马逊有一些为云开发的白皮书，其中有几篇通常适用于任何可伸缩的基础设施。

http://aws.amazon.com/whitepapers/

在缩放时，需要记住一些高级原则：

• 它必须在任何单一组成部分的错误中幸存下来，并且在没有人类干预的情况下这样做。
• 它应该对高负荷做出动态响应，而不需要人为干预。

不要仅仅使用负载均衡器，使用三种负载平衡器，它们作为一个单一的LB，这样如果任何一个失败，其他的就可以承受负载。

web/app服务器应该在所有节点上都有可用的用户状态，因此如果用户被推送到另一个web/app服务器，则会保留其会话。最好的情况是，所有状态都可以从所有服务器服务。

您的网络中应该有冗余路由器，这样您就可以在不停止所有通信的情况下关闭一个路由器。HSRP是实现这一功能的一种协议。

您的数据库计划必须包括在开始分片之前对one DB服务器进行多大的缩放，并在接近这一点之后开始考虑分片的开发。

出于性能考虑，您的环境中可能需要缓存层(memcached)。

一旦您变得足够大，您需要计划如何通过Anycast或GeoIP从多个不同的位置(如美国西部和美国东部，或美国西部和欧洲)托管您的环境。在不同的位置之间移动数据将是一个挑战，一旦您接近需要不同的位置，您就需要开始根据这个假设进行开发。

Ruby本身也存在一些扩展问题，重点在于它是否能够利用服务器上的多个处理器。这些功能是存在的，但是在dev社区中还没有很好地理解这些功能(或者说我是这么认为的)。随着Ruby的成熟，这些问题中的一些将会消失。

Answer 2

感谢您的出色解释；在关系数据库通过数据库负载平衡器的情况下，可伸缩性问题可以减少。它可以线性地扩展，并且在响应时间的一小部分支持更多并发用户，所有这些都不会对您的应用程序进行任何更改，因此它们非常适合基于web或web应用程序。