随着互联网技术及基础设施的发展，很多以前想想都觉得奢侈的场景应用现在都变得非常日常了，比如视频直播、短视频、VR全景等等。就VR全景而已，最近今年在国内的应用非常火，比如VR看房、VR游览景区等等。

在国内，很多VR全景产品的处理引擎都是基于外国友人写的krpano这套软件，然后在应用层面使用不同的开发技能与工具加上扩展的功能模块。就目前我们参与过的VR项目，底层核心部分的处理引擎都是采用krpano。基于krpano的全景项目我们开发了数个，目前就遇到了一个极端情况下的问题。

x01问题

用户反馈：一次性上传20张20MB左右图片；上传采用阿里云OSS，是没有问题的，然而上传成功后在等待切图的时候，一直卡住不动了。而上传较少的图片（哪怕图片超过100MB）或者较多图片每张图片很小都可以上传并切图完成。

x02分析

到了切图流程说明图片肯定是上传成功的，因为采用第三方存储的架构项目，全景图片处理的基本流程是：上传原图到阿里云OSS–>服务端从阿里云OSS通过CDN获取图片（也可以直接一步到位传到服务器本地）–>krpano切图并在服务器临时存储或永久存储–>切图生成的图片上传到OSS，并在并在数据库记录各个图片路径–>通过krpano算法组合图片生成我们看到的全景。

于是，图片上传接口肯定是正常的，不管图片是直接上传到服务器本地还是先上传到阿里OSS这类第三方存储云平台；而且切图接口返回也是正常的，也就是说明切图流程已经开始执行了；再者开发的时候由于考虑这种场景下上传及切图处理时间肯定不会太短，所以做了一个心跳处理，而且该接口也是正常的。

在nginx的错误日志中可以看到在切图过程中出现如下记录：

虽然这里报错本身是文件不存在的，但这里报的是502.html不存在，而该文件确实被用户后来删除过。但重点就是根据nginx配置该文件是系统报502错误时调用的前端显示文件，而且referrer正好是切图接口的前端逻辑所处的路径。也就是切图接口出现502了，而且这个502在浏览器控制台前端并没有出现。

在通过调试，定位到最终“病灶”位于业务逻辑代码调用krpano的这一行：

也就是说问题并不出在业务代码中，而slice方法最终调用的是krpano软件中的文件，如果是linux环境则位于krpano_linux/krpanotools

x03解决

定位到该问题，解决方式其实有很多种，比如说如下几种：

1. 最土豪的方式：增加服务器的计算能力（这个跟带宽没什么关系，主要是CPU等硬件）；
2. 最甩锅的方式：一次别切图这么多，实际上一个全景里面一次来切20张确实很少。
3. 最技术的方式：改造krpano源代码及业务代码，使得其支持多线程并行处理，但开发成本较高。
4. 最勇敢的方式：修改服务器配置环境参数，然而也是最危险的方式，宕机风险陡增。

x04结语

其实在不增加开发成本和硬件投入前提下，最可以接受的方式就是做限制，就好像很多项目图片上传限制到2MB一样，实际上对于单张图片处理也是做了限制的，而由于项目在全景生成部分并不是UGC模式，特别前期一次最多也就处理5张全景图片，于是把限制的阈值设定的值是根据我们测试环境结果而定的，万万没想到最终用户只肯投入配置较低的硬件来做生产。

最后，如果大家有VR全景类项目需求，欢迎与我们联系沟通，我们拥有该类项目开发经验，谢谢~