编写多租户 Rails 3 应用程序以在 Heroku 上部署

Question

我正在构建一个用于在 Heroku 上部署的 Rails 3 应用程序，我想知道是否有关于如何在我的模型中处理多租户的建议。半年前，有一个相关的问题（#3776593）发布在这里，但没有得到很多答案。我还观看了 Guy Naor 关于使用 Rails 编写多租户应用程序的演示，但似乎 3 个提议的解决方案中的 2 个不适用于 Heroku。我会链接到这些，但新的 Stackoverflow 用户仅限于 2 个超链接。

我还遇到过以下工具：

• http://samuel .kadolph.com/2010/12/simple-rails-multi-tenancy/
• http://blog.codecrate.com/2011/03/multitenant-locking-down-your-app-and.html

只是想知道您是否有这方面的经验多租户 gem 或 simple-rails-多租户 gem。似乎最简单的解决方案是简单地在需要在帐户下的所有模型上放置一个belongs_to，但我真的很想知道您在现实世界中使用什么！

Answer 1

这些方法的范围从“不共享任何内容”（这通常意味着每个租户一个数据库）到“共享所有内容”（这通常意味着每个表包含来自许多租户的行）。该范围（如下）可以按隔离程度、成本（即每个租户的成本）以及灾难恢复的难易程度进行细分。

• 每个租户一个数据库；成本最高、隔离程度最高、恢复最容易。
• 每个租户一个模式；其他两者之间的成本，良好的隔离，相当容易的恢复，但恢复通常会降低其他租户的性能。
• 租户之间共享餐桌；成本最低、隔离性最低（共享表）、灾难恢复困难（恢复通常意味着为每个表恢复一些行）。恢复通常会降低其他租户的性能“很多”。

所有这些在某种程度上都是特定于平台的。当 dbms 禁止查询访问多个数据库时，“每个租户一个数据库”具有最高的隔离性。但有些平台允许跨多个数据库查询。

MSDN 有一篇不错的文章，抓住了要点：多租户数据架构。

但如果您仅限于 Heroku，则必须选择 Heroku 支持的选项。我不知道这些选项可能是什么，但我确实知道您最好不要在开发中使用 SQLite。 Heroku 部署将在 PostgreSQL 上运行；你需要针对 PostgreSQL 进行开发。

Answer 2

作为多租户 gem 的作者，我显然有偏见，但我真的相信这是一个很好的解决方案！ gem 的目标是简化这种常见的应用程序需求并使其易于实现。

“老派”替代方案是使用 Rails 对象链来确保所有查询都是通过关联的父级完成的。这种方法的问题在于，您的 Tenant 对象会成为 has_many 关联的垃圾场。

class Tenant
  has_many :users
end
# query for users in the current tenant
current_tenant.users.find params[:id]

多租户 gem 通过确保生成的所有查询自动了解当前租户来解决这个问题。 它还确保创建新记录并自动分配给当前租户，因此您无需添加任何特殊的 before_save 回调。

前任：

Multitenant.with_tenant current_tenant do
  # queries within this block are automatically
  # scoped to the current tenant
  User.all

  # records created within this block are
  # automatically assigned to the current tenant
  User.create :name => 'Bob'
end

Answer 3

我即将开始这项事业（为小型 Rails 应用程序实现多租户），在进行研究时我偶然发现了这篇 SO 帖子。

令人惊讶的是，没有人提到 RyanB 关于使用 Heroku 支持的 PostgreSQL 模式实现 MT 的精彩截屏视频。

以下是截屏视频的链接 http://railscasts.com/episodes/389-multitenancy- with-postgresql。

概念：

在rails应用程序中，我们可以为pg连接设置搜索路径，

      connection.schema_search_path = "schema1, schema2, ..."

如果在schema1上找到相应的表，则后续操作将在schema1上执行。否则，它会搜索 schema2 中的表，依此类推。为了与包括租户在内的整个应用程序模式一起使用，通常的做法是在公共模式中将除租户之外的所有表设为空。

新租户注册：

向租户模型添加 after_create 函数，为新租户创建新架构，并将所有（加载 schema.rb）应用程序表（租户除外）创建到此新架构中。

用户：

当用户访问 subdomain1.myapp.com 时，从租户表中查找该子域的架构，并将连接搜索路径设置为“schema1，public”并对用户进行身份验证。

请注意，我的目的只是介绍解决方案背后的概念。有关实际解决方案，请参阅 RyanB 的截屏视频。