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

核心提示： 辅助系统除了统一的UI、数据交互和用户共享外，还可以把一些常用的功能如上传附件、发送邮件等抽象出来，Rails系统重构：从单一复杂系统到多个小应用集群(8)，在更高级别上减少重复代码，由于这些功能比较复杂，引入的新技术可能存在缺陷，运行一段时期发现问题后又需要退回初始版本，不像UI Helper

辅助系统

除了统一的UI、数据交互和用户共享外，还可以把一些常用的功能如上传附件、发送邮件等抽象出来，在更高级别上减少重复代码。

由于这些功能比较复杂，不像UI Helper等用简单的一两个方法就可以完成，所以我们用独立应用和对应的gem相结合来实现。

以发送邮件功能为例，首先创建一个Rails应用mail，主要功能包括管理邮件模版、统计发送数量、完成邮件发送等；然后创建一个gem，在这个 gem中包含MailService，其他应用引用这个gem后就可以调用MailService的相关方法完成邮件发送。例如：

MailService.send(:welcome_mail,　"customer@example.com",　:username=>"张三")　

架构优势及系统拆分原则

小应用集群架构的优势

我们在第一部分已经详细说明了复杂Rails系统的种种弊端，将大系统拆分成小应用集群后，可以从根本上解决这些问题，并且还可以带来许多其他好处。

快速需求响应

由于每个应用只关注于大系统中的一部分业务逻辑，所以应用代码量一般都比较小。这种小规模的应用是非常容易维护与扩展的。

首先小应用代码比较清晰，无论是BUG修复还是功能扩展或者代码重构都很容易进行。其次测试和部署的周期更短，并且由于各个应用间彼此独立，某个应用的崩溃不会影响到其他应用的正常运行。更快的开发部署周期就保证了系统对于用户需求的快速响应，有利于提高产品的竞争力。

新技术的安全迭代

Ruby/Rails技术社区十分活跃，不仅Rails的版本升级速度很快，各种gem、插件、Web Server等也层出不穷。为了不断提高系统的性能、架构与可扩展性，我们经常需要对Rails进行升级或者引进一些新技术。但对于复杂的Rails系统，升级Rails是一件十分痛苦的事情，由于代码太复杂或没有完善的测试代码，升级后往往会破坏系统的健壮性。另外，引入的新技术可能存在缺陷，运行一段时期发现问题后又需要退回初始版本，这个反复的过程严重降低了生产效率。