[Rails] 从 Request 到 Response（1）

本文翻译自：Rails from Request to Response 系列；个人选择了自己感兴趣的部分进行翻译，需要阅读原文的同学请戳前面的链接。

第一部分导言（Introduction）

服务器

在讲 Rails 调用栈之前，先简单介绍一下不同服务器应用的作用，其中并不会涉及到各个服务器应用（比如 Thin 和 Unicorn 或 Nginx）的细节，因为文章的重点是讲 Rails 端的一些东西。

这里举一个 Unicorn 的简单例子，管窥整个 Rails 应用。

Unicorn架构

Unicorn 是一个实现了Rack接口的服务器应用，通过多个 worker 并行处理请求（request）。启动时，主进程会将 Rails App 代码加在到内存中，随后以加载进来内存为原料进行复制，生成一定数量的 worker，并对他们进行监控和信号捕获（比如被用作关闭和重启的 QUIT，TERM，USR1 信号等等）。这些 worker 负责处理的一个个真实的 web 请求（request）。

下图是 Unicorn 的架构（这幅图片来自Github一篇很棒的文章）：

[Rails] 从 Request 到 Response（1）

这些 worker 从共享的 socket 中读取 HTTP 请求（request），并将它们发给 Rails 应用。随后得到响应（response），写回到共享的 socket 中。这个过程中的大部份都发生在Unicorn HttpServer 类的 #process_client 方法中，下面是相关部分的代码：

# unicorn/lib/unicorn/http_server.rb

def process_client(client)

  status, headers, body = @app.call(env = @request.read(client))

  ...

  http_response_write(client, status, headers, body,

                      @request.response_start_sent)

  client.shutdown

  client.close

rescue => e

  handle_error(client, e)

end

其中省略了一些关于HTTP 100状态处理和Rack socket hijacking相关的代码，感兴趣的话可以阅读完整版本。

我们可以看到，这个方法的核心逻辑相当的简明！

第一行是Rack specification：Rack App 其实就是一个 Ruby Object，我们只需要为它写一个可以接受 hash 参数 env 的 #call 方法，让它的返回 [status, headers, body]（译者：还不是很明白 rack 是什么鬼的同学可以去看一下这个视频，亲测好评）。

这个就是 Rails，Sinatra，Padrino 等那些兼容了Rake接口的框架的核心。回到 #process_client 方法，可以看到，我们向 @app 的 #call 方法传递 env 参数，并在 client 关闭之前，将响应（response）写回。

你没猜错，这个 @app 就是我们的 Rails 项目，我们来看他的声明：

# blog/config/application.rb

module Blog

  class Application < Rails::Application

    ...

  end

end

这就是 Rails 调用栈的入口，但是如果你仔细观察，你会发现 #call 并没有定义在 Blog::Application，而是被声明在了父类 Rails::Application 中。

现在开始，我们需要了解 Rails 应用的继承机制，以及一个请求（request）是如何在 Rails 内部被处理的。

Rails Application and Engines

我们之前提到，整个 Rails 应用的入口 #call 被定义在了 Rails::Application 中，我们通过继承来使用它。这里是它的定义（源码）：

# rails/railties/lib/rails/application.rb

module Rails

  class Application < Engine

    # Implements call according to the Rack API. It simply

    # dispatches the request to the underlying middleware stack.

    def call(env)

      env["ORIGINAL_FULLPATH"] = build_original_fullpath(env)

      env["ORIGINAL_SCRIPT_NAME"] = env["SCRIPT_NAME"]

      super(env)

    end

    ...

  end

end

这里并没有什么东西，大部分功能通过调用 super 来执行。如果我们跟着代码看，可以发现 Rails::Application 类继承于 Rails::Engine 类。如果你熟悉Rails engines，你会惊喜地发现，Rails::Application 就是一个超级 engine!

我们来看看 Engine 类中的 #call 方法：

# rails/railties/lib/rails/engine.rb

module Rails

  class Engine < Railtie

    def call(env)

      env.merge!(env_config)

      if env['SCRIPT_NAME']

        env.merge! "ROUTES_#{routes.object_id}_SCRIPT_NAME" => env['SCRIPT_NAME'].dup

      end

      app.call(env)

    end

    ...

  end

end

所以，Engine 类继承于 Rails::Railtie 。通过观察源码，我们可以发现Railtie0是 Rails 框架的核心，他为 initializers，config keys，generators 和 rack tasks 等提供钩子方法。

所有Rails的主要部件（ActionMailer，ActionView，ActionController 和 ActiveRecord）都是一个 Railtie，这也就是为什么你可以随意拆装组合这些部件。

在 Engine 的 #call 方法中我们看到了 #call 的另一个代理方法（delegation），这里的 app 代表的是什么？在同一个文件中，我们发现了他的定义：

# rails/railties/lib/rails/engine.rb

# Returns the underlying rack application for this engine.

def app

  @app ||= begin

    config.middleware = config.middleware.merge_into(default_middleware_stack)

    config.middleware.build(endpoint)

  end

end

现在我们到了一个牛逼的位置。这个engine构造了一个类似Rack application的中间件，并将 #call 方法代理（delegate）给它，他的终点是我们应用的 routes，ActionDispatch::Routing::RouteSet 类的一个实例。

Rack middleware可以用来「过滤」请求（request）和响应（response），并且可以将一个请求（request）处理过程分解成多个步骤，并视为一个「管道」进行处理，比如：处理权限认证，缓存等等。

你可以通过执行 rake middleware 来列出一个应用所使用的全部中间件。这里是我对 Blog 应用执行这条指令所得到的结果：

$ RAILS_ENV=production rake middleware

use Rack::Sendfile

use #<ActiveSupport::Cache::Strategy::LocalCache::Middleware:0x007f7ffb206f20>

use Rack::Runtime

use Rack::MethodOverride

use ActionDispatch::RequestId

use Rails::Rack::Logger

use ActionDispatch::ShowExceptions

use ActionDispatch::DebugExceptions

use ActionDispatch::RemoteIp

use ActionDispatch::Callbacks

use ActiveRecord::ConnectionAdapters::ConnectionManagement

use ActiveRecord::QueryCache

use ActionDispatch::Cookies

use ActionDispatch::Session::CookieStore

use ActionDispatch::Flash

use ActionDispatch::ParamsParser

use Rack::Head

use Rack::ConditionalGet

use Rack::ETag

run Blog::Application.routes

其中的大部分都不会讲，因为没有必要去了解全部这些中间件，即使一个请求（request），在到达 Blog::Application.routes 之前，会途径列表中从上到下所有的中间件。

到这里，我们已经完成了 App server / Rails application stack 的导言部分的介绍，接下来会着重介绍 Rails routing / dispatch stack。

译者总结

我们可以将 rack app 简化地表示为一个函数：

ƒ: env_set → { [status, headers, body] }

Rails app 其实就是若干个函数的嵌套，逐层对输入的 env 和返回 [status, headers, body] 进行加工。整个Rails的执行过程，不过如此。

env(1) → env(2) → ... → env(i) → ... env(n)

令：s: [status, headers, body]

s(n) → s(n-1) → ... → s(i) → ... s(1)

看完这篇文章后，终于理解了《Ruby社区应该去Rails化了》中这段话的意思：

Rails为何不适合做Web Service?

我发现了一个有意思的现象，最早的一批用Ruby开发Web Service服务的网站，都选择了用Rails开发，而在最近几年又不约而同抛弃Rails重写Web服务框架。当初用Rails的原因很简单，因为产品早期起步，不确定性很高，使用Rails快速开发，可以最大限度节约开发成本和时间。但为何当请求量变大以后，Rails不再适合了呢？

这主要是因为Rails本身是一个full-stack的Web框架，所有的设计目标就是为了开发Website，所以Rails框架封装过于厚重，对于需要更高性能更轻薄的Web Service应用场景来说，暴露出来了很多缺陷：

Rails调用堆栈过深，URL请求处理性能很差

Rails的设计目标是提供Web开发的最佳实践，所以无论你需要不需要，Rails默认提供了开发Website所有可能的组件，但其中绝大部分你可能一辈子都用不上。例如Rails项目默认添加了20个middleware，但其中10个都是可以去掉的，我们自己的项目当中手工删除了这些middleware：

config.middleware.delete 'Rack::Cache'   # 整页缓存，用不上

config.middleware.delete 'Rack::Lock'    # 多线程加锁，多进程模式下无意义

config.middleware.delete 'Rack::Runtime' # 记录X-Runtime（方便客户端查看执行时间）

config.middleware.delete 'ActionDispatch::RequestId' # 记录X-Request-Id（方便查看请求在群集中的哪台执行）

config.middleware.delete 'ActionDispatch::RemoteIp'  # IP SpoofAttack

config.middleware.delete 'ActionDispatch::Callbacks' # 在请求前后设置callback

config.middleware.delete 'ActionDispatch::Head'      # 如果是HEAD请求，按照GET请求执行，但是不返回body

config.middleware.delete 'Rack::ConditionalGet'      # HTTP客户端缓存才会使用

config.middleware.delete 'Rack::ETag'    # HTTP客户端缓存才会使用

config.middleware.delete 'ActionDispatch::BestStandardsSupport' # 设置X-UA-Compatible, 在nginx上设置

其中最夸张的是ActionDispatch::RequestIdmiddleware，只有在大型应用部署在群集环境下进行线上调试才可能用到的功能，有什么必要做成默认的功能呢？ Rails的哲学是：提供最全的功能集给你，如果你用不到，你自己手工一个一个关闭掉，但是这样带来的结果就是默认带了太多不必要的冗余功能，造成性能损耗极大。

我们看一个Ruby web框架请求处理性能评测，这个评测不访问数据库，也不测试并发性能，主要是测试框架处理URL请求路由，渲染文本，返回结果的处理速度。

Rack: 1570.43 request/s

Campig: 1166.16 request/s

Sinatra: 912.81 request/s

Padrino: 648.68 request/s

Rails: 291.27 request/s

Sinatra至少是Rails速度的3倍以上。