RAILS 应用的分拆方案

需求的由来

随着业务的不断发展，新的需求的不断的加入，很多 rails 应用已经不堪重负，到了不得不分拆并进行单独管理的阶段，还有些很多公司雄心博博的希望自己能够快速的建立一个平台化的生态圈，一方面通过开放自己的通行证系统，公开基础的 api，吸引第三方应用入驻平台，另一方面加速自己的开发，不断的往平台里引入新的杀手功能。于是应用的分拆管理变得非常的重要。在这里我简单描述一下我自己在商业应用中的实践。

需求的分解与方案选择

需求的关键点有如下两点

1. 统一帐号系统，可能需要实现单点登录
2. 数据的跨域共享 关于统一帐号系统目前市场上主要有下面几个方案，OAUTH2,CAS 和 OPENID，分别做下简短的描述， OAUTH2：这个标准相信大家已经很熟悉了，因为新浪微博的流行，大家基本都用过，优点很多，客户端实现很简单，服务端管理很方便，对第三方比较友好，支持 scope 授权，如果非要说缺点的话就是服务端需要做的工作比较多，还有就是不支持单点登录。 CAS: 因为采用 https 方式进行认证，所以安全性非常高，而且目前主流的 web 编程语言都对 CAS 协议给予了支持，开发工作量也不大，支持单点登录，主要缺点是对第三方支持很不友好，支持第三方的话系统得新加入代码。 OPENID:openid 是一个分散式认证的解决方案，就是说认证服务器不是集中的，而是分散在全球的各个角落，你在任何一个支持 openid 的网站上注册过 id 都可以直接拿过来在你的网站上用，目前 google 和 microsoft 都已经提供了 openid 服务，看得出来 openid 也是很有前景的一个技术。 个人的选择：最开始我的需求是希望能实现单点登录（多个应用系统只需要登录一次），所以毫不犹豫的选择了 CAS 协议，后来公司提出了将来要开放帐号系统的需求，于是就切到了现在的 OAUTH2，至于为什么没有选择 OPENID，我觉得有几个原因，一个是感觉目前国内没有太好的 OPENID 服务商，还一个是 OPENID 的用户名格式有点蛋疼，不太符合国内主流用户的习惯，还一个重要的原因是不太想把钥匙交给别人。 应用分拆后马上会面临一个问题就是数据的跨域共享，我采用的部署方式是 nginx+thin 的部署方式，还有些应用是跑在 nodejs 下，使用 nginx 将应用映射到不同的子域，不同的应用往往会互相调用对方的资源，所以所有的接口支持 CORS（Cross-Origin Resource Sharing）是必须的。 # Gem 的选择 OAUTH2 服务端：我选择了 doorkeeper 这个 gem，原因是它对 OAUTH2 支持得非常全面，也非常灵活 CORS 中间件：貌似只有 rack-cors 可以选择 注册和认证：devise 是个不错的选择，可以省掉你很多工作 # 补充说明 大家在进行应用拆分后接口一定要规范，建议采用 ruby on rails 官方文档里里建议的一样，使用 namespace 将 api 分离为 v1,v2,v3，尽量不要直接使用脚手架里的接口，设计接口的时候多考虑下通用性，因为现在的接口往往会有很多不同类型的设备来访问，还有接口功能一定要单一，这样可以避免设计出太多的冗余接口