视频流媒体 架构模板
代表产品: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、命中率、码率档位才是核心议题,而不是代码优雅。
🎯 随堂检验
视频流媒体最大的成本与瓶颈,通常来自?
- ACPU 计算
- B带宽——把海量视频送达全球
- C内存
参考原型与延伸阅读
本模板基于以下官方工程博客 / 文档整理。
📖 工程博客 / 文档:
- Netflix: Per-Title Encode Optimization — 按片定制编码阶梯(转码 + 自适应码率的码率阶梯优化)。
- Netflix Open Connect Overview (PDF) — 自建 CDN(Open Connect)在 ISP 部署缓存服务器的内容分发架构。
- HLS vs. DASH (Wowza) — 两大自适应码率流媒体协议对比(分段与码率切换)。
📌 一句话记住视频流媒体:它不是「能放视频的网站」,而是「一条全球内容物流网」——先把一份源片加工成人人能看的多版本(转码),再把它铺到离每个人最近的前置仓(CDN),所有架构取舍最终都在回答『怎么把视频送得又快、又不卡、又省带宽』。