免责声明。 本文完全基于 Netflix 的公开沟通 — 他们的技术博客、会议演讲、开源仓库和外部案例研究。这不是一份 Netflix 官方架构文档。我们建模公开已知的内容,以说明一个复杂技术栈如何能用 C4 模型变得 readable。当某些细节是推断而非 Netflix 明确陈述时,我们会注明。

Play 的解剖学:用 Archyl 以 C4 建模 Netflix

当你在 Netflix 上按下 Play,大约五十个服务在不到 200 毫秒内协作,开始让字节流向你的电视。

认证、profile 解析、eligibility 检查、watch-state 查询、manifest 生成、DRM 许可证发放、ad decisioning(自 2023 年起)、CDN 路由、edge 缓存命中、bitrate 协商、packet pacing — 这一切,都在第零帧到达你的屏幕之前。

Netflix 运行着一千多个微服务。他们的技术博客随口提到 "the membership platform" 仿佛它是单一事物 — 实际是十二个服务。 "The video pipeline" 是数十个微服务,跨三个架构层编排。 "Open Connect" 是一支由一万台 FreeBSD appliance 嵌入 ISP 网络的全球队伍。

如何理解这样一个技术栈?你不能,不能一次理解。这正是 C4 模型被发明用来解决的问题。

在这篇文章中,我们跨四个 C4 层级 — System Context、Container、Component 和 Code — 建模 Netflix 的架构,展示 Archyl 如何让这种规模的技术栈不仅可文档化,而且 可读。

我们不会覆盖每个服务。没人能。我们将跟随一个用户动作 — 按下 Play — 看它穿越各层。

层级 1 — System Context:十件事,而非一千

Netflix C4 System Context: 10 个系统,外部参与者

在 System Context 层级,Netflix 不是一千个微服务。是十个系统。

回顾 Netflix 过去五年的公开沟通,十个不同的系统一致浮现:

  1. Member Experience — 注册、计费、账户、profile、套餐管理
  2. Content Discovery — 搜索、推荐、浏览、排名
  3. Streaming Platform — playback、manifest、DRM、QoE
  4. Open Connect — 自有全球 CDN
  5. Studio Engineering — 从 pre-production 到 post-production 的工具
  6. Content Engineering — 目录、元数据、分类
  7. Data Platform — Kafka、Flink、Iceberg、Atlas、Mantis
  8. Cloud Platform — Spinnaker、Titus、Eureka,联邦化的开发者控制台
  9. Security — 边界、密钥、威胁检测
  10. Ads Platform — 2023 年随广告支持套餐加入

围绕它们:数百种设备上的 member、托管 Open Connect appliance 的 ISP、作为底层云的 AWS、DRM 合作伙伴(Widevine、PlayReady、FairPlay)、支付处理商和合作账单方(App Store、Google Play、电信捆绑)、供应方的内容工作室。

就这些。十个系统,六类外部参与者。其余都是细节。

这就是层级 1 的礼物:在 System Context 你不需要知道 Membership 是十二个微服务。你需要知道它存在,它和计费对话,而 ISP 最终托管你的字节。图是一个对话起点,不是清单。

ADR-001 · 自建 Open Connect,不向 CDN 付费

状态 · Accepted (2011 年,2026 年依然活跃)

背景 · 流媒体流量呈指数级增长。商用 CDN(Akamai、Limelight、Level 3)无法在 Netflix 规模下保证逐帧质量,且成本曲线不可持续。

决策 · 自建 CDN。把 appliance 嵌入 ISP 网络。在网络空闲的夜间预取。运行在带 NVMe + HDD 存储的 FreeBSD + NGINX 上。

后果 · Netflix 视频流量约 95% 现由 Open Connect 直接服务。CDN 不再是成本项,而成为战略护城河。层级 1 图在所有其他流媒体服务有 Akamai 的位置上有 Open Connect。

构建 Open Connect 的决定是塑造 Netflix 层级 1 图最强的单一架构选择。没有它,图会有一个巨大的 Akamai 框出现在今天整个 CDN 所在的位置。

在 Archyl 中,这就是 ADR 赢得自己位置的方式:它解释为什么图是这个样子。

层级 2 — Container:深入 Streaming Platform

Netflix C4 Container: Streaming Platform 内部

按下 Play,你的客户端 — 比如智能电视 — 撞上 Streaming Platform。我们打开盒子。

Streaming Platform 内部,公开来源至少揭示了这些 container:

  • Playback API — 入口点。验证会话,检查并发流上限,决定 bitrate ladder 的 eligibility。
  • Manifest Service(Netflix 内部词汇里的 Cadmium / Akira)— 按会话生成 HLS 或 DASH manifest 并签名。
  • License Service — 与设备的 DRM 握手(Android 和 Chrome 用 Widevine,Edge 和 Xbox 用 PlayReady,Apple 用 FairPlay)。
  • MSL Gateway — Netflix 自有的 Message Security Layer,客户端在 HTTPS 在平台内终止前所讲的协议。
  • FTL (Fast Track Live) — 直播流水线。
  • EVCache — 22,000 实例、14.3 PB 工作集的 Memcached 集群,前端会话和元数据的热读。
  • Cassandra 集群 — viewing state、watch history、持久化会话数据。

典型的 play 同时触发 Playback API → Manifest Service → License Service,在热的时候都从 EVCache 提供,否则从 Cassandra。manifest URL 指向一台 Open Connect appliance — 然后你的电视与一台可能就在你 ISP 数据中心内的服务器对话,毫秒级距离。

此层级的技术栈:Java + Spring Boot,服务间调用用 gRPC,事件用 Kafka,自 2022 年 Falcor → GraphQL 迁移以来,客户端 API 用 GraphQL Federation。

ADR-002 · 默认数据库选择 Cassandra

状态 · Accepted (2011 年,大部分有状态工作负载至今依然活跃)

背景 · Netflix 2008 年的数据中心宕机证明了单一主数据库是业务的 SPOF。多 DC 最终一致性、写入线性扩展、无 SPOF 成为新需求。

决策 · 新服务默认采用 Cassandra。在数据层接受最终一致性。在上层构建 EVCache 覆盖热读路径。

后果 · 大多数有状态服务都是 Cassandra-backed。多区域 active-active 变得自然。对需要全局 SQL 事务的工作负载(membership pricing、redemption code),2020 年加入了 CockroachDB — 但 Cassandra 仍然拥有持久的用户数据。

两条 ADR 之后,图开始变得有意义。container 的选择源自系统级决策,系统级决策源自业务约束。

层级 3 — Component:Cosmos 视频流水线内部

Netflix C4 Component: Cosmos 流水线 VIS CAS LGS VES VVS VQS

编码不在播放时发生。它在标题入库时,几个月前发生。但这是一个绝佳的层级 3 例子 — Netflix 公开了足够多的内容,我们可以绘制其中一个 container 的内部。

Cosmos 是取代 Netflix 之前的视频流水线 Reloaded 的平台。迁移在多年工作后于 2023 年 9 月完成。每个 Cosmos 微服务遵循三层模式:

  • Optimus — 对外暴露的 API 层
  • Plato — 工作流编排层
  • Stratum — 无服务器的计算层

通过编码的标题穿越一连串组件,每个组件是一个 Cosmos 微服务:

  1. VIS — Video Inspection Service。探查源资产。
  2. CAS — Complexity Analysis Service。评分内容编码难度。
  3. LGS — Ladder Generation Service。决定 bitrate ladder。
  4. VES — Video Encoding Service。实际编码,按 chunk 并行。
  5. VVS — Video Validation Service。验证输出完整性。
  6. VQS — Video Quality Service。用 VMAF — Netflix 的开源感知质量度量 — 评分结果。

这就是 Component 级 C4 的样子:不是 "这里有些代码",而是 "这里是一连串业务上有意义的原语,每个都被 owned、每个都可替换、每个都可测量"。

ADR-003 · 从 Reloaded 迁移到 Cosmos

状态 · Accepted (~2018 年开始,2023 年 9 月完成)

背景 · Reloaded 是单体顺序的视频流水线。当 Netflix 的目录扩大、编解码复杂度爆炸(HDR、AV1、per-shot 编码)时,Reloaded 成了瓶颈 — 添加一个新编解码就要重建整条流水线。

决策 · 拆分成 chunk 并行的微服务,每个实现 Optimus / Plato / Stratum 的三层模式。使用 Netflix 内部的优先级感知消息系统 Timestone 进行编排。

后果 · 编码吞吐量倍增。新编解码和质量实验变得可组合,而不是灾难性的。这种拆分解锁了 per-shot 编码,这直接改善了 member 体验的 bitrate 效率。

在 Archyl 模型中,这样的 ADR 与架构一起旅行。当你在 2026 年点开 Cosmos container 看到七个组件时,你也看到 2018 年的决策,解释为什么是七个而不是一个。

三个 ADR 卡片在 Archyl 中渲染

三个决策。Archyl 中的三个卡片,每个都连接到它塑造的 C4 元素 — Open Connect 到它的系统框、Cassandra 到数据库 container、Cosmos 到 2018 年前不存在的组件。图是现在;ADR 是为什么。

Ownership:把模型变成问责

Netflix Ownership Map: 团队映射到系统

C4 模型在你将团队映射到它之前是一个静态产物。

Netflix 公开沟通他们的团队组:Member Systems、Studio Engineering、Open Connect(独立的硬件聚焦组织)、Cloud Platform、Streaming Algorithms、Data Platform、Insight Engineering、Security、Ads Engineering、Personalization Research。

把它们落到 C4 模型上:

  • Member Systems 拥有 Member Experience 和 Ads Platform
  • Studio Engineering 拥有 Studio + Content Engineering 的 container
  • Open Connect 从上到下拥有整个 Open Connect 系统 — 他们硬件/软件的垂直整合很出名
  • Cloud Platform 拥有 Spinnaker、Titus、Eureka — 平台织物
  • Streaming Algorithms 拥有编码组件(Cosmos 流水线)
  • Data Platform 拥有 Kafka、Flink、Iceberg、Atlas、Mantis
  • Personalization Research 拥有推荐模型、搜索、排名

这种映射不是装饰。它是其后一切的基础。

一旦系统、container 或组件有了团队所有者,drift 检测就变得有责任:当一个新服务出现在提交里却不在图上时,某个具体团队会被询问。当合规规则被违反时,inbox 里就有一个名字。当需要写 ADR 时,模糊性崩塌。

在 Archyl 中,Ownership Map 是文档工具变成治理工具的瞬间。

Drift、合规和每周摘要

这种规模的模型会漂移。新服务上线。旧服务退役。栈变化 — Falcor → GraphQL Federation,Reloaded → Cosmos,Hystrix → 维护模式。

Archyl 每周计算一个 drift 分数:已记录的 C4 模型与代码中实际状态之间的差距。合规规则添加策略层 — "每个 container 都需要一个所有者团队"、"无跨数据库访问"、"每项标记 ADR 的技术必须在 radar 上"。

对 Netflix 而言,这是千服务规模的 drift 检测。但规则与十个服务时相同。

而上周发布的 Team Architecture Digest,在类 Netflix 的设置中意味着:

  • Member Systems 的周一摘要覆盖他们十二个 membership 微服务
  • Open Connect 的摘要覆盖 OCA 和控制平面
  • Streaming Algorithms 的摘要覆盖 Cosmos 和编码组件
  • 每个摘要都被 scope 到自己团队拥有的边界内,在自己团队的时区

相同的表面。不同的 scope。这就是 C4 + ownership 解锁的对称性。

你不需要一千个服务

你不是 Netflix。大多数工程组织都不是。

但教训也向下扩展。把 Context 与 Container 与 Component 分开的纪律、写出解释图为什么这样的 ADR、给每个框附上 ownership — 这种纪律就是阻止五十个服务的栈感觉像一千个的东西。

C4 + ADR + Ownership + Drift + 合规就是 Archyl 开箱即用提供的。Netflix 这个例子只是该模型最大的合理压力测试。

打开你自己的架构。勾画十个系统。挑最痛的那个深入到它的 container。写三条 ADR 解释为什么选择是这样。给每个 container 映射一个团队。

你将走在大多数工程组织一年才能到达的位置之前。

想用 C4 建模你自己的架构?从 Archyl 开始。也可以读 为什么 ADR 和 C4 一起更好用 或 Architecture Change Requests 如何把 pull request 的严谨带到你的 C4 模型。