岱山建设网站中国市场营销培训网

当前位置： 首页 > news >正文

岱山建设网站,中国市场营销培训网,可以访问任何网站的浏览器,泰安市星际网络科技有限公司说在前面 在尼恩的#xff08;50#xff09;读者社群中#xff0c;经常指导大家面试架构#xff0c;拿高端offer。 前几天#xff0c;指导一个年薪100W小伙伴#xff0c;拿到字节面试邀请。 遇到一个 非常、非常高频的一个面试题#xff0c;但是很不好回答#xff0…说在前面 在尼恩的50读者社群中经常指导大家面试架构拿高端offer。 前几天指导一个年薪100W小伙伴拿到字节面试邀请。 遇到一个 非常、非常高频的一个面试题但是很不好回答类似如下 短视频系统如何做系统架构短视频APP如何做系统架构 最近有个网易二面又遇到了这个问题。 其实尼恩一直想梳理一个教科书式的答案 这里有一个新的行业案例《字节跳动亿级视频处理系统高可用架构实践》尼恩从 面试维度对这个方案进行二次重构和梳理现在把其做为参考答案收入咱们的《尼恩Java面试宝典 PDF》 V97版本 下面的内容是尼恩是结合自己的3高架构笔记以及尼恩的3高架构知识体系3高架构宇宙做的二次分析。 《尼恩 架构笔记》《尼恩高并发三部曲》《尼恩Java面试宝典》的PDF请到公号【技术自由圈】取 文章目录 说在前面短视频系统如TikTok、Instagram Reel、YouTube Shorts的宏观业务架构1与用户相关的子系统2与视频发布相关的子系统如何使文件在全球范围内可访问而不增加下载时间我们能进一步优化以减少下载时间吗如何访问压缩的视频文件 3点赞和评论相关子系统4推荐子系统 技术选型常见的NOSQL存储框架选型重点介绍MinIO对象存储框架 基于MinIO实现简单的短视频系统1视频上传与转码2直播录制3上传文件4点播地址映射5地址动态代理服务6拉流播放7总结 短视频架构的核心要点CDN缓存就近上传 亿级视频处理系统架构实践视频处理整体的生命周期视频处理系统的目标视频处理系统架构 服务层和工作流系统系统服务层介绍媒体工作流介绍任务执行任务执行的难点1快速响应和恢复任务执行的难点2系统维度函数计算平台高可用性多集群高可用性单集群控制面——服务治理动态多媒体框架 BMF 亿级视频处理宏观流程参考文献所以以上才是“教科书式” 答案视频预告33章10Wqps 基础用户平台 架构与实操推荐阅读 短视频系统如TikTok、Instagram Reel、YouTube Shorts的宏观业务架构 以短视频点播为代表的流媒体技术应用在移动互联网时代实现了快速扩张。 现在短视频内容已成为新趋势每个人都在从TikTok、Instagram、YouTube等平台上消费这些内容。让我们看看如何为TikTok创建一个系统。 在互联网内容趋于多元化的今天短视频迅速替代了传统的文字图片席卷了人们的视野和生活成为信息传播的重要渠道。 这样的应用程序看起来很小但在后台有很多事情正在进行。 以下是相关的挑战 由于该应用程序在全球范围内使用将会有大量的请求发送到服务器。这最终会增加服务器的负载。将视频上传到后台将是一个巨大的任务这将增加服务器的负载并阻塞。流畅地播放视频无缓冲。一个基于用户兴趣推荐视频的推荐系统。 让我们逐一了解每个部分。我将其分为三个部分 与用户相关的子系统与视频发布相关的子系统与点赞和评论相关的子系统推荐子系统 1与用户相关的子系统 这是一个包含与用户相关服务的服务如下所示 注册 用户将在应用程序中注册。登录 它将对凭证进行身份验证并向应用程序发送响应。登出 用户将从应用程序中注销。关注 如果用户想要关注或取消关注其他用户则可以通过此服务完成。 为了存储与用户相关的数据我们将使用基于SQL的数据库如MYSQL或PostgreSQL因为与用户相关的数据例如追踪关注者将会是关联数据所以这是一个适当的选择。 为了优化数据库性能我们将使用主从架构。主数据库用于执行写操作从数据库用于执行读操作。要了解有关此内容的更多信息可以阅读文章如何优化数据库性能并扩展它[3] 现在让我们讨论用户服务的流程。应用程序将发出API调用API Gateway将管理这些API。 它将为用户服务路由请求。 请求将通过负载均衡器进行负载均衡器下将有多个用户服务实例。 根据负载它将决定哪个实例将处理请求。 一旦请求被处理负载均衡器将将响应发送回API网关然后再发送回应用程序。 2与视频发布相关的子系统 一般包含视频上传、存储、处理、播放等流程及相应的流程管理与审核。 核心的操作如下所示 上传视频 将视频上传到后台服务器。发布 如果用户想要创建、编辑或删除帖子则可以通过此服务完成。 与视频发布相关的子系统的技术要点 如何安全可靠地存储PB级海量数据并实现视频数据的快速存取如何支持多种场景下的视频上传如何保障稳定流畅的拉流播放以及如何满足视频转码、水印等基本处理需求都成为构建一个视频点播平台需要考虑和解决的技术难题。 核心的核心就是短视频的存储。 为了存储与帖子相关的数据我们将使用基于NoSQL的数据库如MiniO。 对于每个用户可能会有成千上万的帖子这将导致大量数据。 为了实现最佳性能扩展数据库可能会很困难。NoSQL数据库支持水平分片这有助于我们在不影响性能的情况下扩展数据库。 现在让我们讨论视频服务的流程。 应用程序将发出API调用API Gateway将管理这些API。它将为视频服务路由请求。 请求将通过负载均衡器进行负载均衡器下将有多个视频服务实例。 根据负载它将决定哪个实例将处理请求。一旦请求被处理负载均衡器将将响应发送回API网关然后再发送回应用程序。 如何使文件在全球范围内可访问而不增加下载时间 视频文件将上传到NOSQL如MiniO。 现在如果我们想在世界范围内任何地方访问文件而没有任何延迟那么该文件将发送到内容分发网络(CDN)它将将媒体文件更新到世界各地的不同数据云存储中。 我们能进一步优化以减少下载时间吗 还有一个挑战需要解决即原始视频的大小可能较大因此如果将大文件发送回客户端则下载时间会更长这会影响用户体验。 文件一旦上传到云存储您可以在数据库中存储文件路径。 然后将帖子/视频详细信息发送到消息队列系统如Kafka或RockerMq。 为了使用户体验流畅我们需要压缩视频并为不同设备创建不同分辨率的视频。 视频处理工作者将从消息队列系统接收视频详细信息然后从 云存储中提取文件并进行处理。处理完成后这些新的视频文件将发送到CDN。 如何访问压缩的视频文件 现在您可能会想应用程序如何知道上述讨论中压缩的视频的文件路径由于压缩文件将存储在分类文件夹中因此可以根据分辨率和文件名轻松查找文件。 视频发布API只会返回文件名而要访问文件应用程序将在URL本身中添加分辨率细节例如/media//mediaID/xxxx。 当访问此URL时它将经过API网关并从URL中提取分辨率和文件名详细信息。 然后它将在缓存系统Redis中检查如果文件不可用则将访问CDN并通过它获取文件。然后将其添加到缓存中以便如果再次请求相同文件则不必从CDN获取。 3点赞和评论相关子系统 这是一个包含与视频点赞和评论相关服务的服务。正如名称所示通过此服务我们可以为特定帖子更新点赞和评论。与上面讨论的其他流程相同。 4推荐子系统 通过此服务基于用户偏好推荐一系列帖子。幕后有很多其他事情正在进行。让我们看看幕后运行的流程。 然后创建一个帖子后它将被发送到消息队列系统然后消费者将提取数据并将数据更新到大数据Hadoop中。 将为机器学习服务如PyTorch和Tensorflow设置单独的服务器在这里它将从大数据中提取数据并训练模型。 推荐服务将使用此AI模型为给定用户推荐帖子。 技术选型常见的NOSQL存储框架选型 当前存储从逻辑上一般可分为三类即块存储、文件存储和对象存储。 块存储一般指常见的卷或硬盘存储以及相应的磁盘阵列、NAS、SAN等存储方式操作对象是磁盘使用逻辑块编号寻址数据按字节方式访问读写速度快。文件存储则将数据以不同应用程序要求的结构方式组成不同类型的文件可对文件进行创建、查找、修改、删除等操作易于实现数据共享。对象存储将文件以对象的方式进行存储一个对象包含属性以及内容通常实现方式为多台分布式服务器内置大容量硬盘通过对象存储软件组建集群对外提供读写访问功能。 业内较为主流的开源存储框架MinIO、Ceph、SeaweedFS从开源协议、扩展性、成本等多方面进行对比如下表 由于对象存储结合了块存储读写效率快、存储空间可扩展以及文件存储方便共享的优点同时结合短视频平台数据存储与视频点播需求建议选取对象存储框架作为短视频点播平台的存储逻辑。 进一步考虑到短视频点播平台数据规模、存储动态不宕机扩容、在线HTTP多媒体播放以及学习运维成本等需求通过以上对比建议选用MinIO开源框架作为短视频存储与点播基础框架。 重点介绍MinIO对象存储框架 对象存储的出现是为解决了存储海量大数据的问题如存储海量的视频、图片并进行数据归档、数据备份、大数据分析等操作。 对象存储一般采用key-object的扁平化存储架构使用方便调用API就可进行数据的多样化读写。其大容量、动态扩展、数据灾备等性能是传统文件存储和NAS无法比拟的。 MinIO是一套基于Apache License V2.0协议的轻量级、高性能开源对象存储框架适用于图片、视频、镜像等海量非结构化数据存储。 MinIO采用Golang实现客户端支持Java、Python、JavaScript、Golang语言兼容亚马逊S3云存储服务接口方便与其他应用结合。 1存储机制 MinIO使用纠删码erasure code和校验和checksum来保护数据免受硬件故障和无声数据损坏可保证N/2节点损坏的情况下数据的正常访问。 2扩展性 极简性和扩展性是MinIO集群的两个重要设计理念。 MinIO支持对等扩容和联邦扩容两种扩容方式。对等扩容即通过增加对等的集群节点和磁盘以扩充集群例如原集群包含4个节点4块磁盘则扩容时可同样增加4个节点4个磁盘或其倍数以此保证系统可维持相同的数据冗余SLA降低扩展的复杂性。 联邦扩容其基本原理是引入etcd作为统一命名空间将多个MinIO集群组成一个联邦可在原有联邦的基础上向联邦中增加新集群此扩容方式理论可实现无限扩展且可以实现在原联邦服务不中断的情况下扩容。 3对外服务 MinIO完全兼容S3标准接口客户端和服务端之间通过http/https进行通信。MinIO提供客户端mcMinIO Client以支持UNIX命令同时支持多语言的客户端SDK。此外其存储后端除使用磁盘外还可通过网关对接其他存储系统与资源。具体如下表所示。 4多媒体拉流支持 MinIO对于多媒体文件支持HTTP-Range的方式在线拉流播放与音视频进度条拖拽。 如下图使用浏览器以流的形式访问存储于MinIO的多媒体文件时每拖动一次进度条则会向MinIO服务端发送一条Http-Request请求请求Headers中包含Range字段其内容是当前请求视频进度的开始字节数及缓存结束字节数。 这种形式使MinIO天生支持多媒体文件的拉流播放与进度拖拽。 图 MinIO多媒体在线播放支持 基于MinIO实现简单的短视频系统 出于集群存储可动态扩展性、支持HTTP流式播放、运营成本等因素 建议使用MinIO对象存储作为底层存储开发部署短视频点播地址映射、地址动态代理等服务实现一套短视频存储点播平台。 其实现框架如下图 图 基于MinIO的短视频点播平台架构 点播平台大致可分为存储层、服务层与应用层。 存储层主要部署MinIO对象存储系统及关系数据库MinIO用来存储视频对象关系数据库用来存储视频元数据服务层提供各类存储访问服务接口如文件上传下载、视频播放地址生成、对象地址映射等应用层为前端提供应用功能包括视频上传、查询、播放等功能。 基于MinIO对象存储的点播平台数据访问流程如下图所示 图 基于MinIO的短视频点播平台数据访问流程图 1视频上传与转码 统一采用mp4格式作为视频存储和点播格式为了兼容多种格式视频文件上传需开发转码模块将其转码成mp4格式进行存储将其首先存入本地磁盘缓存。 2直播录制 在直播的过程中开启录制将录制的文件首先存入本地磁盘缓存。 3上传文件 视频转码完成或录制完成后调用MinIO文件上传接口将视频文件上传至MinIO集群/联邦由etcd对MinIO集群提供注册发现服务。 4点播地址映射 服务端部署点播地址映射服务模块实现MinIO视频点播地址与视频ID的映射使存储介质的改变不影响视频点播拉流。 5地址动态代理服务 出于系统安全性考虑我们不希望暴露MinIO存储地址与存储细节希望增加一层网关进行媒体流的转发或地址的代理对外提供统一的服务地址使用地址动态代理可以根据点播请求的视频ID不同动态代理至不同的视频播放地址实现视频存储细节与服务地址的解耦。 6拉流播放 客户端或浏览器使用HTTP协议流式拉取视频文件并播放。 7总结 选用MinIO开源存储框架快速设计并搭建出一套支持海量短视频上传、存储、点播等功能的视频点播平台 为当下不断涌现的短视频点播平台及相关应用提供了一定技术选型与设计参考。 短视频架构的核心要点CDN缓存 除此minio存储之外短视频对CDN分发也是有很高要求的 跟传统的长视频相比的话因为长视频会进行预取刷新的操作会预先将文件分发到CDN节点上去 但是短视频内容因为是UGC而且视频上传完成之后页面马上就要发布出去进行播放所以往往不能像长视频那样提前预取到各个CDN节点进行预热这对视频云平台内部的分发能力是有要求的。 就近上传 用户拍完一段视频需要立即上传。 CDN厂商一般全国各地有多个数据中心“从基础资源能力上来讲要求CDN网络有条件为客户提供就近上传的功能”。 如何实现 通过一套SDK开发者将这套SDK嵌入到他们APP里面去最终用户在将视频上传的时候会通过HTTP DNS的调度去获取离他最近的或者是当前网络中最佳的一个数据中心节点并且实现这个文件的上传功能。 亿级视频处理系统架构实践 字节跳动火山引擎视频中台支撑了多个亿级应用的视频全生命周期管理 火山引擎视频的相关 ToB 业务支持了字节跳动抖音、西瓜视频等产品 全部视频生命周期 视频生产视频下发、视频播放等 视频处理整体的生命周期 视频整体的生命周期大致可以分为四个阶段 端侧生产视频的创作者用手机或者其他设备拍摄一个视频可以对视频做一些增强和编辑通过上传 SDK即可把这个视频上传到云端。云端生产在云端有两个比较核心的流程视频处理和审核这两个流程是并行执行的。云端下发当以上两个流程都执行完以后一个视频也就可以给大家看了接下来就进入云端下发的阶段。 在这个阶段点播服务负责下发视频的播放地址包括相关的 meta 信息然后视频的内容是通过 CDN 下发。视频播放这个阶段由播放 SDK 进行端上视频的处理以及渲染。 在视频生命周期里视频处理系统是云端生产的核心环节。 我们先来看一下字节跳动在视频处理这方面所面临的一些挑战。 大规模 目前字节跳动每天处理的视频量级在亿级因为每一个视频都会产生不同档位、不同格式的视频实际生产出的是接近十亿量级的视频。这对计算和存储都是非常大的消耗这么大体量的业务对系统整体的稳定性和性能也有非常高的要求。多业务 字节跳动的视频业务非常多样包括短视频、中视频、长视频以及点播、直播、RTC 相关的一些业务涉及教育、游戏等不同的垂直行业。资源复杂 除了常规的 CPU 资源还有很多弹性资源以及 CPU/GPU/FPGA 等多种类型的资源还有一些其他的硬件转码设备等。业务高速增长以及大型活动的峰值 到目前为止每年处理的视频量级至少都是在翻倍地增长。 每年又有很多大型的活动给系统带来了非常巨大的考验。 视频处理系统的目标 面临以上这些挑战视频处理系统要实现哪些目标呢 大家可以看上图这张图更偏逻辑的关系。视频处理系统最终的目标总结起来只有三点 满足业务需求。提升用户体验。比如画质、流畅性等方面的体验。降低成本。字节跳动的体量带来的计算、存储以及 CDN 成本都非常巨大所以降低成本也是一个很重要的目标。 为了实现这些目标就需要对视频做不同类型的处理包括转码、编辑、分析也包括一些图片处理每一项都是一种视频的应用。 每一个视频的应用再往下拆解会对应非常多的处理能力比如对于转码应用来说会有一些新的编码器、自适应转码来降低码率通过一些增强的方式提高画质等等。 所有这些能力在最底层都由一个基础的处理系统做支撑。这个系统需要满足高可用、高可扩展以及高效的运维开发效率的需求。 总结起来就是整个视频处理系统以底层的系统支撑为基础构建各种各样的视频处理的能力形成多种视频应用从而满足业务场景的需要提升体验降低成本。 视频处理系统架构 为了实现这些目标视频处理系统的架构如上图所示外层被划分为三个平面 用户平面顾名思义就是从用户的角度如何去调用系统。控制平面它面向的是开发人员、运维人员、支持人员他们如何去控制这个系统以及当系统出问题的时候怎么样对系统做一些管理和应急处理的动作。数据平面系统每天会产生海量的数据。这些数据一方面可以进行分析来指导系统的优化。另一方面也用于计量、计费、监控等。 中间的四层分别是 服务层主要是处理鉴权、任务队列的管理、上层的模板管理、策略控制等等。工作流系统主要是为了串联异步、分布式的媒体处理流程。Lambda高可用的函数计算平台它最大的作用是管理底层海量的资源并且对资源进行高效的调度以及任务的执行。BMF它是一个动态多媒体处理框架目标是把所有多媒体处理的原子能力进行插件化管理然后提高系统的可扩展性以及开发和运维的效率。 下面将为大家详细介绍几个核心层。 服务层和工作流系统 系统服务层介绍 服务层有几个重要的组件。 服务网关它可以进行跨机房的流量调度以及一些接口的鉴权包括接口层的限流。管理服务它有两个作用首先是对整个视频处理系统的所有元数据进行管理包括任务队列、模版和工作流信息等另外是会触发底层工作流的执行同时会去管理整个工作流的生命周期状态。弹性队列可以隔离业务侧的资源。它实现的功能包括队列的资源配置任务的 QPS最大并发任务的数量 MRT、队列管理以及弹性资源的管理。 媒体工作流介绍 服务层下方就是媒体工作流的引擎工作流是以 DAG 的形式组织一系列视频处理的流程。 比如说在西瓜视频上传一个视频后需要去抽取它的封面并对视频进行无水印转码还需要进行各种档位的转码。 这些都是处理视频的流程每一个流程都是一个细粒度的任务。 有效的办法是把这些单个的流程组织起来就形成了一个工作流。 工作流能解决什么问题呢 第一是它解决了复杂业务的调用流程。如果没有工作流处理一个视频就要进行多次的调用。第二是能够比较好管理视频处理流程的依赖关系。在实际的处理过程中前后的流程之间是会有依赖的比如画质增强的流程需要先对原片作增强再进行普通转码或者通过分片转码的功能对视频预先切片再对每一个切片再做转码最后再把它们拼接在一起。这些都可以通过工作流的方式实现。第三是提供任务超时、错误重试等高可用的能力降低了业务使用成本。 下面再简单看一下工作流内部是怎样的结构。 工作流内部主要包含这么几个模块 Gate处理流量调度包括鉴权的功能。Engine管理所有工作流的状态。Scheduler一个工作流包含很多节点Scheduler 可以对每一个节点进行细粒度的任务调度。VWorker它是上层和下层的粘合层会把上层一些偏业务属性的模板转换成一个底层实际可以执行的函数任务的参数。 上图中间绿色的部分就是整个工作流的引擎。 上层就是服务层下层是等会要介绍的函数计算平台。 任务执行 视频处理系统是一个离线处理系统每一个任务都会执行几十秒、几分钟甚至更长的时间。 这时最重要是保证过来的每一个任务都能够最终被执行而且最终保持一致。 所以对系统来讲需要有 at least once 的保证。 其次是任务幂等的要求。 任务幂等有两个意思 首先是这个任务无论什么时候执行多少次最终的结果是一样的而且对业务方来讲是透明的。第二是在一定的时间内如果同一个视频做同一个处理提交了非常多次这时就需要有去重的机制只执行一次。对调用者来讲这个过程也要是透明的这在某些场景下能够比较好的提升系统的效率。 为了保证任务幂等我们在视频 meta 信息关联以及视频的存储方面都做了比较多的工作同时要保证 at least once在工作流和节点层面都做了比较多的超时检测和重试的机制。 任务执行的难点1快速响应和恢复 视频处理系统的下游涉及到计算资源和存储资源。 一旦计算资源和存储资源出问题很难有一个完美的方案对上层业务做到无感知要做的就是尽量避免损失尽量减少对于业务的影响。 这里面有两个比较重要的措施 多级限流限流是常用的手段但是视频处理的不同点是会有一个任务筛选的过程需要保证在有限的资源里所有重要的任务要被优先执行。 举个例子假设底层计算资源现在突然变为正常的一半如何减少对业务的影响 首先在工作流层面需要把一些对任务延时不敏感的工作流任务进行 delay这就需要一些策略的预设置 另外同一个工作流里面需要对不同的节点进行优先级的配置比如视频要转出五个档位可能其中有两个档位是大家消费概率最高的就需要把这两个档位优先转出来其他的档位进行延迟处理。这整体就涉及到了多级限流以及限流策略配置的一种能力。 批量重转它是什么意思呢举个例子假设昨天底层的同学上线了一个有问题的功能但是今天才发现。这时要做的是把昨天这个功能上线这个功能以后所影响的视频全部筛选出来快速进行重转而且不能够影响目前正在运行的业务。 这里面涉及到两个问题。 第一点是如何准确的从某任意一个时间点到另外一个时间点把这一批视频全部都挑出来。 第二点是快速重传而且不能影响线上的业务。所以这里需要有一个单独的子系统来负责整体的批量任务的查找和重转。
任务执行的难点2系统维度 从系统维度我们也做了一些工作包括中间件的冗余备份、对下游异常的检测等。当发现某些实例有问题会对这些实例进行熔断和摘除。其次系统有比较完善的流量切换方案因为系统经过多次大型活动的考验也具有完备的压测及预案这些对于系统的高可用也非常关键。 函数计算平台 上面介绍了工作流的系统。下面介绍一下它的下层函数计算平台。 首先介绍一下函数的概念。 函数对应于媒体工作流里的一个节点同时它也对应于一个细粒度的视频处理的任务。更通俗一点它对应一段可以执行的程序。 这个函数计算平台需要提供哪些能力呢 首先也是最重要的是为视频处理程序提供大规模水平扩展的能力使一个视频处理程序能够很容易大规模稳定地服务于线上业务。其次这个平台需要管理比较庞大的资源这些资源是多种类型的并且能够提供高效的资源调度能力。最后是能够处理各种异常情况及容灾等的高可用能力。 上图是这个函数计算平台的基本架构。 图中左侧部分是一个控制平面开发者可以开发一个函数通过管理 UI 注册到函数计算平台上。 图中右边是整个函数调用的流程。这个流程首先会经过该函数计算平台的一个 gateway到集群层面的调度然后会到一个单集群里单集群内部是我们自研的一个中心调度系统 Order。 Order 有一个中心调度器会把这个任务调度到一个具体的节点上去执行。这个节点就会拉取整个函数的可执行的包然后执行这个函数。 高可用性多集群 在多集群层面 首先我们做了多集群的容灾流量的一键切换其次我们也会根据一些预设配置进行流量的自动调节。 上图是简单的多机房示意图。 图中左右两边都是一个机房每一个机房里有多个集群。 每个机房里会有一个集群级别的调度器模块多机房之间又会有一个模块这个模块负责同步各个机房的资源情况包括资源的总量和使用情况等。 高可用性单集群 我们的单集群是一个中心调度系统有一个中心调度器称为 Server会有一个执行单元称为 Client。Server 是多实例、无状态的能够平滑、动态地升级。 在 Server、 Client 之间会有状态检测以及问题节点的熔断和任务重试等机制。 一般情况下Server 会通过心跳判断一个节点是否活着。除了这一点Server 也会观测节点整体的状态。 比如一个任务是否超时比较多或者任务的失败率比较高等当发生这种情况的时候也会对节点执行熔断策略。 控制面——服务治理 前面介绍过函数计算平台分了几层从上层的网关层到集群的调度到机器内部的调度。 每一层都是一个多实例的服务。所以每个上游都会对下游有一些异常检测摘除也就是所有的组件都会有单点的异常处理。此外还有一些中间件熔断的策略。 动态多媒体框架 BMF BMF 全称是 ByteDance Media Framework。它是字节跳动自研的多媒体处理框架。 之所以会去自研一个视频处理框架是因为我们发现传统的一些视频处理框架会有一些限制。 首先传统框架一般使用 C/C 开发和扩展扩展门槛比较高并且扩展以后需要重新编译在一个大型系统里面这是一件很麻烦的事情。 如果这个框架有很多人在开发和维护那么它的依赖越来越多最后会大大降低开发和运维的效率。 第二点传统的视频处理比如视频转码它的流程比较固定一般处理框架都可以支持。但是对于一些更加复杂的场景比如视频编辑或者 AI 分析传统框架本身在灵活性上会有一些限制。第三点就是传统的框架本身性能上也会有一些瓶颈。以 ffmpeg 为例filter graph 是单线程执行的。如果在 filter graph 里面放一个 GPU 的 filter它的执行效率就会下降得很厉害而且 GPU 的占用率也不会很高。 为了解决上面这些问题我们自研了 BMF 多媒体处理框架。它的目标包括 减少视频应用开发的成本使应用开发标准化。通过一套框架支持各种复杂的应用场景从框架本身来讲它具有比较高的灵活性。通过这个框架把所有视频处理的原子能力模块化并且做到动态管理和复用以此解决大规模协同开发的问题同时也能使这些能力比较好地复用在不同的场景和业务上。屏蔽底层的硬件差异。业务现在会越来越多地用到不同的异构硬件比如说 GPU我们希望这个框架能够 原生支持这些硬件。 上图是 BMF 框架的整体架构。 最上层是应用层。应用层上的每一块是一个视频应用比如前面提到的的视频转码、视频编辑、图片处理等等。下层是模块层每一个模块是视频处理的一个细粒度的原子能力。例如对视频进行编解码或者是进行 ROI 检测等等。 应用层和模块层是通过中间的框架层串联起来的。 这个框架层的中心是一个核心的引擎。这个引擎对上提供一套比较通用、简洁的流式接口使开发者能够比较容易地搭建出视频处理的应用。该接口支持多语言包括 C、Python、Go。对下它会提供一套比较完善的模块开发的 SDK也支持 C、Python、Go 这几种语言。 围绕着核心引擎我们又做了一些相关的服务和工具集这个服务主要用来管理模块的版本、依赖等。 这样的架构有一个最大的好处就是把开发者做了一个比较好的划分。 不同模块的开发者可以只专注于自己模块的开发选用自己熟悉的语言。 模块开发完以后整个模块就可以注册到系统里去。上层的应用开发是支持业务的业务可以不用了解底层的模块是怎么实现的也不用知道这个模块是什么语言实现的只要借助这个框架提供的接口就可以对这个模块进行无缝串联和使用。 上图进一步介绍了 BMF 的动态开发模式。 举个例子在实际情况当中算法开发人员研发了视频处理的算法。 首先这个算法会送到算法优化同学那里做优化。优化完以后整个算法就会形成一个模型。 接下来算法优化的同学会把这个模型注册到系统上模块的开发同学会把这个模型封装成具体的模块也是注册到系统里面去这个模块就是一个具体的原子的能力。 再接下去函数开发者也就是业务开发同学就可以把模块串联成一个具体的视频处理应用做成一个函数注册到函数管理平台然后灰度上线。 大家可以看到整个流程里面的各个团队分工都非常明确独立地开发协作效率很高。 而且这个流程里面所有模块的原子能力都是可以复用的。流程也不会牵扯到任何编译的依赖全部都是动态进行的。 亿级视频处理宏观流程 上图是视频转码的完整流程示例。当用户上传一个视频以后这个视频首先会进入服务端的存储这时会触发一个转码的流程也就是提交一个工作流任务这个任务首先会经过转码的服务然后被放到弹性队列里去下一步任务从弹性队列出队进入到工作流引擎里面去执行工作流引擎会把工作流拆解为一个个细粒度的任务然后送到函数计算平台去执行每一个函数会采用前面介绍的 BMF 动态开发的方式去构建。最终当所有细粒度节点的任务都执行完整个工作流也完成以后转码或者视频处理的流程就完成再一步步往上返回。 最后再回顾一下本文的一些要点 首先视频处理系统最重要的几点要求包括高可用也就是系统的稳定性高可扩展性当支持非常多的业务场景的时候系统的可扩展性对整体高可用也会有很大的影响开发以及运维的效率。 整体的架构总结起来就是媒体工作流加上函数计算平台加上动态的多媒体框架 BMF 这三个核心的部分。高可用性方面在服务层会有任务幂等、多级限流以及批量重传。在平台层会有多机房、多集群的切流策略单集群内部的冗余、上下游的异常检测等。最后底层的动态多媒体框架它虽然没有直接提升系统的高可用性但是它提升了系统的可扩展性以及开发和运维的效率所以它对于系统也起到了非常重要的作用。 未来系统会往更智能化的方向去发展。我们希望能构建一种分布式调度的执行平台用户只需要关注处理流程流程的拆分、资源调度如何执行都由平台来决定。 参考文献 https://blog.csdn.net/weixin_37604985/article/details/132179317 https://zhuanlan.zhihu.com/p/381259391 https://blog.csdn.net/csdnnews/article/details/117915142 所以以上才是“教科书式” 答案 结合 字节的方案大家回到前面的面试题 短视频系统如何做系统架构短视频APP如何做系统架构 以上的方案才是完美的答案才是“教科书式” 答案。 后续尼恩会给大家结合行业案例分析出更多更加劲爆的答案。 当然如果遇到这类问题可以找尼恩求助。 视频预告33章10Wqps 基础用户平台 架构与实操 为了大家拿高端offer拿架构offer即将发布 《第31章视频1000Wqps ID组件 架构与实操》 。《第33章视频10Wqps 基础用户平台 架构与实操》 。 并且提供配套的简历模板 帮助大家进行简历的亮点重建和升级最终帮助大家进大厂、做架构、拿高薪。 推荐阅读 《炸裂靠“吹牛”过京东一面月薪40K》 《太猛了靠“吹牛”过顺丰一面月薪30K》 《炸裂了…京东一面索命40问过了就50W》 《问麻了…阿里一面索命27问过了就60W》 《百度狂问3小时大厂offer到手小伙真狠》 《饿了么太狠面个高级Java抖这多硬活、狠活》 《字节狂问一小时小伙offer到手太狠了》 《收个滴滴Offer从小伙三面经历看看需要学点啥》 《尼恩 架构笔记》《尼恩高并发三部曲》《尼恩Java面试宝典》PDF请到下面公号【技术自由圈】取↓↓↓