Rails系统重构：从单一复杂系统到多个小应用集群

核心提示：Ruby on Rails近几年在国内受到越来越多的开发者的青睐，Rails应用也从较简单的内部系统深入到复杂的企业级应用，Rails系统重构：从单一复杂系统到多个小应用集群，Rails“习惯优于配置”的思想以及ActiveRecord等众多优秀的技术极大地提高了开发效率，但在业务复杂的大型系统

Ruby on Rails近几年在国内受到越来越多的开发者的青睐，Rails应用也从较简单的内部系统深入到复杂的企业级应用。Rails“习惯优于配置”的思想以及ActiveRecord等众多优秀的技术极大地提高了开发效率，但在业务复杂的大型系统中，Rails应用也会面临很多问题。

本文将介绍一种Rails系统重构方案，将复杂的Rails单一系统拆分成相互协作的多个轻量级应用集群，从根本上解决Rails系统在处理复杂的业务时代码臃肿、开发效率降低、难以维护与部署等问题。

复杂Rails系统存在的问题

用Rails可以快速搭建一个较简单的应用，但当业务需求急剧增长，功能越来越复杂时，系统的维护和扩展会变得越来越困难。一般情况下，问题主要表现在以下几个方面：

代码臃肿

我们知道Rails提倡RESTful架构，所以良好的代码组织方式是对每一个实体（Model）都有相应的处理器（Controller）来进行操作，而Rails每个Controller都有一个相应的Helper以及若干个View。这样当系统功能比较复杂时，代码量会急剧增大。

首先是Model的数量会很多。由于Model都放在app/models目录下面，而Rails又不支持Model分目录，虽然可以通过修改 load_paths解决这一问题，但有时（如目录与Model重名）会造成难以调试的错误，所以当Model数量比较多时，这个目录会变得难以管理。

其次是Controller的目录层级会比较深。为保持清晰的代码结构，Controller应该按照功能分类存放在不同的目录下。所以当功能比较多时，很容易出现四五层甚至更深的目录结构，这不仅使代码难以管理，routes的配置和解析也变得很复杂，例如会出现 level1_level2_level3_level4_controller_name_path这样很长的routes Helper方法。