兩個Python web框架:Django & Tornado比較

高洛峰
發布: 2016-10-17 14:17:22
原創
1430 人瀏覽過

在各種語言平台中,python湧現的web框架恐怕是最多的;猜想原因應該是在py中構造框架十分簡單,使得輪子不斷被發明。


這裡記述一下我了解過的兩個py web框架,供大家參考,希望能起他山之石的作用。


Django


Django 應該是最出名的py框架,Google App Engine甚至Erlang都有框架受它影響。


Django是走大而全的方向,它最出名的是其全自動化的管理後台:只需要使用起ORM,做簡單的對象定義,它就能自動生成數據庫結構、以及全功能的管理後台。


Django提供的方便,也意味著Django內建的ORM跟框架內的其他模組耦合程度高。


應用程式必須使用Django內建的ORM,否則就不能享受到框架內提供的種種基於其ORM的便利;理論上可以切換掉其ORM模組,但這就相當於要把裝修完畢的房子拆除重新裝修,不如一開始就去毛胚房做全新的裝修。


Django的賣點是超高的開發效率,其性能擴展有限;採用Django的項目,在流量達到一定規模後,都需要對其進行重構,才能滿足性能的要求。


這方面的經驗可以參考:http://www.slideshare.net/zeeg/djangocon-2010-scaling-disqus


Ruby的Rails也有類似的問題;特到了今日的規模,不要說Rails,甚至連Ruby都需要拋棄重來。


就我的感覺Django適用的是中小型的網站,或者是作為大型網站快速實現產品雛形的工具。


快速推出產品是王道:

 Believe it or not, the bigger problem isn't scaling, it's getting to the point where you have to scave. http://gettingreal.37signals.com/ch04_Scale_Later.php


===== Django 模板=====

Django的模板系統設計十分有意思,也應該其框架內影響最大、爭議最大的部分。


Django模板的設計哲學是徹底的將程式碼、樣式分離;asp.net提倡將程式碼/模板分離,但技術上還是可以混合;而Django則是從根本上杜絕在模板中進行編碼、處理資料的可能。


比方說,asp.net模板中可以寫:

 int i;

 for(i==0;i

 for(i==0;i}

%>


Django是徹底不支援嵌入類似上面的程式碼,只能使用其模板內建的函數;這實際上,是為其模板構造了一種「新語言」;由於此「新語言」十分簡單,所以也能夠將其模板移植到不同平台。


大多數情況下,Django的模板功能是足夠的,但對於特殊(有時「特殊」也不是十分特殊)的情況,還是需要在模板中嵌入程式碼,那麼就需要根據其模板系統的規則做模板擴充。有時候,模板中直接寫一行程式碼能夠解決的問題,用模板擴充實作後,會變成十幾行程式碼。


是否容忍在模板中編程,正是Django模板爭議最大之處。


Tornado


Tornado( http://www.tornadoweb.org )是Facebook開源出來的框架,其哲學跟Django近乎極端。


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對此並**沒有**提供任何支援。


這是Tornado的**設計**,而不是缺陷。


一個系統,要滿足高流量;是必須解決資料庫查詢速度問題的!


資料庫若有查詢效能問題,整個系統無論如何優化,資料庫都會是瓶頸,拖慢整個系統!


異步並**不能**從本質上提到系統的性能;它僅僅是避免多餘的網絡響應等待,以及切換線程的CPU耗費。


如果資料庫查詢回應太慢,需要解決的是資料庫的效能問題;而不是呼叫資料庫的前端Web應用。


對於即時返回的資料查詢,理想情況下需要確保所有資料都在記憶體中,資料庫硬碟IO應該是0;這樣的查詢才能夠快;而如果資料庫查詢夠快,那麼前端web應用程式也就無將資料查詢封裝為非同步的必要。


就算是使用協程,非同步程序對於同步程序始終還是會提高複雜性;需要衡量的是處理這些額外複雜性是否值得。


如果後端有查詢實在是太慢,無法繞過,Tornaod的建議是將這些查詢在後端封裝獨立封裝成為HTTP接口,然後使用Tornado內建的非同步HTTP客戶端進行呼叫。



來源:php.cn
本網站聲明
本文內容由網友自願投稿,版權歸原作者所有。本站不承擔相應的法律責任。如發現涉嫌抄襲或侵權的內容,請聯絡admin@php.cn
熱門教學
更多>
最新下載
更多>
網站特效
網站源碼
網站素材
前端模板