微服务中台技术之视频处理

业务背景

公司最近在尝试使用短视频进行商品展示，相比于静态图片，视频方式让用户可以更直观地感受和体验商品，强化用户购买欲望，这也是促进 GMV 的重要手段。

业务方对视频处理的主要诉求是能满足分辨率调整，修改封装格式，调整码率等，从满足功能的角度看，很多云平台都有类似的视频服务提供，但从成本和可维护性考虑，我们还是自己搭建一套视频处理服务。

主要技术点

首先，提到视频处理，就很容易想到开源工具 ffmpeg，非常强大，几乎所有视频处理功能都可以满足，并且扩展性非常好。

其次，由于视频播放会使用到 cdn 服务，因此视频文件的压缩率就显得异常重要，开源 ffmpeg 的编码压缩率不高，因此我们使用了第三方视频服务提供商的产品，它们的视频压缩比较高，并且也是基于开源 ffmpeg 做的二次开发。

所以我们需要关注的第一个技术点就是要同时支持开源 ffmpeg 和第三方 ffmpeg，以避免强依赖，如下图所示：

视频处理概览

第二个需要关注的技术点是视频存储，关系到后续如何跟 cdn 集成。

第三个需要解决的是处理完成后如何通知调用方，这关系到整体链路的吞吐量。

总体方案架构

针对第一个技术点，我们采用主备链路方式，主链路使用第三方视频服务，备用链路在主链路出现问题时启用。

针对第二个技术点，我们采用 amazon s3，这是比较成熟的对象存储系统，并且可以和 cdn 很好的集成。

对于第三个技术点，考虑到视频处理时长的不确定特点，我们觉得异步通知会更好，避免同步等待，这也是大多数云平台视频处理时的常用做法。

总体处理流程如下图所示：

视频处理整体流程概览

在统一视频服务内部，我们使用 mysql 存储视频处理请求记录及其状态，使用两个 kafka 消息队列，其中 pending 队列用来保存待处理的请求，ready 队列用来保存已经处理完成的结果，详细链路如下图所示：

视频处理详细链路

在 runFFMPEG 内部，为了避免繁琐的手动拼接 ffmpeg 命令，我们使用了一个小的开源组件 ffmepg java wrapper(链接)，并且为了获取执行失败时的输出，我们做了简单的修改。

扩展性与不足

第一点，可以参考众多云平台通过 http 进行回调的方式，视频处理完成后增加 http 回调通知调用方。

第二点，在实际使用中我们发现，视频处理非常耗资源，在高并发情况下，需要等待很长时间才能处理完，吞吐量很低。压测结果：

4 核 8G 机器（aws 平台，普通计算型），只能并发 2 个 ffmpeg 任务(mp4->m3u8，原视频大约 6.7mb)，cpu 即跑满，平均每个任务耗时大约 60s。第三方视频服务提供商推荐 3~4 核一路转码，1 核对应 2g 内存。路数多了，每路的速度多会变慢，而且会相互抢占资源（结论：基本上 4 核 8G 的机器最好是只执行 1 个转码任务了）。因此为了服务自身的稳定性和保障总体吞吐量，最好加上同时允许处理视频任务个数的限制。

第三点，为了容灾而设计的主备链路，目前并没有做到自动切换，而是做监控，有可用性报警后立即启用备用链路，这主要是考虑到备用链路的维护成本问题，实际可以认为是冷备。如果成本允许，还是建议做热备。

总结

本文主要介绍了电商公司常用到的商品短视频处理需求及其实现链路，有类似需求的读者欢迎留言探讨～