在眾多語言開發中，python湧現的web框架恐怕是最多的

Django

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

Django是走大而全的方向，它最出名的是其全自動化的管理後臺：只需要使用起ORM，做簡單的物件定義，它就能自動生成資料庫結構、以及全功能的管理後臺。

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

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

Django的賣點是超高的開發效率，其效能擴充套件有限；採用Django的專案，在流量達到一定規模後，都需要對其進行重構，才能滿足效能的要求。

Ruby的Rails也有類似的問題；以Twitter為例，推特到了今日的規模，不要說Rails，甚至是連Ruby都需要拋棄重來。

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

Tornado

Tornado是Facebook開源出來的框架，其哲學跟Django近乎兩個極端。

Tornado走的是少而精的方向，它也有提供模板功能；雖然不鼓勵，但作者是可以允許在模板進行少量編碼的。

如果跟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客戶端進行呼叫。

Tornado 是 FriendFeed 使用的可擴充套件的非阻塞式 web 伺服器及其相關工具的開 源版本。這個 Web 框架看起來有些像 web.py 或者 Google 的 webapp，不過為了 能有效利用非阻塞式伺服器環境，這個 Web 框架還包含了一些相關的有用工具和 優化。  Tornado 和現在的主流 Web 伺服器框架（包括大多數 Python 的框架）有著明顯 的區別：它是非阻塞式伺服器，而且速度相當快。得利於其 非阻塞的方式和對 epoll 的運用，Tornado 每秒可以處理數以千計的連線，這意味著對於實時 Web 服務來說，Tornado 是一個理想的 Web 框架。我們開發這個 Web 伺服器的主要 目的就是為了處理 FriendFeed 的實時功能 ——在 FriendFeed 的應用裡每一個活 動使用者都會保持著一個伺服器連線。（關於如何擴容 伺服器，以處理數以千計的 客戶端的連線的問題，請參閱 C10K problem。）  案例： FriendFeed, 知乎