1. 需求來源和變動

1.1 需求的來源

最近負責的專案是 一個題庫系統，客戶通過excel來批量錄入試題，且題里面會有圖片和視頻，所以采用的方案是
① excel中使用某種規則運算式來表示圖片
② 客戶手動上傳圖片（得到圖片路徑）
③ code中使用正則替換excel里面的圖片運算式為正常的圖片路徑

這篇文章說的主要是和②有關的一些問題

1.2 用嘴說的原型圖 （可略過）

和產品要了幾次原型圖，都沒有給，最后口述了一下：“就是在原頁面上，出現一個上傳圖片的按鈕，然后出現 一行預覽的就可以，你看著做就行”，這讓我想起了之前去藥店買藥，藥店擺開了3盒藥，問我想吃哪盒，

另一個產品則不耐煩的告訴我們做成和老系統一樣就可以（老系統的互動只能錄單題，是上傳到富文本編輯器里面，且一次性只能上傳1張）

做的程序中，對一次性最多上傳多少張，產品也含糊其辭，我自定義了最多50張，產品也附和著說應該夠用，

后來又一直催著上線，所以就做了解決方案1.0 上線（多圖片單介面）

1.3 需求的實際變動

1.3.1 無窮盡的欲望

① 客戶實際用的時候，最猛一次性錄了近5k道題目，后來后臺介面限制了一次性最多1k道題，
② 一次性1k道題的情況下，客戶又說想一次性上傳幾百張圖片，分批次上傳太麻煩了，產品讓把50張圖片的限制放開了，

1.3.2 網速問題

放開限制以后，客戶一次性上傳了250張，因為是多圖片單介面的,且介面有timeout （1分鐘），所以超時了，且客戶公司網速也很不穩定，（上傳同樣一張200kb的圖片有時候是幾ms，有時候是幾s，有時候甚至更長）

1.3.3 改革

產品一字不落的轉述了客戶的需求 ：”我們人手不足，題很多，別說200張，一次性300張也是家常便飯，不要耽誤我們錄題的進度”，產品表示問題必須盡快解決

2. 解決方案1.0（多圖片單介面模式）

多圖片單介面，說白了，就是所有圖片都通過一個介面上傳，1張圖片是一個介面，300張圖片也是一個介面

3. 解決方案優化程序 （精華）

3.1. 困境

多圖片單介面因為網速和圖片數量的問題，介面超時就比較常見了，且功能比較簡陋，沒有做歷史上傳判斷，所以一批圖片，成功了就都成功了，失敗一個，就判斷都不成功，

排在前面有幾條路：
① 讓客戶多傳幾次（他們那邊其實人不少，有10幾個人在負責，從最后資料來看，帶圖片試題只有1500道左右，按照我們一開始的限定一次性50張，只需要每個人上傳幾次就可以，這是后話了， 當時的情況是客戶一口咬定她們圖片很多很多，多到她們自己都不知道多少張），
② 走單圖片單介面的方案（自己感覺比較low，哈哈）
③ 做成網盤異步那種（和產品溝通以后，產品表示“這樣改太麻煩了，人家著急用呢”）
④ 讓后臺介面放開超時時間（后臺表示timeout可以放開，但是不能無限放開，這次他們要300，下次他們要1000怎么辦，再下次要2000怎么辦）

3.2. 集思廣益

3.2.1 微信群

我在一個微信大佬群里面，發出了我的疑惑，一會兒一個大佬回復我的疑惑

3.2.2 后臺同事

我問幾個后臺同事 “如果一次性上傳1000張圖片，單圖單介面和多圖單介面，你們選哪個”

java同事A，說：“(￣ェ￣;) 你要往服務器上傳片兒嗎？”，哦，天吶，看看我的沙雕同事，“現在不都是在線看嗎，，，“

java同事B，說：“他會選單圖單介面，因為會有粒度控制（即進度條）”

java同事C，說：“他也會選擇單圖單介面，后臺介面或nginx的timeout雖然可以放開，但是不能無限放開，而且單圖單介面也可以優化多單圖單介面和多圖單介面相混合的”

3.2.3 android同事

android 小姐姐說，她們android平時批量上傳一般也單圖單介面，因為多了會超時，(-ω-) 你別說 android 小姐姐的眼影畫的好漂亮，唇色也好看，還會閃閃發光呢，

3.3. 介面多并發的疑惑

結合以上介面選擇了單圖單介面的方案，初步測驗結果如下，
162 張，大概16s, 平均1s = 10張


明明這160個介面是一起發出的，理論完成時間不應該是約等于單張圖片上傳時間嗎？為什么差這么多，

3.4 介面多并發的探索

3.4.1 node 單介面多并發

用了node寫了一個介面，有5s等待，讓前端同時呼叫2次


然后詭異的事情發生了：

按道理來說，2個介面同時發送，應該所用時間是5s才對啊，為什么會發生了等待呢， 但是使用postman 同時send 2次該介面，總耗時又是5s左右，

3.4.2 node 多介面多并發

之前沒聽過說介面會發生阻塞啊，那么使用多介面同時請求呢？




可以看到多介面多并發是正常的，沒有發生阻塞

3.4.3 node 單介面多并發，為什么沒有超時

① 如果單介面多并發會發生阻塞，那么一定時間后，會不會超時呢？我們可以把單介面的等待提高到40s，按照3.4.1的邏輯老說，單介面單次是40s，單介面多并發2次應該是80s


② 不應該啊，等待不應該是40s，為什么是20s，肯定哪里不對
③ 多來幾個并發呢 （單介面4并發）

可以看到后3個介面的等待時間都是20s，也沒有發生超時，可以看到1個等待40s的單介面，同時請求4次，時間總耗時1min

④ 回圈20次總可能會超時吧

可以看到1個等待40s的單介面，同時請求20次，時間總耗時3min左右

總感覺哪里不對，是不是node也有什么不正經的地方呢，要不用正經的java介面試試看？

3.4.4 java 單介面多并發

讓java同事幫忙啟了一個java本地介面，同樣等待40s，同樣單介面回圈20次

可以看到1個等待40s的單介面，同時請求20次，時間總耗時2.7min左右

3.4.5 瀏覽器介面并發限制和http1.1

后來想起來，瀏覽器貌似有介面并發限制

參考來源

HTTP客戶端一般對同一個服務器的并發連接個數都是有限制的，
實際上，瀏覽器確實使用并行連接，但它們將并行連接的總數限制為少量（通常為四個），服務器可以自由地關閉來自特定客戶端的過多連接，

圖片來源

圖片來源

3.4.7 回頭看java 單介面多并發

看看java的介面是不是6個一組呢


可以看到是java介面是非常規范的6個一組

為什么同樣的瀏覽器，同樣的前端頁面，同樣的單介面并發，同樣的20次回圈，node介面不是6個一組呢， node是不是不正經呢，而且我每次請求都是重啟瀏覽器（360做測驗瀏覽器，每次重啟會清空所有快取）

3.4.8 node的疑惑

后來發現有類似的問題
nodejs的express并發問題？一次只能處理一個請求？

看到了這句，在自動清除快取的前提下，又勾選了Disable cache
再次請求發現請求node介面也是6個一組了

3.4.9 瀏覽器并發限制和http2

在查詢http并發限制的程序中，發現http2 幾乎沒有并發限制（有的瀏覽器限制在100個），所以線上換成了h2協議，（鑒于這篇已經很長了，所以關于http1.1, h2和server worker 這部分會另起一篇）

測驗結果如下：
1個25kb，300個大約 7500 kb = 7.32M; 需要大概10s
和3.1 相比速度提升了不少，
由于專案默認開啟了service woker，所以同等條件下，需要大概8s

3.5 和后臺確認多并發風險

由于前端幾乎沒有了上傳個數限制，所以和后臺確認了一下風險，后臺表示會加上上傳限制，同時我這邊也加了500張的限制，

4. 解決方案2.0（單圖片單介面模式）

解決方案2.0 說白了就是單圖片單介面回圈 + 進度條控制 + http2 協議

5. 解決方案未來版 （網盤異步模式）

5.1 單圖片多介面混合模式

如果再采用單圖單介面+多圖單介面的模式，所需時間可能更短，但是后來客戶又提出了做個媒體庫的暢想，，，，

5.2 網盤異步模式

這種模式的初步簡單假設互動是，客戶上傳圖片和百度網盤一樣，每張圖片有個進度條，可以斷點續傳（因為除了圖片，試題中可能還有視頻），同時做成異步提醒，即客戶可以去做其他事情，圖片完全上傳完成以后會通過message提醒客戶，

5.3 終究止步于此的需求

隨著整套系統經歷了近10w同時使用的大考，這部分需求似乎沒有進一步優化的動力，也許，同事說的都的對：“他們都沒主動說，你著急推什么，新版本需求做完了？ 別的專案沒事了？ 耽誤了專案新進度小心扣你績效“”

6. 總結 (可略過)

6.1 盡量保持程式的擴展性

比如現在一次性上傳百張圖片有4種方案，（多圖片單介面模式,單圖片單介面模式，單圖片多介面混合模式, 網盤異步模式），如果一開始選擇了第三種方案，則會省事很多，但是這種馬后炮的話，說出來沒有意義，如何盡量保持程式擴展性，可以從下面2點探討

6.2 盡量多思考一些需求

為什么說盡量，因為每個人作業的情況是不一樣，比如我們這邊有的同事有時候手里有好幾個專案在一塊開發，有的專案催的很緊（比如下午16點確認的復雜需求，到晚上19點的時候就需要上線到生產環境），有的同事則一年只負責一個專案，所以說盡量多思考需求還要看有沒有那份“閑情雅致”和“時間"

6.3. 盡量多問問需求

為什么說還是盡量，因為有一些需求的最終來源者可能都不知道需求真正是什么，而“引導”客戶的真實需求并躍然紙上的作業非開發者的本職作業 ，