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

核心提示： 我们已经将数据共享部分的核心代码开源，文中一些省略的代码（如acts_as_readonly）也可以在此处找到，Rails系统重构：从单一复杂系统到多个小应用集群(7)，具体可参见http://github.com/idapted/eco_apps，用户及权限控制除了数据交互外，应该按照角色来组

我们已经将数据共享部分的核心代码开源，文中一些省略的代码（如acts_as_readonly）也可以在此处找到，具体可参见http://github.com/idapted/eco_apps。

用户及权限控制

除了数据交互外，另一个重要问题是用户的管理，包括系统登录、权限控制等方面。示例程序中，我们用user这个应用来管理用户信息。

单点登录

在应用集群中，用户登录某一个应用后，再访问其他应用时应该不需要再次验证，这就需要实现多个应用间的单点登录。

实现单点登录有很多方法，我们采取一种非常简单的方式，就是多个应用共享session。代码如下：

#　config/initializers/idp_initializer.rb　
ActionController::Base.session_store　=　:active_record_store　
ActiveRecord::SessionStore::Session.acts_as_remote　:user,　:readonly　=>　false　

在initializer中指定所有应用都用user的sessions表存储session数据。当然也可以使用其他session存储方式，例如memcache等，只要保证所有应用的设置都一样即可。

权限控制

我们采用基于角色的权限管理来控制对应用程序的访问，并且在core应用中集中管理。应用中每一个Controller作为一个权限控制节点，在 server启动时，像配置信息一样，各个应用将自己的Controller结构发送到core，由core统一管理与配置。如下图所示：

查看原图（大图）

从示例程序可以看出，将大系统拆分成小应用是基于业务来进行的，每一个应用处理一套功能上接近的、完整的业务逻辑。而每一个小应用 Controller的结构，对于有多种角色的系统来说，应该按照角色来组织，这样可以有比较清晰的结构。Controller做为节点的方案也在一定程度上强迫开发者按照角色设计良好的Controller结构。