Flask 應(yīng)用跑起來之后第一件事往往不是寫業(yè)務(wù)代碼而是把啟動(dòng)方式從python app.py換成一臺(tái)真正能扛請(qǐng)求的服務(wù)器。身邊好幾個(gè)同事第一次部署 Flask 項(xiàng)目時(shí)都問過我同一個(gè)問題Flask 不是自帶服務(wù)器嗎為什么還要折騰 Waitress這篇文章就把這個(gè)問題從頭到尾講明白——Waitress 是什么、解決了什么問題、怎么接進(jìn) Flask 項(xiàng)目、參數(shù)怎么調(diào)以及我實(shí)際部署過程中踩過的那些坑。如果你正準(zhǔn)備把 Flask 應(yīng)用從開發(fā)環(huán)境搬到服務(wù)器上這篇分享能幫你省不少試錯(cuò)時(shí)間。1. 為什么 Flask 應(yīng)用需要一個(gè)真正的服務(wù)器1.1 開發(fā)服務(wù)器和你的誤區(qū)Flask 默認(rèn)啟動(dòng)時(shí)跑的那個(gè)服務(wù)器其實(shí)是 Werkzeug 提供的一個(gè)開發(fā)調(diào)試服務(wù)器。它不是給你上線用的。你執(zhí)行python app.py的時(shí)候Flask 會(huì)打印一行提醒告訴你這個(gè)服務(wù)器僅用于開發(fā)環(huán)境。很多人沒當(dāng)回事直到某個(gè)活動(dòng)頁面訪問量稍微上來一點(diǎn)頁面就開始轉(zhuǎn)圈、請(qǐng)求排隊(duì)、甚至直接假死才回頭研究這一行的含義。Werkzeug 開發(fā)服務(wù)器的設(shè)計(jì)目標(biāo)很明確讓本地調(diào)試時(shí)能拿到清晰的報(bào)錯(cuò)堆棧支持代碼改動(dòng)后自動(dòng)重載方便你邊改邊測(cè)。它根本沒有考慮并發(fā)優(yōu)化、連接管理、超時(shí)控制這些生產(chǎn)環(huán)境必須面對(duì)的問題。它是單進(jìn)程單線程地處理請(qǐng)求遇到耗時(shí)的數(shù)據(jù)庫操作或第三方接口調(diào)用整個(gè)服務(wù)都會(huì)被拖住。一次慢請(qǐng)求就可能堵住后面所有請(qǐng)求這在生產(chǎn)環(huán)境是災(zāi)難。所以我在項(xiàng)目部署時(shí)有一個(gè)默認(rèn)原則任何 Flask 應(yīng)用只要是從開發(fā)機(jī)遷出來、要讓別人訪問一律換掉自帶服務(wù)器換成生產(chǎn)級(jí)的 WSGI 服務(wù)器。這個(gè)原則背后是很簡(jiǎn)單的邏輯——Flask 本身只是一個(gè) WSGI 應(yīng)用框架它負(fù)責(zé)處理路由、視圖、業(yè)務(wù)邏輯但不負(fù)責(zé)高效地接收和分發(fā)網(wǎng)絡(luò)請(qǐng)求。服務(wù)器和框架各司其職用對(duì)了組合才不會(huì)出問題。1.2 WSGI 協(xié)議到底在干什么這里需要先理解一個(gè)概念WSGI。它是 Python Web 應(yīng)用和 Web 服務(wù)器之間的一套標(biāo)準(zhǔn)接口。說白了它定義了兩頭怎么說話服務(wù)器那頭接收 HTTP 請(qǐng)求然后把請(qǐng)求內(nèi)容重整成一個(gè)環(huán)境字典交給應(yīng)用應(yīng)用處理完之后把響應(yīng)內(nèi)容返回給服務(wù)器再由服務(wù)器發(fā)回給客戶端。Flask 應(yīng)用本質(zhì)上是一個(gè)符合 WSGI 規(guī)范的調(diào)用對(duì)象。只要服務(wù)器實(shí)現(xiàn)了 WSGI 協(xié)議就能直接驅(qū)動(dòng) Flask 應(yīng)用。Waitress 做的就是這件事它是一個(gè)純 Python 實(shí)現(xiàn)的、生產(chǎn)級(jí)的、跨平臺(tái)的 WSGI 服務(wù)器專門用來裝載 Flask、Django 這類 WSGI 應(yīng)用。用生活類比來理解Flask 應(yīng)用是餐廳的大廚負(fù)責(zé)炒菜Waitress 是前廳服務(wù)員負(fù)責(zé)接單、傳菜、協(xié)調(diào)流程。沒有服務(wù)員客人一多大廚就得自己跑前跑后很快就亂了。你之前就是一直讓大廚兼職服務(wù)員現(xiàn)在只不過是把服務(wù)員請(qǐng)回來而已。2. 選型為什么選 Waitress而不是其他服務(wù)器2.1 和 Gunicorn 的關(guān)鍵差異國(guó)內(nèi)論壇上討論 Python 部署很多人第一反應(yīng)是 Gunicorn。我也用 Gunicorn 部署過不少項(xiàng)目它確實(shí)成熟穩(wěn)定但它有一個(gè)先天的平臺(tái)限制Unix-only不支持 Windows。如果你手里的服務(wù)器是 Windows Server或者團(tuán)隊(duì)同事用的是 Windows 開發(fā)機(jī)需要本地聯(lián)調(diào)Gunicorn 直接就沒法用。Waitress 是跨平臺(tái)的Windows、Linux、macOS 都可以跑而且安裝方式非常簡(jiǎn)單pip install waitress就能搞定沒有任何 C 擴(kuò)展和編譯依賴。這一點(diǎn)在初學(xué)者和中小團(tuán)隊(duì)場(chǎng)景里特別重要少一個(gè)環(huán)境變量出錯(cuò)的可能性就少一個(gè)半夜排查事故的理由。如果你在 Linux 上部署Gunicorn 和 Waitress 都可以選。但如果追求省心、跨平臺(tái)、不折騰或者你用的是 Windows 服務(wù)器Waitress 幾乎是唯一合理的選擇。有時(shí)候選型不是比誰更高級(jí)而是比誰更匹配你當(dāng)前的運(yùn)行環(huán)境。2.2 多線程模型背后的設(shè)計(jì)邏輯Waitress 采用多線程模型。你可以把它理解為主線程專門負(fù)責(zé)接收連接、分發(fā)任務(wù)然后由一組工作線程池來處理請(qǐng)求。每個(gè)請(qǐng)求在屬于自己的線程里執(zhí)行線程完成任務(wù)后回到池子里等待下一個(gè)請(qǐng)求。這種模型的好處是簡(jiǎn)單、穩(wěn)定、符合直覺不需要像異步編程那樣把代碼拆成各種回調(diào)。這個(gè)設(shè)計(jì)對(duì) Flask 應(yīng)用來說是比較友好的。大多數(shù) Flask 項(xiàng)目屬于 IO 密集型場(chǎng)景比如查詢數(shù)據(jù)庫、讀寫緩存、調(diào)用外部 API真正的 CPU 計(jì)算時(shí)間占比很小。多線程模型讓這些等待操作不互相堵塞幾十上百個(gè)線程同時(shí)處理各自請(qǐng)求完全能扛住日常業(yè)務(wù)壓力。相比之下異步服務(wù)器對(duì)代碼寫法有要求異步視圖、異步數(shù)據(jù)庫驅(qū)動(dòng)都要配套很多 Flask 項(xiàng)目一開始根本不會(huì)這么寫。Waitress 的這種調(diào)整熱度也體現(xiàn)在它能處理 keep-alive 連接、支持 chunked 請(qǐng)求體、自動(dòng)處理 HTTP 協(xié)議的邊緣情況這些都是開發(fā)服務(wù)器不 care 的細(xì)節(jié)。它把協(xié)議層面的臟活累活都包掉了讓你只需要關(guān)注業(yè)務(wù)邏輯。這就是生產(chǎn)服務(wù)器的價(jià)值。3. 實(shí)操過程安裝、接入與啟動(dòng)3.1 最小化接入三行代碼搞定接入 Waitress 真的不需要大改項(xiàng)目。唯一的改動(dòng)就是啟動(dòng)入口。正常 Flask 項(xiàng)目里通常會(huì)有一個(gè)入口文件比如myapp.py里面長(zhǎng)這樣from flask import Flask app Flask(__name__) app.route(/) def index(): return hello waitress原來的啟動(dòng)方式是if __name__ __main__: app.run(host0.0.0.0, port8000)換成 Waitress 之后你只需要在同一個(gè)入口文件里改成from waitress import serve if __name__ __main__: serve(app, host0.0.0.0, port8000, threads8)先安裝依賴pip install waitress然后直接運(yùn)行python myapp.py就這么簡(jiǎn)單你的 Flask 應(yīng)用就跑在了 Waitress 上。用瀏覽器訪問http://服務(wù)器IP:8000你會(huì)發(fā)現(xiàn)響應(yīng)速度、并發(fā)表現(xiàn)完全是兩個(gè)檔次。這里多說一句threads8的意思是讓 Waitress 創(chuàng)建 8 個(gè)工作線程。默認(rèn)值是 4對(duì)于很多小項(xiàng)目來說也夠用但如果你處理的是 IO 密集業(yè)務(wù)我建議先設(shè)置成 8觀察一下內(nèi)存和 CPU 表現(xiàn)再調(diào)整。啟動(dòng)時(shí)機(jī)、線程數(shù)量、連接限制這些參數(shù)的調(diào)整邏輯我放在下一節(jié)展開。3.2 更規(guī)范的生產(chǎn)啟動(dòng)姿勢(shì)用 waitress-serve 命令除了在代碼里調(diào)用serve()Waitress 還提供了一個(gè)命令行工具waitress-serve好處是不用改代碼直接指定應(yīng)用入口就可以啟動(dòng)服務(wù)。這在我部署多個(gè)項(xiàng)目時(shí)非常實(shí)用因?yàn)轫?xiàng)目代碼不需要知道自己在哪個(gè)服務(wù)器上跑啟動(dòng)行為完全由外部控制。waitress-serve --host0.0.0.0 --port8000 --threads8 myapp:app這里的myapp:app指的是myapp.py文件里的app變量。命令行啟動(dòng)和代碼調(diào)用方式在效果上沒有本質(zhì)區(qū)別但命令行方式更利于交給進(jìn)程管理工具來管理比如放進(jìn) systemd 服務(wù)文件里讓它在服務(wù)器開機(jī)時(shí)自動(dòng)拉起、崩潰后自動(dòng)重啟。我實(shí)際部署時(shí)的做法是項(xiàng)目代碼里不寫任何啟動(dòng)邏輯只定義app然后用 systemd 配合waitress-serve啟動(dòng)。這樣團(tuán)隊(duì)里任何人拿到項(xiàng)目代碼都知道入口是什么不會(huì)被開發(fā)時(shí)的app.run()干擾。3.3 用 systemd 把 Waitress 變成常駐服務(wù)不推薦直接掛一個(gè)終端跑服務(wù)因?yàn)榻K端一關(guān)服務(wù)就沒了。Linux 上用 systemd 管理是標(biāo)準(zhǔn)做法。創(chuàng)建一個(gè)服務(wù)文件比如/etc/systemd/system/myapp.service內(nèi)容大致如下[Unit] DescriptionMy Flask App with Waitress Afternetwork.target [Service] Userwww-data Groupwww-data WorkingDirectory/opt/myapp ExecStart/opt/myapp/venv/bin/waitress-serve --host127.0.0.1 --port8000 --threads8 myapp:app Restartalways RestartSec3 [Install] WantedBymulti-user.target然后執(zhí)行systemctl daemon-reload systemctl enable myapp systemctl start myapp這里有幾個(gè)細(xì)節(jié)值得注意。ExecStart一定要寫虛擬環(huán)境里的絕對(duì)路徑不要寫簡(jiǎn)短的waitress-serve否則 systemd 找不到解釋器。Restartalways確保進(jìn)程異常退出后能自動(dòng)恢復(fù)。綁定的地址我寫的是127.0.0.1不是0.0.0.0因?yàn)榍懊鎽?yīng)該還有一層反向代理承擔(dān)外部流量Waitress 只需要接受本機(jī)請(qǐng)求。這個(gè)架構(gòu)問題下面細(xì)說。4. 生產(chǎn)環(huán)境配置與參數(shù)調(diào)優(yōu)4.1 線程數(shù)到底怎么定很多人會(huì)把線程數(shù)拍腦袋設(shè)置為 16 或者 32實(shí)際上沒有一個(gè)絕對(duì)正確的數(shù)值只看你的業(yè)務(wù)情況。我們需要理解 Waitress 的線程模型線程數(shù)越多能同時(shí)處理的請(qǐng)求越多但每個(gè)線程都要占用內(nèi)存和上下文切換開銷開太多反而會(huì)讓性能下降。我的經(jīng)驗(yàn)是分兩步來定。第一步看場(chǎng)景如果業(yè)務(wù)里主要操作是查數(shù)據(jù)庫、調(diào)接口、讀寫文件這些操作大量時(shí)間在等待 IO線程可以適當(dāng)多開比如 8 到 16如果業(yè)務(wù)里有 CPU 密集計(jì)算比如圖像處理、復(fù)雜的數(shù)值運(yùn)算Python 的全局解釋器鎖會(huì)讓多線程無法真正并行這時(shí)候多線程收益不大應(yīng)該考慮把這類任務(wù)拆分到獨(dú)立隊(duì)列里處理等待時(shí)間就沒意義撐高線程數(shù)。第二步是壓測(cè)驗(yàn)證。先設(shè)置一個(gè)合理初值比如 8然后拿測(cè)試工具模擬并發(fā)請(qǐng)求觀察 CPU 和內(nèi)存曲線。如果 CPU 沒有跑滿、排隊(duì)延遲仍然高可以逐步加大線程數(shù)如果內(nèi)存漲得厲害、頻繁切換線程導(dǎo)致響應(yīng)變慢就往回調(diào)。我在一個(gè)內(nèi)部報(bào)表項(xiàng)目里做過測(cè)試線程從 4 調(diào)到 8并發(fā)吞吐提升明顯從 8 調(diào)到 16 反而沒有顯著變化最后穩(wěn)定在 12。這說明不是越大越好找到自己的平衡點(diǎn)才重要。4.2 connection-limit 和其他連接參數(shù)Waitress 的--connection-limit參數(shù)控制最大并發(fā)連接數(shù)默認(rèn)值是 100。如果你的服務(wù)有比較高的瞬時(shí)連接比如前端頁面同時(shí)加載很多資源或者有大量長(zhǎng)連接保持這個(gè)參數(shù)就很容易變成瓶頸。我建議監(jiān)控連接數(shù)如果接近上限就調(diào)大。但要注意連接數(shù)和線程數(shù)是配合使用的。連接數(shù)控制的是“能有多少連接被接受”線程數(shù)控制的是“能有多少請(qǐng)求被同時(shí)處理”如果連接數(shù)遠(yuǎn)大于線程數(shù)多余的連接只能排隊(duì)等待反而容易出現(xiàn)超時(shí)。還有一個(gè)參數(shù)是--channel-timeout默認(rèn) 120 秒。它控制著空閑 keep-alive 連接能存活多久。對(duì)大多數(shù)應(yīng)用來說120 秒太長(zhǎng)連接掛著不放會(huì)占用系統(tǒng)資源。我在實(shí)際項(xiàng)目中會(huì)把它縮短到 30 秒左右讓不活躍的連接盡快釋放。但以下場(chǎng)景要慎重如果客戶端下載大文件或上傳大體積內(nèi)容過短的通道超時(shí)會(huì)導(dǎo)致傳輸被中斷。另外--send-bytes參數(shù)控制單次 socket 發(fā)送的數(shù)據(jù)塊大小默認(rèn)值是 18000 字節(jié)一般情況下不用管它。調(diào)小它會(huì)讓大數(shù)據(jù)量響應(yīng)的發(fā)送更平滑調(diào)大它可能減少系統(tǒng)調(diào)用次數(shù)但這些都屬于細(xì)節(jié)微調(diào)非必要不折騰。先把線程數(shù)、連接數(shù)據(jù)、通道超時(shí)三個(gè)參數(shù)調(diào)整到合理區(qū)間服務(wù)表現(xiàn)就已經(jīng)很好了。4.3 反向代理的配合方式生產(chǎn)環(huán)境里我強(qiáng)烈推薦在 Waitress 前面再加一層反向代理比如 Nginx。原因有三方面一是 TLS 證書管理交給反向代理Python 進(jìn)程不直接處理加密握手性能更穩(wěn)二是反向代理可以管理靜態(tài)文件的緩存減輕 Flask 應(yīng)用的負(fù)擔(dān)三是可以靈活做負(fù)載均衡、限流、訪問日志這些功能沒必要在應(yīng)用里重復(fù)實(shí)現(xiàn)。部署架構(gòu)就是外部請(qǐng)求 - Nginx - 127.0.0.1:8000 - Waitress - Flask App。所以前面 systemd 配置里把監(jiān)聽地址設(shè)為127.0.0.1就是為了讓外部流量只能通過 Nginx 進(jìn)來避免端口直接暴露。Nginx 里的一個(gè)核心配置是轉(zhuǎn)發(fā)頭信息location / { proxy_pass http://127.0.0.1:8000; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; }這里有個(gè)容易踩坑的細(xì)節(jié)如果 Flask 應(yīng)用需要生成絕對(duì) URL比如重定向跳轉(zhuǎn)、郵件里的鏈接Flask 會(huì)根據(jù)請(qǐng)求頭判斷當(dāng)前協(xié)議。當(dāng) Nginx 把 HTTPS 終止掉后如果 Waitress 收到的請(qǐng)求只是普通的 HTTPFlask 生成的鏈接就會(huì)是http://開頭客戶端點(diǎn)擊跳轉(zhuǎn)后直接變回不安全的連接。Waitress 解決這個(gè)問題的方式是提供--url-scheme參數(shù)。如果你的 Nginx 已經(jīng)處理了 HTTPS 終止需要把 Waitress 設(shè)置成感知外部協(xié)議。一種是直接設(shè)置waitress-serve --trusted-proxy* --url-schemehttps myapp:app--trusted-proxy*表示信任來自任意來源的轉(zhuǎn)發(fā)信息--url-schemehttps強(qiáng)制把外部協(xié)議識(shí)別為 HTTPS。這個(gè)參數(shù)要在確認(rèn)只有 Nginx 能直接訪問 Waitress 時(shí)才使用否則存在偽造請(qǐng)求頭的風(fēng)險(xiǎn)。更穩(wěn)的做法是在 Nginx 里設(shè)置X-Forwarded-Proto然后配置 Waitress 的--trusted-proxy指向 Nginx 的 IP讓 Waitress 自動(dòng)從轉(zhuǎn)發(fā)頭里識(shí)別協(xié)議。這樣處理之后Flask 生成的絕對(duì)鏈接才會(huì)是正確的 HTTPS 地址重定向也不會(huì)出問題。5. 常見問題與排查技巧實(shí)錄5.1 高頻問題速查表我把實(shí)際操作中遇到的、還有社區(qū)里經(jīng)?？吹降膯栴}整理了一張速查表方便你直接參考。問題現(xiàn)象常見原因解決思路重啟后服務(wù)起不來端口被占用檢查舊進(jìn)程lsof -i:8000或netstat -tunlp找到占用進(jìn)程并處理并發(fā)一高就響應(yīng)超時(shí)threads 設(shè)置過小逐步調(diào)大線程數(shù)并壓測(cè)驗(yàn)證不要一次調(diào)過多前端頁面加載大量資源時(shí)卡頓connection-limit 太小觀察連接數(shù)曲線適當(dāng)調(diào)大連接限制反向代理訪問返回 502Nginx 連不上 Waitress確認(rèn) Waitress 監(jiān)聽地址、端口、防火墻規(guī)則日志里出現(xiàn)大量的連接重置客戶端斷開連接一般不用處理關(guān)注頻率是否異常升高HTTPS 頁面里生成的鏈接是 http代理頭信息沒識(shí)別正確設(shè)置 trusted-proxy 和 url-scheme內(nèi)存占用持續(xù)上漲線程數(shù)過多或代碼內(nèi)存泄漏壓測(cè)觀察內(nèi)存曲線結(jié)合日志找泄漏點(diǎn)Windows 上用不了 Gunicorn平臺(tái)不支持換成 Waitress直接適配這張表里最典型的其實(shí)是端口占用問題。我遇到過不止一次部署新版本時(shí)先停了服務(wù)但舊進(jìn)程沒殺干凈新進(jìn)程啟動(dòng)直接報(bào)address already in use。處理方式就是先找到舊進(jìn)程確認(rèn)沒有正在處理的請(qǐng)求后停掉。用 systemd 管理服務(wù)時(shí)systemctl restart myapp一般會(huì)自動(dòng)處理好但如果手動(dòng)跑進(jìn)程就容易留下這個(gè)問題。5.2 壓測(cè)帶來的幾個(gè)認(rèn)知更新我第一次部署 Waitress 時(shí)沒有做壓測(cè)就直接上線了一個(gè)內(nèi)部工具結(jié)果某個(gè)業(yè)務(wù)部門集中使用的時(shí)間段數(shù)據(jù)庫連接池先被打滿了。問題不在于 Waitress 線程不夠而是每個(gè)線程處理請(qǐng)求都要去拿一個(gè)數(shù)據(jù)庫連接連接池不夠用了請(qǐng)求全卡在等待連接上。排查過程很有意思從 Nginx 日志看請(qǐng)求已經(jīng)發(fā)給 Waitress 了從 Flask 日志看部分請(qǐng)求進(jìn)入視圖后就沒有返回從數(shù)據(jù)庫監(jiān)控看連接數(shù)飆到了上限。最后定位到問題不在服務(wù)器層而在數(shù)據(jù)庫連接池配置。這個(gè)經(jīng)驗(yàn)提醒我一個(gè)重要的原則調(diào)優(yōu)不能只看 Web 服務(wù)器本身的參數(shù)要沿著調(diào)用鏈路把數(shù)據(jù)庫連接池、外部接口超時(shí)、緩存配置一起過一遍。不然你調(diào)大了線程數(shù)反而會(huì)讓數(shù)據(jù)庫連接池更快耗盡。后來我把項(xiàng)目里的數(shù)據(jù)庫連接池上限和 Waitress 線程數(shù)做了配套設(shè)置比如線程數(shù)定在 12連接池就至少保證 20 個(gè)連接留出余量應(yīng)對(duì)排隊(duì)和重試。這樣做之后高峰期的表現(xiàn)明顯穩(wěn)定很多。5.3 Windows 部署時(shí)的一個(gè)隱性坑在 Windows 上部署 Flask 服務(wù)時(shí)Waitress 幾乎是唯一方便的生產(chǎn)服務(wù)器選擇但它有一個(gè)容易被忽略的問題Windows 的 socket 行為在某些邊界條件下和 Linux 不同。比如大量短連接建立和關(guān)閉時(shí)Windows 上可能出現(xiàn) TIME_WAIT 端口堆積導(dǎo)致新連接無法建立。這個(gè)問題不常見但如果你的服務(wù)連接頻繁且量比較大就可能碰到。我的排查方法是觀察系統(tǒng)網(wǎng)絡(luò)狀態(tài)如果出現(xiàn)大量 TIME_WAIT 且新連接建立失敗可以通過調(diào)整系統(tǒng)注冊(cè)表里的端口回收參數(shù)來解決。具體配置因系統(tǒng)版本而異但思路是讓關(guān)閉后的端口更快進(jìn)入可用狀態(tài)。另外Windows 上不要頻繁重啟 Waitress 進(jìn)程短生命周期進(jìn)程會(huì)加劇這個(gè)問題。盡量保持服務(wù)進(jìn)程長(zhǎng)期運(yùn)行配合守護(hù)工具實(shí)現(xiàn)自動(dòng)拉起就好了。5.4 一下最容易被忽略的超時(shí)組合很多人只關(guān)注請(qǐng)求處理時(shí)長(zhǎng)卻忽略了下游依賴方的超時(shí)設(shè)置。我在一個(gè)對(duì)外提供 API 服務(wù)時(shí)遇到過反復(fù)超時(shí)檢查發(fā)現(xiàn) Waitress 的通道超時(shí)設(shè)置太長(zhǎng)導(dǎo)致請(qǐng)求掛在那里遲遲不釋放線程同時(shí)調(diào)用方的超時(shí)時(shí)間又短于是客戶端不斷重試反而把服務(wù)打掛。這種問題本質(zhì)上是一個(gè)超時(shí)鏈路的匹配問題。我的做法是建立一套統(tǒng)一的超時(shí)規(guī)范Waitress 通道超時(shí)設(shè)置到 30 秒Flask 視圖內(nèi)調(diào)外部接口的超時(shí)設(shè)置到 5 秒反向代理的超時(shí)設(shè)置到 60 秒客戶端提交請(qǐng)求的超時(shí)控制在 30 秒以內(nèi)。層與層之間留出合理的余量就不會(huì)出現(xiàn)下游先超時(shí)重試、上游還在慢慢處理的惡性循環(huán)。你可以根據(jù)自己業(yè)務(wù)的響應(yīng)時(shí)間要求調(diào)整這組數(shù)值但思路是一樣的從最上游到最下游每一層的超時(shí)時(shí)間都要有意識(shí)地設(shè)計(jì)而不是用默認(rèn)值湊合。部署 Web 服務(wù)這件事很多時(shí)候不是功能做完了就結(jié)束而是把連接細(xì)節(jié)一點(diǎn)一點(diǎn)磨順的過程。我現(xiàn)在接手任何一個(gè) Flask 項(xiàng)目第一步就是確認(rèn)它是不是跑在真正的生產(chǎn)服務(wù)器上第二步就是檢查超時(shí)鏈路和連接池設(shè)置。Waitress 在我看來是一個(gè)非常省心的選擇安裝簡(jiǎn)單、跨平臺(tái)、行為可預(yù)測(cè)不需要像某些服務(wù)器那樣為編譯或平臺(tái)兼容頭疼。它不會(huì)讓你的業(yè)務(wù)代碼變得花哨但它能在背后穩(wěn)穩(wěn)地把請(qǐng)求接住、分發(fā)好、送出去讓 Flask 應(yīng)用真正站在能上場(chǎng)的位置。如果你現(xiàn)在的項(xiàng)目還在用開發(fā)服務(wù)器扛線上流量找個(gè)周末花半小時(shí)換成 Waitress已經(jīng)能規(guī)避掉大部分低級(jí)故障了。