当rails应用程序变得太大时该怎么办?

时间:2014-07-26 01:00:21

标签: ruby-on-rails ruby design-patterns

我正在处理一个变得太大的rails应用程序。启动和大量内存需要很长时间。我们遇到了性能问题。测试非常缓慢。管理代码库,调试和引入新的未来变得越来越困难。我们正在考虑将应用程序拆分为更小的组件(Rails引擎或不同的Rails应用程序),其中所有组件将共享一个数据库。 考虑到这种情况,我们需要分享模型,可能还有一些库,测试和一些宝石等......这听起来不适合我!

是否可以应用任何模式?

3 个答案:

答案 0 :(得分:4)

这里有一些很好的建议可以拆分Rails代码库但是我认为在你申请任何代码之前你需要停下来并认真考虑你是如何进入这个职位的。所有这些解决方案都带来了新的复杂性和挑战。它们可能值得折衷,但前提是你确保它们也能解决你今天遇到的问题。

考虑你列出的每个痛点(启动时间很慢,内存使用率高,性能差,休息性能差,开发速度慢)并运行" 5为什么"锻炼他们。为什么会发生这些事情。为什么应用程序会进入这种状态。

最重要的是,在您提交拆分大型应用程序的任何计划之前,请先考虑应用程序是否应该很大。如果您的应用程序比您的产品需求更复杂,那么切换到同样复杂的服务集群并不是一种改进。

更具体地说,我建议不要在apps / services /之间进行共享数据库访问。共享数据库具有共享模式,该模式变得脆弱。它还会导致紧密耦合的服务,这些服务缺乏您需要关注的分离,以便看到您的开发速度有任何改进。正如将一个大型类拆分为几个紧密耦合的文件一样,也不会改进它,也不会将一个应用程序拆分为耦合服务。 如果您必须维护一个大型应用程序,则需要隔离单独的问题。为此,您需要打破它们之间的依赖关系。基于我所看到的修复Rails monoliths的努力,您可以更好地在现有应用程序中创建干净的界面,然后拆分组件,而不是将应用程序分开,然后希望可以独立改进生成的组件。

答案 1 :(得分:2)

是的,有几种方法可以做到:

  1. Micro services Erin Swenson-Healey为rails发了一篇不错的帖子。
  2. Hexagonal Architecture GoRuCo 2012 Hexagonal Rails by Matt WynneRefactoring with Hexagonal Rails
  3. Rails引擎方法。 Dealing with Rails Application Complexity - A Report from MWRC
  4. 使用更适合高复杂性和更多PORO导向的其他框架。 http://lotusrb.org/
  5. 另见Ruby Midwest 2011 - Keynote: Architecture the Lost Years by Robert Martin

答案 2 :(得分:1)

阅读Sandi Metz撰写的“Ruby中的实用面向对象设计”。此外,观看她在互联网上的每一个演讲和谈话。 Youtube是一个很好的起点。她是个很棒的演讲者。 Rails是用Ruby编写的,而Ruby是一种面向对象的语言,它带来了巨大的好处。但是,面向对象的部分需要一些工作。桑迪会带你去那里。