隨著互聯(lián)網(wǎng)技術(shù)及基礎(chǔ)設(shè)施的發(fā)展，很多以前想想都覺得奢侈的場(chǎng)景應(yīng)用現(xiàn)在都變得非常日常了，比如視頻直播、短視頻、VR全景等等。就VR全景而已，最近今年在國(guó)內(nèi)的應(yīng)用非常火，比如VR看房、VR游覽景區(qū)等等。

在國(guó)內(nèi)，很多VR全景產(chǎn)品的處理引擎都是基于外國(guó)友人寫的krpano這套軟件，然后在應(yīng)用層面使用不同的開發(fā)技能與工具加上擴(kuò)展的功能模塊。就目前我們參與過的VR項(xiàng)目，底層核心部分的處理引擎都是采用krpano?；趉rpano的全景項(xiàng)目我們開發(fā)了數(shù)個(gè)，目前就遇到了一個(gè)極端情況下的問題。

x01問題

用戶反饋：一次性上傳20張20MB左右圖片；上傳采用阿里云OSS，是沒有問題的，然而上傳成功后在等待切圖的時(shí)候，一直卡住不動(dòng)了。而上傳較少的圖片（哪怕圖片超過100MB）或者較多圖片每張圖片很小都可以上傳并切圖完成。

x02分析

到了切圖流程說明圖片肯定是上傳成功的，因?yàn)椴捎玫谌酱鎯?chǔ)的架構(gòu)項(xiàng)目，全景圖片處理的基本流程是：上傳原圖到阿里云OSS–>服務(wù)端從阿里云OSS通過CDN獲取圖片（也可以直接一步到位傳到服務(wù)器本地）–>krpano切圖并在服務(wù)器臨時(shí)存儲(chǔ)或永久存儲(chǔ)–>切圖生成的圖片上傳到OSS，并在并在數(shù)據(jù)庫(kù)記錄各個(gè)圖片路徑–>通過krpano算法組合圖片生成我們看到的全景。

于是，圖片上傳接口肯定是正常的，不管圖片是直接上傳到服務(wù)器本地還是先上傳到阿里OSS這類第三方存儲(chǔ)云平臺(tái)；而且切圖接口返回也是正常的，也就是說明切圖流程已經(jīng)開始執(zhí)行了；再者開發(fā)的時(shí)候由于考慮這種場(chǎng)景下上傳及切圖處理時(shí)間肯定不會(huì)太短，所以做了一個(gè)心跳處理，而且該接口也是正常的。

在nginx的錯(cuò)誤日志中可以看到在切圖過程中出現(xiàn)如下記錄：

雖然這里報(bào)錯(cuò)本身是文件不存在的，但這里報(bào)的是502.html不存在，而該文件確實(shí)被用戶后來刪除過。但重點(diǎn)就是根據(jù)nginx配置該文件是系統(tǒng)報(bào)502錯(cuò)誤時(shí)調(diào)用的前端顯示文件，而且referrer正好是切圖接口的前端邏輯所處的路徑。也就是切圖接口出現(xiàn)502了，而且這個(gè)502在瀏覽器控制臺(tái)前端并沒有出現(xiàn)。

在通過調(diào)試，定位到最終“病灶”位于業(yè)務(wù)邏輯代碼調(diào)用krpano的這一行：

也就是說問題并不出在業(yè)務(wù)代碼中，而slice方法最終調(diào)用的是krpano軟件中的文件，如果是linux環(huán)境則位于krpano_linux/krpanotools

x03解決

定位到該問題，解決方式其實(shí)有很多種，比如說如下幾種：

1. 最土豪的方式：增加服務(wù)器的計(jì)算能力（這個(gè)跟帶寬沒什么關(guān)系，主要是CPU等硬件）；
2. 最甩鍋的方式：一次別切圖這么多，實(shí)際上一個(gè)全景里面一次來切20張確實(shí)很少。
3. 最技術(shù)的方式：改造krpano源代碼及業(yè)務(wù)代碼，使得其支持多線程并行處理，但開發(fā)成本較高。
4. 最勇敢的方式：修改服務(wù)器配置環(huán)境參數(shù)，然而也是最危險(xiǎn)的方式，宕機(jī)風(fēng)險(xiǎn)陡增。

x04結(jié)語

其實(shí)在不增加開發(fā)成本和硬件投入前提下，最可以接受的方式就是做限制，就好像很多項(xiàng)目圖片上傳限制到2MB一樣，實(shí)際上對(duì)于單張圖片處理也是做了限制的，而由于項(xiàng)目在全景生成部分并不是UGC模式，特別前期一次最多也就處理5張全景圖片，于是把限制的閾值設(shè)定的值是根據(jù)我們測(cè)試環(huán)境結(jié)果而定的，萬萬沒想到最終用戶只肯投入配置較低的硬件來做生產(chǎn)。

最后，如果大家有VR全景類項(xiàng)目需求，歡迎與我們聯(lián)系溝通，我們擁有該類項(xiàng)目開發(fā)經(jīng)驗(yàn)，謝謝~