flask 源碼之旅（基礎）---什麼是 WSGI？

flask源碼之旅（基礎）---WSGI

什麼是WSGI?

想學習python web編程，WSGI是一個繞不開的概念，那麼問題來了，WSGI究竟是什麼呢？咱們又爲何須要它？ 在正式開始對WSGI講解以前，先讓咱們的思緒一塊兒穿越歷史，來到那個戰火紛飛的抗戰年代《諜戰1938》......

小碼是一名英勇的地下黨員，他的手裏掌握了一份珍貴的敵方情報，急需把這份情報上交給組織處理。

小碼遮遮藏藏的找到了領導發生了以下對話：

小碼： 「領導你那邊安全嗎？」

領導：「我安全！你那邊安全嗎？」

小碼：「我安全啊！」

因而小碼放心的上交了情報，領導欣慰的拍了拍小碼的肩：「小夥子乾的不錯嘛！等通知吧」。

以後，領導帶着情報回到了組織，按照組織章程找到專業的情報分析人員。

情報人員通過一頓分析後，再按照組織章程反饋一個分析結果給領導。

領導拿到分析結果後，會把相關狀況通知給小碼，英勇的小碼同志會根據這個狀況決定下一步的行動。

如今咱們經過圖像化的方式表達一下上面的小故事：

猜想一下，在python web裏WSGI是故事中的什麼角色？

......

是領導？

哈哈哈，實際上是組織章程啦！那麼故事中的小碼、情報傳遞約定、領導、情報分析員又都是什麼呢？

這裏我再提供一張圖，你們對照一下：

先後兩張圖片對應一下，是否是就明白了呢。

uWsgi是web服務器，瀏覽器發起HTTP請求，web服務器接收請求後，會根據WSGI協議調用flask框架實現的web應用程序處理請求，flask app處理完畢後把結果反饋回uWsgi web服務器，web服務器對瀏覽器進行HTTP應答。

扮演uWsgi這種web服務器角色的你們耳熟能翔的還有apache，而和flask同樣的web框架在python中還有很出名的django。

web服務器負責接收HTTP請求，解析HTTP請求，根據配置調用後面的處理程序。flask這種框架則能夠認爲是一套工具集，有了這套工具集咱們寫起來應用處理程序更加的方便，駕輕就熟。

那麼Nginx又是什麼呢？咱們每次google搜索flask部署，nginx+uWsgi+flask此類部署形式充斥屏幕。如今讓咱們再回到前面的故事......

小碼這種地下黨員有不少，分佈在全國各地。天天的情報像雪花同樣從四面八方涌來，領導的能力主要體如今組織能力強，能夠勝任調度情報分析人員處理情報的工做，可是這麼多情報領導根本就協調處理不過來啊。

這個時候應該怎麼辦呢？人不夠那就加人唄！因而，組織就新增一些辦事處，每一個辦事處任命領導和情報分析小組，問題就天然能夠獲得解決啊。

可是，小碼懵逼了！那麼多辦事處，他該找那個啊？這個時候，組織又想辦法了，其中一個辦法就是再成立一個情報接收處。情報一概到接收處，情報接收處再根據一些章程把情報分派到各個辦事處去，問題就又解決了。

迴歸正題，想必你們已經明白了，nginx就是情報接收處。nginx優點在於性能高，能夠專門用來接收請求，在Nginx後面咱們能夠部署多個uWsgi Server，由Nginx把請求分發到各個uWsgi Server上去。

問題又來了~沒錯，我就是問題寶寶。Nginx是怎麼把這些請求傳遞到各個uWsgi Server上的呢？

上面，咱們提到了uWsgi服務器自己是能夠直接接收情報的，也就是能夠直接處理HTTP請求。那麼Nginx會直接再把HTTP請求轉發給uWsgi嗎？

理論上是能夠的啊，可是並無這麼作......由於HTTP做爲一個文本協議，實在是不夠高效並且浪費空間。那怎麼辦呢？乾脆咱們另外想一個更好、更快、更強的協議得了！

因而uwsgi橫空出世~(ps：此處有音樂~葫蘆娃~葫蘆娃~一顆藤上七朵花~滴蠟鞭打全不怕~)

沒錯，你們和我一塊兒拼寫一遍，這個協議叫u-w-s-g-i，不是u-W-s-g-i。uwsgi是協議，uWsgi是服務器程序，Nginx能夠經過uwsgi協議和uWsgi服務器交流信息。

因而，新的通訊流程變成了這個醬紫：

好了~文章講到這裏已經基本上要結束了，沒錯是基本上要結束了，也就是尚未結束呢~呵呵

眼尖的童鞋想必已經發現了(我知道並無人發現......)，我上面在講故事的時候提到了一個問題：「那麼多辦事處，小碼該找那個上交情報？」的時候，有說到「其中一個辦法是成立情報接待處」。那就是說還有其餘辦法嘍~

這裏再給你們多講兩句，瀏覽器在訪問web服務的時候通常是經過域名去訪問的。

也就是說，小碼在上交情報的時候，不多會直接去碰頭地點，而是先去一個地方，低聲說一句：「天王蓋地虎」，會有人告訴他，去某某地方吧，那裏有個風同樣的男子在等你。

因而辦法就來了，既然能夠告知小碼這種地下黨員去那裏上交情報，那麼咱們在小王上交情報的時候讓他去辦事處A，在小李上交情報的時候告訴他去辦事處B就能夠了啊。

而後，第二種解決方案的交互圖，給各位讀者老爺們雙手奉上：

最後的最後，把第一種方案的完整交互也補一下：

好了，到這裏整個文章真的要結束了！（長吁一口氣~）

什麼？你問我，若是第一種方案裏Nginx性能也不夠了怎麼辦？ 請參考第二種方案，把它和第一種方案結合一下，是否是感受又能抗的住了，哈哈。

這裏有一個萌萌的二維碼~請你們使勁掃它，不要客氣！