首先要明白web服務(wù)就是一個(gè)解析請(qǐng)求 然后返回響應(yīng)的過(guò)程。
然后明白wsgi是什么？
一套接口標(biāo)準(zhǔn)，用來(lái)實(shí)現(xiàn)在服務(wù)器和python程序之間的轉(zhuǎn)換。使得服務(wù)器和python程序之間能夠交互。
常見(jiàn)的python 的web程序的架構(gòu)一般是這樣子
Nginx-->(wsgi)gunicorn-->framework-->application
wsgi工作在wsgi服務(wù)器和web服務(wù)器的中間，一般是使用nginx來(lái)進(jìn)行反向代理。然后使用gunicorn來(lái)
當(dāng)wsgi服務(wù)器。
wsgi的接口是這樣子的：
wsgi_app(environ, start_response)
environ 包含符合wsgi 標(biāo)準(zhǔn)的一個(gè)字典 如下所示：
{'wsgi.url_scheme': 'http', 'HTTP_ACCEPT_ENCODING': 'gzip, deflate, br', 'SCRIPT_NAME': '', 'HTTP_ACCEPT': 'text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8', 'HTTP_CONNECTION': 'keep-alive', 'REQUEST_METHOD': 'GET', 'SERVER_SOFTWARE': 'Werkzeug/0.12.1', 'HTTP_UPGRADE_INSECURE_REQUESTS': '1', 'SERVER_PROTOCOL': 'HTTP/1.1', 'wsgi.multiprocess': False, 'REMOTE_ADDR': '127.0.0.1', 'QUERY_STRING': 'next=%2F', 'wsgi.run_once': False, 'SERVER_NAME': '127.0.0.1', 'werkzeug.server.shutdown': <function WSGIRequestHandler.make_environ.<locals>.shutdown_server at 0x000000198E7241E0>, 'wsgi.input': <_io.BufferedReader name=828>, 'wsgi.version': (1, 0), 'HTTP_COOKIE': 'UM_distinctid=15c7b3a049547-08fef361539c6f-323f5e0f-144000-15c7b3a049666a; CNZZDATA1262121305=568492071-1496716091-%7C1496716211; csrftoken=ovtMsXELMG8ISgFhdDzqcYJKVParC8ajkCr8Kza6RKQ9reVO3wOiwXuJigTw6Iaa; __wzdbd8a16e4306732acca12=1504512971|1acb4ba715b7; test=tests', 'SERVER_PORT': '5000', 'PATH_INFO': '/login', 'HTTP_ACCEPT_LANGUAGE': 'zh-CN,zh;q=0.8', 'REMOTE_PORT': 64941, 'HTTP_HOST': '127.0.0.1:5000', 'HTTP_USER_AGENT': 'Mozilla/5.0 (Windows NT 6.3; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/60.0.3112.113 Safari/537.36', 'wsgi.errors': <_io.TextIOWrapper name='<stderr>' mode='w' encoding='UTF-8'>, 'werkzeug.request': <BaseRequest 'http://127.0.0.1:5000/login?next=%2F' [GET]>, 'HTTP_CACHE_CONTROL': 'max-age=0', 'wsgi.multithread': False}
這里的environ就是給了一個(gè)request 定義了一個(gè)標(biāo)準(zhǔn)。
start_response 是一個(gè)返回響應(yīng)的函數(shù)，通過(guò)request來(lái)產(chǎn)生響應(yīng)。
那么wsgi服務(wù)器具體做了什么 ，它究竟是干什么的呢？
其實(shí)主要就是將數(shù)據(jù)轉(zhuǎn)化成wsgi格式的 。具體整個(gè)wsgi后面發(fā)生了什么呢?
下面來(lái)閱讀整個(gè)flask框架。首先要明白的是flask的框架不過(guò)是應(yīng)用和wsgi 之間的一層抽象。
主要提供的功能就是路由綁定 即將路由和具體的執(zhí)行函數(shù)綁定在一起。
def dispatch_request(self):
try:
endpoint, values = self.match_request()
return self.view_functions[endpoint](**values)
except HTTPException, e:
handler = self.error_handlers.get(e.code)
if handler is None:
return e
return handler(e)
except Exception, e:
handler = self.error_handlers.get(500)
if self.debug or handler is None:
raise
return handler(e)
這個(gè)函數(shù)根據(jù)相應(yīng)的路由返回對(duì)應(yīng)的響應(yīng)。
那么在這之前就需要一個(gè)在程序啟動(dòng)一開(kāi)始就把函數(shù)和路由綁定的方法。
def route(self, rule, **options):
def decorator(f):
self.add_url_rule(rule, f.__name__, **options)
self.view_functions[f.__name__] = f
return f
return decorator
這就是flask中的 @app.route 的route，使用裝飾器，將函數(shù)名字和路由綁定在一起。
比如
@app.route('/test/<int:id>')
def test(id):
do something
這里將這個(gè)路由和 test這個(gè)函數(shù)綁定在一起。這里還有動(dòng)態(tài)參數(shù)這個(gè)概念。即 <>中的部分。這個(gè)依靠
正則表達(dá)式來(lái)獲取值。
整個(gè)流程就是這樣子的：
例： 瀏覽器--> 請(qǐng)求/test/32--> 經(jīng)過(guò)wsgi服務(wù)器，environ中有一個(gè)path，上面的那個(gè)dispatch-request函數(shù)來(lái)
從路由字典中尋找 發(fā)現(xiàn) test函數(shù)對(duì)應(yīng)的是 這個(gè)類(lèi)型的路由。 解析出 動(dòng)態(tài)參數(shù)，傳給test函數(shù)。
還有一個(gè)問(wèn)題 有一些任務(wù)是需要在整個(gè)流程前執(zhí)行的，那么需要有這么一種機(jī)制來(lái)進(jìn)行執(zhí)行。
flask 中有這么一個(gè)變量
self.before_request_funcs
用來(lái)保存需要先執(zhí)行的函數(shù)。
def preprocess_request(self):
for func in self.before_request_funcs:
rv = func()
if rv is not None:
return rv
def wsgi_app(self, environ, start_response):
with self.request_context(environ):
rv = self.preprocess_request()
if rv is None:
rv = self.dispatch_request()
response = self.make_response(rv)
response = self.process_response(response)
return response(environ, start_response)
可以看到首先是執(zhí)行before_request_funcs這個(gè)字典中的函數(shù)。同理如果有需要在每次請(qǐng)求之后執(zhí)行的
函數(shù)也是這樣子，變動(dòng)的是 變成了在每次返回響應(yīng)之前執(zhí)行，即執(zhí)行完具體的路由函數(shù)后。
這應(yīng)該是框架最主要的功能。現(xiàn)在使用這個(gè)就可以寫(xiě)web程序了。
但是還有一個(gè)問(wèn)題，http是無(wú)狀態(tài)的協(xié)議，如果有多個(gè)用戶(hù)登錄網(wǎng)站，如何判斷那個(gè)是那個(gè)呢？
這時(shí)就需要session 來(lái)實(shí)現(xiàn)了。 用session來(lái)維持會(huì)話(huà)，給每個(gè)請(qǐng)求一個(gè)cookie標(biāo)識(shí)，服務(wù)端通過(guò)這個(gè)
cookie來(lái)判斷那個(gè)是那個(gè)用戶(hù)。flask自帶的session都是存在客戶(hù)端的，考慮到安全，使用了加密。
在服務(wù)端保存一個(gè)密鑰，每次需要這個(gè)密鑰來(lái)進(jìn)行信息讀取。
flask_login 這個(gè)擴(kuò)展模塊使用了這個(gè)機(jī)制來(lái)進(jìn)行登錄管理，通過(guò)保存用戶(hù)的id， 可以很清楚的知道具體是那個(gè)
用戶(hù)在登錄，對(duì)一些必須登錄的界面也可以很方便的進(jìn)行管理。使用裝飾器這個(gè)語(yǔ)法糖 寫(xiě)起來(lái)是這樣子的：
@app.route('/mypost')
@login_reqired
def mypost()：
do something
這樣子就可以對(duì)一些頁(yè)面實(shí)現(xiàn)訪(fǎng)問(wèn)控制了。
最后還有一個(gè)比較理解的地方，即flask中的上下文。
Flask中分為請(qǐng)求上下文 requestcontext 和 應(yīng)用上下文 appcontext
這背后的主要實(shí)現(xiàn)是靠：
LocalStack(object):
LocalProxy(object):
這種上下文像threadlocal，各個(gè)線(xiàn)程的對(duì)象 面向其他線(xiàn)程是隔離的。
為什么要這樣子呢？
因?yàn)樵诓l(fā)的時(shí)候如果是多個(gè)線(xiàn)程共享一個(gè)上下文，很容易出現(xiàn)混亂。
這就是對(duì)一些全局的變量進(jìn)行了隔離。
應(yīng)用上下文的作用
首先 代碼在執(zhí)行的時(shí)候處于兩種狀態(tài)，一種是已經(jīng)壓入上下文的一種是沒(méi)壓入的。
所以在執(zhí)行一些操作時(shí)經(jīng)常遇到 不在上下文這樣子的錯(cuò)誤。
上面使用棧實(shí)現(xiàn)這種結(jié)構(gòu)的原因是因?yàn)镕lask是支持在一個(gè)python進(jìn)程中有多個(gè)應(yīng)用的。
下面來(lái)看這幾類(lèi)的實(shí)現(xiàn)
首先是聲明兩個(gè)實(shí)例 一個(gè)代表請(qǐng)求上下文 一個(gè)代表應(yīng)用上下文
_request_ctx_stack = LocalStack()
_app_ctx_stack = LocalStack()
然后來(lái)翻看werkzeug的源碼 發(fā)現(xiàn)這幾個(gè)類(lèi)實(shí)現(xiàn)的很巧妙。
這里面自己實(shí)現(xiàn)了類(lèi)似 threadlocal 的東西。
如果有g(shù)reenlet存在則首先使用greenlet
實(shí)現(xiàn)這種隔離就是通過(guò)不同的線(xiàn)程id 不同實(shí)現(xiàn)隔離。
__slots__ = ('__storage__', '__ident_func__')
def __setattr__(self, name, value):
storage[ident][name] = value
最主要的就是通過(guò)上面幾行代碼來(lái)實(shí)現(xiàn)的。
通過(guò)不同的線(xiàn)程id 和 來(lái)保存不同的函數(shù)名字，和值對(duì)應(yīng)起來(lái)。
LocalStack 使用local來(lái)實(shí)現(xiàn)棧
def push(self, obj):
"""Pushes a new item to the stack"""
rv = getattr(self._local, 'stack', None)
if rv is None:
self._local.stack = rv = []
rv.append(obj)
return rv
local 和 lcoalstack方法都實(shí)現(xiàn)了 __call__ 調(diào)用localproxy。這里是一個(gè)代理模式的最佳實(shí)踐。
ls = Localstack()
ls.push(10) # 還是localstack對(duì)象
proxy = ls() # 變成了localproxy 對(duì)象
幾乎全部的操作都被代理。
使用
_get_current_object 獲取真正的對(duì)象。
現(xiàn)在最基本的就差不多完了。但是又出現(xiàn)了一個(gè)問(wèn)題。當(dāng)一個(gè)程序開(kāi)始變得比較大，功能開(kāi)始繁雜。開(kāi)始多個(gè)人寫(xiě)同一個(gè)app，
使用之前的方式在一個(gè)文件中進(jìn)行開(kāi)發(fā)是很痛苦的事情。這個(gè)時(shí)候就需要一些方式來(lái)對(duì)其進(jìn)行解耦。使用一些手段來(lái)進(jìn)行拆分。
這時(shí)藍(lán)圖就出現(xiàn)了，以一種模塊的方式來(lái)將代碼進(jìn)行解耦。
官方文檔是這樣說(shuō)明藍(lán)圖的應(yīng)用場(chǎng)景的
* 把一個(gè)應(yīng)用分解為一個(gè)藍(lán)圖的集合。這對(duì)大型應(yīng)用是理想的。一個(gè)項(xiàng)目可以實(shí)例化一個(gè)應(yīng)用對(duì)象，初始化幾個(gè)擴(kuò)展，并注冊(cè)一集合的藍(lán)圖。
* 以 URL 前綴和/或子域名，在應(yīng)用上注冊(cè)一個(gè)藍(lán)圖。 URL 前綴/子域名中的參數(shù)即成為這個(gè)藍(lán)圖下的所有視圖函數(shù)的共同的視圖參數(shù)（默認(rèn)情況下）。
* 在一個(gè)應(yīng)用中用不同的 URL 規(guī)則多次注冊(cè)一個(gè)藍(lán)圖。
* 通過(guò)藍(lán)圖提供模板過(guò)濾器、靜態(tài)文件、模板和其它功能。一個(gè)藍(lán)圖不一定要實(shí)現(xiàn)應(yīng)用或者視圖函數(shù)。
* 初始化一個(gè) Flask 擴(kuò)展時(shí)，在這些情況中注冊(cè)一個(gè)藍(lán)圖。
比如一個(gè)網(wǎng)站 一般包含 -->登錄認(rèn)證 api 主頁(yè)面 。。。各種功能
不使用藍(lán)圖的話(huà)就是一堆代碼耦合在一起，對(duì)控制復(fù)雜度很不利。 使用藍(lán)圖的話(huà)
認(rèn)證模塊 使用auth api就使用api 主頁(yè)面使用main 開(kāi)頭的方法。各自模塊的代碼放在
各自的python文件中，不同模塊的靜態(tài)文件也放在不同的文件中，管理起來(lái)很方便。
最簡(jiǎn)單的實(shí)現(xiàn)藍(lán)圖的方法就是對(duì)注冊(cè)的藍(lán)圖直接加上前綴
大概如下
main = register(prefix，blueprint_folder)
main.add_url_route(prefix+rule, ...)。。。
總結(jié) ：
從計(jì)算機(jī)網(wǎng)絡(luò)中學(xué)習(xí)到的很重要的一個(gè)概念就是分層。使用合理的層次來(lái)把任務(wù)進(jìn)行劃分。各層間保存相互獨(dú)立。
通過(guò)一個(gè)叫SAP(服務(wù)訪(fǎng)問(wèn)點(diǎn))的東西來(lái)實(shí)現(xiàn)各層間的訪(fǎng)問(wèn)。如上圖，從最下層的Baseserver 到 tcpserver 到httpserver
到wsgiserver 每一層的功能都很明確，具體要在那一層進(jìn)行任務(wù)只關(guān)心它的下一層就好了。還有很主要的一點(diǎn)，不管是
一個(gè)概念的出現(xiàn)，還是一個(gè)新技術(shù)的出現(xiàn)都是前人發(fā)現(xiàn)現(xiàn)有的技術(shù)無(wú)法滿(mǎn)足需求，有更好的方法來(lái)解決問(wèn)題，從而出現(xiàn)
了新技術(shù)。大部分東西看其本質(zhì)還是那些。理解好了最根基的那些東西，再出來(lái)什么新的東西不過(guò)是到了一定時(shí)間點(diǎn)正好
該出來(lái)的東西。有了根基 無(wú)非就是看看就能夠開(kāi)始使用。
