gunicorn工作原理

Gunicorn“綠色獨角獸”是一個被廣泛使用的高性能的Python WSGI UNIX HTTP服務(wù)器，移植自Ruby的獨角獸（Unicorn ）項目,使用pre-fork worker模式，具有使用非常簡單，輕量級的資源消耗，以及高性能等特點。

Gunicorn 服務(wù)器作為wsgi app的容器，能夠與各種Web框架兼容（flask，django等）,得益于gevent等技術(shù)，使用Gunicorn能夠在基本不改變wsgi app代碼的前提下，大幅度提高wsgi app的性能。

總體結(jié)構(gòu)

gunicorn pre-fork worker模型中有一個管理進(jìn)程以及幾個的工作進(jìn)程。管理進(jìn)程:master，工作進(jìn)程:worker。（以下代碼中為了方面理解，均去除了一些干擾代碼）

master通過pre-fork的方式創(chuàng)建多個worker:

def spawn_worker(self):
    self.worker_age += 1
    #創(chuàng)建worker。請注意這里的app 對象并不是真正的wsgi app對象，而是gunicorn的app
    #對象。gunicorn的app對象負(fù)責(zé)import我們自己寫的wsgi app對象。
    worker = self.worker_class(self.worker_age, self.pid, self.LISTENERS,
                                self.app, self.timeout / 2.0,
                                self.cfg, self.log) 
    pid = os.fork()
    if pid != 0:  #父進(jìn)程，返回后繼續(xù)創(chuàng)建其他worker，沒worker后進(jìn)入到自己的消息循環(huán)
        self.WORKERS[pid] = worker
        return pid
 
    # Process Child
    worker_pid = os.getpid()
    try:
        ..........
        worker.init_process() #子進(jìn)程，初始化woker，進(jìn)入worker的消息循環(huán)，
        sys.exit(0)
    except SystemExit:
        raise

在worker.init_process()函數(shù)中，worker中g(shù)unicorn的app對象會去import 我們的wsgi app。也就是說，每個woker子進(jìn)程都會單獨去實例化我們的wsgi app對象。每個worker中的swgi app對象是相互獨立、互不干擾的。

manager維護(hù)數(shù)量固定的worker：

def manage_workers(self):
        if len(self.WORKERS.keys()) < self.num_workers:
            self.spawn_workers()
        while len(workers) > self.num_workers:
            (pid, _) = workers.pop(0)
            self.kill_worker(pid, signal.SIGQUIT)

創(chuàng)建完所有的worker后，worker和master各自進(jìn)入自己的消息循環(huán)。
master的事件循環(huán)就是收收信號，管理管理worker進(jìn)程，而worker進(jìn)程的事件循環(huán)就是監(jiān)聽網(wǎng)絡(luò)事件并處理（如新建連接，斷開連接，處理請求發(fā)送響應(yīng)等等），所以真正的連接最終是連到了worker進(jìn)程上的。（注：有關(guān)這種多進(jìn)程模型的詳細(xì)介紹，可以參考http://blog.csdn.net/largetalk/article/details/7939080）

worker

woker有很多種，包括：ggevent、geventlet、gtornado等等。這里主要分析ggevent。

每個ggevent worker啟動的時候會啟動多個server對象：worker首先為每個listener創(chuàng)建一個server對象（注：為什么是一組listener,因為gunicorn可以綁定一組地址,每個地址對于一個listener），每個server對象都有運行在一個單獨的gevent pool對象中。真正等待鏈接和處理鏈接的操作是在server對象中進(jìn)行的。

#為每個listener創(chuàng)建server對象。
    for s in self.sockets:
        pool = Pool(self.worker_connections) #創(chuàng)建gevent pool
        if self.server_class is not None:
           #創(chuàng)建server對象
            server = self.server_class(  
                s, application=self.wsgi, spawn=pool, log=self.log,
                handler_class=self.wsgi_handler, **ssl_args)
        .............
        server.start() #啟動server，開始等待鏈接，服務(wù)鏈接
        servers.append(server)

上面代碼中的server_class實際上是一個gevent的WSGI SERVER的子類：

class PyWSGIServer(pywsgi.WSGIServer):
    base_env = BASE_WSGI_ENV

需要注意的是構(gòu)造PyWSGIServer的參數(shù)：

self.server_class(
                s, application=self.wsgi, spawn=pool, log=self.log,
                handler_class=self.wsgi_handler, **ssl_args)

這些參數(shù)中s是server用來監(jiān)聽鏈接的套接字。spawn是gevent的協(xié)程池。application即是我們的wsgi app（通俗點講就是你用 flask 或者 django寫成的app），我們的app就是通過這種方式交給gunicorn的woker去跑的。 handler_class是gevent的pywsgi.WSGIHandler子類。

當(dāng)所有server對象創(chuàng)建完畢后，worker需要定時通知manager，否則會被認(rèn)為是掛掉了。

while self.alive:
            self.notify()
            .......

這個地方的notify機(jī)制設(shè)計的比較有趣，每個worker有個與之對應(yīng)的tmp file，每次notify的時候去操作一下這個tmp file（比如通過os.fchmod），這個tmp file的last update的時間戳就會更新。而manager則通過檢查每個worker對應(yīng)的temp file的last update的時間戳，來判斷這個進(jìn)程是否是掛掉的。

WSGI SERVER

真正等待鏈接和處理鏈接的操作是在gevent的WSGIServer 和 WSGIHandler中進(jìn)行的。
最后再來看一下gevent的WSGIServer 和 WSGIHandler的主要實現(xiàn):

WSGIServer 的start函數(shù)里面調(diào)用start_accepting來處理到來的鏈接。在start_accepting里面得到接收到的套接字后調(diào)用do_handle來處理套接字：

def do_handle(self, *args):
    spawn = self._spawn
    spawn(self._handle, *args)

可以看出，WSGIServer 實際上是創(chuàng)建一個協(xié)程去處理該套接字，也就是說在WSGIServer 中，一個協(xié)程單獨負(fù)責(zé)一個HTTP鏈接。協(xié)程中運行的self._handle函數(shù)實際上是調(diào)用了WSGIHandler的handle函數(shù)來不斷處理http 請求：

def handle(self):
    try:
        while self.socket is not None:
            result = self.handle_one_request()#處理HTTP請求
            if result is None:
                break
            if result is True:
                continue
            self.status, response_body = result
            self.socket.sendall(response_body)#發(fā)送回應(yīng)報文
          ..............

在handle函數(shù)的循環(huán)內(nèi)部，handle_one_request函數(shù)首先讀取HTTP 請求，初始化WSGI環(huán)境，然后最終調(diào)用run_application函數(shù)來處理請求：

def run_application(self):
    self.result = self.application(self.environ, self.start_response)
    self.process_result()

在這個地方才真正的調(diào)用了我們的 app。

總結(jié)：gunicorn 會啟動一組 worker進(jìn)程，所有worker進(jìn)程公用一組listener，在每個worker中為每個listener建立一個wsgi server。每當(dāng)有HTTP鏈接到來時，wsgi server創(chuàng)建一個協(xié)程來處理該鏈接，協(xié)程處理該鏈接的時候，先初始化WSGI環(huán)境，然后調(diào)用用戶提供的app對象去處理HTTP請求。
轉(zhuǎn)自：https://blog.csdn.net/jailman/article/details/78496522