前言
項(xiàng)目架構(gòu) nginx+supervisor+daphne+django,因?yàn)閐jango里面使用了channel包來(lái)處理websockert請(qǐng)求所以django的網(wǎng)關(guān)協(xié)議從WSGI升級(jí)為了ASGI,從而使用了風(fēng)評(píng)較好且支持ASGI協(xié)議的daphne來(lái)進(jìn)行網(wǎng)關(guān)框架部署,supervisor進(jìn)行進(jìn)程管理,nginx進(jìn)行請(qǐng)求代理.
問(wèn)題點(diǎn)1
nginx(80)配置轉(zhuǎn)發(fā)websockert的時(shí)候(location /api)一直握手不成功。nginx配置如下:
server {
listen 80;
charset utf-8;
access_log /var/log/nginx/access.log;
gzip_types text/plain application/x-javascript text/css text/javascript application/x-httpd-php application/json text/json image/jpeg image/gif image/png application/octet-stream;
...
location /api {
proxy_pass http://10.200.1.228:6099;
proxy_redirect off;
proxy_set_header Host $http_host;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
client_max_body_size 1000m;
chunked_transfer_encoding on;
proxy_connect_timeout 600;
proxy_read_timeout 600;
proxy_send_timeout 600;
proxy_set_header X-Real-IP $remote_addr; #獲取真實(shí)ip
proxy_http_version 1.1; #http協(xié)議版本
proxy_set_header Connection "upgrade"; #連接方式-請(qǐng)求升級(jí)
proxy_set_header Upgrade $http_upgrade; #升級(jí)協(xié)議
}
...
}
問(wèn)題解決1
websokert請(qǐng)求升級(jí)的頭都有添加,看了channels的官網(wǎng)也是這么配置的.
初期排查是因?yàn)槲业膚ebsocker的url是 application/message/
.....,我確實(shí)廢物這個(gè)問(wèn)題竟然沒(méi)發(fā)現(xiàn)
問(wèn)題點(diǎn)2
我修改了websockert的url,從application/message/
改為了api/application/message/
,但是握手還是握不上這就觸及到我知識(shí)盲區(qū)了..修改的操作如下.
# 殺掉supervisor進(jìn)程
ps -aux | grep supervisor
kill -s 9 pid
# 修改url
從application/message/改為api/application/message/
具體操作略過(guò)
# 啟動(dòng)supervisor
supervisor -c supervisor.conf
問(wèn)題解決2
我不走nginx直接取訪(fǎng)問(wèn)后端端口(6099)上的websockert服務(wù)api/application/message/
竟然也訪(fǎng)問(wèn)不到但是原來(lái)的urlapplication/message
是可以訪(fǎng)問(wèn)到的,這說(shuō)明我新改的代碼沒(méi)有生效呀.
于是我又去查看django日志的時(shí)候發(fā)現(xiàn)刷出了幾百行的6099端口占用中的日志證實(shí)猜想,我的新進(jìn)程根本就沒(méi)有起來(lái).
然后我就把6099端口上的服務(wù)和superviso殺掉,再次重啟supervisor.
6099上的api/application/message/
就可以訪(fǎng)問(wèn)了同樣的nginx就可以正常轉(zhuǎn)發(fā)了.
問(wèn)題刨析2
后面我又做了下實(shí)驗(yàn)有如下發(fā)現(xiàn):
- kill殺掉supervisor進(jìn)程時(shí)掛載的command(本文的6099后端服務(wù))并不會(huì)停掉.
2.kill殺掉某一個(gè)command時(shí)只要supervisor配置了autorestart它就會(huì)一直去重啟command
上面的操作是有問(wèn)題的
# 殺掉supervisor進(jìn)程
ps -aux | grep supervisor
kill -s 9 pid
# 這里我以為是殺掉后端服務(wù)其實(shí)6099一直都在哨颂,并不會(huì)隨著supervisor停止而停止
# 修改url
從application/message/改為api/application/message/
具體操作略過(guò)
# 啟動(dòng)supervisor
supervisor -c supervisor.conf
#由于上面的6099服務(wù)并沒(méi)停止導(dǎo)致了我在這里進(jìn)行啟動(dòng)的command(6099服務(wù))一直在報(bào)端口被占用..
總結(jié)
supervisor的啟停還是用人家自己命令吧,不知道就百度為了省這一分鐘花了兩個(gè)小時(shí)去解決。相种。
supervisor命令貼一份
#daphne是supervisor配置文件中的program命名
supervisorctl 是 supervisord的命令行客戶(hù)端工具
supervisorctl status: 查看所有進(jìn)程的狀態(tài)
supervisorctl stop daphne:停止daphne
supervisorctl start daphne:?jiǎn)?dòng)daphne
supervisorctl restart daphne: 重啟daphne
supervisorctl update : 配置文件修改后可以使用該命令加載新的配置
supervisorctl reload: 重新啟動(dòng)配置中的所有程序
...
把 daphne 換成 all 可以管理配置中的所有進(jìn)程