随着互聯網技(jì)術及基礎設施的(de)發展，很(hěn)多以前想想都(dōu)覺得奢侈的(de)場(chǎng)景應用現(xiàn)在都(dōu)變得非常日(rì)常了，比如視(shì)頻(pín)直播、短視(shì)頻(pín)、VR全景等等。就VR全景而已，最近(jìn)今年(nián)在國(guó)內(nèi)的(de)應用非常火，比如VR看(kàn)房(fáng)、VR遊覽景區(qū)等等。

在國(guó)內(nèi)，很(hěn)多VR全景産品的(de)處理(lǐ)引擎都(dōu)是基于外(wài)國(guó)友(yǒu)人(rén)寫的(de)krpano這(zhè)套軟件(jiàn)，然後在應用層面使用不同的(de)開(kāi)發技(jì)能與工(gōng)具加上(shàng)擴展的(de)功能模塊。就目前我們參與過的(de)VR項目，底層核心部分的(de)處理(lǐ)引擎都(dōu)是采用krpano。基于krpano的(de)全景項目我們開(kāi)發了數個(gè)，目前就遇到了一個(gè)極端情況下(xià)的(de)問(wèn)題。

x01問(wèn)題

用戶反饋：一次性上(shàng)傳20張20MB左右圖片；上(shàng)傳采用阿裏雲OSS，是沒有(yǒu)問(wèn)題的(de)，然而上(shàng)傳成功後在等待切圖的(de)時(shí)候，一直卡住不動了。而上(shàng)傳較少的(de)圖片（哪怕圖片超過100MB）或者較多圖片每張圖片很(hěn)小(xiǎo)都(dōu)可以上(shàng)傳并切圖完成。

x02分析

到了切圖流程說(shuō)明(míng)圖片肯定是上(shàng)傳成功的(de)，因為(wèi)采用第三方存儲的(de)架構項目，全景圖片處理(lǐ)的(de)基本流程是：上(shàng)傳原圖到阿裏雲OSS–>服務端從(cóng)阿裏雲OSS通(tōng)過CDN獲取圖片（也可以直接一步到位傳到服務器(qì)本地(dì)）–>krpano切圖并在服務器(qì)臨時(shí)存儲或永久存儲–>切圖生(shēng)成的(de)圖片上(shàng)傳到OSS，并在并在數據庫記錄各個(gè)圖片路(lù)徑–>通(tōng)過krpano算(suàn)法組合圖片生(shēng)成我們看(kàn)到的(de)全景。

于是，圖片上(shàng)傳接口肯定是正常的(de)，不管圖片是直接上(shàng)傳到服務器(qì)本地(dì)還(hái)是先上(shàng)傳到阿裏OSS這(zhè)類第三方存儲雲平台；而且切圖接口返回也是正常的(de)，也就是說(shuō)明(míng)切圖流程已經開(kāi)始執行了；再者開(kāi)發的(de)時(shí)候由于考慮這(zhè)種場(chǎng)景下(xià)上(shàng)傳及切圖處理(lǐ)時(shí)間(jiān)肯定不會太短，所以做了一個(gè)心跳(tiào)處理(lǐ)，而且該接口也是正常的(de)。