七层架构
一次「打开 App 并上滑」穿过七个平面。这不是机房里的服务清单，而是按公开资料归纳的能力分层：上面四层决定产品形态，下面三层决定能否在几亿 DAU 下活下来。
上滑
要下一批 Feed
鉴权并纠偏到本单元
并行召回和排序
约十条 ID 和播放地址
拉当前和下一条视频
出画
异步上报划走或完播
| 层 | 英文 | 这一跳解决什么 |
|---|---|---|
| L0 客户端 | Client | 全屏沉浸播放，本地先做一半体验 |
| L1 接入与边缘 | Edge & Gateway | 把字节赶到用户最近的地方 |
| L2 业务服务 | Business Services | 推荐之外的账户、关系、搜索与交易 |
| L3 推荐与内容理解 | Recommendation | 抖音真正的操作系统 |
| L4 媒体处理 | Media Pipeline | 一条视频从拍摄到可播 |
| L5 数据平面 | Data Plane | 行为事件驱动的实时闭环 |
| L6 存储 | Storage | 按访问模式拆，而不是一个大库 |
L0 客户端
抖音的产品形态决定了客户端不是薄壳：全屏信息流、手势上滑、下一条预取、自适应码率、弱网重缓冲，都在端上完成。服务端给出「下一批视频」的元数据，真正的丝滑感来自播放器策略。
- 播放器按网速在多码率档之间切换，优先保证首帧和连续播放，而不是一味追最高清。
- 观看当前视频时预加载下一条甚至下几条，把推荐接口的网络往返藏进观看时间。
- 曝光、完播、划走、停留时长、复播、点赞评论等行为在端上组包，近实时上报，喂给推荐闭环。
- 发布侧做分片上传、断点续传、本地压缩，降低弱网失败率。
为何这样拆：短视频的交互单位是「一条」，不是「一页」。端上必须把下一条当成已经在播的内容来准备。
L1 接入与边缘
视频体积大、QPS 高、用户全国分布。接入层把静态媒体和动态 API 拆开：媒体走 CDN / 边缘缓存，业务请求走网关做鉴权、路由、限流和灰度。
- 点播视频以对象存储为源站，边缘节点缓存热内容，冷内容回源。热榜和头部创作者的视频命中率极高。
- 上传走就近接入，避免手机把几百 MB 的成片拖过骨干网。
- API 网关统一鉴权、设备风控、配额和超时；推荐、搜索、社交走不同后端集群。
- 多机房就近接入 + 故障切流，避免单地域把全国用户拖垮。
为何这样拆：推荐再准，首帧如果要 3 秒，用户已经划走。分发延迟是产品体验的一部分。
L2 业务服务
Feed 是主屏，但完整产品是一张业务网：账号与资料、关注与好友、评论与私信、搜索、直播入口、电商与广告。它们以微服务形式独立扩缩容，通过 RPC 互相调用。
- 用户服务管账号、资料、权限；计数（粉丝、赞）与资料读写分离，热点账号要单独保护。
- 社交图（关注、好友、屏蔽）读多写少、深度遍历多，适合图存储而不是纯关系表。
- 评论、点赞是写放大场景：一条爆款视频会在短时间涌入海量互动，需要削峰、异步落库、缓存计数。
- 搜索覆盖视频、用户、音乐、直播、商品，和推荐共用内容理解信号，但目标是满足 Query 而不是猜兴趣。
- 广告与电商以「混排」插入信息流，受频控、相关性和商业目标约束，不能破坏主 Feed 体验。
为何这样拆：推荐决定打开理由，社交和交易决定留下来之后能不能变成平台。
L3 推荐与内容理解
和早期微博、朋友圈不同，抖音主 Feed 不是「关注的人发了什么」，而是「模型认为你下一秒会看完什么」。内容理解把视频变成可计算的向量和标签，推荐系统在百毫秒内从亿级候选里抽出十几条。
- 多路召回并行：协同过滤、双塔向量检索、热门、社交、同城、作者粉丝、运营池等，把搜索空间从亿级压到千级。
- 粗排用轻量模型快速打分，精排用更重的模型吃用户序列、视频侧特征和交叉特征。
- 重排处理多样性、重复作者、时效、疲劳度；混排插入直播、广告、购物车。
- 内容理解用视觉、语音、文本、音乐指纹给视频打标并生成 embedding，新内容冷启动依赖这一层。
- 在线学习把刚刚发生的滑动反馈写回稀疏参数（公开对应 ByteDance Monolith 等工作），让兴趣漂移以分钟级体现。
为何这样拆：没有关注关系当冷启动拐杖时，模型必须在几条视频内抓住用户。这是架构一切取舍的中心。
L4 媒体处理
用户上传的是源文件，用户看的是适配网络和设备的分发版本。中间是一条异步流水线：转码、抽帧封面、水印、质检、机审与人审。只有过审并完成关键档转码的内容才会进入可推荐池。
- 源文件进对象存储后触发转码任务，产出 360p 到 1080p（及更高）多档，供播放器 ABR 选择。
- 抽关键帧做封面、识别空镜/黑屏/低质，避免把无法观看的内容送进推荐。
- 机审覆盖色情、违法、广告导流等；不确定样本进人工审核队列。高风险类目先审后发。
- 直播是另一条实时管道：推流接入 → 转码 → CDN，弹幕礼物走独立高 QPS 通道，不能阻塞视频帧。
为何这样拆：推荐只消费「已经可播且可理解」的内容。媒体管道是推荐的上游工厂。
L5 数据平面
每一次滑动都是一条事件。数据平面把客户端埋点、服务端日志汇入消息队列，一边用流计算更新实时特征和画像，一边落入湖仓做训练与分析。实验平台让每一次策略改动都能量化。
- 行为事件经 Kafka 类总线解耦：推荐、计数、通知、安全、分析各取所需。
- Flink 类流计算维护短时兴趣、反作弊信号、热点检测、实时计数。
- 特征平台保证训练与线上服务用同一套特征定义，降低训练-服务不一致。
- 离线湖仓做样本拼接、模型训练、报表；在线模型做增量更新。
- 大规模 A/B 实验（字节跳动公开分享过实验中台）是推荐迭代的操作系统，而不是上线前的检查项。
为何这样拆：推荐效果来自闭环速度：从「划走」到「参数更新」越短，模型越能追上兴趣变化。
L6 存储
视频二进制、用户资料、社交图、计数、倒排索引、embedding 的访问模式完全不同。抖音类系统按「数据形状」选存储，再用缓存挡住热点。
- 对象存储承载源片与转码产物，按生命周期分层（热/温/冷）。
- Redis 类缓存承担 Feed 结果、会话、计数、热点视频元数据；爆款 Key 要分片或本地缓存。
- 元数据（用户、视频记录）用分布式关系库；计数和 Timeline 往往另建。
- 关注关系用图存储（公开资料中的 ByteGraph 一类）支持好友、二度关系、屏蔽。
- 搜索倒排与向量索引（ANN）分别服务关键词检索和双塔召回。
为何这样拆：存储选型错误会在爆款出现时立刻放大：热点 Key、大 V 粉丝列表、热视频评论是典型炸弹。