今天下午在思考以前一直在疑惑的問題。也就是在擁有nginx這樣的服務器存在了為什么還需要uwsgi這樣的服務器。他們之間究竟是什么關系。
我一直在疑惑分層的問題，今天也在這里總結寫出我的思考。
首先上一個我今天梳理的圖片：
Nginx作為我認為傳統意義上的web服務器，一般是認為在最外層也就是暴露在公網上那一層的。其實當我以前還在使用apache服務器的時候就一直在糾結這個問題。當時覺得既然nginx和apache這樣的服務器作為http服務器是一件正常而且理所當然的事情。然后他將把所有的消息交由上層的應用直接處理。我當時是這樣想的。但是后來我接觸了后端，使用了python語言來對web進行開發的時候發現，在nginx和apache 與應用中間似乎還有一段是非透明的，也就是我們今天討論的主角wsgi，那么wsgi究竟是個什么東西？
其實我查了很多資料，資料里面說得最多的就是wsgi就是架起了nginx這種靜態服務器與應用框架之間橋梁的東西，這樣說非常抽象。我來描述一下今天與🔦討論之后我的理解，當我的網站是一個中大型網站的時候，對我們服務的訪問將是成千上萬的。那么這里面包含着各種各樣的服務請求。 nginx作為web服務器將這些請求都收集起來然后主要做一個向背后的真正處理這些請求的應用服務器做轉發。 比如nginx收到了1w個請求，其中有3k個請求要求請求flask框架上的某個接口，那么nginx服務器直接將這個請求轉發給uwsgi應用服務器。應用服務器監聽的端口收到這個請求之后，便開始與框架所在的應用層通信，將該請求按照wsgi的標准交給我們的應用層框架，然后再由引用層將符合標准的數據取出來做處理，處理完畢之后再返回給應用服務器，應用服務器最終將處理好的信息發給nginx再由nginx回給用戶。
看到這里，其實就可以發現，其實我們常看到的wsgi服務器 根本就不是我們傳統意義上理解的nginx和apache這種服務器。而是wsgi_server 應用處理服務器也就是uwsgi gunicorn 和各種框架自帶的wsgi開發用的應用處理服務器。理解這點我認為非常重要。 其實拋開nginx不看我們可以把wsgi分成三個部分。 wsgi_server wsgi_middleware and wsgi_application。
這個過程看上去非常復雜，而其中的很多細節，現在對我來說是不透明的，因為我現在並沒有親手去試過。
但是我的疑惑其實得到一些解答，也就是為什么擁有像nginx這樣的服務器還需要uwgi標准的服務器？試想一下，我們的應用可能擁有各種各樣的服務，可能有些使用php有些使用python，如果我只有某一個wsgi的服務器在進行服務，那么他將監聽所有來自80端口和443端口的請求，對於無法兼容她們的應用，就無法處理這些請求了。所以我們需要一個能處理各種各樣請求並轉發的靜態服務器也就是nginx服務器這樣的角色來做這件事情，然后將對應的請求發給對應的應用服務器進行處理。從而提高效率，分工明確的處理來自互聯網的各種各樣的需求，也使得背后的邏輯顯得更高效和合理。
我最近准備找個時間實踐一個uwsgi服務器。 這將是更近一步了解服務器方面和socket編程的一個好的契機。現在對我來說這一塊還非常不透明。 此篇主要記錄了我的理解，不對的地方還請大家多多指出。