在各種語言平台中,python湧現的web框架恐怕是最多的,是一個百花齊放的世界,各種micro-framework、framework不可勝數;猜想原因應該是在python中構造框架十分簡單,使得輪子不斷被發明。所
以在Python社群總有關於Python框架孰優孰劣的話題。以下就來介紹python的幾大框架:
Django
Django 應該是最有名的py框架,Google App Engine甚至Erlang都有框架受它影響。
Django是走大而全的方向,它最出名的是其全自動化的管理後台:只需要使用起ORM,做簡單的物件定義,它就能自動生成資料庫結構、以及全功能的管理後台。
Django提供的方便,也意味著Django內建的ORM跟框架內的其他模組耦合程度高。
應用程式必須使用Django內建的ORM,否則就不能享受到框架內提供的種種基於其ORM的便利;理論上可以切換掉其ORM模組,但這就相當於要把裝修完畢的房子拆除重新裝修,不如一開始就去毛胚房做
全新的裝修。
Django的賣點是超高的開發效率,其性能擴展有限;採用Django的項目,在流量達到一定規模後,都需要對其進行重構,才能滿足性能的要求。
而Django的缺點主要源自Django堅持自己創造所有的輪子,整個系統相對封閉,Django最為人詬病的地方有:
· 系統緊密耦合,如果你覺得Django內置的某項功能不是很好,想用喜歡的第三方函式庫來代替是很難的,例如下面將要說的ORM、Template。要在Django裡用SQLAlchemy或Mako幾乎是不可能,即使打了一
些補丁用上了也會讓你覺得非常非常彆扭。
· Django自帶的ORM遠不如SQLAlchemy強大,除了在Django這一畝三分地,SQLAlchemy是Python世界裡事實上的ORM標準,其它框架都支持SQLAlchemy了,唯獨Django仍然堅持自己的那一套。 Django的
開發人員對SQLAlchemy的支援也是有 過討論和嘗試的,不過最終還是放棄了,估計是代價太高且跟Django其它的模組很難合到一塊。
· Template功能比較弱,不能插入Python程式碼,要寫複雜一點的邏輯需要另外用Python實作Tag或Filter。 Django的模板系統設計十分有意思,也應該其框架內影響最大、爭議最大的部分。
Django模板的設計哲學是徹底的將程式碼、樣式分離;asp.net提倡將程式碼/模板分離,但技術上還是可以混合;而Django則是從根本上杜絕在模板中進行編碼、處理資料的可能。
比方說,asp.net模板中可以寫:
<%
# int i;
for(i==0;i< 10;i++){
....
}
#%>
Django是徹底不支援嵌入類似上面的程式碼,只能使用其模板內建的函數;這實際上,是為其模板建構了一種「新語言」;由於此「新語言」十分簡單,所以也能夠將其模板移植到不同平台。
大多數情況下,Django的模板功能是足夠的,但對於特殊(有時「特殊」也不是十分特殊)的情況,還是需要在模板中嵌入程式碼,那麼就需要根據其模板系統的規則做模板擴充。有時候,模板中直接寫
一行程式碼能夠解決的問題,用模板擴充實作後,會變成十幾行程式碼。
是否容忍在模板中編程,正是Django模板爭議最大之處。
Pylons & TurboGears & repoze.bfg
除了Django另一個大頭就是Pylons了,因為TurboGears2.x是基於Pylons來做的,而repoze.bfg也已經併入Pylons project裡這個大的專案裡,後面不再單獨討論TurboGears和repoze.bfg了。
Pylons和Django的設計理念完全不同,Pylons本身只有兩千行左右的Python程式碼,不過它還附帶一些幾乎就是Pylons禦用 的第三方模組。 Pylons只提供一個架子和可選方案,你可以根據自己的喜好自
由的選擇Template、ORM、form、auth等元件,系統高度可 自訂。我們常說Python是一個膠水語言(glue language),那我們完全可以說Pylons就是一個用膠水語言設計的膠水框架。
選擇Pylons多是選擇了它的自由,選擇了自由的同時也預示著你選擇了噩夢:
· 學習噩夢,Pylons依賴於許多第三方庫,它們並不是Pylons造,你學Pylons的同時還得學這些庫怎麼使用,關鍵有些時候你都不知道你要學什麼。 Pylons的學習曲線相對比Django要高的多,而之
前Pylons的官方文檔也一直是人批評的對象,好在後來出了The Definitive Guide to Pylons這本書,這一局面有所改觀。因為這個原因,Pylons一度被譽為只適合高手使用的Python框架。
· 調試惡夢,因為牽涉到的模組多,一旦有錯誤發生就比較難定位問題處在哪裡。可能是你寫的程式的錯、也可能是Pylons出錯了、再或是SQLAlchemy出錯了、搞不好是formencode有bug,反正很凌亂
亂了。這個只有用的很熟了才能解決這個問題。
· 升級惡夢,安裝Pylons大大小小共要安裝近20個Python模組,各有各自的版本號,要升級Pylons的版本,哪個模組出了不相容的問題都有可能,升級基本上很難很難。至今reddit的Pylons還停留在
古董的0.9.6上,SQLAlchemy也還是0.5.3的版本,應該跟這條有關係。
Pylons和repoze.bfg的融合可能會催生下一個能挑戰Django地位的框架。
Tornado & web.py
Tornado( http://www.tornadoweb.org )是Facebook開源出來的框架,其哲學跟Django近乎兩個極端。 Tornado就是一個Web server(對此本文不作詳述),同時又是一個類別web.py的micro-framework。
Tornado走的是少而精的方向,它也有提供模板功能;雖然不鼓勵,但作者是可以允許在模板進行少量編碼(直接嵌入單行py代碼)的。
如果跟asp.net相比,Tornado有點類似僅實作了AsyncHttpHandler;除此之外,全部都需要自己去實作。
好吧,其實它有模板,有國際化支持,甚至還有內建的OAuth/OpenID模組,方便做第三方登錄,它其實也直接實現了Http伺服器。
但它沒有ORM(只有一個mysql的超簡單封裝),甚至沒有Session支持,更不要說Django那樣自動化的後台。
假設是一個大型網站,在高性能的要求下,框架的各個部分往往都需要定制,可以復用的模組非常少;一個以Django開發的網站,各部分經過不斷的定制, Django框架剩下的,很有可能也就是tornado一
開始所能提供的這部分。
殊途同歸。
HTTP伺服器
Tornado為了高效實作Comet/後端異步調用HTTP接口,是直接內嵌了HTTP伺服器。
前端無需加apache / lighttpd / nginx等也可以供瀏覽器訪問;但它並沒有完整實現HTTP 1.1的協議,所以官方文檔是推薦用戶在生產環境下在前端使用nginx,後端反向代理到多個Tornado實例。
Tornado本身就是單執行緒的非同步網路程序,它預設啟動時,會根據CPU數量運行多個實例;充分利用CPU多核心的優勢。
單執行緒非同步
網站基本上都會有資料庫操作,而Tornado是單執行緒的,這表示如果資料庫查詢回傳過慢,整個伺服器回應會被堵塞。
資料庫查詢,實質上也是遠端的網路呼叫;理想情況下,是將這些操作也封裝成為非同步的;但Tornado對此並沒有提供任何支援。
一個系統,要滿足高流量;是必須解決資料庫查詢速度問題的!
資料庫若有查詢效能問題,整個系統無論如何優化,資料庫都會是瓶頸,拖慢整個系統!
非同步並**不能**從本質上提到系統的效能;它只是避免多餘的網路回應等待,以及切換執行緒的CPU耗費。
如果資料庫查詢回應太慢,需要解決的是資料庫的效能問題;而不是呼叫資料庫的前端Web應用。
對於即時回傳的資料查詢,理想情況下需要確保所有資料都在記憶體中,資料庫硬碟IO應該為0;這樣的查詢才能夠快;而如果資料庫查詢夠快,那麼前端web應用程式也就無將資料查詢封裝為非同步的必要
。
就算是使用協程,非同步程式對於同步程式始終還是會提高複雜性;需要衡量的是處理這些額外複雜性是否值得。
如果後端有查詢實在是太慢,無法繞過,Tornaod的建議是將這些查詢在後端封裝獨立封裝成為HTTP接口,然後使用Tornado內建的異步HTTP客戶端進行呼叫。
以上是深入了解常用的Python Web的幾大框架的詳細內容。更多資訊請關注PHP中文網其他相關文章!