flask 原始碼之旅（基礎）---什麼是 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效能也不夠了怎麼辦？ 請參考第二種方案，把它和第一種方案結合一下，是不是感覺又能抗的住了，哈哈。
這裡有一個萌萌的二維碼~請大家使勁掃它，不要客氣！
