Rails Breaking Up a Monolithic Rails App Without MicroService

hooopo for Shopper+ · 2015年12月27日 · 最后由 citysheep 回复于 2016年02月26日 · 5985 次阅读
本帖已被设为精华帖!

一个业务系统随着不断的迭代,功能越来越多,代码量也随之越来越大,成为Monolithic系统。主流的拆分方案是MicroService,当然,也有Cookpad这种继续Monolithic的任性做法。那么,除了Monolithic和MicroService之外,还有没有其他的拆分方案呢?在比较各种方案之前,我们先来了解一下以下3个指标:

  1. 业务逻辑共享:不需要为相同的功能写两套甚至更多的重复代码。
  2. 可以独立部署:每个小应用在访问量和应用类型是有很大差别的,比如管理后台可能只有自己人在用,访问量小,但多耗时的请求。前台网站和API可能并发访问量高,需要部署更多的进程。独立部署的好处是可以节省内存,针对各种的访问量调整进程数量。
  3. 没有远程调用:除了需要给远程调用编写额外的API接口之外,远程调用带来的额外性能开销是巨大的,无论是服务端还是客户端。同时,远程调用给编码带来的复杂性也随之增加,本来一个update_attributes方法轻易能做到的功能,再引入远程调用之后,需要在代码里去处理超时、处理异常、重试,也就是把一个单机问题变成了分布式系统问题。另外一个难解的问题就是数据库事务,带有写入操作的远程调用处理事务更加困难。

上面提到的3点,Monolithic满足了1和3,而MicroService满足了1和2。那么有没有3点都满足的呢?答案是Engine!

Core Engine 和 Feature Engine

首先,Rails Engine是什么和Rails Engine怎么用就不在本文介绍了,可以通过下面两个链接来了解:

好吧,Core Engine 和 Feature Engine这两个概念是不存在的,为了区分我自己启的。一提到Engine,我们首先想到的是Devise和Forem这种有完整MVC结构,mount到宿主应用上,提供扩展功能的 Feature Engine。然而,另外一种用于业务逻辑共享的 Engine,暂且称为 Core Engine。

Core Engine 里主要是Model,但也不仅仅是Model,还包括Migration、Model依赖的Gem、全局配置和常量等。

Engine和普通Gem的区别

Gem主要用来共享通用逻辑,而Engine可以用来共享业务逻辑。并且,Engine可以 hook到 Rails 的生命周期里,比如设置auto load 路径,eager load 路径、migration 文件路径等。 Rails App 使用的是 Gemfile,而Engine使用的是gemspec。两者虽然相似,但有细微的区别,在使用的时候需要注意。比如,gemspec里是不能引用 git 上的资源,只能引用rubygems或本地的gem。另外,gemspec只负责安装依赖,但不管加载,所以除了像Gemfile一样指定了gem,还要手动require 所引入的gem。

Demo

首先介绍一下我们网站的一些背景:

  • 网站前台(Frontend):主要是注册、登录、shopping cart、checkout、payment、product and catalog 显示、搜索、推荐等功能。
  • 网站管理后台(Backend):主要是财务、订单处理、包裹处理、产品和类目管理、促销管理、采购、库存管理、客服系统、第三方平台订单同步等。
  • API:提供给Android和iOS应用

我们的目标是把网站拆分成网站前台、网站管理后台、API,并满足上面提到的三点:业务逻辑共享、可以独立部署、无远程调用。

Shared Core Engine

下面开始演示抽出Core Engine涉及到的一些细节问题:

lib/core/engine.rb

require 'rails/all'
require 'mysql2'
require 'active_merchant'
require 'kaminari'
require 'cancan'
require 'ancestry'
require 'state_machine'
# other require

module Core
  class Engine < ::Rails::Engine
  end
end

宿主App Gemfile,以backend为例:

source 'https://rubygems.org/'
gem 'rails'
gem 'core', :path => '../core'

目录结构:

├── core
├── backend
├── api
└── frontend

让宿主项目可以使用Core Engine里的Migration文件:

module Core
  class Engine < ::Rails::Engine

    # run bundle exec rake db:migrate 可以migrate core 内部的 migrations
    initializer :append_migrations do |app|
      unless app.root.to_s == root.to_s
        app.config.paths["db/migrate"] += config.paths["db/migrate"].expanded
      end
    end
  end
end

Auto Load Path等配置:

module Core
  class Engine < ::Rails::Engine
    config.autoload_paths += %W(
      #{config.root}/lib
      #{config.root}/app/models/concerns
      #{config.root}/app/models/rpush
      #{config.root}/app/service_objects
    )

    config.eager_load_paths += %W(
      #{config.root}/app/mailers
      #{config.root}/lib
      #{config.root}/app/models/concerns
      #{config.root}/app/models/rpush
      #{config.root}/app/uploaders
    )
  end
end

cap deploy之前自动同步最新的代码:

set :core_path, '/var/www/core'

task :sync_core, :roles => :web do
  b = ENV['CORE_BRANCH'] || branch
  bash = StringIO.new(<<-BASH)
    if [ -d #{core_path} ]; then
      cd #{core_path} &&  git remote update && git checkout origin/#{b}
    else
      git clone -b #{b} git@xxxx/core.git #{core_path}
    fi
  BASH
  upload(bash, "/tmp/fetch_core.sh")
  run "/bin/bash /tmp/fetch_core.sh"
  run "ln -sf #{core_path} #{deploy_to}/releases/"
  run "ln -sf #{core_path} #{deploy_to}/"
end

before 'bundle:install', 'sync_core'

除了Model可以共享之外,路由其实也可以通过Core Engine的方式共享。一些情况,在管理后台发邮件和rake task也需要调用前台App的路由结构,但由于网站管理后台和网站前台分离,只能通过硬编码来拼路由或是引入MicroService,而Core Engine的方式可以共享Rails App的任意部分,抽出Route Engine 之后,只需要这样调用:

MyApp::Engine.routes.url_helpers.new_post_path

Thin Model Fat Service Object

理论上,Core Engine里的Model应该是网站前台和管理后台共用那部分,而只有前台使用的Model单独留在前台,只有后台使用的Model单独留在后台。但由于Rails的关联机制等因素,这一点很难做到。退而求其次,我们可以优化到:Core Engine包含所有Model,但网站前台业务逻辑代码只放在网站前台,网站管理后台的业务逻辑代码只放在管理后台。要做到这一点就必须改变之前Fat Model的代码组织方式:

class Product < AR
  def method_for_frontend
  end

  def method_for_backend
  end
end

上面代码在Monolithic App里无任何问题。在Core Engine里,就会让网站前台和管理后台都加载了不属于自己的逻辑。解决办法就是拥抱Service Object,让Model里只存放共用的逻辑和方法,其他移除到Service Object或Concern里,这样就可以做更细粒度的加载。

结论

如果不是多语言混合型团队,没有必要引入MicroService,Core Engine是一个不错的过渡。

共收到 10 条回复

写的很好. 然后最近使用的spree就推荐使用Engine进行个性化.

所以说Core里包含了所有公共Model和通用逻辑?不同用途的APP(API、后台管理、Web端)引用Core然后扩展特有行为? 也就是说Engine在这里的用途只是解决各独立项目之间的代码复用的问题

4楼 已删除

用MicroService,有推荐的gem吗?

思路挺新颖的,是一种不错的应用Engine的方法。

现在做项目挺担惊受怕的,后端怕 microservice,前端怕 SPA

正好需要,谢谢分享

学习了,正好可以用到现在的产品上。

karloku 调查下谁在用 Ruby 的 Padrino Web 框架? 中提及了此贴 12月06日 02:30
需要 登录 后方可回复, 如果你还没有账号请点击这里 注册