加入收藏 | 设为首页 | 会员中心 | 我要投稿 李大同 (https://www.lidatong.com.cn/)- 科技、建站、经验、云计算、5G、大数据,站长网!
当前位置: 首页 > 百科 > 正文

ruby-on-rails – RoR SaaS应用程序架构

发布时间:2020-12-16 21:47:37 所属栏目:百科 来源:网络整理
导读:我已经做了大量的基础RoR工作,但是在扩展和运行多个应用程序方面并没有真正面对很多. 我正在为一个客户建立一个应用程序,我希望在类似的行业向其他用户销售,但我正在努力与高级架构.似乎不必为每个客户端运行一个完全独立的应用程序实例,但是我不知道如何为
我已经做了大量的基础RoR工作,但是在扩展和运行多个应用程序方面并没有真正面对很多.

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

这可以使用子域轻松地完成吗?可以根据此加载不同的配置吗?有谁知道37信号应用如何根据帐户管理不同的配置?

解决方法

当我们对我们的应用做出相同的决定时,我们考虑了几件事情

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

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

其次,我们考虑了成本.当我们认为我们可以在同一个Amazon EC2实例的自己的Rails实例中运行多个客户,并在同一个RDS实例中使用自己的Amazon RDS数据库时,成本变得非常有吸引力.由于我们有一个面向应用程序的业务,不久之后就不会有超过200个客户,所以我们可能会在三至五年的时间里谈论几千美元的额外托管成本.

当我们比较成本与复杂性时,我们得出结论,让每个人在自己的实例中是理所当然的.

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

(编辑:李大同)

【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容!

    推荐文章
      热点阅读