資訊專欄INFORMATION COLUMN
摘要：百萬量級的產(chǎn)品，扛起來并不費力。當你的網(wǎng)站或者接口有一個用戶訪問時，能在短時間內(nèi)返回，那么，當用戶量達到時，是否能在同樣的時間內(nèi)返回呢這是個問題。對于后端來說，把響應(yīng)時間控制在合理的范圍之內(nèi)是很重要的。其他的也是類似。
分幾點來答：
1. 首先，這其實是個技術(shù)選型題。做技術(shù)選型的時候不能單純的考慮性能，應(yīng)該優(yōu)先考慮業(yè)務(wù)類型，以及團隊水平。另外的話，框架只是其中一環(huán)，還有配套呢。
如果是數(shù)據(jù)驅(qū)動型，尤其是要用到關(guān)系型數(shù)據(jù)庫，那么選擇Django足以，ORM會比較省事，但是性能損耗是個很明顯的問題。不過還是看團隊，如果大家玩flask或者bottle都賊溜，那么還要什么Django，自己造就行了。（題外話，不過你得提防比較水的人破壞整體結(jié)構(gòu)）
如果下游是由很多微服務(wù)構(gòu)成的，Tornado處理起來會有一定優(yōu)勢，用它的異步模型。（而不是用同步的方式寫代碼23333，要是這么用的話，你讓flask怎么想，讓bottle怎么想，讓村東頭的sanic怎么想
??在這里還是要推薦下我自己建的Python開發(fā)學習群：725479218，群里都是學Python開發(fā)的，如果你正在學習Python ，小編歡迎你加入,大家都是軟件開發(fā)黨，不定期分享干貨（只有Python軟件開發(fā)相關(guān)的），包括我自己整理的一份2018最新的Python進階資料和高級開發(fā)教程，歡迎進階中和進想深入Python的小伙伴
2. Django能抗多少量？上面選型如果定下來Django了，那么剩下的就是“Where there is a will, there is a way”的問題。這個問題跟“Where there is a way, there is a will”的差別在于，并不是框架能支撐你到多大的并發(fā)量，而是你想要抗住很大的并發(fā)量，怎么優(yōu)化現(xiàn)有框架。
當你的項目大到一定程度，瓶頸基本不在框架上（換語言另說，有人不懂框架亂搞的另說）。
我們用Django開發(fā)對外的產(chǎn)品不多，量級10w 100w的都有，但是我們上線前的準備都是朝著要抗足夠高的流量目標的（誰沒有一顆抗萬億流量的心呢），并且要能夠通過增加機器提高承載能力。當然有些業(yè)務(wù)類型沒法通過簡單的增加機器來進行擴容，那只能通過其他途徑優(yōu)化單機的TPS。所以最終壓測的結(jié)果都要遠高于真實流量。百萬量級的產(chǎn)品，扛起來并不費力。不過還是強調(diào)一下，看業(yè)務(wù)類型！
3. 用戶體驗問題當量級變大之后，影響用戶體驗嗎？
用戶體驗分很多方面，包括交互，設(shè)計，前端，后端。這里討論的是后端，那么就說后端。后端對用戶體驗的影響只有一個——那就是響應(yīng)時間。當你的網(wǎng)站或者接口有一個用戶訪問時，能在短時間內(nèi)返回response，那么，當用戶量達到10w時，是否能在同樣的時間內(nèi)返回response呢？這是個問題。
對于后端來說，把響應(yīng)時間控制在合理的范圍之內(nèi)是很重要的。20ms和30ms或許差別不大，但是50ms跟100ms會有明顯差別。
怎么衡量合理的返回時間呢？
這塊還是得說點細節(jié)，比方說Django的系統(tǒng)，一個用戶請求進來了，需要涉及多少次Redis查詢，平均每次響應(yīng)時間是多少；涉及到多少次內(nèi)網(wǎng)或者外網(wǎng)的HTTP請求，平均響應(yīng)時間是多少；涉及到多少次MySQL查詢，平均響應(yīng)時間是多少。
所以大家面試時都喜歡問一個問題：用戶輸入網(wǎng)址之后，到頁面展示出來的詳細過程是什么？
當你知道了所有的細節(jié)之后，你就能知道，如果系統(tǒng)只涉及到Redis查詢，那應(yīng)該多少ms內(nèi)返回是合理的，如果你發(fā)現(xiàn)nginx日志里面的后端響應(yīng)時間高于你的預期，那你就得排查下了。其他的也是類似。
所以當談?wù)摰胶蠖松系挠脩趔w驗時，我自己的看法就是，能多快就多快的給他數(shù)據(jù)。磨磨唧唧，妥妥拽拽的最招人煩。
文章版權(quán)歸作者所有，未經(jīng)允許請勿轉(zhuǎn)載,若此文章存在違規(guī)行為，您可以聯(lián)系管理員刪除。
轉(zhuǎn)載請注明本文地址：http://systransis.cn/yun/41899.html
摘要：百萬量級的產(chǎn)品，扛起來并不費力。當你的網(wǎng)站或者接口有一個用戶訪問時，能在短時間內(nèi)返回，那么，當用戶量達到時，是否能在同樣的時間內(nèi)返回呢這是個問題。對于后端來說，把響應(yīng)時間控制在合理的范圍之內(nèi)是很重要的。其他的也是類似。 分幾點來答： 1. 首先，這其實是個技術(shù)選型題。 做技術(shù)選型的時候不能單純的考慮性能，應(yīng)該優(yōu)先考慮業(yè)務(wù)類型，以及團隊水平。另外的話，框架只是其中一環(huán)，還有配套呢。 如果...
摘要：博客網(wǎng)站的用戶信息并不復雜，因此擴展就足夠了?？梢栽谶@個基礎(chǔ)上，擴展為一個美觀詳細的用戶信息頁面。當然最好再給個人信息添加一個入口。沒有對用戶的登錄狀態(tài)進行檢查?？偨Y(jié)本章使用一對一鏈接的方式，擴展并更新了用戶信息。 可能你已經(jīng)發(fā)現(xiàn)了，Django自帶的User模型非常實用，以至于我們沒有寫用戶管理相關(guān)的任何模型。 但是自帶的User畢竟可用的字段較少。比方說非常重要的電話號碼、頭像等都...
摘要：希望能夠幫助到大家，減少在起步階段的油耗，集中精神突破技術(shù)。在平時寫代碼的時候你不一定會用到，但是他卻是你解決問題的思想源泉如果說算法是一個程序員的九陽神功，那么設(shè)計模式就是你的乾坤大挪移。 showImg(https://segmentfault.com/img/remote/1460000019249986); 不知怎么的，最近不少關(guān)注我的讀者都開始私信我怎么學好python？零基...
摘要：存在個人隱私數(shù)據(jù)被審查的風險。首先，我們認為違法數(shù)據(jù)的審查有利于社會和經(jīng)濟的安定。永不關(guān)停對于去中心化存儲的用戶來說，不用擔心運營方關(guān)停的可能性，因為最終去中心化存儲是屬于用戶的，屬于社區(qū)的，并不是屬于公司的。 在這個信息爆炸的時代，數(shù)據(jù)存儲與我們每一個人息息相關(guān)。從打孔卡到軟盤硬盤再到中心化云端存儲服務(wù)，人類在尋求更便捷有效的數(shù)據(jù)存儲方式的道路上從未停下過腳步。未來會出現(xiàn)比如今最流行...
閱讀 1199·2023-04-25 17:05
閱讀 3024·2021-11-19 09:40
閱讀 3577·2021-11-18 10:02
閱讀 1752·2021-09-23 11:45
閱讀 3035·2021-08-20 09:36
閱讀 2794·2021-08-13 15:07
閱讀 1145·2019-08-30 15:55
閱讀 2476·2019-08-30 14:11
