分享兩個Python web框架：Django&Tornado
Django
Django 應該是最出名的Python框架，Google App Engine甚至Erlang都有框架受它影響。
Django是走大而全的方向，它最出名的是其全自動化的管理后臺：只需要使用起ORM，做簡單的對象定義，它就能自動生成數(shù)據(jù)庫結構、以及全功能的管理后臺。
Django提供的方便，也意味著Django內(nèi)置的ORM跟框架內(nèi)的其他模塊耦合程度高。
應用程序必須使用Django內(nèi)置的ORM，否則就不能享受到框架內(nèi)提供的種種基于其ORM的便利;理論上可以切換掉其ORM模塊，但這就相當于要把裝修完畢的房子拆除重新裝修，倒不如一開始就去毛胚房做全新的裝修。
Django的賣點是超高的開發(fā)效率，其性能擴展有限;采用Django的項目，在流量達到一定規(guī)模后，都需要對其進行重構，才能滿足性能的要求。
這方面的經(jīng)驗可以參考：http://www.slideshare.net/zeeg/djangocon-2010-scaling-disqus
Ruby的Rails也有類似的問題;以Twitter為例，推特到了今日的規(guī)模，不要說Rails，甚至是連Ruby都需要拋棄重來。
就我的感覺Django適用的是中小型的網(wǎng)站，或者是作為大型網(wǎng)站快速實現(xiàn)產(chǎn)品雛形的工具。
快速推出產(chǎn)品是王道：
Believe it or not, the bigger problem isn't scaling, it's getting to the point where you have to scale. Without the first problem you won't have the second. - http://gettingreal.37signals.com/ch04_Scale_Later.php
Django 模板
Django的模板系統(tǒng)設計十分有意思，也應該其框架內(nèi)影響最大、爭議最大的部分。
Django模板的設計哲學是徹底的將代碼、樣式分離;asp.net提倡將代碼/模板分離，但技術上還是可以混合;而Django則是從根本上杜絕在模板中進行編碼、處理數(shù)據(jù)的可能。
比方說，asp.net模板中可以寫：
- <%
- int i;
- for(i==0;i<10;i++){
- ....
- }
- %>
Django是徹底不支持嵌入類似上面的代碼，僅能使用其模板內(nèi)置的函數(shù);這實際上，是為其模板構造了一種“新語言”;由于此“新語言”十分簡單，所以也能夠將其模板移植到不同平臺。
大多數(shù)情況下，Django的模板功能是足夠的，但對于特殊(有時“特殊”也不是十分特殊)的情況，還是需要在模板中嵌入代碼，那么就需要根據(jù)其模板系統(tǒng)的規(guī)則做模板擴展。有時候，模板中直接寫一行代碼能夠解決的問題，用模板擴展實現(xiàn)后，會變成十幾行代碼。
是否容忍在模板中編程，正是Django模板爭議最大之處。
Tornado
Tornado( http://www.tornadoweb.org )是Facebook開源出來的框架，其哲學跟Django近乎兩個極端。
Tornado走的是少而精的方向，它也有提供模板功能;雖然不鼓勵，但作者是可以允許在模板進行少量編碼(直接嵌入單行py代碼)的。
如果跟asp.net相比，Tornado有點類似僅實現(xiàn)了AsyncHttpHandler;除此之外，全部需要自己去實現(xiàn)。
好吧，其實它有模板，有國際化支持，甚至還有內(nèi)置的OAuth/OpenID模塊，方便做第三方登錄，它其實也直接實現(xiàn)了Http服務器。
但它沒有ORM(僅有一個mysql的超簡單封裝)，甚至沒有Session支持，更不要說Django那樣自動化的后臺。
假設是一個大型網(wǎng)站，在高性能的要求下，框架的各個部分往往都需要定制，可以復用的模塊非常少;一個以Django開發(fā)的網(wǎng)站，各部分經(jīng)過不斷的定制，Django框架剩下的，很有可能也就是tornado一開始所能提供的這部分。
殊途同歸。
HTTP服務器
Tornado為了高效實現(xiàn)Comet/后端異步調(diào)用HTTP接口，是直接內(nèi)嵌了HTTP服務器。
前端無需加apache / lighttpd / nginx等也可以供瀏覽器訪問;但它并沒有完整實現(xiàn)HTTP 1.1的協(xié)議，所以官方文檔是推薦用戶在生產(chǎn)環(huán)境下在前端使用nginx，后端反向代理到多個Tornado實例。
Tornado本身是單線程的異步網(wǎng)絡程序，它默認啟動時，會根據(jù)CPU數(shù)量運行多個實例;充分利用CPU多核的優(yōu)勢。
單線程異步
網(wǎng)站基本都會有數(shù)據(jù)庫操作，而Tornado是單線程的，這意味著如果數(shù)據(jù)庫查詢返回過慢，整個服務器響應會被堵塞。
數(shù)據(jù)庫查詢，實質(zhì)上也是遠程的網(wǎng)絡調(diào)用;理想情況下，是將這些操作也封裝成為異步的;但Tornado對此并沒有提供任何支持。
這是Tornado的設計，而不是缺陷。
一個系統(tǒng)，要滿足高流量;是必須解決數(shù)據(jù)庫查詢速度問題的!
數(shù)據(jù)庫若存在查詢性能問題，整個系統(tǒng)無論如何優(yōu)化，數(shù)據(jù)庫都會是瓶頸，拖慢整個系統(tǒng)!
異步并**不能**從本質(zhì)上提到系統(tǒng)的性能;它僅僅是避免多余的網(wǎng)絡響應等待，以及切換線程的CPU耗費。
如果數(shù)據(jù)庫查詢響應太慢，需要解決的是數(shù)據(jù)庫的性能問題;而不是調(diào)用數(shù)據(jù)庫的前端Web應用。
對于實時返回的數(shù)據(jù)查詢，理想情況下需要確保所有數(shù)據(jù)都在內(nèi)存中，數(shù)據(jù)庫硬盤IO應該為0;這樣的查詢才能足夠快;而如果數(shù)據(jù)庫查詢足夠快，那么前端web應用也就無將數(shù)據(jù)查詢封裝為異步的必要。
就算是使用協(xié)程，異步程序對于同步程序始終還是會提高復雜性;需要衡量的是處理這些額外復雜性是否值得。
如果后端有查詢實在是太慢，無法繞過，Tornaod的建議是將這些查詢在后端封裝獨立封裝成為HTTP接口，然后使用Tornado內(nèi)置的異步HTTP客戶端進行調(diào)用。
原文鏈接：http://www.cnblogs.com/wuvist/archive/2011/06/28/django-And-tornado.html
【編輯推薦】
