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

发布时间：2020-12-17 02:00:21 所属栏目：百科来源：网络整理

导读：我正处于Rails 3应用程序原型设计的早期阶段,该应用程序将公开一个公共API.该网站有三个独立的问题,我打算分成三个子域. api.mysite.com 公开的API. admin.mysite.com 用于创建博客的管理门户(使用公共API). x.mysite.com 在admin.mysite.com上创建的公共博

我正处于Rails 3应用程序原型设计的早期阶段,该应用程序将公开一个公共API.该网站有三个独立的问题,我打算分成三个子域.

> api.mysite.com

>公开的API.

> admin.mysite.com

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

> x.mysite.com

>在admin.mysite.com上创建的公共博客站点,其中x是博客的名称.这也将使用公共API.

>这三个将共享域对象.例如,您应该可以使用在api.mysite.com或x.mysite.com上创建的帐户登录admin.mysite.com.

问题

>我是否应该尝试构建一个rails应用程序来处理所有三个问题,还是应该将其拆分为多个应用程序,每个应用程序处理特定问题？
>什么是优点&每个人的缺点？
>有没有人了解一些较大的网站(basecamp,github,shopify)是如何组织的？

解决方法

你的问题相当普遍,所以我会试着回答一般问题.而你提到“更大的网站”的事实让我得出结论,你担心缩放.

>一开始,构建一个应用程序肯定会更容易 – 特别是因为域是共享的.您可以为各种接口(api,html等)执行单独的控制器,但使用共享后端.这将减少代码重复和保持3个应用程序同步的复杂性.还要记住,您可能会根据用户反馈改变您对功能的想法,并且您希望能够灵活地快速响应.
>我可以看到分离出三种不同的可部署的主要好处是,您可以为每个部署分配一个独立的部署计划.例如,api中的错误修复不必等待管理员准备部署.或者你可以让不同的团队并行工作.
>如果您对会话中保留的内容非常小心,您将能够在多个服务器上部署多个应用程序实例,指向同一个数据库(a.k.a.水平扩展).这些实例中的每一个都与其他实例相同,并且负载平衡器(专用硬件或虚拟)在它们之间引导流量.最终,当您的数据库无法处理负载时,此方法会耗尽.此时,您可以查看更多缓存,分片,无sql和各种巧妙的缩放技术.

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

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

（编辑：李大同）

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