上月初开始实习的,想来一个月了,却一直没有时间更新博客,导致七月博客竟然一篇都没有……
学了三年Java,就因为接触了三个月的Python,于是就找了一个Python相关的实习,这厮太不“忠义”了……
过去的这个月,接触的最多的就是Python的WSGI了,WSGI不是框架不是模块,仅仅是一个规范协议,定义了一些接口,却影响着Python网络开发的方方面面。对于WSGI有这么一段定义:WSGI is the Web Server Gateway Interface. It is a specification for web servers and application servers to communicate with web applications (though it can also be used for more than that).我想我这篇文章不是详细介绍WSGI内容的,只是想扯扯我对WSGI相关的学习。
诚如那个WSGI的定义所说的,协议定义了一套接口来实现服务器端与应用端通信的规范化(或者说是统一化)。这是怎样的一套接口呢?很简单,尤其是对于应用端。
应用端只需要实现一个接受两个参数的,含有__call__方法的,返回一个可遍历的含有零个或多个string结果的Python对象(我强调说Python对象,只是想和Java的对象区别开,在Python里一个方法、一个类型……都是对象,Python是真“一切皆对象”,详见《Python源码分析》)即可。码农都知道,传入参数的名字可以任意取,这里也不例外,但习惯把第一个参数命名为“environ”,第二个为“start_response”。至于这个对象的内容怎样,应用自由发挥去吧……
服务器端要做的也不复杂,就是对于每一个来访的请求,调用一次应用端“注册”的那个协议规定应用端必须要实现的对象,然后返回相应的响应消息。这样一次服务器端与应用端的通信也就完成了,一次对用户请求的处理也随之完成了!当然了,既然协议规定了服务器端在调用的时候要传递两个参数,自然也规定了这两个参数的一些细节。比如第一个参数其实就是一个字典对象,里面是所有从用户请求和服务器环境变量中获取的信息内容,协议当然会定义一些必须有的值,及这些值对应的变量名;第二个参数其实就是一个回调函数,它向应用端传递一个用来生成响应内容体的write对象,这个对象也是有__call__方法的。
协议也提到了,还可以设计中间件来连接服务器端与应用端,来实现一些通用的功能,比如session、routing等。
具体怎么应用这个协议呢?Python自带的wsgiref模块有个简单的例子:
from wsgiref.simple_server import make_server
def hello_world_app(environ, start_response):
status = '200 OK' # HTTP Status
headers = [('Content-type', 'text/plain')] # HTTP Headers
start_response(status, headers)
# The returned object is going to be printed
return ["Hello World"]
httpd = make_server('', 8000, hello_world_app)
print "Serving on port 8000..."
# Serve until process is killed
httpd.serve_forever()
这个例子更多体现的是应用端的开发方法,很简单的按照协议实现一个了满足规范的方法,这样当浏览器向本机8000端口发起一个请求时,就会得到一个“Hello World”的字符串文本响应。这个例子虽然简单,但非常清楚的说明了应用端与服务器端的接口应用方式。
你可能会想到:现在对该端口的不同地址的请求都是由这个“hello_world_app”函数处理的,你可以实现一个功能,解析一下请求的PATH信息,针对不同的地址转发给不同的函数或是类来处理;你可能会觉得使用environ和start_response这两个参数不直观,你可以像Java的servlet那样自己封装成两个request和response对象来用;你觉得有些常用功能可以提取出来,在具体应用逻辑之外来做……哈哈,那你就已经在思考怎么做中间件或是Web框架了!其实这些也都有人做过了,比如Routes、WebOb、Beaker……当然你大可以自己造自己独有的轮子,有时候自己做过一遍了才会对现有的成熟的东西有更好的理解,最重要的是在Python的世界里这些都不难做到!
不知你是不是和我一样,在写应用的时候或多或少的会想一下服务器端是怎么运作的呢?可能最模糊的流程大家都能想得到:服务器开一个socket等待客户端连接;请求来了,服务器会读出传来的数据,然后根据HTTP协议做一些初步的封装,接着就可以调用事先注册的应用程序了,并将请求的数据塞进去;等响应处理完毕了再把数据通过socket发出去,over。好在Python的代码简洁,而自带的wsgiref中的simple server也很简单,就让我们探究一下更具体的实现吧!
首先看一下类的继承关系,这个simple server真正的类是WSGIServer,继承自HTTPServer,HTTPServer类又继承自TCPServer,TCPServer又继承自BaseServer;与server类直接打交道的还有RequestHandler类,从最上层的WSGIRequestHandler —> BaseHTTPRequestHandler —> StreamRequestHandler —> BaseRequestHandler。相对Java而言不是很复杂吧,它们是怎么工作的呢?容我稍微解释一下。
让我们从Server的最基类BaseServer看起。它有一段注释非常清楚的介绍了它定义的方法的用处:
Methods for the caller:
- __init__(server_address, RequestHandlerClass)
- serve_forever()
- handle_request() # if you do not use serve_forever()
- fileno() -> int # for select()
Methods that may be overridden:
- server_bind()
- server_activate()
- get_request() -> request, client_address
- verify_request(request, client_address)
- server_close()
- process_request(request, client_address)
- close_request(request)
- handle_error()
Methods for derived classes:
- finish_request(request, client_address)
可见,一个server类其实就这么几个方法。
在可以被外部调用的四个方法中,构造方法显然就是用来创建实例的;第四个可能是和构建异步服务器有关的,这里就略过了;从具体的代码可以看到,剩下两个方法的用处是相同的,就是处理收到的请求,只是serve_forever()方法会在server进程存在期间循环处理,而handle_request()处理一次就退出了(其实server_forever()就是循环调用了handle_request())。在handle_request()中说明了具体的从接受到返回一个请求的全部流程,代码也很简单:
def handle_request(self):
"""Handle one request, possibly blocking."""
try:
request, client_address = self.get_request()
except socket.error:
return
if self.verify_request(request, client_address):
try:
self.process_request(request, client_address)
except:
self.handle_error(request, client_address)
self.close_request(request)
BaseServer虽然定义了这些内部调用的方法,但内容基本都是空的,留给了具体的Server类去实现。从BaseServer的代码中就可以看到RequestHandler类的用处了,它是具体的解析了request的内容,它由finish_request()调用,而这个finsh_request()方法显然应该是在process_request()方法中被调用的。
TCPServer继承BaseServer类,它真正具体化了我们猜测的socket连接的初始化过程。
在与上面两个类相同的源文件中,还有两个主要的类:ThreadingMixIn和ForkingMixIn,这两个类分别重载了process_request()方法,并且相应使用了新建一个线程或是进程的方式来调用finish_request()方法。这也从应用的角度解释了为什么要在finish_request()外套一层process_request(),而不是直接在handle_request()的第二个try块中调用。
HTTPServer其实做的工作很简单,就是记录了socket server的名字。
接下来就该看看WSGIServer了。它做了两件新的工作:设置了一些基本的环境变量值,并且接受应用程序的注册。从这个Server的代码可以看出,应用端实现的那个接口就是从这里注册到服务器端的,而且只能注册一个哦!所以要有多个应用只能通过routing的方式来转发调用了。而且这个WSGIServer不是多线程或是多进程的~
至于具体封装请求内容的RequestHandler类就不打算分析了,感兴趣的话,看官们自个看一下源码吧,也很简单哦!下一篇博客打算分享一下我对pylons框架的运行过程的学习。
分享到:
相关推荐
mod_wsgi 是一个 Apache 模块,实现了 Python WSGI 接口服务
Linux+Django+Python+Wsgi配置过程
Zappa 极大的简化了在 AWS Lambda API 网关上发布所有 Python WSGI 应用。相当于是无服务器的部署运行你的 Python Web 应用
主要给大家介绍了关于Python WSGI的相关资料,文中通过示例代码介绍的非常详细,对大家的学习或者工作具有一定的参考学习价值,需要的朋友们下面随着小编来一起学习学习吧
如果我们的Web应用是采用Python开发,而且符合WSGI规范,比如基于Django,Flask等框架,那如何将其部署在Apache中呢?本文中,我们就会介绍如何使用Apache模块mod_wsgi来运行Python WSGI应用。 安装mod_wsgi 我们...
mod_wsgi的目标是实现一个简单的Apache模块,支持任何Python WSGI的接口的Python应用程序的托管。
python2.7+Django 1.11 在windows 下部署到apache24 下可用
mod_wsgi各版本,包括cpu架构,python版本限制。用于apache的模块组件。
Python 内置的 WSGI 服务器.py
资源分类:Python库 所属语言:Python 资源全名:necrophos-wsgi-0.0.1.tar.gz 资源来源:官方 安装方法:https://lanzao.blog.csdn.net/article/details/101784059
windows下使用flask+wsgi+Apache部署python web, 博客地址 https://blog.csdn.net/Albert201605/article/details/115429256
切肉刀 Python WSGI 应用程序的血腥简单 A/B 测试: 在一行代码中呈现显示或行为差异。 测量和比较多个变体之间的转化,包括统计显着性。 保证回头客同样的体验。 与现有的身份验证和存储层轻松集成。 Cleaver 的...
到Python和WSGI的端口。 使用 。 有关如何将其用于在Python中创建GraphQL服务器(具有中继支持)的演示,请参见 。 学分 该代码由Martijn Faassen移植。 执照 如何执行测试 python2.7 bootstrap-buildout.py bin/...
python-Python 内置的 WSGI 服务器.rar
支持python2.7的mod_wsgi的windows版本。里面文件包括: mod_wsgi-win32-ap22py27-3.3.so python-2.7.msi
另一个VIM设置-Python WSGI版这是我在新的WSGI开发机器上使用的设置脚本。 随意评论或编辑您认为合适的内容。安装 git clone git://github.com/mlindemu/yavs-wsgi.gitcd yavs-wsgi./yavs-wsgi.sh安装了什么? 以下...
为了让大家更好的对python中WSGI有更好的理解,我们先从最简单的认识WSGI着手,然后介绍一下WSGI几个经常使用到的接口,了解基本的用法和功能,最后,我们通过实例了解一下WSGI在实际项目中如何使用。 WSGI是什么? ...
希望apache可以部署django项目的话,就必须在apache的modules目录下放入mod_wsgi.so。这个使用于apache2.2和python2.7.