ruby-on-rails - 如何扩展你的 1 服务器 Rails 应用程序

Question

我有一个 Rails 应用程序在使用 passenger、apache 和 MySQL 的单个 VPS 上运行。我通过以下简单设置将其移至 Amazon AWS:

ELB > Web 服务器 > MySQL

假设我预计日常用户数量会激增，并希望开始使用多个实例在 Amazon AWS 上进行扩展。新手从哪里开始这段旅程？我是否只需从我的生产配置 Web 服务器创建一个 AMI，然后让 ASG 在需要时启动它们？

我了解 AWS 会根据负载需求增加使用自动缩放组的实例数量，但我是否需要在我的 Rails 应用程序中构建任何不同的架构以使其跨多个接口(interface)大规模运行？

Answer 1

水平缩放的问题在于它确实取决于应用程序。没有“只需加水”的方法。

但是您可以在开始时遵循一些通用的方法:

1. 将 MySQL 服务器提取到一个单独的实例中，该实例能够承受更高的负载。然后根据需要创建尽可能多的连接到 MySQL 数据库的工作实例(即应用程序)。您可以在 MySQL 服务器因请求饱和而无法再跟上负载之前继续这样做。

2. 完成第 1 步后，您可以添加 MySQL 副本并设置主从复制。这将为您留下一个 MySQL 集群，其中一个服务器可以接受写入，而所有其他服务器都是只读的。设置完成后，更改您的应用程序以将 SELECT 发送到只读副本，将 INSERT/DELETE/UPDATE 发送到可写主服务器。这种方法基于这样一个事实，即大多数应用程序的读取频率远高于写入频率。对你来说可能不是这样，但如果是这样，它会让你漂浮很长时间。就在您使 MySQL 主服务器写入性能饱和之前。

3. 从步骤 2 中压缩所有内容后，您可以继续对数据进行分片。这现在越来越依赖于您的应用程序。但我会提供一个盲例来传达这个想法。比如说，你有一个以用户为中心的应用程序(例如，一个私有(private)相册，没有共享功能)，每个用户都有一个名字。在这种情况下，您可以创建两个完全独立的集群，其中第一个将为名称以 A-M 开头的用户提供服务，第二个将为以 N-Z 开头的用户提供服务。它实质上使负载减少了一倍，但使整个架构复杂化。

虽然是通用的，但这些秘诀可以帮助您构建一个非常可靠的应用程序，该应用程序能够每天为数百万用户提供服务，然后您才被迫采用更奇特的扩展方式。

希望这对您有所帮助!