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

核心提示： 而将系统进行拆分后，在升级Rails或应用新技术时，Rails系统重构：从单一复杂系统到多个小应用集群(9)，可以拿某一个不是特别重要的应用做实验，通过实验总结出一些升级经验，为了降低风险，最好有一个gem方法的引用列表，或验证新技术是否可用，没有问题后再推广到其他应用

而将系统进行拆分后，在升级Rails或应用新技术时，可以拿某一个不是特别重要的应用做实验。通过实验总结出一些升级经验，或验证新技术是否可用，没有问题后再推广到其他应用，这样就可以逐步地、安全地完成新技术的更新。

团队建设

对于复杂的Rails系统，团队有新成员加入时，会由于经验、技术水平不足等无法接触系统，往往需经过较长时间的培训才可以真正进入开发。另外由于系统的复杂度及新手对系统整体缺乏了解，很容易在修改代码后影响系统其他部分。而对于小应用集群，可以让新手从较简单、非核心的系统着手，对技术、业务较为熟悉后再转移到其他应用，这样就可以迅速、平滑地融入团队。

由于轻量级应用维护、扩展都比较简单，一般一个开发者可以负责多个应用，这样开发者就有了很大的自主性。另外如果有错误也不会影响他人，降低了风险，更有利于团队合作。在这样简单、安全、快速迭代的开发环境中，开发者的工作积极性会更高。

小应用集群架构的缺陷

由于多个应用之间的交互很大一部分是通过只读数据库来进行的，而数据库难以做到远程连接，所以要求所有的应用都部署在同一个局域网上。对于要求有大量服务器并且分布于多个数据中心（甚至多个国家）的情况，就不能完全依赖于该架构实现。当然广域网上的分布式应用需要考虑更多的问题，超出了本文的讨论范围，这里不再赘述。

另外由于每个应用都依赖于做为基础库的gem，所以gem里面的方法更改后需要重新启动所有相关的应用，方法才能生效。gem方法一旦出错，会牵连到多个应用，所以对gem方法的更改一定要慎重，并且要经过充分的测试确保没有问题后再进行部署。为了降低风险，最好有一个gem方法的引用列表，这样可以确保gem方法升级后不会带来潜在风险。