RoR SaaS应用程序的体系结构

Question

我已经完成了大量的基础RoR工作,但是并没有真正面对扩展和运行多个应用程序.

我正在为客户构建应用程序,我希望将其推向类似行业的其他用户,但我正在努力应对高级架构.似乎没有必要为每个客户端运行完全独立的应用程序实例,但我不知道如何为各种用户加载不同的配置/布局/功能.我不希望每个单独的应用程序都具有极高的流量,因此每个应用程序拥有唯一的实例/数据库似乎是浪费.然而,每个实例可能都需要自己的CSS以及可能的功能的不同配置.

这是否可以使用子域轻松完成？我可以根据此加载不同的配置吗？有没有人了解37信号应用程序如何根据帐户管理不同的配置？

Answer 1

当我们为我们的申请做出同样的决定时,我们考虑了几件事......

首先,我们考虑了复杂性.当您开始将多个客户添加到同一数据库中时,您需要考虑如何对其数据进行分段.如果你为一个客户编写了应用程序,你可能不必太担心这个问题.在许多情况下,这些问题根植于核心数据模型,这将导致大量重构(如果不是完全重写).

此外,您永远不会逃避这种复杂性.特别是在面向业务的应用程序中,将一个客户的数据暴露给另一个客户可能是致命的.您将始终需要添加额外的代码和许多额外的测试来保护自己免受此攻击.

其次,我们考虑了成本.当我们考虑在相同的RDS实例中我们可以在同一个Amazon EC2实例上使用自己的Amazon RDS数据库在自己的Rails实例中运行多个客户时,成本变得非常有吸引力.由于我们有一个面向企业的应用程序,并且不会很快就会有超过200个客户,我们可能会谈论在3 - 5年内额外托管成本几千美元.

当我们比较成本与复杂性时,我们得出的结论是,将每个人都放在他们自己的实例中是值得的理论扩展问题.

这种方法的缺点是您必须确保能够跟上维护,监视和升级多个实例的步伐.像Chef这样的一些简单的脚本和工具可以在这里走很长的路.

Answer 2

免责声明

确保您确实能够向其他客户推销您正在编写的应用程序。你和你的客户签订了合同吗？如果是这样，他们很可能拥有您正在编写的代码的权利，在这种情况下，您将违反合同。

维基百科上有一篇关于多租户的非常好的文章，您绝对应该阅读。它将回答您的很多问题并让您思考您的策略。我的建议是以可以支持多租户的方式构建您的应用程序，因为事后将其固定起来要困难得多。

37s 应用程序不允许除配色方案之外的任何自定义，这可能是通过更改样式表的设置来完成的。例如：

<%= stylesheet_link_tag(@tenant.style.name) %>

您将根据子域加载租户：

before_filter :load_tenant, :if => :tenant_request?
def tenant_request?
  request.subdomain.present? && !request.subdomain == 'www'
end    

def load_tenant
  @tenant = Tenant.find_by_name(request.subdomain)
end

如果您希望能够拥有可以打开和关闭的功能，最简单的方法可能是添加一个位掩码（有一个用于位掩码的 gem），它可以让您查询可用的特性。这不会扩展超过一定数量的功能，但将是一个好的开始。您最终会得到如下视图代码：

<% if tenant.has_feature?(:messaging) %>
  <li><%= link_to 'Messages', messages_url %></li>
<% end %>

确保无论你做出什么选择，你都会做最简单有效的事情。