Nginx + uWSGI + Python + Django構建必應高清壁紙站

寫在前面

作這個網站的初衷是由於，每次打開必應搜索搜東西的時候都會被上面的背景圖片吸引，我想必應的壁紙應該是通過專業人員精選出來的，我甚至會翻看之前的歷史圖片，惟一美中不足的是必應的首頁只能查看最多7天的壁紙。因此我萌生出本身建一個網站，天天定時蒐集必應的壁紙，將壁紙信息保存在數據庫中，這樣就能夠看到好久以前的壁紙圖片了。網站使用的是python的django框架，前端接入使用了nginx+uwsgi。沒什麼特別的考慮，其實網站自己沒什麼技術含量，使用python的django入手仍是很快的，固然用nodejs+express也是不錯的(其實個人node比python熟，想折騰點新東西哈哈)。我在這裏寫出步驟來，給剛剛上手的朋友們一個參考。服務器是直接購買的阿里雲的，第一年很便宜才100不到好像，1核2G的基礎配置帶寬也低，不過夠用了。域名直接在萬網購買，其實也是阿里旗下，備案也很方便，按照提示步驟操做，差很少2周之內就下來了。最終的成果能夠到這裏先睹爲快：必應高清壁紙，必應每日一圖

安裝python環境

咱們使用的是最新的django框架，須要比較新版本的python環境，阿里雲的服務器我購買的時候選擇的是centos 6.9，不過我以爲操做系統版本對後面的操做影響不大，服務器內置都已經安裝有python環境，只不過是python2.6.6比較老的版本了。因此爲了使用最新的django 3.0.1，我乾脆安裝最新的python 3.8.1。這裏我本身下載python源碼進行編譯，安裝。 

wget https://www.python.org/ftp/python/3.8.1/Python-3.8.1.tgz
tar zxvf Python-3.8.1.tgz 
cd Python-3.8.1
./configure 
make
make install

安裝好以後，python2.6與python3.8是共存的，咱們可使用python3命令來使用3.8.1版本的python，經過下面的命令能夠看到咱們安裝的python3.8被安裝到的目錄：

$ which python3
/usr/local/bin/python3
$ ll /usr/local/bin/python3
/usr/local/bin/python3 -> python3.8

跟隨python3一塊兒安裝的還有pip3，是python的包管理工具，python2.x用的是pip，python3.x用的是pip3。接下來咱們安裝django框架

安裝django框架

pip3 install django

結果報告下面的錯誤：

看提示是ssl的版本太低，而python須要更高的版本，使用命令 openssl version 查看獲得當前系統安裝的openssl的版本是1.0.1e，而python3.8須要openssl版本爲1.0.2或者以上的版本。這裏咱們安裝openssl 1.1.1的版本：

# 下載源碼編譯安裝
wget https://www.openssl.org/source/openssl-1.1.1a.tar.gz
tar -zxvf openssl-1.1.1a.tar.gz
cd openssl-1.1.1a
./config --prefix=/usr/local/openssl no-zlib 
make
make install

# 替換系統目錄中低版本的庫
mv /usr/bin/openssl /usr/bin/openssl.bak
mv /usr/include/openssl/ /usr/include/openssl.bak
ln -s /usr/local/openssl/include/openssl /usr/include/openssl
ln -s /usr/local/openssl/lib/libssl.so.1.1 /usr/local/lib64/libssl.so
ln -s /usr/local/openssl/bin/openssl /usr/bin/openssl
ln -s /usr/local/openssl/lib/libssl.so.1.1 /usr/lib64/libssl.so

# 加入庫搜索路徑並使之生效
echo "/usr/local/openssl/lib" >> /etc/ld.so.conf
ldconfig -v

# 查看openssl版本輸出：OpenSSL 1.1.1a  20 Nov 2018
openssl version

這樣新版openssl就安裝好了，咱們再從新編譯並安裝Python3，以下：

cd Python-3.8.1
./configure --with-openssl=/usr/local/openssl
make
make install

這裏的3.8.1編譯的時候是添加 --with-openssl=/usr/local/openssl 這個選項，而不是網上的資料說的 --with-ssl 網上說的這個選項是錯的，會報錯 unrecognized options 。除此之外還有一個問題讓我費了點時間值得注意一下，就是在openssl進行make install以後，從新編譯python3.8的時候，編譯結束老是有下面的錯誤提示：

Could not build the ssl module!
Python requires an OpenSSL 1.0.2 or 1.1 compatible libssl with X509_VERIFY_PARAM_set1_host().

就是提示找不到ssl，該錯誤提示仍是由於編譯python的時候 -ssl  選項沒有找到正確的 libssl.so 的動態庫。咱們能夠經過下面的命令來肯定當前系統中的ssl動態庫的狀況：

ldconfig -v | grep ssl 

# 在其輸出中咱們要肯定是否還有老的ssl庫在裏面，實際上在編譯提示找不到ssl的時候
# 我經過命令查看的結果發現 /usr/lib64/libssl.so 軟鏈的仍是 1.0.1 的老版本
# 因而我改爲鏈接到新編譯的 1.1.1 版本以後，最後看到的是下面的結果

libssl.so.1.1 -> libssl.so.1.1
libssl3.so -> libssl3.so
libssl.so.10 -> libssl.so.1.0.1e

以後再從新編譯python就沒有報ssl not found的錯誤了，說明新版ssl已經編譯到python3.8.1中，此時咱們再用上面的命令安裝django，最後獲得下面的提示，表示安裝成功完成：

Installing collected packages: sqlparse, pytz, asgiref, Django
Successfully installed Django-3.0.5 asgiref-3.2.7 pytz-2019.3 sqlparse-0.3.1

這裏要注意的是，網絡很慢的狀況下會常常超時，我以後是經過wget手工下載以後再進行安裝的：

wget https://files.pythonhosted.org/packages/a9/4f/8a247eee2958529a6a805d38fbacd9764fd566462fa0016aa2a2947ab2a6/Django-3.0.5-py3-none-any.whl
pip3 install ./Django-3.0.5-py3-none-any.whl

安裝成功以後，咱們經過下面的方法驗證是否正常：

python3
Python 3.8.1 (default, Apr 18 2020, 00:10:11) 
[GCC 4.4.6 20120305 (Red Hat 4.4.6-4)] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import django
>>> print(django.get_version())
3.0.5

就是直接運行python3，打開python3的交互輸入，引用django模塊，打印出其版本，正確打印出了咱們安裝的3.0.5版本，說明安裝正常了

配置django

django框架安裝正常以後，咱們創建一個簡單的django工程testdj以下：

django-admin.py startproject testdj

建立完成以後，會在當前目錄下建立一個目錄與工程名同名 testdj，咱們看下該目錄的結構：

這樣咱們的django項目就建立好了，咱們經過其提供的管理腳本 manage.py 來啓動他：

# 注意這裏要用python3來運行
python3 manage.py runserver 0.0.0.0:8000

運行以後報錯了：

因爲django3.0.5版本默認引用了sqlite3的數據庫，咱們並無安裝sqlite3，因此報錯，咱們先在 settings.py 中把這個配置去掉：

再次運行以後正常，可是此時咱們還不能在瀏覽器中訪問他，咱們須要編寫對應的頁面，由於此時項目中什麼都沒有，連主頁都沒有，運行成功以下圖：

 

編寫視圖以及設置url路由

下面咱們爲主頁的請求編寫一個view並配置一下路由規則，讓主頁請求路由到咱們編寫的view上，在上面的目錄結構裏面，與 settings.py 同一目錄下添加文件 view.py 內容以下：

# view.py
from django.http import HttpResponse

def hello(request):
    return HttpResponse("Hello world ! ")

修改urls.py的內容以下：

# urls.py
from django.contrib import admin
from django.urls import path
from django.conf.urls import url
from . import view

urlpatterns = [
    url(r'^$', view.hello),
]

將 settings.py 中的 ALLOWED_HOSTS 配置修改成以下：

# 若是不修改會報相似的錯誤
# Invalid HTTP_HOST header: 'ip:8000'. You may need to add 'ip' to ALLOWED_HOSTS.
ALLOWED_HOSTS = ['*']

再次啓動項目以後，在瀏覽器經過地址訪問獲得正確輸出：

此時咱們的diango順利啓動，下面咱們在django中使用數據庫，django中默認配置sqlite3，咱們這裏爲演示方便，也使用sqlite3做爲例子，相信換成其餘的數據庫不難

在django中使用sqlite3

咱們使用sqlite3這個小巧簡單的單文件數據庫來作演示，sqlite3雖然結構簡單，可是功能可一點不簡單，支持大多數常見的sql語法，首先咱們須要安裝sqlite3：

wget https://www.sqlite.org/2018/sqlite-autoconf-3240000.tar.gz
tar -xvzf sqlite-autoconf-3240000.tar.gz
cd sqlite-autoconf-3240000/
./configure --prefix=/usr/local/sqlite
make
make install

編譯完成以後，咱們須要從新編譯與安裝python3.8.1，按照上面編譯python3的流程從新跑一遍(包括  ./configure --with-openssl=/usr/local/openssl ) ，從新編譯python3以後，咱們能夠打開python3的輸入交互環境，直接在裏面 import sqlite3 沒有報錯，即sqlite3能夠在python3中正常使用了，若是有報錯的話，按照咱們上面解決 openssl 的思路去定位相似的問題，相信應該很好解決。在調用configure配置python3的時候，會生成 config.log 裏面也能夠查看到一些出錯信息。接下來咱們首先生成一個sqlite3的數據庫文件，並建立一個表，插入測試數據，過程以下：

# 咱們的數據庫文件的名字取 db.sqlite3
sqlite3 db.sqlite3

create table "tb_message"
(
   "message_id" integer NOT NULL PRIMARY KEY AUTOINCREMENT,
   "message_user" varchar(255) NOT NULL, 
   "message_content" text default ''   
);

insert into tb_message(message_user,message_content)values('張三','這是張三發送的消息');
insert into tb_message(message_user,message_content)values('李四','這是李四發送的消息');

將生成的數據庫文件的名字放在想要放置的目錄下，爲了測試方便，咱們將其放在django工程的根目錄，咱們將在django項目中讀出表的數據並展現到網頁上，爲了使用django的model，咱們須要先建立一個app，在django工程的根目錄下使用下面的命令建立一個名字爲djapp的app：

django-admin startapp djapp 

咱們看到建立了一個djapp的文件夾，咱們看看djapp的目錄結構：

咱們前面爲了順利運行django項目，將settings.py中關於sqlite的配置註釋了，如今咱們須要將這些配置正常化，同時咱們剛纔建立的djapp咱們要在 settings.py 配置中添加進來：

# settings.py
# 這裏配置了數據庫文件所在的路徑

DATABASES = {
    'default': {
        'ENGINE': 'django.db.backends.sqlite3',
        'NAME': os.path.join(BASE_DIR, 'db.sqlite3'),
    }
}
...
# Application definition
INSTALLED_APPS = [
    'django.contrib.admin',
    'django.contrib.auth',
    'django.contrib.contenttypes',
    'django.contrib.sessions',
    'django.contrib.messages',
    'django.contrib.staticfiles',
    'djapp',
]

生成model定義，也就是 djapp/models.py 的內容，在django中，咱們能夠本身編寫models.py的內容，而後使用相關的命令生成數據庫的表結構，反過來咱們能夠本身定義好表結構，使用相關命令由表結構去生成model的類定義。我通常習慣於本身定義好數據庫的表結構，而後使用命令生成model的類定義，下面咱們生成model類定義到文件 djapp/models.py 中：

# 咱們在manage.py所在的目錄運行下面的命令

python3 manage.py inspectdb > djapp/models.py

咱們能夠在 djapp/models.py 文件中看到生成的model定義的內容，一個數據庫表對應一個class，咱們只建立了一個表，因此文件中只有一個模型類，要注意的是這一步驟的前提是必須在 settings.py 中設置sqlite3的相關配置：

from django.db import models
class TbMessage(models.Model):
    message_id = models.AutoField(primary_key=True)
    message_user = models.CharField(max_length=255)
    message_content = models.TextField(blank=True, null=True)

    class Meta:
        managed = False
        db_table = 'tb_message'

接着咱們修改以前 view.hello 的實現，在裏面讀取數據庫表的記錄，並將數據呈現到模板文件中，再編寫模板文件以前，咱們須要在 settings.py 中設置模板文件所在的目錄：

TEMPLATES = [
    {
        'BACKEND': 'django.template.backends.django.DjangoTemplates',
        'DIRS': [BASE_DIR+"/templates"],
        'APP_DIRS': True,
        'OPTIONS': {
            'context_processors': [
                'django.template.context_processors.debug',
                'django.template.context_processors.request',
                'django.contrib.auth.context_processors.auth',
                'django.contrib.messages.context_processors.messages',
            ],
        },
    },
]

咱們將模板文件放在項目根目錄下的 templates 目錄下，咱們在此目錄下新建一個模板文件 test.tmp 內容以下：

<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 
<title>django test</title>
</head>
<body>
{% for msg in msg_list %}
    <div>用戶名：{{ msg.message_user }} 消息：{{ msg.message_content }} </div>
{% endfor %}
</body>
</html>

django的模板提供各類包括if、for、過濾器等豐富的模板標籤來控制模板的呈現邏輯，使用過MVC方式編寫Web應用程序的應該很容易理解，具體的用法很容易在網絡上找到，我也再也不說明了，上面的模板實際上就是將後端返回的數據中對應的model數據呈現到模板文件中，而後返回最終呈現的HTML內容，咱們的 testdj/view.py 的內容以下：

# view .py
from django.http import HttpResponse
from django.shortcuts import render
from django.http import JsonResponse
from djapp.models import TbMessage

def hello(request):
    xlist = TbMessage.objects.all().order_by('message_id')
    msg_list = []
    context={"msg_list":msg_list}
    for msg in xlist:
        msg_list.append({"message_user":msg.message_user,"message_content":msg.message_content})
    return render(request, 'test.tmp', context)

django生成的模板類提供了豐富的訪問數據庫的能力，包括按各類條件去查詢數據庫以及進行排序等，另外經過 Model.objects.raw() 函數能夠直接寫自定義的sql，數據訪問這部分更多的函數功能能夠查詢django的文檔，這裏也不在浪費篇幅說明了，上述操做好以後，咱們再啓動django的項目，輸入網址，在網頁上就能看到結果了：

至此咱們的django項目已經運行起來了，而且能夠訪問sqlite3數據庫中的數據，咱們列出目前爲止整個項目目錄的結構以及其說明，方便你們參考：

到目前爲止咱們運行django項目都是經過項目目錄下的 manage.py 進行運行，此種方式僅僅是django爲方便調試而提供的一個簡易的web服務器，在線上環境咱們確定不能這麼使用，那麼接下來咱們須要經過 Nginx、uWSGI與django結合的方式搭建能夠在線上部署的方案

安裝uWSGI

在開始這個話題以前，咱們首先來講明幾個比較重要的概念：

首先要說明的是WSGI，他的全稱叫作Web服務器網關接口（Python Web Server Gateway Interface，縮寫爲WSGI）是爲Python語言定義的Web服務器和Web應用程序或框架之間的一種簡單而通用的接口。WSGI 不是框架，也不是一個模塊而是一個接口規範，是Web服務器與Web應用之間的一種通訊規範，該規範不只僅侷限於Python語言，任何語言編寫的Web服務器和Web應用程序之間均可以使用WSGI來通訊。WSGI標準在 PEP 333 中定義並被許多框架實現，其中包括現咱們這裏的django框架

說了這麼多到底WSGI是什麼呢，WSGI只是一種規範，是用於Web服務器和Web應用程序之間通訊用的，Web服務器咱們知道是提供HTTP服務的服務端程序，例如Nginx、Apache Http Server、Windows IIS 都是常見的Web服務器程序，那麼Web應用程序又是什麼呢。講這個以前咱們須要先回顧一下Web程序的發展歷史，HTTP協議出來以後，做爲服務端的實現，Web服務器開始只能提供對靜態資源的訪問，例如html、圖片資源等等，像下面的形式：

人們不知足於只獲取靜態的網頁內容，就出現了動態的網頁技術，由Web服務器調用一個外部的程序來生成動態的HTML內容返回給瀏覽器端。而這個外部的程序可使用shell，也可使用perl等腳本編寫，或者乾脆使用C語言編寫，這些程序能夠訪問外部數據源來生成HTML。那麼Web服務器程序與這個生成動態HTML內容的外部程序之間經過什麼來傳遞請求參數呢，Web服務器又經過什麼方式來得到並返回由外部程序生成的動態HTML內容呢。由此定義了一個規範，也便是Common Gateway Interface，公共網關接口規範，就是咱們常說的CGI了，這些被Web服務器調用的外部程序也所以被稱爲CGI程序。CGI規範規定：CGI程序從他的標準輸入中，接受Web服務器的輸入(例如請求參數)，並經過標準輸出將生成的HTML內容返回給Web服務器。HTTP請求中的一些變量(例如Host，客戶端ip地址，瀏覽器的Agent信息等)則是由Web服務器設置在環境變量中，再由CGI程序從環境變量中讀取，這種請求模式變成下面的圖：

以後出現了CGI規範的改進版，也即FastCGI規範，FastCGI程序與Web服務器之間的通訊並非經過標準輸入與輸出，也不經過環境變量來與Web服務器交換HTTP的變量信息，FastCGI程序自己是一個獨立的服務端程序，其經過socket監聽端口，與Web服務器通訊，只不過通訊協議使用FastCGI協議而已。那麼咱們這裏說的CGI程序與FastCGI程序是用來處理動態的Web請求並動態生成HTML內容返回給Web服務器的，他們就是咱們所說的Web應用程序。隨着動態語言的發展，涌現出了愈來愈多的動態網頁技術，可是總歸其模式與上面講的差別不大，例如咱們常見的語言的請求結構以下圖所示：

之因此須要Web服務器與Web應用程序這種架構，是由於Web服務器自己不處理動態內容，動態內容的處理交給Web應用程序去處理，Web應用程序由廣大的程序員根據本身的業務需求使用各類各樣的語言去編寫，而Web服務器與Web應用程序之間經過某種規範或者說協議來規定怎樣去通訊，這就出現了各類語言框架下實現的CGI、FastCGI、Servlet、Rack、WSGI等協議或規範，Web服務器與Web應用程序之間若是都遵循相同的協議或實現相同的規範，理論上應該是與語言無關的，因爲各類各樣的緣由，有些規範或者協議，只在特定的語言的web框架中出現或者說多數狀況下是這樣，例如Servlet在Java中使用，Rack在Ruby中使用

在一些狀況下Web服務器與Web應用程序是兩個獨立的進程，他們經過socket進行通訊，通訊協議是雙方都支持的協議規範(例如FastCGI)。還有一些狀況Web服務器與Web應用程序之間的通訊是緊耦合的，好比IIS是經過ISAPI的方式，其實是加載一個dll，調用dll中的相關功能與.NET Web應用交互的。當Nginx與Python Django結合的時候他支持這兩種方式，一種是 Nginx+mod_wsgi 方式，這種方式下由Nginx去調用 mod_wsgi 模塊中的功能，進而調用python的Web應用程序功能動態生成HTML，其運行的上下文環境在 Nginx 進程中：

 

另外一種方式就是上面截圖中展現的經過socket與uWSGI進程交互的方式，Web服務器與uWSGI通訊的協議能夠是 HTTP 協議，也能夠是二進制的 uwsgi 協議，uWSGI程序支持這兩種方式與之通訊，咱們這裏使用二進制 uwsgi 協議的方式，不過咱們首先要安裝 uWSGI 程序(終於說到本章的正題了，前面講原理都是作鋪墊)： 

pip3 install uwsgi
ModuleNotFoundError: No module named '_ctypes'

報錯找不到模塊 '_ctypes' 經查詢咱們須要安裝 libffi-devel 命令以下：

yum install libffi-devel -y

安裝完成以後，咱們須要從新配置Python3.8.1並從新make以及make install，命令在上面都有，這裏就不重複說了，完成以後繼續安裝 uwsgi 沒有報錯，安裝成功，咱們嘗試用下面的命令經過uwsgi啓動django應用：

uwsgi --http :8000 --wsgi-file testdj/wsgi.py

咱們以前說過uWSGI程序支持兩種方式接受請求，一種是使用 HTTP 協議，另外一種是使用二進制的 uwsgi 協議，這裏咱們須要在瀏覽器中直接訪問，因此咱們這裏運行 uwsgi 的時候經過 --http 選項指定 http 協議，並指定 wsgi 應用文件所在的路徑爲django項目根目錄下的 testdj/wsgi.py 文件，啓動以後在瀏覽器中輸入地址直接訪問便可正確出結果，截圖與前面同樣。接下來咱們須要使用 Nginx 來做爲Web服務器並經過uwsgi進程與wsgi應用來處理動態請求。爲何咱們須要Nginx呢，上面運行uwsgi不是已經能夠直接使用了嗎，咱們在以前已經說過了，如今的網站的結構通常都是 Web服務器程序 + 動態語言程序 的結構，是由於各個模塊應該各自作本身擅長的事，wsgi應用擅長處理動態的http請求並生成動態的HTML內容，Nginx是專業的Web服務器擅長其餘的HTTP請求的處理，事實上uWSGI程序中實現了一個簡陋的HTTP服務，因此咱們才能夠經過 HTTP 的方式直接在瀏覽器中訪問他，然而若是靜態資源也用他來處理，其性能確定比Nginx差不少，因此這裏要引入Nginx，引入Nginx的另外一個好處是還能夠作負載均衡

安裝Nginx

首先咱們須要安裝Nginx服務，Nginx是使用很是普遍的高性能Web服務器，在CentOS下安裝也很是簡單：

yum install nginx 

沒有任何報錯，直接安裝完成，固然本身下載源碼安裝想要的版本也很方便，下面咱們須要配置Nginx，安裝以後的nginx的配置文件地址在 /etc/nginx/conf.d/default.conf  

server {
    ...
    listen       80;
    # 靜態文件請求
    location /static {
       alias  /data/testdj/static/;
    }

    # uwsgi_pass 轉向到uWSGI的8000端口
    location / {
       uwsgi_pass  127.0.0.1:8000; 
       include     /etc/nginx/uwsgi_params;
    }
    ...
}

這裏我列出了比較關鍵的配置，第一個static匹配用於請求靜態資源，咱們的靜態資源能夠放在一個單獨的 static 目錄中，這樣靜態資源請求不會轉發到 uWSGI 去處理，而是直接由 Nginx 處理返回，其餘的請求咱們經過 uwsgi_pass 配置轉發到本機的 8000 端口上，實際上這個配置代表咱們的 uWSGI 進程開啓的是以 uwsgi 二進制協議進行 socket 通訊的8000端口，而不是上面的 HTTP 協議的 8000 端口，若是是 HTTP 協議的8000端口，這裏直接配置一個普通的 http 代理便可，配置完成以後 ，咱們如下面的命令啓動 uWSGI程序：

uwsgi --socket 127.0.0.1:8000 --wsgi-file testdj/wsgi.py

咱們這裏使用的是 --socket 而不是 --http 而且監聽的是 127.0.0.1 這個地址，由於咱們的Nginx與uWSGI進程運行在同一臺機器上，這個端口就不用暴露到外面了，啓動 uWSGI 以後，咱們啓動 Nginx進程，直接在瀏覽器中輸入 http://ip 便可以正常訪問了

在後端運行uWSGI進程

咱們前面經過 uwsgi 命令啓動uWSGI的方式，程序跑在咱們shell環境的前端，若是咱們的終端鏈接斷掉則程序會退出，咱們須要之後端服務的形式運行uWSGI，這裏咱們須要將 uWSGI 運行所須要的參數放到一個配置文件中，咱們將這些參數放在 uwsgi.ini 中，固然這個文件名字以及放置的具體路徑並無特殊要求，文件內容以下：

# uwsgi.ini 
[uwsgi]

# uWSGI的端口
socket = 127.0.0.1:8000

# 直接做爲web服務器使用
# http=ip:port

# django項目目錄
chdir           = /data/testdj

# 以django項目名命名的wsgi文件，實際上這個文件是不存在的
# 可是配置必須這麼配
module          = testdj.wsgi
master          = true

#進程數
processes       = 4
threads = 2
vacuum          = true

# 保存啓動以後主進程的pid
pidfile=uwsgi.pid

# 設置uwsgi後臺運行，uwsgi.log保存日誌信息
daemonize=uwsgi.log

設置好以後，咱們在 uwsgi.ini 文件所在的目錄運行下面的命令便可(Nginx不用重啓)：

# -d 參數表示從後臺運行
uwsgi -d --ini uwsgi.ini 

再次訪問網頁，大功告成

收集必應壁紙

文章開頭咱們說咱們要創建一個必應壁紙的收集展現網站，其實主要是介紹 Nginx+uWSGI+Django 的使用，由於網站使用的是 Python語言和Django框架，因此搭建網站也費了一些周折，這個是耗時最多的，其實環境搭建好以後，代碼的編寫反而很簡單，在django中編寫程序很方便。收集必應壁紙自己並無什麼特別要說明的，就是下載天天的必應美圖，將圖片保存到本身的網站，並將相關信息入庫，在網站上展現出來。不過呢這裏簡單說一下怎麼獲取必應的背景壁紙，有一種很容易想到的方法是直接在代碼裏面請求必應的網站，而後查看網頁結構，獲取必應壁紙的url，不過必應的壁紙並無這麼麻煩，經過在Chrome瀏覽器中訪問必應網站發現，必應其實有提供接口，以下：

經過在Chrome瀏覽器中請求必應網站，選擇 "XHR" 能夠看到必應的壁紙是經過一個 Ajax 請求獲取的數據，咱們找到這個請求便可，我貼出來：

https://cn.bing.com/HPImageArchive.aspx?format=js&idx=0&n=1&nc=1587287726147&pid=hp

這個接口裏面的參數是能夠設置的，format表示返回的數據的格式 js 返回的是json格式的數據，n 應該是返回的圖片的張數，idx 應該是分頁的參數，具體的參數含義，你們能夠去網上搜索一下，已經有一些人研究過了。不過好像不管怎麼設置，並無辦法獲取過久的歷史圖片數據，必應的官網上也只能看到最近一週的圖片。也因如此，纔有了本篇文章，必應壁紙收集站的實現徹底使用上面提到的技術，網站也會持續完善中，歡迎你們來這裏反饋留言：關於必應高清壁紙。另外服務器我直接從阿里雲買的低配版本機器，帶寬和性能都比較基礎，目前來講是夠用的，域名是直接從萬網購買並備案的，其實整個流程仍是很便捷的，並且第一年的價格很便宜。 到此本篇介紹就完結了，但願對你們使用django搭建web網站有所幫助