<>踩坑記 Django

Django Python

19.1.1.5 模板new_topic

做完書上的步驟后，對(duì)主題添加頁(yè)面經(jīng)行測(cè)試，但是瀏覽器顯示 服務(wù)器異常。

個(gè)人采用的開發(fā)環(huán)境是virtual studio code , 測(cè)試起來(lái)很是難受，因?yàn)槲遗渲玫膁ebug環(huán)境，斷點(diǎn)操作沒有作用。

經(jīng)過(guò)我不斷的測(cè)試，才發(fā)現(xiàn)我失敗的原因是由于之前的誤操作，先建立new_pizzas.py后改為new_pizzas.html的，錯(cuò)誤就在這里。在我之后新建了my_new_pizzas.html后，測(cè)試成功了。

這個(gè)過(guò)程真的是很痛苦啊，奇怪的錯(cuò)誤真的是有很多。

19.2 創(chuàng)建用戶賬戶

登錄成功后不能跳轉(zhuǎn)到 pizzas:index

經(jīng)過(guò)網(wǎng)上不斷查證：

觀看了博友的文章后：

https://www.cnblogs.com/quicksnow/p/4649737.html

受到了啟發(fā)：

在項(xiàng)目 setting.py 添加

LOGIN_REDIRECT_URL = 'pizzas:index’

具體這種用法可以參考《反向解析URL》

https://www.liujiangblog.com/course/django/136

部署項(xiàng)目

部署參考

部署步驟

簡(jiǎn)要的梳理安裝的步驟，重點(diǎn)是所遇到的錯(cuò)誤以及解決方法。

項(xiàng)目文件

拷貝本地項(xiàng)目到服務(wù)器Linu端

配置數(shù)據(jù)庫(kù)

連接數(shù)據(jù)庫(kù)

運(yùn)行項(xiàng)目在服務(wù)器 localhost

使用 curl 測(cè)試本地項(xiàng)目是否運(yùn)行成功

curl測(cè)試

6. 注意 MySQL數(shù)據(jù)庫(kù)可能會(huì)報(bào)錯(cuò)：

django2.2/mysql ImproperlyConfigured: mysqlclient 1.3.13 or newer is required; you have 0.9.3

服務(wù)器端 nginx、uWSGI的安裝

參考文章：

基本知識(shí)

web服務(wù)器和web框架

web服務(wù)器即用來(lái)接受客戶端請(qǐng)求，建立連接，轉(zhuǎn)發(fā)響應(yīng)的程序。至于轉(zhuǎn)發(fā)的內(nèi)容是什么，交由web框架來(lái)處理，即處理這些業(yè)務(wù)邏輯。如查詢數(shù)據(jù)庫(kù)、生成實(shí)時(shí)信息等。Nginx就是一個(gè)web服務(wù)器，Django或flask就是web框架。

WSGI協(xié)議

只要web服務(wù)器和web框架滿足WSGI協(xié)議，它們就能相互搭配。所以WSGI只是一個(gè)協(xié)議，一個(gè)約定。而不是python的模塊、框架等具體的功能。

wsgi.py

django項(xiàng)目攜帶的一個(gè)wsgi接口文件

如果項(xiàng)目名叫project_name的話，此文件就位于[project_name/project_name/wsgi.py]

uWSGI

實(shí)現(xiàn)了WSGI協(xié)議的一個(gè)web服務(wù)器。即用來(lái)接受客戶端請(qǐng)求，轉(zhuǎn)發(fā)響應(yīng)的程序。實(shí)際上，一個(gè)uWSGI的web服務(wù)器，再加上Django這樣的web框架，就已經(jīng)可以實(shí)現(xiàn)網(wǎng)站的功能了

Nginx

一個(gè)普通的個(gè)人網(wǎng)站，訪問(wèn)量不大的話，當(dāng)然可以由uWSGI和Django構(gòu)成。但是一旦訪問(wèn)量過(guò)大，客戶端請(qǐng)求連接就要進(jìn)行長(zhǎng)時(shí)間的等待。這個(gè)時(shí)候就出來(lái)了分布式服務(wù)器，我們可以多來(lái)幾臺(tái)web服務(wù)器，都能處理請(qǐng)求。但是誰(shuí)來(lái)分配客戶端的請(qǐng)求連接和web服務(wù)器呢？Nginx就是這樣一個(gè)管家的存在，由它來(lái)分配。這也就是由Nginx實(shí)現(xiàn)反向代理，即代理服務(wù)器。

參考

wsgi：一種實(shí)現(xiàn)python解析的通用接口標(biāo)準(zhǔn)/協(xié)議，是一種通用的接口標(biāo)準(zhǔn)或者接口協(xié)議，實(shí)現(xiàn)了python web程序與服務(wù)器之間交互的通用性。

利用它，web.py或bottle或者django等等的python web開發(fā)框架，就可以輕松地部署在不同的web server上了；

uwsgi:同WSGI一樣是一種通信協(xié)議

uwsgi協(xié)議是一個(gè)uWSGI服務(wù)器自有的協(xié)議，它用于定義傳輸信息的類型，它與WSGI相比是兩樣?xùn)|西。

uWSGI :一種python web server或稱為Server/Gateway

uWSGI類似tornadoweb或者flup，是一種python web server，uWSGI是實(shí)現(xiàn)了uwsgi和WSGI兩種協(xié)議的Web服務(wù)器，負(fù)責(zé)響應(yīng)python 的web請(qǐng)求。

因?yàn)閍pache、nginx等，它們自己都沒有解析動(dòng)態(tài)語(yǔ)言如php的功能，而是分派給其他模塊來(lái)做，比如apache就可以說(shuō)內(nèi)置了php模塊，讓人感覺好像apache就支持php一樣。

uWSGI實(shí)現(xiàn)了wsgi協(xié)議、uwsgi協(xié)議、http等協(xié)議。 Nginx中HttpUwsgiModule的作用是與uWSGI服務(wù)器進(jìn)行交換。

項(xiàng)目流程 這個(gè)是很重要的

首先客戶端請(qǐng)求服務(wù)資源，

nginx作為直接對(duì)外的服務(wù)接口,接收到客戶端發(fā)送過(guò)來(lái)的http請(qǐng)求,會(huì)解包、分析，

如果是靜態(tài)文件請(qǐng)求就根據(jù)nginx配置的靜態(tài)文件目錄，返回請(qǐng)求的資源，

如果是動(dòng)態(tài)的請(qǐng)求,nginx就通過(guò)配置文件,將請(qǐng)求傳遞給uWSGI；uWSGI 將接收到的包進(jìn)行處理，并轉(zhuǎn)發(fā)給wsgi，

wsgi根據(jù)請(qǐng)求調(diào)用django工程的某個(gè)文件或函數(shù)，處理完后django將返回值交給wsgi，

wsgi將返回值進(jìn)行打包，轉(zhuǎn)發(fā)給uWSGI，

uWSGI接收后轉(zhuǎn)發(fā)給nginx,nginx最終將返回值返回給客戶端(如瀏覽器)。

*注:不同的組件之間傳遞信息涉及到數(shù)據(jù)格式和協(xié)議的轉(zhuǎn)換

這個(gè)也是很重要的

1. 第一級(jí)的nginx并不是必須的，uwsgi完全可以完成整個(gè)的和瀏覽器交互的流程；

2. 在nginx上加上安全性或其他的限制，可以達(dá)到保護(hù)程序的作用；

3. uWSGI本身是內(nèi)網(wǎng)接口，開啟多個(gè)work和processes可能也不夠用，而nginx可以代理多臺(tái)uWSGI完成uWSGI的負(fù)載均衡；

4. django在debug=False下對(duì)靜態(tài)文件的處理能力不是很好，而用nginx來(lái)處理更加高效。

一點(diǎn)說(shuō)明

看了很多人部署的文章，但是他們都沒有說(shuō)明，最后需不需使用

python manage.py runserver 8000

來(lái)運(yùn)行項(xiàng)目，答案是不需要。

不需要在個(gè)，項(xiàng)目就可以運(yùn)行的。

最后的坑

注意 Linux 路徑下 文件的下級(jí)目錄用‘/’來(lái)表示，window好像不做嚴(yán)格區(qū)分‘\’‘/’都可以

如果出現(xiàn)404錯(cuò)誤，可以檢查項(xiàng)目、應(yīng)用的 views.py。把‘\’替換掉就可以了。

下一步學(xué)習(xí)

學(xué)生管理系統(tǒng)

簡(jiǎn)單的前端

總結(jié)

以上是生活随笔為你收集整理的python从入门到实践django看不懂_Python编程：从入门到实践踩坑记 Django的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。