生活随笔
收集整理的這篇文章主要介紹了
WSGI
小編覺得挺不錯的,現在分享給大家,幫大家做個參考.
2019獨角獸企業重金招聘Python工程師標準>>>
前言
本文不涉及WSGI的具體協議的介紹，也不會有協議完整的實現，甚至描述中還會摻雜著本人自己對于WSGI的見解。所有的WSGI官方定義請看http://www.python.org/dev/peps/pep-3333/。
WSGI是什么？
WSGI的官方定義是，the Python Web Server Gateway Interface。從名字就可以看出來，這東西是一個Gateway，也就是網關。網關的作用就是在協議之間進行轉換。
也就是說，WSGI就像是一座橋梁，一邊連著web服務器，另一邊連著用戶的應用。但是呢，這個橋的功能很弱，有時候還需要別的橋來幫忙才能進行處理。
下面對本文出現的一些名詞做定義。wsgi app，又稱應用?，就是一個WSGI application。wsgi container ，又稱容器?，雖然這個部分常常被稱為handler，不過我個人認為handler容易和app混淆，所以我稱之為容器。 wsgi_middleware ，又稱*中間件*。一種特殊類型的程序，專門負責在容器和應用之間干壞事的。
一圖勝千言，直接來一個我自己理解的WSGI架構圖吧
可以看出，服務器，容器和應用之間存在著十分糾結的關系。下面就要把這些糾結的關系理清楚。
WSGI應用
WSGI應用其實就是一個callable的對象。舉一個最簡單的例子，假設存在如下的一個應用：
| 1 | def?application(environ, start_response):? |
| 4 | ??response_headers?=?[('Content-type',?'text/plain'),? |
| 5 | ??????????????????????('Content-Length',?str(12)]? |
| 6 | ??write?=?start_response(status, response_headers)? |
這個WSGI應用簡單的可以用簡陋來形容，但是他的確是一個功能完整的WSGI應用。只不過給人留下了太多的疑點，environ是什么？start_response是什么？為什么可以同時用write和return來返回內容？
對于這些疑問，不妨自己猜測一下他的作用。聯想到CGI，那么environ可能就是一系列的環境變量，用來表示HTTP請求的信息，比如說method 之類的。start_response，可能是接受HTTP response頭信息，然后返回一個write函數，這個write函數可以把HTTP response的body返回給客戶端。return自然是將HTTP response的body信息返回。不過這里的write和函數返回有什么區別？會不會是其實外圍默認調用write對應用返回值進行處理？而且為什么 應用的返回值是一個列表呢？說明肯定存在一個對應用執行結果的迭代輸出過程。難道說他隱含的支持iterator或者generator嗎？
等等，應用執行結果？一個應用既然是一個函數，說明肯定有一個對象去執行它，并且可以猜到，這個對象把environ和start_response傳給應用，將應用的返回結果輸出給客戶端。那么這個對象是什么呢？自然就是WSGI容器了。
WSGI容器
先說說WSGI容器的來源，其實這是我自己編造出來的一個概念。來源就是JavaServlet容器。我個人理解兩者有相似的地方，就順手拿過來用了。
WSGI容器的作用，就是構建一個讓WSGI應用成功執行的環境。成功執行，意味著需要傳入正確的參數，以及正確處理返回的結果，還得把結果返回給客戶端。
所以，WSGI容器的工作流程大致就是，用webserver規定的通信方式，能從webserver獲得正確的request信息，封裝好，傳給WSGI應用執行，正確的返回response。
一般來說，WSGI容器必須依附于現有的webserver的技術才能實現，比如說CGI，FastCGI，或者是embed的模式。
下面利用CGI的方式編寫一個最簡單的WSGI容器。關于WSGI容器的協議官方文檔并沒有具體的說如何實現，只是介紹了一些需要約束的東西。具體內容看PEP3333中的協議。
| 09 | #Make the environ argument? |
| 11 | environ['REQUEST_METHOD']?=?os.environ['REQUEST_METHOD']? |
| 12 | environ['SCRIPT_NAME']?=?os.environ['SCRIPT_NAME']? |
| 13 | environ['PATH_INFO']?=?os.environ['PATH_INFO']? |
| 14 | environ['QUERY_STRING']?=?os.environ['QUERY_STRING']? |
| 15 | environ['CONTENT_TYPE']?=?os.environ['CONTENT_TYPE']? |
| 16 | environ['CONTENT_LENGTH']?=?os.environ['CONTENT_LENGTH']? |
| 17 | environ['SERVER_NAME']?=?os.environ['SERVER_NAME']? |
| 18 | environ['SERVER_PORT']?=?os.environ['SERVER_PORT']? |
| 19 | environ['SERVER_PROTOCOL']?=?os.environ['SERVER_PROTOCOL']? |
| 20 | environ['wsgi.version']?=?(1,?)? |
| 21 | environ['wsgi.url_scheme']?=?'http'? |
| 22 | environ['wsgi.input']????????=?sys.stdin? |
| 23 | environ['wsgi.errors']???????=?sys.stderr? |
| 24 | environ['wsgi.multithread']??=?False? |
| 25 | environ['wsgi.multiprocess']?=?True? |
| 26 | environ['wsgi.run_once']?????=?True? |
| 29 | #make the start_response argument? |
| 30 | #注意，WSGI協議規定，如果沒有body內容，是不能返回http response頭信息的。? |
| 36 | ????global?sent_header? |
| 38 | ????????sys.stdout.write(body)? |
| 40 | ????????print?res_status? |
| 41 | ????????for?k, v?in?res_headers:? |
| 42 | ????????????print?k?+?': '?+?v? |
| 44 | ????????sys.stdout.write(body)? |
| 45 | ????????sent_header?=?True? |
| 47 | def?start_response(status, response_headers):? |
| 49 | ????global?res_headers? |
| 50 | ????res_status?=?status? |
| 51 | ????res_headers?=?response_headers? |
| 54 | #here is the application? |
| 55 | ??def?application(environ, start_response):? |
| 58 | ????response_headers?=?[('Content-type',?'text/plain'),? |
| 59 | ????????????????????????('Content-Length',?str(12)]? |
| 60 | ????write?=?start_response(status, response_headers)? |
| 64 | #here run the application? |
| 65 | result?=?application(environ, start_response)? |
看吧。其實實現一個WSGI容器也不難。
不過我從WSGI容器的設計中可以看出WSGI的應用設計上面存在著一個重大的問題就是：為什么要提供兩種方式返回數據？明明只有一個write函數，卻 既可以在application里面調用，又可以在容器中傳輸應用的返回值來調用。如果說讓我來設計的話，直接把start_response給去掉了。 就用application(environ)這個接口。傳一個方法，然后返回值就是status, response_headers和一個字符串的列表。實際傳輸的方法全部隱藏了。用戶只需要從environ中讀取數據處理就行了。。
可喜的是，搜了一下貌似web3的標準里面應用的設計和我的想法類似。希望web3協議能早日普及。
Middleware中間件
中間件是一類特殊的程序，可以在容器和應用之間干一些壞事。。其實熟悉python的decorator的人就會發現，這和decoraotr沒什么區別。
下面來實現一個route的簡單middleware。
| 02 | ????def?__init__(self):? |
| 03 | ????????self.path_info?=?{}? |
| 04 | ????def?route(self, environ, start_response):? |
| 05 | ????????application?=?self.path_info[environ['PATH_INFO']]? |
| 06 | ????????return?application(environ, start_response)? |
| 07 | ????def?__call__(self, path):? |
| 08 | ????????def?wrapper(application):? |
| 09 | ????????????self.path_info[path]?=?application? |
這就是一個很簡單的路由功能的middleware。將上面那段wsgi容器的代碼里面的應用修改成如下：
| 03 | #here is the application? |
| 05 | def?hello(environ, start_response):? |
| 08 | ????response_headers?=?[('Content-type',?'text/plain'),? |
| 09 | ????????????????????????('Content-Length',?str(len(output)))]? |
| 10 | ????write?=?start_response(status, response_headers)? |
| 14 | def?world(environ, start_response):? |
| 17 | ????response_headers?=?[('Content-type',?'text/plain'),? |
| 18 | ????????????????????????('Content-Length',?str(len(output)))]? |
| 19 | ????write?=?start_response(status, response_headers)? |
| 21 | #here run the application? |
| 22 | result?=?router.route(environ, start_response)? |
這樣，容器就會自動的根據訪問的地址找到對應的app執行了。
延伸
寫著寫著，怎么越來越像一個框架了？看來Python開發框架真是簡單。。
其實從另外一個角度去考慮。如果把application當作是一個運算單元。利用middleware調控IO和運算資源，那么利用WSGI組成一個分布式的系統。
轉載于:https://my.oschina.net/lvrplayer/blog/32659
總結
以上是生活随笔為你收集整理的WSGI的全部內容，希望文章能夠幫你解決所遇到的問題。
如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。
