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

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

x01問題

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

x02分析

到了切圖流程說明圖片肯定是上傳成功的，因為采用第三方存儲的架構項目，全景圖片處理的基本流程是：上傳原圖到阿里云OSS–>服務端從阿里云OSS通過CDN獲取圖片（也可以直接一步到位傳到服務器本地）–>krpano切圖并在服務器臨時存儲或永久存儲–>切圖生成的圖片上傳到OSS，并在并在數據庫記錄各個圖片路徑–>通過krpano算法組合圖片生成我們看到的全景。

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

在nginx的錯誤日志中可以看到在切圖過程中出現如下記錄：

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

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

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

x03解決

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

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

x04結語

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

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