ruby sinatra 内部机制(二)

基础知识:

1.ruby的proc

ruby的proc的一般使用过程如下:

>> p=Proc.new{|item| p item}
=> #<Proc:0x000000010e446060@(irb):9>
>> p.call("6")
"6"
 

proc是通过call进行调度的,也就是说proc是可以响应call的。

 

2. rack的中间件的概念

   我个人感觉rack中间件类似代理,包裹了endpoint,在完成处理后,中间件再将被包裹的endpoint返回。

    一个简单的rack中间件如下:

MyApp = proc do |env|
    [200, {'Content-Type' => 'text/plain'}, ['ok']]
    end
class MyMiddleware
    def initialize(app)
	@app = app 
    end
    def call(env)
	if env['PATH_INFO'] == '/' 
	    @app.call(env)
	else
	    [404, {'Content-Type' => 'text/plain'}, ['not ok']]
	end 
    end
end
# this is the actual configuration
use MyMiddleware
run MyApp

 通过执行 rackup -p 4567 -s thin启动,访问4567端口后curl 127.0.0.1:4567/ab,返回not ok。从这里我们可以看到MyMiddleware作为中间件,处理非法请求。

 

那么sinatra和中间件又有神马关系呢?

    sinatra既可以作为endpoint(被中间件包裹的app),也可以作为中间件过滤处理请求。

    sinatra的所有请求的入口是call,从而知道每次call都会去调用prototype,在引入@prototype时,就引入了rack的中间件。同样,根据上面的例子,sinatra支持使用use来引入其他的中间件。

当一个请求到达后,则所有的before过滤器会被触发,而在处理请求后,所有的after都会被触发,除非before、after有特定的路径限制。

      # The prototype instance used to process requests.
      def prototype
        @prototype ||= new
      end

      # Create a new instance without middleware in front of it.
      alias new! new unless method_defined? :new!

      # Create a new instance of the class fronted by its middleware
      # pipeline. The object is guaranteed to respond to #call but may not be
      # an instance of the class new was called on.
      def new(*args, &bk)
        build(Rack::Builder.new, *args, &bk).to_app
      end

      # Creates a Rack::Builder instance with all the middleware set up and
      # an instance of this class as end point.
      def build(builder, *args, &bk)
        setup_default_middleware builder
        setup_middleware builder
        builder.run new!(*args, &bk)
        builder
      end

      def call(env)
        synchronize{protype.call(env)}
      end
 

使用rack的中间件 (保存为config.ru)

require 'sinatra' 
require 'rack'
# A handy middleware that ships with Rack
# and sets the X-Runtime header 
use Rack::Runtime
get('/') { 'Hello world!' }

 在启动访问后

curl 127.0.0.1:4567 -vv

* About to connect() to 127.0.0.1 port 4567 (#0)
*   Trying 127.0.0.1... connected
* Connected to 127.0.0.1 (127.0.0.1) port 4567 (#0)
> GET / HTTP/1.1
> User-Agent: curl/7.21.4 (universal-apple-darwin11.0) libcurl/7.21.4 OpenSSL/0.9.8r zlib/1.2.5
> Host: 127.0.0.1:4567
> Accept: */*
> 
< HTTP/1.1 200 OK
< X-Frame-Options: sameorigin
< X-XSS-Protection: 1; mode=block
< Content-Length: 12
< Content-Type: text/html;charset=utf-8
< X-Runtime: 0.000396


< Connection: keep-alive
< Server: thin 1.5.0 codename Knife
< 
* Connection #0 to host 127.0.0.1 left intact
* Closing connection #0
Hello world!

sinatra自己作为中间件 (保存为config.ru)

require 'rubygems'
require 'sinatra/base'
MyApp = proc do |env|
    [200, {'Content-Type' => 'text/plain'}, ['ok']]
    end
class MyMiddlewareSinatra < Sinatra::Base
    before do
      if env['PATH_INFO'] != '/' 
	halt "not good"
      end	
    end
end
# this is the actual configuration
use MyMiddlewareSinatra
run MyApp

 利用rackup -s thin -p 4567启动后访问/abc,返回not good

 

 

 

分发原则

在sinatra作为endpoint的时候,每一个请求生成一个对应的实例。而当sinatra作为中间件运行时,则是所有的请求都对应一个实例。

在sinatra作为app处理请求的时候,调用的如下代码:

 # The prototype instance used to process requests.
      def prototype
        @prototype ||= new
      end
      def call(env)
        synchronize { prototype.call(env) }
      end

 而在作为中间件调用的如下代码

 # Rack call interface.
    def call(env)
      dup.call!(env)
    end
    def call!(env) # :nodoc:
      @env      = env
      @request  = Request.new(env)
      @response = Response.new
      @params   = indifferent_params(@request.params)
      template_cache.clear if settings.reload_templates
      force_encoding(@params)

      @response['Content-Type'] = nil
      invoke { dispatch! }
      invoke { error_block!(response.status) }

      unless @response['Content-Type']
        if Array === body and body[0].respond_to? :content_type
          content_type body[0].content_type
        else
          content_type :html
        end
      end

      @response.finish
    end
 

 

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
城市应急指挥系统是智慧城市建设的重要组成部分,旨在提高城市对突发事件的预防和处置能力。系统背景源于自然灾害和事故灾难频发,如汶川地震和日本大地震等,这些事件造成了巨大的人员伤亡和财产损失。随着城市化进程的加快,应急信息化建设面临信息资源分散、管理标准不统一等问题,需要通过统筹管理和技术创新来解决。 系统的设计思路是通过先进的技术手段,如物联网、射频识别、卫星定位等,构建一个具有强大信息感知和通信能力的网络和平台。这将促进不同部门和层次之间的信息共享、交流和整合,提高城市资源的利用效率,满足城市对各种信息的获取和使用需求。在“十五”期间,应急信息化工作将依托这些技术,实现动态监控、风险管理、预警以及统一指挥调度。 应急指挥系统的建设目标是实现快速有效的应对各种突发事件,保障人民生命财产安全,减少社会危害和经济损失。系统将包括预测预警、模拟演练、辅助决策、态势分析等功能,以及应急值守、预案管理、GIS应用等基本应用。此外,还包括支撑平台的建设,如接警中心、视频会议、统一通信等基础设施。 系统的实施将涉及到应急网络建设、应急指挥、视频监控、卫星通信等多个方面。通过高度集成的系统,建立统一的信息接收和处理平台,实现多渠道接入和融合指挥调度。此外,还包括应急指挥中心基础平台建设、固定和移动应急指挥通信系统建设,以及应急队伍建设,确保能够迅速响应并有效处置各类突发事件。 项目的意义在于,它不仅是提升灾害监测预报水平和预警能力的重要科技支撑,也是实现预防和减轻重大灾害和事故损失的关键。通过实施城市应急指挥系统,可以加强社会管理和公共服务,构建和谐社会,为打造平安城市提供坚实的基础。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值