Rack Middleware

  • March 12, 2019 10:02
  • Posted by cain
  • 0 comments

Rack官网对于Rack的介绍比较简单,只是介绍了Rack的作用和基本的使用。不过也可能因为不复杂,所以才用简单的几段话介绍了Rack。虽然我们不用了解middleware的调用原理也可以开发出能使用的middleware,但是总有点不知所以然的感觉,所以抽空总结了下Rack中middleware的调用原理。

Rack middleware的使用

  1. 配置config.ru文件,定义好要用到的middleware和要run的middleware,为什么有些middleware需要run,有些需要use,下面再详细介绍。下面是一个简单的调用。

    # ./config.ru
    app = Proc.new { |env| ['200', {'Content-Type' => 'text/html'}, ['get rack\'d']] }
    run app
    

接着执行rackup命令应用就可以跑起来了。

  1. 同时还可以把middleware定义成一个类,但是要在初始化实例的时候初始化@app和定义一个call方法,并且在call方法中需要调用@app.call(env),如下:

    # rack_demo.rb
    require 'rack'
    
    class Timing
      def initialize(app)
        @app = app
      end
    
      def call(env)
        ts = Time.now
        status, headers, body = @app.call(env)
        elapsed_time = Time.now - ts
        puts "Timing: #{env['REQUEST_METHOD']} #{env['REQUEST_URI']} #{elapsed_time.round(3)}"
        return [status, headers, body]
      end
    end
    
    app = proc do |env|
      ['200', {'Content-Type' => 'text/html'}, ['Hello, Rack!']]
    end
    
    Rack::Handler::WEBrick.run(Timing.new(app), :Port => 9292, :Host => '0.0.0.0')
    

    执行ruby rack_demo.rb就可以跑起一个服务了。

middleware的具体使用和返回格式要求这里不详细介绍,可以参考Ruby Rack 及其应用。同时上面的两种使用方式的作用原理是一样的。下面再详细分析。

Rack Middleware实现的原理

定义好config.ru配置文件后在当前目录执行rackup命令,会去到ruby对应的bin目录执行文件。一般在ruby安装好后都会有这个二进制文件的,在我本地的位置是 ~/.rvm/gems/ruby-2.5.3/bin/rackup

# ~/.rvm/gems/ruby-2.5.3/bin/rackup
require 'rubygems'

version = ">= 0.a"
...

if Gem.respond_to?(:activate_bin_path)
  load Gem.activate_bin_path('rack', 'rackup', version)
else
  gem "rack", version
  load Gem.bin_path("rack", "rackup", version)
end

上面源码会执行后面的rack gem下面的rackup二进制文件,其中的源码为:

#!/usr/bin/env ruby
# ~/.rvm/gems/ruby-2.5.3/gems/rack-2.0.6/bin/rackup
require "rack"
Rack::Server.start

主要是为了启动Rack Server,那启动的过程又做了什么东西呢? 调用栈从 def self.start => initialize => parse_options 这一系列的调用只是为了初始化一个Server,然后加上一些默认的Options配置,初始化后主要是加了如下的默认配置:

{
  :environment => "development",
  :pid         => nil,
  :Port        => 9292,
  :Host        => "localhost",
  :AccessLog   => [],
  :config      => "config.ru"
}

其中config中的值config.ru就是默认的配置文件,然后就是实例执行run方法了。run方法中调用了wrappedapp方法,这个方法主要是把那些middleware汇总为一个app的方法。沿着方法调用栈继续查看,其中`buildapp`方法比较重要。源码如下:

def build_app(app)
  middleware[options[:environment]].reverse_each do |middleware|
    middleware = middleware.call(self) if middleware.respond_to?(:call)
    next unless middleware
    klass, *args = middleware
    app = klass.new(app, *args)
  end
  app
end

middleware[options[:environment]]求得的值是Rack中默认的middleware。遍历的块中每个middleware都会去创建一个实例,以app变量作为参数传入,这就是为什么每个middleware在initialize的时候都需要传入一个app变量,并初始化赋值给@app实例变量。上面的迭代遍历过程最后方法返回的app会变成如下的链式反应:

#<Rack::ContentLength:0x00007ff72d568200
 @app=
  #<Rack::Chunked:0x00007ff72d568ef8
   @app=
    #<Rack::CommonLogger:0x00007ff72d569ce0
     @app=
      #<Rack::ShowExceptions:0x00007ff72e940c28
       @app=
        #<Rack::Lint:0x00007ff72e941ee8
         @app=
          #<Rack::TempfileReaper:0x00007ff72e943018
           @app=
            #<StatusLogger:0x00007ff72d4a0570
             @app=
              #<StatusLoggear:0x00007ff72d4a1088
               @app=
                #<Proc:0x00007ff72d4a2820@/Users/Cain/code/ruby/rack/config.ru:30>>>>

这样通过调用app.call可以调用到所有middleware的call方法。 如下例子:

#config.ru
class FirstMidd
  def initialize(app)
    @app = app
  end

  def call(env)
    puts "1"
    status, head, body = @app.call(env)
    puts "7"
    [status, head, body]
  end
end

class SecondMidd
  def initialize(app)
    @app = app
  end

  def call(env)
    puts "2"
    status, head, body = @app.call(env)
    puts "6"
    [status, head, body]
  end
end

class ThirdMidd
  def initialize(app)
    @app = app
  end

  def call(env)
    puts "3"
    status, head, body = @app.call(env)
    puts "5"
    [status, head, body]
  end
end

class Top
  def call(env)
    puts "4"
    [200, {'Content-Type' => 'text/plain'}, ["hello, this is a test."]]
  end
end

use FirstMidd
use SecondMidd
use ThirdMidd
run Top.new

发送一个请求curl http://localhost:9292后,服务器会会按照 => 1, 2, 3, 4, 5, 6, 7 的顺序输出。上面的执行顺序体现了一个调用栈的调用过程。 同时上面还有一个app参数值的传入,求app过程如下:

  # ~/.rvm/gems/ruby-2.5.3/gems/rack-2.0.6/lib/rack/server.rb
  def build_app_and_options_from_config
    ...

    app, options = Rack::Builder.parse_file(self.options[:config], opt_parser)
    @options.merge!(options) { |key, old, new| old }
    app
  end

  # ~/.rvm/gems/ruby-2.5.3/gems/rack-2.0.6/lib/rack/builder.rb
  def self.parse_file(config, opts = Server::Options.new)
    options = {}
    if config =~ /\.ru$/
      ...
      app = new_from_string cfgfile, config
    else
      ...
    end
    return app, options
  end

  def self.new_from_string(builder_script, file="(rackup)")
    eval "Rack::Builder.new {\n" + builder_script + "\n}.to_app",
        TOPLEVEL_BINDING, file, 0
  end

最后会调用newfromstring这个方法。这个方法就是通过eval执行之前config.ru中的内容。其中Builder#to_app方法执行了 app = @use.reverse.inject(app) { |a,e| e[a] }config.ru 中run方法调用的那些middleware实例逐个迭代作为参数嵌入到app变量中,app最终的效果如上面build_app方法中最后的app变量的形式一样。最终这个app值作为build_app方法的实参调用,最终合并成最终链条。

上面留了个问题,为什么在 config.ru 中有些middleware需要用use,而最后会有个run方法的调用。因为run实例中的call方法是在server里面最后调用的方法,call方法按照状态,头部,body的形式返回。和其它的一些middleware初始化@app,然后在call方法中执行@app.call(env)还是有些区别的,所以在Rack里的实现就把run的那个middleware实例作为最终的[status, headers, body]形式返回给前面的middleware逐层去处理逻辑了。

Rack和应用服务器的对接

Rack是应用服务器和应用的连接桥梁,具体是怎么实现的呢?其实Rack只是按照一定的规则去找出应用服务器,然后通过执行其中定义好的run方法,把上面链接好的迭代app传入服务器中去执行,从而达到中间桥梁的作用,主要的代码在Rack::Server#start的时候run了应用服务器。如下:

# ~/.rvm/gems/ruby-2.5.3/gems/rack-2.0.6/lib/rack/server.rb

def start
  ...
  server.run wrapped_app, options, &blk
end

这行代码中,server的调用过程如下:

# ~/.rvm/gems/ruby-2.5.3/gems/rack-2.0.6/lib/rack/server.rb

def server
  @_server ||= Rack::Handler.get(options[:server])

  unless @_server
    @_server = Rack::Handler.default

    # We already speak FastCGI
    @ignore_options = [:File, :Port] if @_server.to_s == 'Rack::Handler::FastCGI'
  end

  @_server
end

如果没有配置对应的:server选项,调用Rack::Handler.get会返回nil,然后调用Rack::Handler.default去查找对应的server。会通过pick ['puma', 'thin', 'webrick']按照默认服务器名字的顺序去查找对应的服务器handler。 如果require了puma,而puma因为定义了一个覆盖Handler中default的方法,如下:

# /Users/Cain/.rvm/gems/ruby-2.5.3/gems/puma-3.12.0/lib/puma/rack_default.rb
require 'rack/handler/puma'

module Rack::Handler
  def self.default(options = {})
    Rack::Handler::Puma
  end
end

这时 Rack::Handler.default 返回的就是 Rack::Handler::Puma 这个类。这时调用server.run wrapped_app, options, &blk就相当于调用了Rack::Handler::Puma.run,从而在puma中接到可以处理的请求后再执行app.call(env),就会出现一系列的链式调用。从而保证middleware都可以被调用到call方法,然后再次返回处理逻辑。

总结:Rack还做了很多的其它处理工作,把app和app server给串联起来只是其中的一部分。总的来说就是当一个请求过来时,可以通过一个个的middleware链式的调用,完成一些列的功能调用。从而细分了各个功能点,方便了开发人员更好的去扩展。

Ref:

Comments

Post your comment