Django適合作大用戶量的系統嗎?

分幾點來答:前端

1. 首先,這實際上是個技術選型題。

作技術選型的時候不能單純的考慮性能,應該優先考慮業務類型,以及團隊水平。另外的話,框架只是其中一環,還有配套呢。nginx

若是是數據驅動型,尤爲是要用到關係型數據庫,那麼選擇Django足以,ORM會比較省事,可是性能損耗是個很明顯的問題。不過仍是看團隊,若是你們玩flask或者bottle都賊溜,那麼還要什麼Django,本身造就好了。(題外話,不過你得提防比較水的人破壞總體結構)面試

若是下游是由不少微服務構成的,Tornado處理起來會有必定優點,用它的異步模型。(而不是用同步的方式寫代碼23333,要是這麼用的話,你讓flask怎麼想,讓bottle怎麼想,讓村東頭的sanic怎麼想數據庫

  在這裏仍是要推薦下我本身建的Python開發學習羣:725479218,羣裏都是學Python開發的,若是你正在學習Python ,小編歡迎你加入,你們都是軟件開發黨,不按期分享乾貨(只有Python軟件開發相關的),包括我本身整理的一份2018最新的Python進階資料和高級開發教程,歡迎進階中和進想深刻Python的小夥伴flask

2. Django能抗多少許?

上面選型若是定下來Django了,那麼剩下的就是「Where there is a will, there is a way」的問題。這個問題跟「Where there is a way, there is a will」的差異在於,並非框架能支撐你到多大的併發量,而是你想要抗住很大的併發量,怎麼優化現有框架。後端

當你的項目大到必定程度,瓶頸基本不在框架上(換語言另說,有人不懂框架亂搞的另說)。併發

咱們用Django開發對外的產品很少,量級10w 100w的都有,可是咱們上線前的準備都是朝着要抗足夠高的流量目標的(誰沒有一顆抗萬億流量的心呢),而且要可以經過增長機器提升承載能力。固然有些業務類型無法經過簡單的增長機器來進行擴容,那隻能經過其餘途徑優化單機的TPS。因此最終壓測的結果都要遠高於真實流量。百萬量級的產品,扛起來並不費力。不過仍是強調一下,看業務類型!框架

3. 用戶體驗問題

當量級變大以後,影響用戶體驗嗎?異步

用戶體驗分不少方面,包括交互,設計,前端,後端。這裏討論的是後端,那麼就說後端。後端對用戶體驗的影響只有一個——那就是響應時間。當你的網站或者接口有一個用戶訪問時,能在短期內返回response,那麼,當用戶量達到10w時,是否能在一樣的時間內返回response呢?這是個問題。微服務

對於後端來講,把響應時間控制在合理的範圍以內是很重要的。20ms和30ms或許差異不大,可是50ms跟100ms會有明顯差異。

怎麼衡量合理的返回時間呢?

這塊仍是得說點細節,比方說Django的系統,一個用戶請求進來了,須要涉及多少次Redis查詢,平均每次響應時間是多少;涉及到多少次內網或者外網的HTTP請求,平均響應時間是多少;涉及到多少次MySQL查詢,平均響應時間是多少。

因此你們面試時都喜歡問一個問題:用戶輸入網址以後,到頁面展現出來的詳細過程是什麼?

當你知道了全部的細節以後,你就能知道,若是系統只涉及到Redis查詢,那應該多少ms內返回是合理的,若是你發現nginx日誌裏面的後端響應時間高於你的預期,那你就得排查下了。其餘的也是相似。

因此當談論到後端上的用戶體驗時,我本身的見解就是,能多快就多快的給他數據。磨磨唧唧,妥妥拽拽的最招人煩。

相關文章
相關標籤/搜索