Django適合做大用戶量的系統(tǒng)嗎？

DataPipeline 發(fā)布于2019-07-30 16:54 / 715人閱讀

摘要：百萬(wàn)量級(jí)的產(chǎn)品，扛起來(lái)并不費(fèi)力。當(dāng)你的網(wǎng)站或者接口有一個(gè)用戶訪問(wèn)時(shí)，能在短時(shí)間內(nèi)返回，那么，當(dāng)用戶量達(dá)到時(shí)，是否能在同樣的時(shí)間內(nèi)返回呢這是個(gè)問(wèn)題。對(duì)于后端來(lái)說(shuō)，把響應(yīng)時(shí)間控制在合理的范圍之內(nèi)是很重要的。其他的也是類似。

分幾點(diǎn)來(lái)答：

1. 首先，這其實(shí)是個(gè)技術(shù)選型題。

做技術(shù)選型的時(shí)候不能單純的考慮性能，應(yīng)該優(yōu)先考慮業(yè)務(wù)類型，以及團(tuán)隊(duì)水平。另外的話，框架只是其中一環(huán)，還有配套呢。

如果是數(shù)據(jù)驅(qū)動(dòng)型，尤其是要用到關(guān)系型數(shù)據(jù)庫(kù)，那么選擇Django足以，ORM會(huì)比較省事，但是性能損耗是個(gè)很明顯的問(wèn)題。不過(guò)還是看團(tuán)隊(duì)，如果大家玩flask或者bottle都賊溜，那么還要什么Django，自己造就行了。（題外話，不過(guò)你得提防比較水的人破壞整體結(jié)構(gòu)）

如果下游是由很多微服務(wù)構(gòu)成的，Tornado處理起來(lái)會(huì)有一定優(yōu)勢(shì)，用它的異步模型。（而不是用同步的方式寫代碼23333，要是這么用的話，你讓flask怎么想，讓bottle怎么想，讓村東頭的sanic怎么想

??在這里還是要推薦下我自己建的Python開(kāi)發(fā)學(xué)習(xí)群：725479218，群里都是學(xué)Python開(kāi)發(fā)的，如果你正在學(xué)習(xí)Python ，小編歡迎你加入,大家都是軟件開(kāi)發(fā)黨，不定期分享干貨（只有Python軟件開(kāi)發(fā)相關(guān)的），包括我自己整理的一份2018最新的Python進(jìn)階資料和高級(jí)開(kāi)發(fā)教程，歡迎進(jìn)階中和進(jìn)想深入Python的小伙伴

2. Django能抗多少量？

上面選型如果定下來(lái)Django了，那么剩下的就是“Where there is a will, there is a way”的問(wèn)題。這個(gè)問(wèn)題跟“Where there is a way, there is a will”的差別在于，并不是框架能支撐你到多大的并發(fā)量，而是你想要抗住很大的并發(fā)量，怎么優(yōu)化現(xiàn)有框架。

當(dāng)你的項(xiàng)目大到一定程度，瓶頸基本不在框架上（換語(yǔ)言另說(shuō)，有人不懂框架亂搞的另說(shuō)）。

我們用Django開(kāi)發(fā)對(duì)外的產(chǎn)品不多，量級(jí)10w 100w的都有，但是我們上線前的準(zhǔn)備都是朝著要抗足夠高的流量目標(biāo)的（誰(shuí)沒(méi)有一顆抗萬(wàn)億流量的心呢），并且要能夠通過(guò)增加機(jī)器提高承載能力。當(dāng)然有些業(yè)務(wù)類型沒(méi)法通過(guò)簡(jiǎn)單的增加機(jī)器來(lái)進(jìn)行擴(kuò)容，那只能通過(guò)其他途徑優(yōu)化單機(jī)的TPS。所以最終壓測(cè)的結(jié)果都要遠(yuǎn)高于真實(shí)流量。百萬(wàn)量級(jí)的產(chǎn)品，扛起來(lái)并不費(fèi)力。不過(guò)還是強(qiáng)調(diào)一下，看業(yè)務(wù)類型！

3. 用戶體驗(yàn)問(wèn)題

當(dāng)量級(jí)變大之后，影響用戶體驗(yàn)嗎？

用戶體驗(yàn)分很多方面，包括交互，設(shè)計(jì)，前端，后端。這里討論的是后端，那么就說(shuō)后端。后端對(duì)用戶體驗(yàn)的影響只有一個(gè)——那就是響應(yīng)時(shí)間。當(dāng)你的網(wǎng)站或者接口有一個(gè)用戶訪問(wèn)時(shí)，能在短時(shí)間內(nèi)返回response，那么，當(dāng)用戶量達(dá)到10w時(shí)，是否能在同樣的時(shí)間內(nèi)返回response呢？這是個(gè)問(wèn)題。

對(duì)于后端來(lái)說(shuō)，把響應(yīng)時(shí)間控制在合理的范圍之內(nèi)是很重要的。20ms和30ms或許差別不大，但是50ms跟100ms會(huì)有明顯差別。

怎么衡量合理的返回時(shí)間呢？

這塊還是得說(shuō)點(diǎn)細(xì)節(jié)，比方說(shuō)Django的系統(tǒng)，一個(gè)用戶請(qǐng)求進(jìn)來(lái)了，需要涉及多少次Redis查詢，平均每次響應(yīng)時(shí)間是多少；涉及到多少次內(nèi)網(wǎng)或者外網(wǎng)的HTTP請(qǐng)求，平均響應(yīng)時(shí)間是多少；涉及到多少次MySQL查詢，平均響應(yīng)時(shí)間是多少。

所以大家面試時(shí)都喜歡問(wèn)一個(gè)問(wèn)題：用戶輸入網(wǎng)址之后，到頁(yè)面展示出來(lái)的詳細(xì)過(guò)程是什么？

當(dāng)你知道了所有的細(xì)節(jié)之后，你就能知道，如果系統(tǒng)只涉及到Redis查詢，那應(yīng)該多少ms內(nèi)返回是合理的，如果你發(fā)現(xiàn)nginx日志里面的后端響應(yīng)時(shí)間高于你的預(yù)期，那你就得排查下了。其他的也是類似。

所以當(dāng)談?wù)摰胶蠖松系挠脩趔w驗(yàn)時(shí)，我自己的看法就是，能多快就多快的給他數(shù)據(jù)。磨磨唧唧，妥妥拽拽的最招人煩。