# 视频流媒体 架构模板 > **代表产品**:Netflix、YouTube、各类点播 / 直播平台 > **一句话定位**:把又大又重的视频文件,以最低的卡顿、最省的带宽,送到全球任何一个屏幕上。 --- ## 1. 一句话定位 一个视频流媒体产品 = **一条「内容物流网」**:把一个几 GB 的源视频,加工成适配千百种网络与屏幕的版本,提前铺到离用户最近的「前置仓」,等用户点开时,就近、按需、一段一段地取。 架构上最反直觉的一点:它和普通网站最大的不同,不是逻辑复杂,而是**最贵、最稀缺的资源是「带宽」**,而最重的一次性投入是**「转码算力」**。整套架构几乎都在回答两件事:**怎么把同一个视频变成「人人都能流畅看」的多个版本(转码)**,以及**怎么把这些版本「铺到离用户最近、且尽量不回源站」(CDN 分发)**。 ## 2. 业务本质:它在解决什么问题 用户要的是**「点开就放、不转圈、清晰、还能拖进度」**。它取代的是「下载完整个文件再看」的旧时代——系统让你**边下边看(流式)**,而且无论你网好网差、用手机还是电视,都尽量给你「当前网络下最好的画质」。 钱从哪来: - **订阅**(包月看片,要稳定流畅的体验); - **广告**(免费观看 + 贴片/插播广告按曝光计费); - 这两者的共同前提都是「**播得流畅**」——卡顿是体验与留存的头号杀手。 **关键事实:每多一个人看一分钟视频,就实打实地消耗一份带宽。** 普通网站「多一次请求几乎不要钱」,这里「多播一部高清电影就是实打实的带宽账单」。而**带宽是这门生意最大的成本项**——这一条决定了为什么 CDN、缓存命中率、码率档位会成为架构的核心议题。 ## 3. 核心需求与约束 **功能性需求(系统要能做什么):** - [ ] 上传 / 入库:创作者或片方把源视频传上来。 - [ ] 转码(Transcoding):把一个源文件转成**多种码率 / 分辨率**的版本。 - [ ] 流式播放:边下边看,而非下完再看。 - [ ] 自适应码率(ABR):随网速实时切清晰度,网好上 4K、网差降标清,**优先不卡**。 - [ ] 拖动 / 快进:能跳到任意时间点开始播。 - [ ] 推荐:海量片库里帮用户找到想看的。 - [ ] 元数据:标题、封面、字幕、时长、可用码率清单等。 - [ ] (可选)直播:边录边转边播,对延迟敏感。 **非功能性需求 / 质量属性(这才是架构的主战场):** | 质量属性 | 目标 | 为什么对这类系统重要 | |---|---|---| | **启播时间 / 首帧延迟** | < 1~2 秒 | 点开转圈太久用户直接退。第一帧出得越快越好。 | | **卡顿率(rebuffering)** | 越低越好,接近 0 | 播放途中转圈是体验头号杀手,直接影响留存。 | | **带宽成本 / 每 GB 分发** | 越低越好 | 带宽是最大成本项,毛利全看它。这是和普通系统最大的区别。 | | **CDN 命中率** | 越高越好 | 命中边缘缓存=便宜又快;回源=又贵又慢。命中率直接决定成本。 | | **可用性** | 99.9%+ | 播不出来用户立刻就走。 | | **画质** | 在不卡的前提下尽量高 | 体验关键,但要和带宽成本平衡。 | **关键约束(不可逾越的边界):** - 🔴 **带宽又贵又是大头**。这是头号约束,CDN 与缓存命中率的一切努力都为它服务。 - 🔴 **视频文件巨大**。一个源片几 GB,转码后版本数倍增,存储与分发都吃力。 - 🔴 **转码是重计算、慢操作**。一个长视频转出几十个版本要消耗大量 CPU/GPU 时间,绝不能卡在用户请求路径上。 - 🔴 **用户网络千差万别**。同一个视频,要能在千兆光纤和地铁里的弱网上都尽量流畅——逼出了多码率 + 自适应。 - 直播额外约束:**对延迟极其敏感**,不能像点播那样慢慢转码、慢慢铺。 ## 4. 架构全景图 ``` 创作者/片方 观众(各种屏幕/网络) │ 上传源片(几 GB) ▲ ▼ │ 按当前带宽请求分片 ┌──────────────┐ │ │ 上传/入库服务 │ │ │ • 收原始文件 │ │ └──────┬───────┘ │ │ 放入源片存储 + 投递转码任务 │ ▼ │ ┌─────────────────────────────────────────────┐ │ │ 转码管线(异步、重计算、可弹性扩容) │ │ │ ┌──────────┐ 一个源片 │ │ │ │ 转码任务 │ 切成小片段(分片) │ │ │ │ 队列 │ 各分片并行转成多档: │ │ │ └────┬─────┘ 1080p / 720p / 480p / 240p │ │ │ ▼ + 生成「清单(manifest)」 │ │ │ ┌──────────────┐ │ │ │ │ 弹性转码工作集 │ (按队列长度自动扩缩) │ │ │ └──────┬───────┘ │ │ └─────────┼──────────────────────────────────────┘ │ │ 写入 │ ▼ │ ┌────────────────────────┐ 预热 / 按需回源 │ │ 对象存储(权威母带) │ ─────────────────────────┐ │ │ • 所有码率的分片 │ ▼ │ │ • 清单文件 │ ┌──────────────────────────────┐ │ └────────────────────────┘ │ CDN(多层边缘节点,全球铺开) │─┘ │ • 缓存热门分片就近分发 │ ┌────────────────────────┐ │ • 未命中才回源对象存储 │ │ 元数据服务 / 推荐 │ ──标题/清单──▶│ ◀═══ 绝大多数流量在这里被吃掉 ═│ │ (标题/封面/可用码率) │ └──────────────────────────────┘ └────────────────────────┘ 播放器(ABR 自适应码率): 先拿清单 → 估算当前带宽 → 请求"合适档位"的下一段分片 网变好→切高清;网变差→切低清;目标是"绝不卡" ``` > 灵魂部件是两块:**「转码管线」**(把一份源片变成人人能看的多版本,重计算、必须异步)和**「CDN + 对象存储」**(把内容铺到用户身边、把带宽成本压下来)。其余(元数据、推荐)都是围绕「让这条物流网把视频又快又省地送达」服务的。 ## 5. 组件职责 - **上传 / 入库服务**:接收源视频,存进对象存储的「母带」区,并**投递一个转码任务**。*为什么需要*:源片是一切的起点;它把「上传」和「后续重加工」解耦——上传完立即返回,转码慢慢来。 - **转码管线(Transcoding Pipeline)**:把源片**切成小片段**,把每个片段**并行转成多档码率/分辨率**,并生成描述「有哪些档、每档的分片在哪」的**清单(manifest)**。*为什么需要*:用户网络与屏幕千差万别,一个版本不可能通吃;且切片+多档是「自适应码率」和「边下边看」的物理基础。它必须**异步、可弹性扩容**,因为转码极重。 - **对象存储(权威母带 / 全部产物)**:存源片和**所有码率的分片 + 清单**。一次写、海量读、不可变。*为什么需要*:这是内容的唯一权威副本,也是 CDN 未命中时的回源地。 - **CDN(边缘分发网络)**:把热门分片缓存在**离用户最近的边缘节点**,就近响应;未命中才回源对象存储。*为什么需要*:**这是把带宽成本和延迟同时打下来的关键**——让绝大多数流量在边缘被消化,既快又省,还保护源站。 - **播放器(客户端 ABR 逻辑)**:先取清单,**实时估算当前带宽**,据此决定下一段分片请求哪一档码率;网络好就升清晰度,变差就降,**首要目标是不卡**。*为什么需要*:网络是实时波动的,只有客户端能感知此刻的真实带宽并即时调整。**自适应的「大脑」在播放器侧。** - **元数据服务**:存标题、封面、时长、字幕、可用码率清单等「关于视频的信息」(注意:不是视频本身)。*为什么需要*:浏览、搜索、起播前的信息展示都靠它;它是轻量高频读,和重量级的视频字节流分开。 - **推荐服务**:从海量片库里为用户挑内容。*为什么需要*:片库越大,「找到想看的」越难,推荐直接驱动观看时长与留存。 ## 6. 关键数据流 **场景一:一个视频从上传到可被观看(写 / 加工路径)** ``` 1. 创作者上传源片(几 GB) ──▶ 上传服务 ──▶ 存入【对象存储·母带区】 2. 上传服务投递一个【转码任务】到队列后,立即返回("上传成功,处理中") 3. 转码管线异步领取任务: a. 把源片切成许多小片段(比如每 4~10 秒一段) b. 每个片段并行转成多档:1080p / 720p / 480p / 240p ... c. 生成【清单 manifest】:列出"有哪些档、每档每段的地址" 4. 所有产物(分片 + 清单)写回【对象存储】 5. (可选)把热门内容的分片【预热】推送到 CDN 边缘节点 6. 元数据服务标记该视频"可播",可用码率清单就绪 ``` > 注意第 2 步:**上传完立刻返回,转码在后台慢慢做。** 转码是重计算,绝不能让用户卡在那等几十分钟——这是「重活异步化」的典型。 **场景二:观众点开播放(读 / 分发路径,最核心)** ``` 1. 用户点开视频 ──▶ 元数据服务:拿到【清单】(有哪些码率、分片在哪) 2. 播放器估算当前带宽(比如此刻 5 Mbps)──▶ 决定先要 720p 3. 播放器请求"720p 的第 1 段分片" ──▶ 就近的【CDN 边缘节点】 命中 → 边缘直接返回(快、便宜) ← 绝大多数情况 未命中 → CDN 回源【对象存储】取一次,顺手缓存,再返回(慢、贵) 4. 第 1 段到手即开播(边下边看),同时后台预取后续分片 5. 网络变好(升到 20 Mbps)→ 下一段改请求 1080p;变差 → 降到 480p ⟲ 每隔几秒、每一段都重新决策一次,目标:画质尽量高 且 绝不卡 ``` > 注意第 3 步:**命中边缘=又快又便宜,回源=又慢又贵。** 整个分发经济学就压在「CDN 命中率」上。注意第 5 步:**清晰度是「按分片」动态切换的**,不是整片定死——这就是自适应码率(ABR)。 **场景三:直播(为什么和点播不一样)** ``` 主播推流 ──▶ 实时接入 ──▶ 边收边切片 + 边转码(必须快,不能慢慢转) ──▶ 立即推到 CDN 边缘 ──▶ 观众以仅几秒的延迟拉流观看 关键差异:点播可以"先慢慢转码好再分发";直播是"边产生边转码边分发", 转码窗口极短、对延迟极敏感,架构要为"实时"重新设计。 ``` > 直播把点播的「先加工、后分发」压缩成「边加工边分发」,延迟约束完全不同,通常需要**单独的低延迟链路**。 ## 7. 数据模型与存储选择 核心实体:`视频(源片)` ──转码──▶ `多档分片(segments)` + `清单(manifest)`;`视频` ── 关联 ──▶ `元数据(标题/封面/字幕)`;`用户` ──产生──▶ `观看行为(供推荐)`。 | 数据 | 存储类型 | 为什么 | |---|---|---| | 源片(母带) | 对象存储 | 文件巨大、不可变、写一次、偶尔读(回源/重转码) | | 转码产物(各档分片 + 清单) | 对象存储 + CDN | 巨大、不可变;**被海量读 → 必须靠 CDN 边缘分发** | | 视频元数据(标题/封面/可用码率) | 关系型 / 文档型 | 轻量、高频读、要支持浏览与检索,和视频字节流分开 | | 转码任务状态 | 队列 + 状态库 | 异步任务,要排队、重试、追踪进度 | | 观看行为 / 播放质量日志 | 列存 / 时序 | 海量、按时间聚合,供推荐与质量监控(卡顿率等) | | 用户 / 订阅 | 关系型 | 要事务、强一致(计费相关) | > 教学点:**「视频本身」和「关于视频的信息」是两类截然不同的数据,必须分开存。** 视频字节是「巨大、不可变、靠 CDN 分发」的对象存储料;元数据是「轻量、高频读、要检索」的数据库料。把它们混在一起,会让浏览页面被巨大的视频字节拖垮。**用「对象存储 + CDN」描述视频存储,是因为它的访问形态是「不可变大文件 + 海量就近读」,与具体产品无关。** ## 8. 关键架构决策与权衡 ⭐ **决策 1:转码——同步还是异步?(几乎没有悬念,但要懂为什么)** - **同步**:上传后当场转码,转完才告诉用户成功。 - 优点:逻辑直白。 - 代价:转一个长视频要几分钟到几十分钟,**用户被卡死在上传请求里**;转码占用的算力还会和在线请求抢资源,流量一来就崩。 - **异步**:上传即返回「处理中」,转码任务进队列,由后台弹性工作集慢慢消化。 - 优点:用户体验顺滑;转码算力可独立**弹性扩缩**;失败可重试;削峰填谷。 - 代价:有「上传后到可播」的延迟;要维护任务队列、状态追踪、重试与去重。 - **取向**:**必须异步**。这是「把重计算从请求路径上挪走」的铁律——任何耗时远超用户耐心的操作,都该异步化。 **决策 2:存几档码率?(成本 vs 体验)** - 档位太少(比如只有高清+标清):省转码算力、省存储,但**没法贴合各种网络**——弱网用户要么卡、要么只能看很糊的。 - 档位太多(从 4K 到极低清十几档):贴合度极好,自适应平滑,但**转码算力翻倍、存储翻倍**(每多一档,所有分片都要多存一份)。 - **取向**:**取一组覆盖主流网络与屏幕的有限档位**(典型几档到十几档),并可对热门内容多备几档、冷门内容少备。代价是要在「贴合度/画质」与「转码+存储成本」之间持续权衡。**这是一道纯粹的成本-体验平衡题,没有标准答案,取决于用户网络分布。** **决策 3:CDN 策略——热门预热,还是一律按需回源?** - **一律按需(被动)**:第一个请求某分片的用户触发回源,之后才缓存在边缘。 - 优点:简单,只缓存真正被看的。 - 代价:**每个边缘节点的「第一个观众」都要等一次回源**(慢);大热内容上线瞬间,大量未命中同时回源,**惊群冲击源站**。 - **热门预热(主动)**:预测/已知会火的内容(新剧首播、头部创作者),**提前把分片推到各边缘节点**。 - 优点:开播即命中,启播快;削掉惊群。 - 代价:要预测热度,预热了没人看就浪费了边缘存储与推送带宽。 - **取向**:**冷长尾按需回源,头部热门主动预热**,两者结合。**「为可预测的热点提前铺货,为不可预测的长尾按需取货」**——这正是物流仓配的思路。 **决策 4:点播 vs 直播——要不要两套架构?** - 点播(VOD):内容已存在,可以**先从容转码好、再慢慢铺 CDN**,优化重点是命中率和成本。 - 直播(Live):内容**正在产生**,必须边收边切边转边分发,优化重点是**端到端延迟**,转码窗口极短。 - **取向**:两者**通常需要不同的链路**。直播为低延迟牺牲一些转码精细度和缓存策略;点播为成本和画质从容加工。强行用点播架构做直播,会因延迟不达标而失败。**「延迟敏感」与「成本敏感」是两种不同的设计取向,别用一套架构硬套两种约束。** **决策 5:自适应码率(ABR)的决策权,放服务端还是客户端?** - 服务端决定推哪档:服务端要感知每个客户端的实时网络,几乎不现实。 - **客户端(播放器)决定**:播放器最清楚「此刻这条网络有多快、缓冲还剩几秒」,由它逐段挑码率。 - **取向**:**决策权在客户端**。服务端只负责「把所有档位都备好、清单写清楚」,具体每一段挑哪档由播放器实时定。**把决策放在「信息最全的那一端」**——只有客户端能实时感知本地网络。 ## 9. 规模化与瓶颈 和普通系统不同:**这里的瓶颈是「转码算力」和「CDN 带宽/命中率」,而不是业务数据库。** - **第一个瓶颈:转码算力。** 上传高峰或大批量入库时,转码任务堆积,「可播」延迟拉长。 破解:① **异步队列削峰**;② 转码工作集**弹性扩缩**(队列长就扩、闲了就缩);③ 分片**并行转码**(一个视频切成段并行处理);④ 冷门内容少转几档。 - **第二个瓶颈:CDN 带宽与命中率(成本核心)。** 带宽是最大成本项,命中率每降一点,回源成本和延迟都飙升。 破解:① **分层缓存**(边缘 → 区域中间层 → 源站,层层拦截回源);② **热门内容预热**;③ 提高分片可缓存性(不可变分片天然好缓存)。 - **第三个瓶颈:热门内容的惊群效应。** 爆款上线瞬间,海量用户同时请求同一批分片;若边缘没命中,会同时回源**压垮源站**。 破解:① 预热;② 回源请求**合并/去重**(同一分片的并发回源只发一次);③ 分层缓存吸收冲击。 - **存储增长**:档位 × 内容量 → 存储膨胀。破解:冷内容降档/归档到更廉价的存储层。 ## 10. 安全与合规要点 - **内容版权(DRM)与防盗链**:付费内容要做版权保护与播放授权,防止分片被直接抓取、防止盗链消耗你的带宽。这是付费视频生意的底线。 - **盗版上传与内容审核**:用户上传型平台要识别盗版/违规内容(上传即审核),并能快速下架。 - **带宽盗用**:别人盗链你的 CDN 资源 = 花你的钱。要做来源校验、签名 URL、有效期控制。 - **地域合规(版权地理限制)**:很多内容只在特定地区有版权,分发要按地域做访问控制。 - **隐私**:观看历史是敏感行为数据,要保护与最小暴露。 ## 11. 常见误区 / 反模式 - ❌ **不转码,直接发源片** → ✅ 源片对弱网/小屏用户又大又放不动,且无法自适应。**必须转成多档。** - ❌ **不上 CDN,从源站直发** → ✅ 带宽成本爆炸、延迟高、源站被打垮。**视频分发必须走 CDN 边缘。** - ❌ **同步转码,卡住上传请求** → ✅ 转码是重计算,**必须异步**(队列 + 弹性工作集),上传即返回。 - ❌ **不做自适应码率(ABR),全程定死一档** → ✅ 网差就卡、网好浪费。**按分片随网速动态切换。** - ❌ **整片当一个大文件下发** → ✅ 无法边下边看、无法自适应、无法只缓存热门片段。**必须切片 + 清单。** - ❌ **热门内容也一律按需回源** → ✅ 上线瞬间惊群压垮源站。**可预测的热点要预热。** - ❌ **视频字节和元数据混在一起存** → ✅ 浏览页会被巨大字节拖垮。**字节走对象存储+CDN,元数据走数据库。** ## 12. 演进路线:MVP → 成长期 → 成熟期 | 阶段 | 用户/规模量级 | 架构长什么样 | 此时该操心什么 | |---|---|---|---| | **MVP** | 验证想法 | **单档码率 + 直接分发**:上传后转一档(或干脆原片)、放对象存储、可能挂一个简单 CDN;无 ABR 或只有最基础的切片 | **先验证有没有人看**,别一上来自建全球转码集群和多 CDN | | **成长期** | 百万级播放 | **多码率转码管线**(异步队列+弹性扩容)+ **CDN 分发** + 播放器 **ABR**;元数据与视频字节分离;开始关注命中率 | 把卡顿率压下来、把带宽成本(命中率)打下来;转码不堆积 | | **成熟期** | 千万~亿级 | **全球多 CDN + 分层缓存 + 智能预热** + 精细 ABR + 大规模弹性转码 + 推荐系统 + (按需)**直播低延迟链路** + DRM/地域合规 | 带宽成本、命中率、惊群、转码算力、容灾、版权合规 | ## 13. 可复用要点 - 💡 **把「重计算」从用户请求路径上挪走。** 转码异步化的思想,适用于任何「耗时远超用户耐心」的操作——图像处理、报表生成、批量导入,都该进队列、可弹性扩容、可重试。 - 💡 **把数据放到离消费者最近的地方(缓存/CDN),是同时降延迟和降成本的最强杠杆。** 这里是视频分片,在别处可能是静态资源、API 响应、计算结果。命中率就是成本表。 - 💡 **把决策放在「信息最全的那一端」。** ABR 把码率决策交给最了解本地网络的播放器;同理,很多决策应下沉到最掌握上下文的层。 - 💡 **为「可预测的热点」提前铺货,为「不可预测的长尾」按需取货。** 预热 + 按需回源的组合,是一切热点/长尾混合负载的通用配方。 - 💡 **同一份内容做成多档、按实时条件动态选取。** 多码率 + 自适应的本质是「准备好一组弹性档位,运行时按真实环境挑最合适的」——这套思想在限流降级、多级服务质量里同样适用。 - 💡 **识别你系统真正的「成本大头」,围绕它做架构。** 这里是带宽,所以 CDN、命中率、码率档位才是核心议题,而不是代码优雅。 ## 🎯 随堂检验 --- ## 参考原型与延伸阅读 > 本模板基于以下**官方工程博客 / 文档**整理。 **📖 工程博客 / 文档:** - [Netflix: Per-Title Encode Optimization](https://netflixtechblog.com/per-title-encode-optimization-7e99442b62a2) — 按片定制编码阶梯(转码 + 自适应码率的码率阶梯优化)。 - [Netflix Open Connect Overview (PDF)](https://openconnect.netflix.com/Open-Connect-Overview.pdf) — 自建 CDN(Open Connect)在 ISP 部署缓存服务器的内容分发架构。 - [HLS vs. DASH (Wowza)](https://www.wowza.com/blog/hls-vs-dash) — 两大自适应码率流媒体协议对比(分段与码率切换)。 --- > 📌 一句话记住视频流媒体:**它不是「能放视频的网站」,而是「一条全球内容物流网」——先把一份源片加工成人人能看的多版本(转码),再把它铺到离每个人最近的前置仓(CDN),所有架构取舍最终都在回答『怎么把视频送得又快、又不卡、又省带宽』。**