ruby-on-rails - 在 Rails 3 中设计一个现代平台

Question

我正处于一个 Rails 3 应用程序原型(prototype)的早期阶段，它将公开一个公共(public) API。该网站有三个独立的关注点，我计划将它们分成三个子域。

api.mysite.com

公开的 API。

admin.mysite.com

用于创建博客的管理门户(使用公共(public) API)。

x.mysite.com

创建于 的公共(public)博客站点admin.mysite.com 在哪里 x 是博客的名称。这也将使用公共(public) API。

这三个都将共享域对象。例如，您应该能够登录到 admin.mysite.com 使用您在 上创建的帐户api.mysite.com 或 x.mysite.com .

问题

我应该尝试构建一个 Rails 应用程序来处理所有三个问题，还是应该将其拆分为多个应用程序，每个应用程序处理一个特定的问题？

各自的优缺点是什么？

有谁知道一些较大的网站(basecamp、github、shopify)是如何组织的？

Answer 1

您的问题相当笼统，因此我将尝试笼统地回答。您提到“更大的站点”这一事实使我得出结论，您担心扩展。

一开始，构建一个应用程序肯定会更容易——尤其是因为域是共享的。您可以为各种接口(interface)(api、html 等)执行单独的 Controller ，但使用共享的后端。这将减少代码重复和保持 3 个应用程序同步的复杂性。另请记住，您可能会根据用户反馈改变对功能的看法，并且您希望足够灵活以快速响应。

我可以看到分离出三个不同的可部署项目的主要好处是，您可以为每个项目制定独立的部署计划。例如，api 中的错误修复不必等待管理员准备好部署。或者你可以让不同的团队并行工作。

如果您注意 session 中保留的内容，您将能够在多个服务器上部署应用程序的多个实例，指向同一个数据库(也称为水平扩展)。这些实例中的每一个都与其他实例相同，并且负载均衡器(专用硬件或虚拟)在它们之间引导流量。最终，当您的数据库无法处理负载时，这种方法就会失去动力。到那时，您可以查看更多的缓存、分片、no-sql 和各种巧妙的扩展技术。

大多数(但不是全部)较大的站点最终会通过一些数据分片进行某种水平扩展。

总而言之，专注于为您的用户提供有用的应用程序。如果事情起飞，你可以担心缩放。更多的应用程序失败是因为用户体验很糟糕，而不是无法扩展。