Rails Breaking Up a Monolithic Rails App Without MicroService

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

一个业务系统随着不断的迭代,功能越来越多,代码量也随之越来越大,成为 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 是一个不错的过渡。

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

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

4 楼 已删除

用 MicroService,有推荐的 gem 吗?

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

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

正好需要,谢谢分享

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

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