摘要：通過(guò)回調(diào)函數(shù)將響應(yīng)狀態(tài)和響應(yīng)頭返回給，同時(shí)返回響應(yīng)正文，響應(yīng)正文是可迭代的并包含了多個(gè)字符串。返回響應(yīng)正文負(fù)責(zé)獲取請(qǐng)求，將請(qǐng)求傳遞給，由處理請(qǐng)求后返回。

我想大部分Python開發(fā)者最先接觸到的方向是WEB方向（因?yàn)榭偸怯虚_發(fā)者希望馬上給自己做個(gè)博客出來(lái)，例如我），既然是WEB，免不了接觸到一些WEB框架，例如Django,Flask,Torando等等，在開發(fā)過(guò)程中，看過(guò)一些文檔總會(huì)介紹生產(chǎn)環(huán)境和開發(fā)環(huán)境服務(wù)器的配置問(wèn)題，服務(wù)器又設(shè)計(jì)web服務(wù)器和應(yīng)用服務(wù)器，總而言之，我們碰到最多的，必定是這個(gè)詞 --- WSGI。
接下來(lái)的文章，會(huì)分為以下幾個(gè)部分：

1.WSGI介紹

1.1什么是WSGI

1.2怎么實(shí)現(xiàn)WSGI

2.由Django框架分析WSGI

3.實(shí)際環(huán)境使用的wsgi服務(wù)器

4.WSGI服務(wù)器比較

首先介紹幾個(gè)關(guān)于WSGI相關(guān)的概念
WSGI：全稱是Web Server Gateway Interface，WSGI不是服務(wù)器，python
模塊，框架，API或者任何軟件，只是一種規(guī)范，描述web server如何與web application通信的規(guī)范。server和application的規(guī)范在PEP 3333中有具體描述。要實(shí)現(xiàn)WSGI協(xié)議，必須同時(shí)實(shí)現(xiàn)web server和web application，當(dāng)前運(yùn)行在WSGI協(xié)議之上的web框架有Torando,Flask,Django

uwsgi：與WSGI一樣是一種通信協(xié)議，是uWSGI服務(wù)器的獨(dú)占協(xié)議，用于定義傳輸信息的類型(type of information)，每一個(gè)uwsgi packet前4byte為傳輸信息類型的描述，與WSGI協(xié)議是兩種東西，據(jù)說(shuō)該協(xié)議是fcgi協(xié)議的10倍快。

uWSGI：是一個(gè)web服務(wù)器，實(shí)現(xiàn)了WSGI協(xié)議、uwsgi協(xié)議、http協(xié)議等。

WSGI協(xié)議主要包括server和application兩部分：

WSGI server負(fù)責(zé)從客戶端接收請(qǐng)求，將request轉(zhuǎn)發(fā)給application，將application返回的response返回給客戶端；
WSGI application接收由server轉(zhuǎn)發(fā)的request，處理請(qǐng)求，并將處理結(jié)果返回給server。application中可以包括多個(gè)棧式的中間件(middlewares)，這些中間件需要同時(shí)實(shí)現(xiàn)server與application，因此可以在WSGI服務(wù)器與WSGI應(yīng)用之間起調(diào)節(jié)作用：對(duì)服務(wù)器來(lái)說(shuō)，中間件扮演應(yīng)用程序，對(duì)應(yīng)用程序來(lái)說(shuō)，中間件扮演服務(wù)器。

WSGI協(xié)議其實(shí)是定義了一種server與application解耦的規(guī)范，即可以有多個(gè)實(shí)現(xiàn)WSGI server的服務(wù)器，也可以有多個(gè)實(shí)現(xiàn)WSGI application的框架，那么就可以選擇任意的server和application組合實(shí)現(xiàn)自己的web應(yīng)用。例如uWSGI和Gunicorn都是實(shí)現(xiàn)了WSGI server協(xié)議的服務(wù)器，Django，Flask是實(shí)現(xiàn)了WSGI application協(xié)議的web框架，可以根據(jù)項(xiàng)目實(shí)際情況搭配使用。

以上介紹了相關(guān)的常識(shí)，接下來(lái)我們來(lái)看看如何簡(jiǎn)單實(shí)現(xiàn)WSGI協(xié)議。

上文說(shuō)過(guò)，實(shí)現(xiàn)WSGI協(xié)議必須要有wsgi server和application，因此，我們就來(lái)實(shí)現(xiàn)這兩個(gè)東西。

我們來(lái)看看官方WSGI使用WSGI的wsgiref模塊實(shí)現(xiàn)的小demo

有關(guān)于wsgiref的快速入門可以看看這篇博客

def demo_app(environ,start_response):  
    from StringIO import StringIO  
    stdout = StringIO()  
    print >>stdout, "Hello world!"  
    print >>stdout  
    h = environ.items(); h.sort()  
    for k,v in h:  
        print >>stdout, k,"=", repr(v)  
    start_response("200 OK", [("Content-Type","text/plain")])  
    return [stdout.getvalue()]  
  
httpd = make_server("localhost", 8002,  demo_app)  
httpd.serve_forever()  # 使用select  

實(shí)現(xiàn)了一個(gè)application，來(lái)獲取客戶端的環(huán)境和回調(diào)函數(shù)兩個(gè)參數(shù)，以及httpd服務(wù)端的實(shí)現(xiàn)，我們來(lái)看看make_server的源代碼

def make_server(  
    host, port, app, server_class=WSGIServer, handler_class=WSGIRequestHandler  
):  
  """Create a new WSGI server listening on `host` and `port` for `app`"""  
  server = server_class((host, port), handler_class)  
  server.set_app(app)  
  return server

接受一系列函數(shù)，返回一個(gè)server對(duì)象,實(shí)現(xiàn)還是比較簡(jiǎn)單，下面我們來(lái)看看在django中如何實(shí)現(xiàn)其自身的wsgi服務(wù)器的。

下面我們自己來(lái)實(shí)現(xiàn)一遍：
WSGI 規(guī)定每個(gè) python 程序（Application）必須是一個(gè)可調(diào)用的對(duì)象（實(shí)現(xiàn)了__call__ 函數(shù)的方法或者類），接受兩個(gè)參數(shù) environ（WSGI 的環(huán)境信息） 和 start_response（開始響應(yīng)請(qǐng)求的函數(shù)），并且返回 iterable。幾點(diǎn)說(shuō)明：

environ 和 start_response 由 http server 提供并實(shí)現(xiàn)
environ 變量是包含了環(huán)境信息的字典
Application 內(nèi)部在返回前調(diào)用 start_response
start_response也是一個(gè) callable，接受兩個(gè)必須的參數(shù)，status（HTTP狀態(tài)）和 response_headers（響應(yīng)消息的頭）
可調(diào)用對(duì)象要返回一個(gè)值，這個(gè)值是可迭代的。

 # 1. 可調(diào)用對(duì)象是一個(gè)函數(shù)
def application(environ, start_response):
 
   response_body = "The request method was %s" % environ["REQUEST_METHOD"]
 
   # HTTP response code and message
   status = "200 OK"
 
   # 應(yīng)答的頭部是一個(gè)列表，每對(duì)鍵值都必須是一個(gè) tuple。
   response_headers = [("Content-Type", "text/plain"),
                       ("Content-Length", str(len(response_body)))]
 
   # 調(diào)用服務(wù)器程序提供的 start_response，填入兩個(gè)參數(shù)
   start_response(status, response_headers)
 
   # 返回必須是 iterable
   return [response_body]    
   
# 2. 可調(diào)用對(duì)象是一個(gè)類
class AppClass:
    """這里的可調(diào)用對(duì)象就是 AppClass 這個(gè)類，調(diào)用它就能生成可以迭代的結(jié)果。
        使用方法類似于： 
        for result in AppClass(env, start_response):
             do_somthing(result)
    """
 
    def __init__(self, environ, start_response):
        self.environ = environ
        self.start = start_response
 
    def __iter__(self):
        status = "200 OK"
        response_headers = [("Content-type", "text/plain")]
        self.start(status, response_headers)
        yield "Hello world!
"
 
# 3. 可調(diào)用對(duì)象是一個(gè)實(shí)例 
class AppClass:
    """這里的可調(diào)用對(duì)象就是 AppClass 的實(shí)例，使用方法類似于： 
        app = AppClass()
        for result in app(environ, start_response):
             do_somthing(result)
    """
 
    def __init__(self):
        pass
 
    def __call__(self, environ, start_response):
        status = "200 OK"
        response_headers = [("Content-type", "text/plain")]
        self.start(status, response_headers)
        yield "Hello world!
"

服務(wù)器程序端

上面已經(jīng)說(shuō)過(guò)，標(biāo)準(zhǔn)要能夠確切地實(shí)行，必須要求程序端和服務(wù)器端共同遵守。上面提到， envrion 和 start_response 都是服務(wù)器端提供的。下面就看看，服務(wù)器端要履行的義務(wù)。

準(zhǔn)備 environ 參數(shù)
定義 start_response 函數(shù)
調(diào)用程序端的可調(diào)用對(duì)象

import os, sys
 
def run_with_cgi(application):    # application 是程序端的可調(diào)用對(duì)象
    # 準(zhǔn)備 environ 參數(shù)，這是一個(gè)字典，里面的內(nèi)容是一次 HTTP 請(qǐng)求的環(huán)境變量
    environ = dict(os.environ.items())
    environ["wsgi.input"]        = sys.stdin
    environ["wsgi.errors"]       = sys.stderr
    environ["wsgi.version"]      = (1, 0)
    environ["wsgi.multithread"]  = False
    environ["wsgi.multiprocess"] = True
    environ["wsgi.run_once"]     = True            
    environ["wsgi.url_scheme"] = "http"
 
    headers_set = []
    headers_sent = []
 
    # 把應(yīng)答的結(jié)果輸出到終端
    def write(data):
        sys.stdout.write(data)
        sys.stdout.flush()
 
    # 實(shí)現(xiàn) start_response 函數(shù)，根據(jù)程序端傳過(guò)來(lái)的 status 和 response_headers 參數(shù)，
    # 設(shè)置狀態(tài)和頭部
    def start_response(status, response_headers, exc_info=None):
        headers_set[:] = [status, response_headers]
          return write
 
    # 調(diào)用客戶端的可調(diào)用對(duì)象，把準(zhǔn)備好的參數(shù)傳遞過(guò)去
    result = application(environ, start_response)
    
    # 處理得到的結(jié)果，這里簡(jiǎn)單地把結(jié)果輸出到標(biāo)準(zhǔn)輸出。
    try:
        for data in result:
            if data:    # don"t send headers until body appears
                write(data)
    finally:
        if hasattr(result, "close"):
            result.close()

下面我們以django為例，分析一下wsgi的整個(gè)流程

WSGI application應(yīng)該實(shí)現(xiàn)為一個(gè)可調(diào)用iter對(duì)象，例如函數(shù)、方法、類(包含**call**方法)。需要接收兩個(gè)參數(shù)：一個(gè)字典，該字典可以包含了客戶端請(qǐng)求的信息以及其他信息，可以認(rèn)為是請(qǐng)求上下文，一般叫做environment（編碼中多簡(jiǎn)寫為environ、env），一個(gè)用于發(fā)送HTTP響應(yīng)狀態(tài)（HTTP status）、響應(yīng)頭（HTTP headers）的回調(diào)函數(shù),也就是start_response()。通過(guò)回調(diào)函數(shù)將響應(yīng)狀態(tài)和響應(yīng)頭返回給server，同時(shí)返回響應(yīng)正文(response body)，響應(yīng)正文是可迭代的、并包含了多個(gè)字符串。
下面是Django中application的具體實(shí)現(xiàn)部分：

class WSGIHandler(base.BaseHandler): 
   initLock = Lock() 
   request_class = WSGIRequest 
   def __call__(self, environ, start_response): 
   # 加載中間件 
    if self._request_middleware is None: 
         with self.initLock: 
             try: # Check that middleware is still uninitialized. 
                 if self._request_middleware is None: 
                    self.load_middleware() 
             except: # Unload whatever middleware we got 
                    self._request_middleware = None raise          
     set_script_prefix(get_script_name(environ)) # 請(qǐng)求處理之前發(fā)送信號(hào)   
     signals.request_started.send(sender=self.__class__, environ=environ) 
     try: 
          request = self.request_class(environ)  
     except UnicodeDecodeError: 
           logger.warning("Bad Request (UnicodeDecodeError)",exc_info=sys.exc_info(), extra={"status_code": 400,}
           response = http.HttpResponseBadRequest() 
     else: 
           response = self.get_response(request) 
     response._handler_class = self.__class__ status = "%s %s" % (response.status_code, response.reason_phrase) 
     response_headers = [(str(k), str(v)) for k, v in response.items()] for c in response.cookies.values(): response_headers.append((str("Set-Cookie"), str(c.output(header="")))) 
     # server提供的回調(diào)方法，將響應(yīng)的header和status返回給server     
     start_response(force_str(status), response_headers) 
     if getattr(response, "file_to_stream", None) is not None and environ.get("wsgi.file_wrapper"): 
          response = environ["wsgi.file_wrapper"](response.file_to_stream) 
     return response

可以看出application的流程包括:加載所有中間件，以及執(zhí)行框架相關(guān)的操作，設(shè)置當(dāng)前線程腳本前綴，發(fā)送請(qǐng)求開始信號(hào)；處理請(qǐng)求，調(diào)用get_response()方法處理當(dāng)前請(qǐng)求，該方法的的主要邏輯是通過(guò)urlconf找到對(duì)應(yīng)的view和callback，按順序執(zhí)行各種middleware和callback。調(diào)用由server傳入的start_response()方法將響應(yīng)header與status返回給server。返回響應(yīng)正文

負(fù)責(zé)獲取http請(qǐng)求，將請(qǐng)求傳遞給WSGI application，由application處理請(qǐng)求后返回response。以Django內(nèi)建server為例看一下具體實(shí)現(xiàn)。通過(guò)runserver運(yùn)行django
項(xiàng)目，在啟動(dòng)時(shí)都會(huì)調(diào)用下面的run方法，創(chuàng)建一個(gè)WSGIServer的實(shí)例，之后再調(diào)用其serve_forever()方法啟動(dòng)服務(wù)。

def run(addr, port, wsgi_handler, ipv6=False, threading=False): 
   server_address = (addr, port) 
   if threading: 
        httpd_cls = type(str("WSGIServer"), (socketserver.ThreadingMixIn, WSGIServer), {}) 
   else: 
        httpd_cls = WSGIServer # 這里的wsgi_handler就是WSGIApplication 
   httpd = httpd_cls(server_address, WSGIRequestHandler, ipv6=ipv6) 
    if threading: 
        httpd.daemon_threads = True httpd.set_app(wsgi_handler)    
     httpd.serve_forever()

下面表示W(wǎng)SGI server服務(wù)器處理流程中關(guān)鍵的類和方法。

WSGIServerrun()方法會(huì)創(chuàng)建WSGIServer實(shí)例，主要作用是接收客戶端請(qǐng)求，將請(qǐng)求傳遞給application，然后將application返回的response返回給客戶端。
創(chuàng)建實(shí)例時(shí)會(huì)指定HTTP請(qǐng)求的handler：WSGIRequestHandler類
通過(guò)set_app和get_app方法設(shè)置和獲取WSGIApplication實(shí)例wsgi_handler
處理http請(qǐng)求時(shí)，調(diào)用handler_request方法，會(huì)創(chuàng)建WSGIRequestHandler
實(shí)例處理http請(qǐng)求。
WSGIServer中get_request方法通過(guò)socket接受請(qǐng)求數(shù)據(jù)

WSGIRequestHandler由WSGIServer在調(diào)用handle_request時(shí)創(chuàng)建實(shí)例，傳入request、cient_address、WSGIServer三個(gè)參數(shù)，__init__方法在實(shí)例化同時(shí)還會(huì)調(diào)用自身的handle方法handle方法會(huì)創(chuàng)建ServerHandler實(shí)例，然后調(diào)用其run方法處理請(qǐng)求

ServerHandlerWSGIRequestHandler在其handle方法中調(diào)用run方法，傳入self.server.get_app()參數(shù)，獲取WSGIApplication，然后調(diào)用實(shí)例(__call__
)，獲取response，其中會(huì)傳入start_response回調(diào)，用來(lái)處理返回的header和status。通過(guò)application獲取response以后，通過(guò)finish_response返回response

WSGIHandlerWSGI協(xié)議中的application，接收兩個(gè)參數(shù)，environ字典包含了客戶端請(qǐng)求的信息以及其他信息，可以認(rèn)為是請(qǐng)求上下文，start_response用于發(fā)送返回status和header的回調(diào)函數(shù)

雖然上面一個(gè)WSGI server涉及到多個(gè)類實(shí)現(xiàn)以及相互引用，但其實(shí)原理還是調(diào)用WSGIHandler，傳入請(qǐng)求參數(shù)以及回調(diào)方法start_response()，并將響應(yīng)返回給客戶端。

因?yàn)槊總€(gè)web框架都不是專注于實(shí)現(xiàn)服務(wù)器方面的，因此，在生產(chǎn)環(huán)境部署的時(shí)候使用的服務(wù)器也不會(huì)簡(jiǎn)單的使用web框架自帶的服務(wù)器，這里，我們來(lái)討論一下用于生產(chǎn)環(huán)境的服務(wù)器有哪些？

1.
gunicorn

Gunicorn（從Ruby下面的Unicorn得到的啟發(fā)）應(yīng)運(yùn)而生：依賴Nginx的代理行為，同Nginx進(jìn)行功能上的分離。由于不需要直接處理用戶來(lái)的請(qǐng)求（都被Nginx先處理），Gunicorn不需要完成相關(guān)的功能，其內(nèi)部邏輯非常簡(jiǎn)單：接受從Nginx來(lái)的動(dòng)態(tài)請(qǐng)求，處理完之后返回給Nginx，由后者返回給用戶。

由于功能定位很明確，Gunicorn得以用純Python開發(fā)：大大縮短了開發(fā)時(shí)間的同時(shí)，性能上也不會(huì)很掉鏈子。同時(shí)，它也可以配合Nginx的代理之外的別的Proxy模塊工作，其配置也相應(yīng)比較簡(jiǎn)單。

配置上的簡(jiǎn)單，大概是它流行的最大的原因。

2.

uwsgi
因?yàn)槭褂肅語(yǔ)言開發(fā)，會(huì)和底層接觸的更好，配置也是比較方便，目前和gunicorn兩個(gè)算是部署時(shí)的唯二之選。
以下是通常的配置文件

[uwsgi]
http = $(HOSTNAME):9033
http-keepalive = 1
pythonpath = ../
module = service
master = 1
processes = 8
daemonize = logs/uwsgi.log
disable-logging = 1
buffer-size = 16384
harakiri = 5
pidfile = uwsgi.pid
stats = $(HOSTNAME):1733


運(yùn)行：uwsgi --ini   conf.ini

3.

fcgi
不多數(shù)，估計(jì)使用的人也是比較少，這里只是提一下

4.

bjoern
Python WSGI界最牛逼性能的Server其中一個(gè)是bjoern，純C，小于1000行代碼，就是看不慣uWSGI的冗余自寫的。

綜合廣大Python開發(fā)者的實(shí)際經(jīng)歷，我們可以得出，使用最廣的當(dāng)屬uWSGI以及gunicorn，我們這里來(lái)比較比較兩者與其他服務(wù)器的區(qū)別。
1.gunicorn本身是個(gè)多進(jìn)程管理器，需要指定相關(guān)的不同類型的worker去工作，使用gevent作為worker時(shí)單機(jī)大概是3000RPS Hello World，勝過(guò)torando自帶的服務(wù)器大概是2000左右，uWSGI則會(huì)更高一點(diǎn)。
2.相比于tornado對(duì)于現(xiàn)有代碼需要大規(guī)模重構(gòu)才能用上高級(jí)特性，Gevent只需要一個(gè)monkey，容易對(duì)代碼進(jìn)行快速加工。
3.gunicorn 可以做 pre hook and post hook.

下面來(lái)對(duì)比以下uWSGI和gunicorn的速度差比

可以看到，如果單純追求性能，那uWSGI會(huì)更好一點(diǎn)，而gunicorn則會(huì)更易安裝和結(jié)合gevent。

結(jié)合這篇文章,我們也可以得出相同結(jié)論，在阻塞響應(yīng)較多的情況下，gunicorn的gevent模式無(wú)疑性能會(huì)更加強(qiáng)大。

功能實(shí)現(xiàn)方面，無(wú)疑uWSGI會(huì)更多一些，配置也會(huì)更加復(fù)雜一些，可以看看uWSGI的配置和gunicorn的配置

至于怎么去選擇，就看大家的項(xiàng)目結(jié)構(gòu)怎么樣了。

最后，宣傳一下我們的開源組織，PSC開源組，希望以開源項(xiàng)目的方式讓每個(gè)人都能更有融入性的去學(xué)習(xí)，公開化你的學(xué)習(xí)。
github地址：https://github.com/PythonScie...
官方論壇：http://www.pythonscientists.com