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

核心提示： 系统划分原则系统划分是否合理直接关系到代码和架构的质量，一般来说，Rails系统重构：从单一复杂系统到多个小应用集群(10)，拆分系统要遵守以下几个原则：每个应用独立完成一个完整的业务逻辑，例如在示例程序中，当然框架还有很多需要完善的地方，例如应用间的写交互通过消息队列来实现、如何做集成测试等，

系统划分原则

系统划分是否合理直接关系到代码和架构的质量。一般来说，拆分系统要遵守以下几个原则：

每个应用独立完成一个完整的业务逻辑。例如在示例程序中，course这个应用应该完成所有的课程管理操作，包括课程的基本信息维护、课程包的管理等。如果把课程的基本信息维护和课程包维护这两个联系十分紧密的业务功能放在两个应用中，就会造成这两个应用间频繁的交互，导致系统性能和代码质量的下降。

按照业务而不是按照用户角色来拆分系统。

高内聚。核心业务处理不应该通过service来处理，一个应用中最关键的业务逻辑应该不依赖于其他应用，完全可以自我实现。

低耦合。一个应用不应该知道太多其他应用的业务逻辑，程序之间的接口越小越好。

系统拆分的好坏并没有可以量化的标准，很多时候需要经过多次迭代才能达到比较合理的划分。在开始的时候可以大胆一些，将系统拆分成尽可能多的应用，然后在开发过程中如果发现应用间交互很频繁，则可以将其合并为一个应用。

小结

以上介绍了如何把一个复杂的Rails系统拆分成多个轻量级应用集群，这个框架结构在idapted一年多的实践来看效果还是很令人满意的。以idapted的在线英语学习平台eqenglish为例，现在大约有15个业务系统，4个支撑应用，核心应用每个约有40个左右的Model。每周有1-2次重大更新部署，每天有30-40次代码签入和 3-5次BUG修复或功能改进更新。由于框架提供了很多基础设施，搭建一个新应用的时间也大大缩短，例如用于跟踪学生学习状态的LPR（Learner Progress Report）一个人两周即开发完成并上线。

当然框架还有很多需要完善的地方，例如应用间的写交互通过消息队列来实现、如何做集成测试等，希望能得到Ruby/Rails社区更多的反馈与意见。