1. 为什么芒果TV选择Serverless音视频转码？

在视频平台快速发展的今天，芒果TV面临着海量视频内容需要处理的挑战。传统转码方案需要维护庞大的服务器集群，不仅前期投入成本高，在面对流量波动时还容易出现资源浪费或处理能力不足的问题。

我们团队在2020年Q3做过一次成本分析：使用传统ECS方案时，转码集群的峰值资源利用率仅为35%，而低谷期大量服务器处于闲置状态。更棘手的是，在热门剧集上线时，经常需要临时扩容，从申请服务器到部署完成至少需要2小时，严重影响内容上线时效。

经过多轮技术选型评估，我们最终选择了腾讯云Serverless音视频转码方案。这个决策主要基于三个核心考量：

1. 成本效益：按实际使用量计费，无需为闲置资源付费。实测数据显示，相比传统方案可降低45%以上的成本
2. 弹性伸缩：自动应对流量波动，从1个并发到1000个并发都能无缝支持
3. 运维简化：无需管理服务器，团队可以更专注于业务逻辑开发

关键提示：选择Serverless方案时，要特别注意冷启动问题。我们通过预置并发和优化函数包体积，将冷启动时间控制在300ms以内，完全满足业务需求。

2. 核心架构设计与技术选型

2.1 整体架构概览

我们的Serverless音视频转码系统采用事件驱动架构，主要组件包括：

[用户上传视频] → [COS触发事件] → [SCF云函数] → [FFmpeg转码] → [结果回传COS] → [CLS日志收集]

这个架构的最大特点是完全无状态，每个转码任务都是独立的，可以并行处理。我们通过以下几个关键技术点确保系统可靠性：

1. 断点续传：利用COS的多段上传特性，即使转码过程中断也能从断点继续
2. 实时监控：通过CLS日志服务实时追踪每个转码任务的进度
3. 错误重试：自动重试失败的转码任务，最多重试3次

2.2 FFmpeg定制与优化

FFmpeg作为转码核心工具，我们对其进行了深度定制：

# 优化后的转码命令示例 ffmpeg -i input.mp4 \ -c:v libx264 -preset faster -crf 23 \ -c:a aac -b:a 128k \ -movflags +faststart \ output.mp4

关键优化点包括：

• 使用libx264编码器并设置preset为faster，在质量和速度间取得平衡
• 添加-movflags +faststart使视频支持流式播放
• 针对移动端优化，设置CRF值为23（推荐范围18-28）

经验分享：我们发现FFmpeg的内存占用与并发数直接相关。经过测试，将云函数内存设置为1536MB时，可以稳定处理1080p视频转码，同时保持较好的性价比。

3. 详细部署与配置指南

3.1 环境准备

在开始部署前，需要确保具备以下条件：

1. 腾讯云账号（建议使用子账号并授予最小权限）
2. 安装Serverless Framework CLI：

   npm install -g serverless

3. 申请函数长时运行白名单（默认超时时间为900秒）

3.2 项目初始化与结构

使用官方模板初始化项目：

sls init transcode-app --name=mango-tv-transcode

生成的项目结构如下：

mango-tv-transcode/ ├── .env # 环境变量配置 ├── serverless.yml # 应用全局配置 ├── log/ │ └── serverless.yml # 日志服务配置 └── transcode/ ├── src/ │ ├── ffmpeg # 定制版FFmpeg二进制 │ └── index.py # 转码逻辑实现 └── serverless.yml # 函数配置

3.3 关键配置详解

3.3.1 转码参数配置（transcode/serverless.yml）

inputs: memorySize: 3072 # 内存大小(MB) timeout: 43200 # 超时时间(秒) asyncRunEnable: true # 启用长时运行 environment: variables: DST_BUCKET: mango-tv-output DST_PATH: processed/ FFMPEG_CMD: > ffmpeg -i {inputs} -c:v libx264 -preset faster -crf 23 -c:a aac -b:a 128k -movflags +faststart {outputs}

3.3.2 日志配置（log/serverless.yml）

inputs: name: mango-tv-logs topic: transcode-logs period: 30 # 日志保留30天

配置技巧：在测试环境可以将timeout设置为较短时间（如300秒），生产环境再调整为12小时。这样可以避免因配置错误导致长时间运行产生不必要费用。

4. 生产环境最佳实践

4.1 性能优化方案

经过半年多的生产实践，我们总结出以下优化经验：

1. 并发控制：通过COS触发器限制最大并发数，避免突发流量导致费用激增

   events: - cos: parameters: bucket: mango-tv-input filter: prefix: uploads/ events: 'cos:ObjectCreated:*' maxRetryNum: 3 batchSize: 1 # 每次触发处理1个文件

2. 智能转码策略：根据视频分辨率动态调整参数

   # index.py中的动态参数调整 if width >= 1920: # 1080p视频 crf = 23 preset = 'slower' else: # 720p及以下 crf = 26 preset = 'fast'

3. 缓存优化：对热门内容预生成转码结果，减少重复计算

4.2 监控与告警设置

完善的监控是保证服务稳定的关键。我们配置了以下监控项：

1. 函数错误率：当5分钟内错误率>1%时触发告警
2. 转码耗时：监控P99耗时，超过30分钟发出警告
3. COS存储量：设置存储容量预警阈值

监控看板示例配置：

# 在serverless.yml中添加 monitoring: alarms: - name: HighErrorRate metric: ErrorCount threshold: 5 period: 300 comparisonOperator: GreaterThanThreshold

4.3 安全防护措施

1. 输入验证：检查上传文件确实是视频文件

   def is_video_file(filename): video_ext = ['.mp4','.mov','.avi'] return any(filename.lower().endswith(ext) for ext in video_ext)

2. 权限最小化：为函数配置的角色仅授予必要的COS读写权限

3. 敏感信息保护：将API密钥等配置在环境变量中，不写入代码

5. 踩坑记录与问题排查

5.1 常见问题解决方案

问题1：转码输出文件损坏

• 原因：FFmpeg进程被意外终止
• 解决方案：在函数中添加信号处理逻辑，确保优雅退出

问题2：日志延迟

• 原因：CLS日志服务批量上传机制导致
• 解决方案：重要日志直接调用CLS API实时上传

问题3：长视频转码超时

• 原因：默认超时时间不足
• 解决方案：提前评估视频时长，动态设置timeout值

5.2 调试技巧

1. 本地测试：使用serverless invoke local命令本地调试

   sls invoke local -f transcode --data '{"Records":[{"cos":{"cosObject":{"url":"http://example.com/test.mp4"}}}]}'

2. 日志查询：通过CLS控制台使用高级查询语法

   status:fail AND request_id:"8e7f8a90"

3. 性能分析：在FFmpeg命令中添加-benchmark参数获取详细耗时

6. 成本控制与优化

6.1 详细成本分析

我们对比了三种方案的月度成本（以处理1000小时1080p视频为例）：

成本优化主要来自：

1. 使用预留并发享受折扣
2. 智能调度将转码任务安排在低价时段
3. 压缩函数包减少冷启动时间

6.2 实用省钱技巧

1. 批量处理：对小文件进行合并处理
2. 分辨率分级：对不重要的视频降低转码质量要求
3. 存储生命周期：设置自动删除原始文件策略

# 在COS桶策略中添加生命周期规则 lifecycle: rules: - id: delete-original status: Enabled filter: prefix: uploads/ expiration: days: 7

从技术团队的角度来看，Serverless音视频转码确实带来了革命性的变化。最让我印象深刻的是去年暑期档，我们同时上线了5部热门剧集，转码系统平稳应对了平时10倍的流量冲击，而成本只增加了不到2倍。这种弹性在过去是无法想象的。

对于准备采用类似方案的团队，我的建议是：从小规模试点开始，逐步积累经验。可以先选择非核心业务进行验证，等熟悉了Serverless的特性后再推广到关键业务。我们在实施过程中建立的"成本-质量-速度"三角平衡模型，对后续优化起到了关键指导作用。