作者
李汇波，腾讯业务运维高级工程师，目前就职于TEG 云架构平台部 技术运营与质量中心，现负责微信、QQ社交类业务的视频转码运维。
摘要
随着短视频兴起和快速发展，对于视频转码处理的需求也越来越多。低码率高清晰，4K、超清、高清、标清适配不同终端和不同网络环境来提升用户体验，以及水印、logo、裁剪、截图等多样化的用户需求。对于资源的多样化需求和弹性扩缩容也需要快速响应，而随着公司自研上云项目的推进，设备的稳定行和多样性可提供更多选择，来满足像朋友圈、视频号、广告、公众号等转码业务快速、稳定、抗突发的资源需求。
服务场景
MTS（Media transcoding service）的定位是点播场景准实时（及离线）视频处理服务。为业务提供分钟级可完成的高清压缩、截图水印、简单剪辑等基本视频处理功能，同时具备向下集成定制画质增加，质量测评等深度功能的能力。
业务开发者定义批量处理模板，当内容生产方上传数据时，触发转码作业输出多规格压缩视频和视频封面，即可发表推送。
背景
微信侧和小视频平台承接着非常多视频文件，而这些视频基本都在转码平台根据业务需求进行处理，为了降低码率减少成本，降低用户因网络而卡顿等功能。最早转码平台基本上是各个业务维护一个独立集群，集群繁多，集群之间资源也不能互相调度使用，并且单集群容量较小，请求量大的业务不得不部署多套集群支撑。
这给运营带来很大的挑战，需要一套容量上限更大，资源调度更灵活，运营更便捷的平台。而随着公司自研上云项目的推进和 TKE 容器化，转码平台需要能快速对接 TKE 资源，利用公司海量计算资源来满足业务对视频转码的诉求。
建设思路和规划
视频接入和转码过程经常面临多业务突发，在保障业务质量前提下又需要提升利用率，提高运营的效率。
平台能力建设：单集群能力上限提高，业务频控隔离互不影响，资源调度灵活调整
资源管理建设：围绕 TKE 容器平台充分挖掘空闲碎片资源，通过 HPA 错开高低峰弹性扩缩容，提升 CPU 利用率。与此同时，利用视频接入服务流量高、CPU 使用率低，转码服务流量低、CPU 使用率高特点，通过两种场景混部充分利用物理机资源，防止纯流量集群低负载
运营系统建设：适配业务场景，完善变更上下架流程，进程监控告警剔除，建立稳定保障平台
平台能力建设
架构升级
老转码平台架构：
- 为 master/slave 主从结构，容灾能力相对较弱，而且受限 Master 性能，单集群大概管理8000台 worker
- 资源调度层面不能友好区分不同核数的 worker，导致有些负载高，有些负载低
不能够基于业务维度做频控，单业务突发影响整个集群
新转码平台架构：
- 合并 Master/Access 模块为 sched，sched 调度模块分布式部署，任一节点挂了可自动剔除掉
- worker 和 sched 建立心跳并且上报自身状态和 cpu 核数等信息，便于调度根据 worker 负载来分配任务，保障同一个集群部署不同规格 cpu worker 负载均衡
- 单集群管理能力 3w+ worker，满足节假日业务突增
- 业务合并到公共大集群，可对单业务进行频控，减少业务直接的干扰
架构的升级，平台不再受限单集群能力，日常和节假日高峰可快速满足需求，并且业务合并大集群错开高低峰，可资源利用
接入服务 svpapi 升级 DevOps 2.0
借助业务上 tke 东风，小视频平台接入服务 svpapi 实现标准化升级。重要改进包括：
- 整合原有多变更系统、多监控系统、多基础资源管理系统到智研统一入口，具体包括研发测试、日常版本发布、资源弹性扩缩容、业务监控告警、业务日志检索分析。通过 CICD 流程屏蔽直接对 TKEStack 操作，安全性更好
- 模块配置区分使用场景托管于七彩石，并支持1分钟级业务开关切换，支持节假日期间灵活的流量调度和业务流控频控
- 下半年接入服务计划利用智研监控集群流量水平，结合 TKEStack 根据流量 HPA 能力，实践资源扩容无人值守能力
资源管理建设
具备平台能力后，下一步需要对不同容器规格的资源进行分类并均衡调度，这里主要的难点：
1、业务场景多样性：TKE 集群涉及很多，性能规格也各不相同，从6核到40核都需要能使用
2、资源管理和运营需要考虑：Dockerfile 镜像制作，适配 TApp 不同集群配置，容器上下架，运维变更规范等
梳理出 TKE 不同集群下容器配置
# 不同cpu规格适配不同环境变量
- name: MTS_DOCKER_CPU_CORE_NUM
value: "16"
- name: MTS_DOCKER_MEM_SIZE
value: "16"# 算力平台亲和性设置，当负载超过70%，则驱逐该pod
affinity:
nodeAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
nodeSelectorTerms:
- matchExpressions:
- key: max_vm_steal
operator: Lt
values:
- "70"资源调度均衡
转码属于异步任务，处理的每个任务请求时间是不一样的，并且有状态，所以无法基于北极星去均衡调度任务，需要平台侧来设计调度策略
- 基于不同规格 CPU 机器 worker 性能，均衡分配任务
- 根据不同 worker 版本进行调度，支持小业务快速版本迭代
在对不同规格容器，通过 Score 和版本来均衡调度
基于调度能力的在不同 CPU 规格上的任务均衡，C6 和 C12 利用率较相近，不会导致大规格容器资源浪费
运营系统建设
转码集群的 worker 资源怎样扩容到对应集群，这里增加了一层资源管理层，需要手动调用将指定的 worker 从集群上下架。对应平台侧开发专业 OSS 系统，将集群的 sched/worker/任务做成页面便于运营，并且封装上下架的 API。而 TKE 跟转码平台其实无任何关联，为了实现解耦，运维侧开发对接 TKE 上下架的功能，制定流程，将 TKE 扩缩容的资源调用 OSS API 实现同步，具体逻辑如图：
TKE 支持北极星服务，将对应的 TApp 关联到北极星服务名，将北极星服务作为不同转码集群扩缩容 IP 的元数据管理，保障 TKE 和转码侧资源的一致性
进程监控
转码平台管理的 worker 有上万台，在运行过程或者新版本发布中不能及时监控容器进程状态是怎么样，通过批量扫描时间太长，不能快速知道进程异常状态，因此结合组内进程监控平台，建设转码容器的进程监控告警，异常 worker 通过机器人企业微信、电话告警及时通知剔除，提升服务质量
资源利用优化
转码业务目前基本是社交的自研业务，节假日效应突发比较明显，而且资源需求较大，大部分还是准实时，对于转码耗时也比较敏感。因此平时在保障速度外，会预留30%~50的 buff，而业务凌晨基本上是低峰，因此部分资源在凌晨是浪费的。TKE 支持根据系统指标自动伸缩，并且它计费模式也是根据一天内实际使用量收费，这里我们基于 CPU 利用率指标，来配置弹性伸缩，低峰时缩容，高峰时自动扩容，减少资源的占用，从而减少成本
弹性扩缩容
根据实际负载节点副本数在凌晨低峰缩容
Workloads CPU 实际使用占 request 百分比峰值能够达到75%以上，在保障业务稳定的情况下，提升 CPU 利用率
成果小结
目前转码平台从分散小集群合并的三地大集群，运营能力的提升+资源利用率提升，正在努力提升云原生成熟度，截止到2021年5月。
- 业务累计接入微信朋友圈、视频号、c2c、公众号、看一看、广告、QQ 空间等内部视频业务，每天视频转码处理1亿+
- 日常保持在70%左右 CPU 利用率，根据负载自动弹性扩缩容，业务成熟度显著提高
关于我们
更多关于云原生的案例和知识，可关注同名【腾讯云原生】公众号~
福利：
①公众号后台回复【手册】，可获得《腾讯云原生路线图手册》&《腾讯云原生最佳实践》~
②公众号后台回复【系列】，可获得《15个系列100+篇超实用云原生原创干货合集》，包含Kubernetes 降本增效、K8s 性能优化实践、最佳实践等系列。
【腾讯云原生】云说新品、云研新术、云游新活、云赏资讯，扫码关注同名公众号，及时获取更多干货！！
