?當(dāng)你開(kāi)始著手部署應(yīng)用時(shí)，最簡(jiǎn)單的方式莫過(guò)于使用管理員身份重啟my_app或者所有服務(wù)，使產(chǎn)品升級(jí)至當(dāng)前版本。開(kāi)始的時(shí)候一切都很好，但是最終你會(huì)發(fā)現(xiàn)一旦應(yīng)用啟動(dòng)以后，在重啟期間去嘗試連接會(huì)得到眾多HTTP 503 錯(cuò)誤。

最后你可能發(fā)現(xiàn)Gunicorn和uWSGI可以在不關(guān)閉套接字的情況下重新加載你的應(yīng)用，這樣在你的應(yīng)用啟動(dòng)時(shí)，網(wǎng)絡(luò)請(qǐng)求僅僅是被延時(shí)了一點(diǎn)點(diǎn)。只要你的應(yīng)用不會(huì)花費(fèi)很長(zhǎng)時(shí)間在啟動(dòng)上，它就會(huì)工作的很好。不幸的是，現(xiàn)有的許多應(yīng)用可能會(huì)花費(fèi)1分鐘的時(shí)間在啟動(dòng)上，對(duì)于等待在套接字上的鏈接來(lái)說(shuō)，這太長(zhǎng)了。

Gunicorn使用kill -HUP $PID,通過(guò)關(guān)閉所有工作進(jìn)程，然后再啟動(dòng)它們來(lái)重新加載。但是工作進(jìn)程緩慢的初始化過(guò)程往往會(huì)導(dǎo)致問(wèn)題的產(chǎn)生。uWSGI使用鏈?zhǔn)街剌d，它每次只會(huì)啟動(dòng)一個(gè)工作進(jìn)程。我需要對(duì)Tornado的支持，它當(dāng)前并不十分適合uWSGI。

使用負(fù)載均衡器

一種常見(jiàn)的技術(shù)是從負(fù)載均衡器中移除單個(gè)服務(wù)器，升級(jí)/重啟應(yīng)用，然后再把它加載回來(lái)。我們正在使用負(fù)載均衡器，但是為了調(diào)度整個(gè)過(guò)程，在配置節(jié)點(diǎn)的時(shí)候需要協(xié)調(diào)使用HAProxy來(lái)管理套接字。我們當(dāng)前的部署方案是同時(shí)部署到所有節(jié)點(diǎn)，而不是一個(gè)接一個(gè)的來(lái)，一個(gè)相當(dāng)大的變化。在等待LBs（譯注：負(fù)載均衡器）將節(jié)點(diǎn)移出池期間，可以使用404'ing狀態(tài)頁(yè)來(lái)欺騙healthcheck。這比我想要的時(shí)間要多一點(diǎn)，對(duì)于每個(gè)服務(wù)器來(lái)說(shuō)，兩次healthcheck失敗間隔5秒鐘，這包括了升級(jí)完成后web進(jìn)程恢復(fù)的時(shí)間。

Gunicorn 重載 ++

Gunicorn會(huì)自動(dòng)重啟失敗的web進(jìn)程，所以它可能會(huì)殺掉每個(gè)進(jìn)程，在其間休眠，直到所有的子進(jìn)程執(zhí)行完畢。這很有效，不過(guò)如果應(yīng)用啟動(dòng)的次數(shù)變動(dòng)顯著的話，我們要么會(huì)為重啟等待過(guò)長(zhǎng)時(shí)間，要么會(huì)等待不長(zhǎng)的時(shí)間并承擔(dān)一些故障宕機(jī)的風(fēng)險(xiǎn)。

因?yàn)镚unicorn包含了指向應(yīng)用的Python鉤子，所以完全可能寫(xiě)出一小段代碼，在工作進(jìn)程準(zhǔn)備就緒的時(shí)候通知重啟進(jìn)程。Gunicorn并不包含需要的鉤子，但做出改變非常簡(jiǎn)單。在新版本發(fā)布前它需要一些修改。

現(xiàn)在重啟進(jìn)程發(fā)揮了這樣的事實(shí)優(yōu)勢(shì)，就是說(shuō)單個(gè)的soket具有接受連接的多個(gè)進(jìn)程。重啟只會(huì)極微弱的減少服務(wù)能力（1/N），但我們因此可以繼續(xù)處理流量而無(wú)需讓連接等待過(guò)長(zhǎng)時(shí)間。

這種進(jìn)程一般是這樣的
?

            
for child_pid of gunicorn-master:
 kill child_pid
 wait for app startup

          

我的第一個(gè)版本使用shell和nc來(lái)監(jiān)聽(tīng)?wèi)?yīng)用啟動(dòng)的UDP數(shù)據(jù)包。盡管將我們的進(jìn)程管理器集成到shell環(huán)境比我預(yù)想的要麻煩一點(diǎn)，但它工作的很好。

重啟腳本被調(diào)用的時(shí)候應(yīng)該帶上Gunicorn的PID，就是masterrestart.sh的 $PID
?

            
echo 'Killing children of ' $1;
 
children=$(pgrep -P $1)
for child in $children
do
 echo 'Killing' $child
 kill $child
 response=$(timeout 60 nc -w 0 -ul 4012)
 if [ "$response" != '200 OK' ]; then
  echo 'BROKEN'
  exit 1;
 fi
done

          

在串聯(lián)上post_worker_init腳本，以便app運(yùn)行的時(shí)候通知重啟腳本。
?

            
import socket
import time
 
def post_worker_init(worker):
 _send_udp('200 OK\n')
 
def _send_udp(message):
 
 udp_ip = "127.0.0.1"
 udp_port = 4012
 
 sock = socket.socket(socket.AF_INET, # Internet
       socket.SOCK_DGRAM) # UDP
 sock.sendto(message, (udp_ip, udp_port))
如果我們有這樣一個(gè)WSGI（ Python Web Server Gateway Interface）應(yīng)用:
 
from werkzeug.wrappers import Request, Response
 
@Request.application
def application(request):
 resp = Response('Hello World!')
 if request.path == '/_status':
  resp.status = '200 OK'
 else:
  resp.status ='404 Not Found'
 return resp

          

我們甚至可以去做檢查/_status頁(yè)面之類的事情，以此來(lái)驗(yàn)證應(yīng)用是否已運(yùn)行。
?

            
def post_worker_init(worker):
 env = {
  'REQUEST_METHOD': 'GET',
  'PATH_INFO': '/_status',
 }
 def start_response(*args, **kwargs):
  _send_udp(args[0])
 
 worker.wsgi(env, start_response)

          

注意不要試圖在這個(gè)健康檢測(cè)中運(yùn)行太多的應(yīng)用，如果不管什么原因你的post_worker_init產(chǎn)生了一個(gè)錯(cuò)誤，那么工作進(jìn)程將會(huì)退出，并阻止應(yīng)用的啟動(dòng)。在你檢查可能失效的DB鏈接的時(shí)候這會(huì)是一個(gè)問(wèn)題，即使你的應(yīng)用可以工作，它也無(wú)法再次啟動(dòng)。

現(xiàn)在通過(guò)一分鐘的應(yīng)用啟動(dòng)，我們實(shí)現(xiàn)了滾動(dòng)重啟，而無(wú)需停止應(yīng)用或者丟棄任何鏈接！