速读#
这篇不是把 YouTube 架构照搬到个人站，而是用它当镜子，标出哪些该补、哪些不该碰。真正该试的是多副本和消息队列这类小 demo，不是上来追多机房和分布式存储；清醒比贪心重要。
一层一层照#
CDN#
YouTube 全球边缘缓存；我用 Cloudflare CDN，思路同，规模差几个数量级。
我这几百请求的站没有真正长尾，大部分内容都能算「热」。CDN 边际已满，不必纠结命中率。 不该碰的，认了。
负载均衡#
YouTube 多层分发；我只有 Nginx L7 单机反代。
缺口： 没有真正流量分发，一台挂就全挂。
该试： upstream 多后端 + replicas，哪怕 round-robin——为理解分发，不为上规模。标「该试」，不是「已会」。
微服务#
Compose 拆容器是关注点分离雏形，仍是一起部署，不能独立扩缩。
分了职责，没分伸缩边界。 这规模拆微服务是过度工程——不该补，但知道刀以后往哪下。
分布式存储#
多副本 + 共识极重；我连一个单实例数据库都用不满。
学 CAP，不搭集群。 差距大，不该碰。
异步#
YouTube 上传后异步转码；我这边：表单后邮件可扔队列，不阻塞主请求。
该试： 消息队列 demo，把生产 / 消费从纸面变实操——顺便亲手碰一遍队列带来的新麻烦：消息丢了怎么办、重复消费怎么办。解决方案脱离过问题，是背不住的。
容错#
systemd 自拉、Docker restart、缓存失效回落 DB——都是进程 / 单机级。没有故障域。
差距真实，这规模不该补。
CAP：做过取舍，只是没叫这个名#
CAP 说的是：网络分区一旦发生（分布式里迟早发生），一致性和可用性只能保一个。所以实际工程常在 C 与 A 之间按业务取舍：YouTube 播放计数偏 A——少算几次没人在乎，服务不能停；付费偏 C——钱宁可暂时办不了，也不能算错。
严格说，我的单机没有网络分区，谈不上 CAP——这点得先承认，不然是拿理论贴金。但取舍的方向感是相通的：SQLite 用一把全库写锁保证任何时刻只有一个写者，等于用并发吞吐换绝对一致，和分布式里「偏 C」的选择是同一种性格。取舍我早就做过，只是当时不知道它在理论里叫什么。 有了锚点，再看别人架构里的 C/A 决策，就能对上号而不是背名词。
对照表#
| 维度 | 我的博客 | YouTube | 判断 |
|---|---|---|---|
| 流量 | 很小 | 极大 | 不该追 |
| 部署 | 单机 Compose | 全球多中心 | 该试 replicas，不该追多机房 |
| 存储 | 单库 | 分布式存储 | 不该碰 |
| 缓存 | 单 Redis | 多层 | 边际已满 |
| 网关 | Nginx | 多层 LB | 该试 upstream |
| CI/CD | GitHub Actions | 内部系统 | 已够 |
表的价值不在差距有多大，在每一行标了 该试 / 不该碰 / 已够。清醒比贪心重要。
带走的判断#
- 架构思路是通的，区别在规模——单机全栈是理解分布式的锚点，不是「我会分布式了」
- 该试的标清楚去动手；不该碰的也标清楚，不焦虑
- 看大架构时问：「照出我哪层差距、这规模该不该补？」避免退化成资料
真正该补的就两条：多副本 demo、消息队列 demo。其余的，认了。
分布式不是一个待吞的大领域，是一组按规模决定「该补 / 不该补」的具体缺口。照镜子，不是仰望。