介紹兩個Python web框架：Django & Tornado

在各類語言平臺中，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也有相似的問題；以Twitter爲例，推特到了今日的規模，不要說Rails，甚至是連Ruby都須要拋棄重來。 就個人感受Django適用的是中小型的網站，或者是做爲大型網站快速實現產品雛形的工具。 快速推出產品是王道： 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的模板系統設計十分有意思，也應該其框架內影響最大、爭議最大的部分。 Django模板的設計哲學是完全的將代碼、樣式分離；asp.net提倡將代碼/模板分離，但技術上仍是能夠混合；而Django則是從根本上杜絕在模板中進行編碼、處理數據的可能。 比方說，asp.net模板中能夠寫： <% int i; for(i==0;i<10;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客戶端進行調用。