當你開始著手部署應用時，最簡單的方式莫過于使用管理員身份重啟my_app或者所有服務，使產品升級至當前版本。開始的時候一切都很好，但是最終你會發現一旦應用啟動以后，在重啟期間去嘗試連接會得到眾多HTTP 503 錯誤。

最后你可能發現Gunicorn和uWSGI可以在不關閉套接字的情況下重新加載你的應用，這樣在你的應用啟動時，網絡請求僅僅是被延時了一點點。只要你的應用不會花費很長時間在啟動上，它就會工作的很好。不幸的是，現有的許多應用可能會花費1分鐘的時間在啟動上，對于等待在套接字上的鏈接來說，這太長了。

Gunicorn使用kill -HUP $PID,通過關閉所有工作進程，然后再啟動它們來重新加載。但是工作進程緩慢的初始化過程往往會導致問題的產生。uWSGI使用鏈式重載，它每次只會啟動一個工作進程。我需要對Tornado的支持，它當前并不十分適合uWSGI。

使用負載均衡器

一種常見的技術是從負載均衡器中移除單個服務器，升級/重啟應用，然后再把它加載回來。我們正在使用負載均衡器，但是為了調度整個過程，在配置節點的時候需要協調使用HAProxy來管理套接字。我們當前的部署方案是同時部署到所有節點，而不是一個接一個的來，一個相當大的變化。在等待LBs（譯注：負載均衡器）將節點移出池期間，可以使用404'ing狀態頁來欺騙healthcheck。這比我想要的時間要多一點，對于每個服務器來說，兩次healthcheck失敗間隔5秒鐘，這包括了升級完成后web進程恢復的時間。

Gunicorn 重載 ++

Gunicorn會自動重啟失敗的web進程，所以它可能會殺掉每個進程，在其間休眠，直到所有的子進程執行完畢。這很有效，不過如果應用啟動的次數變動顯著的話，我們要么會為重啟等待過長時間，要么會等待不長的時間并承擔一些故障宕機的風險。

因為Gunicorn包含了指向應用的Python鉤子，所以完全可能寫出一小段代碼，在工作進程準備就緒的時候通知重啟進程。Gunicorn并不包含需要的鉤子，但做出改變非常簡單。在新版本發布前它需要一些修改。

現在重啟進程發揮了這樣的事實優勢，就是說單個的soket具有接受連接的多個進程。重啟只會極微弱的減少服務能力（1/N），但我們因此可以繼續處理流量而無需讓連接等待過長時間。

這種進程一般是這樣的
 

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

我的第一個版本使用shell和nc來監聽應用啟動的UDP數據包。盡管將我們的進程管理器集成到shell環境比我預想的要麻煩一點，但它工作的很好。

重啟腳本被調用的時候應該帶上Gunicorn的PID，就是masterrestart.sh的 $PID