这二十年其实是同一个故事在反复上演: 数据先撑爆了存储和计算, 然后撑爆了数据库, 接着业务拆成微服务又撑爆了运维; 每一次"撑爆"都把某家公司摁在地上摩擦, 而它们挣扎着爬起来时顺手造的那个轮子, 转头就成了全行业的地基; 这篇严格按时间从上往下串成一个故事, 每个轮子只记三件事: 哪年、谁家、被啥需求逼的; 它同时也是 ds/ 这一摞笔记的索引页, 相关的都挂了内链;

一张总图先压个轴, 后面分幕细讲 (主线是后台基建, 另有"可靠性"和"前台 Web"两条副线, 放在最后单讲):

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
1998 ─ VMware        虚拟化: 一台物理机切成多台 VM, 是多租户云的前提
2003 ─ GFS / Xen      Google 在会坏的廉价磁盘上存 PB / 开源虚拟化
2004 ─ MapReduce / nginx  普通工程师也能并行算 PB / nginx 解决 C10K 高并发
2006 ─ Bigtable·Chubby·AWS·Hadoop  结构化存储·协调·云诞生·开源三驾马车
2007 ─ Dynamo        Amazon: 购物车永不拒写 → AP/最终一致, 还带火 p99 理念
2008 ─ Cassandra / ZooKeeper  NoSQL / 开源版 Chubby
2009 ─ Redis         内存缓存, 挡住数据库前的读流量
2010 ─ Kafka / Spark  把数据流统一成一条日志 / 把计算搬进内存
2012 ─ Spanner       全球规模 + 强一致 + SQL, NewSQL 诞生
2013 ─ Docker        容器: 解决"在我机器上能跑"
2014 ─ k8s·Raft·Lambda  编排容器·可懂的共识·Serverless
2015 ─ CNCF + etcd    容器时代的协调大脑, 云原生定旗号
2016 ─ Envoy         多语言微服务要统一的网络/观测层
2017 ─ Istio         管一大群 Envoy, k8s 赢得编排之战
2018+ ─ Prometheus / Jaeger / eBPF  可观测性 + sidecarless 苗头
副线 ─ 可靠性: GameDay(06) → Chaos Monkey(11) → Chaos Engineering(15) → 双十一
副线 ─ 前台: Web 1.0(只读) → Web 2.0(读写/UGC) → Web 3.0(读写还能拥有)

第一幕 (1998-2006): 浇地基、三驾马车、云诞生

故事得从地基讲起, 因为后面所有东西都跑在它上面; 云不是凭空变出来的, 底下垫着两层: 数据中心和虚拟化; 第一层是数据中心, Google、Amazon 这些家伙发现与其买昂贵大型机, 不如拿海量廉价机器堆出一台"仓库级计算机" (warehouse-scale computer, Google 的 Barroso 和 Hölzle 专门写过本小册子就叫这名), 一栋楼塞几万台、自己设计供电散热, 把单位算力成本压到地板; 第二层是虚拟化, VMware (1998)、Xen (2003)、KVM (2007) 这些 hypervisor 能把一台物理机切成多台互相隔离的虚拟机 (VM), 一台机器上跑好几家互不打扰的客户, 这就是 multi-tenancy (多租户); 后来 AWS 卖的 IaaS, 本质就是卖这些 VM 切片; 虚拟化细节详见 12.xen、18.vmware_esx_mem;

地基之上, 2000 年泡沫一破, 一地鸡毛里活下来的是 Google、Amazon、Yahoo; Google 的处境最惨也最典型: 它想把整个互联网抓下来建索引, 可买的全是随时冒烟的廉价 PC; 于是被逼着三年连发三记重拳, 也就是"三驾马车": 2003 年的 GFS 思路简单粗暴, 既然磁盘必坏就大文件切块、每块三份、一个 master 管元数据, 它顺手立下了云原生的祖训"故障是常态不是意外"; 2004 年的 MapReduce 解决另一半烦恼, 大多数工程师不会写分布式, 那就把容错调度全塞进框架, 工程师只管写 map 和 reduce, "把分布式复杂性藏进框架"从此成了行业默认动作; 2006 年的 Bigtable 给 Search/Gmail 撑起 web 尺度的结构化大表;

这三个家伙都得有人拍板"谁是 master"、都要存关键元数据, 于是同年 Google 又掏出 Chubby, 一个粗粒度锁服务当裁判; 详见 11.chubby; 它就是后来 ZooKeeper 和 12.etcd 这一支的老祖宗;

另一条线上, Amazon 在闷声干件改变世界的事; 它的零售基建本来就得扛黑五的瞬间洪峰, 平时一大半算力闲着, 2006 年它一拍脑袋干脆把这份弹性算力按量租出去, AWS 就这么诞生 (S3 三月、EC2 八月), 基础设施第一次变成"按需开、用多少付多少"; 紧接着一场"上云大迁徙"开始: 公司不再自己买服务器堆机房 (CapEx 重资产), 而是租云按量付费 (OpEx 轻装), 新一代创业公司 (Airbnb、Uber) 干脆生在云上、从没自己的机房; 至此"买机器"变成了"调个 API 开机器";

第二幕 (2006-2010): 开源复刻、NoSQL、把数据库哲学掰弯

Google 论文漂亮但代码不开源, 急坏一票工程师; 一个叫 Doug Cutting 的照着 GFS 和 MapReduce 硬造出开源版 Hadoop (2006, 在 Yahoo), 一开源就成了整个大数据时代的公共地基;

正当大家忙着复刻 Google, Amazon 又甩出一篇把数据库哲学掰弯的论文 Dynamo (SOSP 2007); 需求极朴素也极要命: 购物车的写入永远不能被拒绝, 哪怕机房断网也得能下单; 为了"永远可用"它放弃强一致, 选了 AP + 最终一致; 这是 CAP 取舍第一次被做成真系统, NoSQL 世界观就此立住; 详见 6.cap、7.eventual_consistency;

Dynamo 还顺手带火一个影响至今的度量理念: 别盯平均延迟, 要盯 p99; Amazon 的 SLA 不写"平均 100ms", 而是写"99.9% 的请求得在 X 毫秒内"; 道理在于平均会骗人, 哪怕 1% 的请求慢死也拉不动平均, 可在 Amazon 尺度 1% 就是几百万个想摔手机的用户; 更要命的是 fan-out: 一个商品页扇出到几十上百个服务, 用户等的是最慢那一个, 所以单个服务的尾巴 (tail) 到用户那儿就成了常态, 这就是 tail latency 问题的起点; 这条线后面还会被推进两步 (2013 年 Google 的《The Tail at Scale》把 fan-out 的账算明白: 100 个后端各 1% 慢, 整体就 63% 慢; 2016 年 Google SRE 书把它制度化成 SLI/SLO/SLA + error budget), 它跟 congestion control (BBR 治的就是尾延迟) 和 LLM 推理 (p99 TTFT 是命根子) 是一根筋, 工程界从"看平均"转向"盯尾巴"是这二十年一个根本的世界观转变;

Dynamo 一开路各家照着痛点开造: Facebook 用 Dynamo 去中心化 + Bigtable 数据模型搞出 Cassandra (2008); Yahoo 照着 Chubby 复刻 ZooKeeper (2008); web 应用嫌 SQL 又慢又死板, 2009 年 Redis 和 MongoDB 接连冒头; 这一代的关键词就是分片和最终一致; 详见 8.sharding;

这里插一句前台: web 2.0 一火 (后面前台副线细讲), 一个网站要同时伺候的用户从几千涨到几百万, 逼出两道专门扛流量的闸; 一道是 nginx (2004, 俄罗斯人 Igor Sysoev 写的), 解决 C10K 问题 (Apache 一个连接开一个进程、上万并发就崩, nginx 改用事件驱动一个进程 epoll 盯上万连接), 它身兼 web server / 反向代理 / 负载均衡, 是网站的标准前门, 跟后面的 Envoy 是表亲、只不过守的是南北向; 另一道就是 redis, 挡在数据库前面当缓存、把海量读流量接走, 让金贵的数据库不被打爆; 一句话, nginx 扛连接数, redis 扛读流量;

插曲: 开源世界的两台发动机, Berkeley 和 Apache

讲到这儿会发现, 这些开源项目老往两个地方聚, 一个是伯克利, 一个是 Apache, 角色恰好相反: Berkeley 是发明系统的产房, Apache 是把系统登记成行业标准的户口本;

Berkeley 的玩法几十年没变, 开一个五六年周期的主题实验室, 一边产出开源系统一边孵化公司: AMPLab (2011-2016) 吐出 Spark 和 Mesos; 接棒的 RISELab 搞出 Ray; 再接棒的 Sky Lab 又冒出 vLLM (现在 LLM 推理满世界在用的引擎); 串起这一长串的灵魂人物是 Ion Stoica (Spark、Ray、Databricks、Anyscale 背后都有他), 三连招就是研究 → 开源 → 创业; Apache 则不发明东西, 只提供一个厂商中立的家, 公司把轮子捐进去后连竞争对手都能放心一起用, 所以 Hadoop、Cassandra、Kafka、ZooKeeper、Spark、Flink、Dubbo、RocketMQ 几乎全在它名下挂户口; 一句话: Berkeley 管生, Apache 管养;

第三幕 (2010-2012): 实时计算, 顺手把强一致捡回来

MapReduce 是批处理, 跑一轮等半天; 移动和社交一爆发, 大家要的变成实时和迭代; LinkedIn 内部系统两两对接缠成一团意大利面, 2010 年它把"所有数据流"统一成一条持久化日志、谁要谁订阅, 这就是 Kafka, "log 是一等公民"从此引爆; 几乎同时 Berkeley 的 Spark (2010) 嫌 MapReduce 每轮落盘太慢, 把中间结果搬进内存、快了一个量级; Twitter 用 Storm (2011) 接它的推文洪流;

正当"要规模就得牺牲一致性"快成铁律时, Google 又"既要又要": Spanner (OSDI 2012) 偏要全球规模 + 强一致 + SQL, 杀手锏是 TrueTime (GPS 加原子钟把时钟不确定性框进一个小区间), 做到全球外部一致; NewSQL 就此诞生, 当众证明一致性和扩展性不是只能二选一; 详见 9.spanner;

第四幕 (2013-2016): 容器革命与编排之战

战场整个换了, 前面拼"数据怎么存怎么算", 现在拼"应用怎么打包、部署、管"; 2013 年快倒闭的小公司 dotCloud 掏出 Docker, Linux 的 cgroups + namespace 早躺在内核里 (详见 5. Docker 网络栈协议 那套), 只是难用, Docker 给它配了镜像格式 + 仓库, 一举干掉"在我机器上能跑、一上线就崩"这个世纪难题, 这是云原生的大爆炸; 紧接着新麻烦来了, 几千个容器谁来编排? Google 把内部 Borg 十五年经验蒸馏成 Kubernetes (2014) 开源, 它的声明式 + reconcile 范式详见 12.etcd; k8s 要个协调大脑而 Paxos 太难写, 于是 Stanford 那篇可读的 Raft (2014) 应运而生喂给了 etcd; 详见 5.paxos; 2015 年 CNCF 成立、k8s 当种子项目, "云原生"大旗立起;

编排之战 (2014-2017): Docker 让容器好用了, 紧接着三家为"谁来编排"这把交椅打了场混战; Docker Swarm (Docker 公司) 卖点是简单、跟 Docker 无缝, 但止于简单、撑不住复杂场景; Mesos + Marathon (出身 Berkeley) 是个"数据中心操作系统"、两层调度啥都能跑, Twitter/Airbnb 拿它扛过超大规模, 但太底层太通用、容器编排是后来拼上去的; Kubernetes (Google) 从 Borg 蒸馏、声明式还特别能扩 (CRD/operator); k8s 笑到最后不是某个功能更强, 而是几股劲合一: 2015 年进 CNCF 拿中立户口, Red Hat、IBM 立刻围过来推、网络效应滚起来, 它那套声明式 + 可扩展平台正好卡在 Swarm (太薄) 和 Mesos (太底层) 中间的甜点上; 到 2017 年风向定了, Docker 公司自己宣布支持 k8s (等于认输), Mesosphere 也跟进、后改名 D2iQ, 连本有自家 ECS 的 AWS 都端出托管 k8s (EKS); 一句话, k8s 赢在它不只是个调度器, 而是个能声明期望、还能随便往上扩的控制平面平台;

顺带辨析: 一道叫 *aaS 的阶梯

AWS 在 2006 年开了 IaaS, Amazon 又在 2014 年用 Lambda 开了 FaaS, 正好把这道 *aaS 阶梯凑齐; 它们是同一根梯子, 每往上爬一级, 交给云厂商管的越多、自己留的控制越少:

层级 租的 自己还得管 代表
自建机房 啥都自己来 机器/网络/电/OS/runtime/app —
IaaS 机器 OS 往上 AWS EC2、阿里云 ECS
PaaS 平台 只管 app 代码 Heroku、App Engine
FaaS 一个函数 只管函数本身, 按调用付费、能缩到 0 AWS Lambda、函数计算
SaaS 做好的软件 啥都不用管, 打开就用 Salesforce、Gmail、Notion

记法就是做披萨: 自己买面粉烤 (自建) → 买冷冻披萨回家烤 (IaaS) → 叫外卖 (PaaS) → 下馆子 (SaaS) → 自动售披萨机按个出 (FaaS); FaaS 是 Serverless 的内核 (Serverless ≈ FaaS + 托管后端), 是云原生"别管服务器"那条哲学的最远端, 经典痛点是冷启动 (从 0 扩起来那一下的延迟);

第五幕 (2016-2020): 服务网格与云原生成熟

业务拆成几百个微服务后, 新痛点是: 服务之间怎么通信、加密、观测? 每个服务自己写一套重试/TLS/埋点已经够烦、还多语言各写一遍; Lyft 受够了, 2016 年掏出 Envoy, 把这些横切脏活全抽进一个进程外代理 (sidecar), 它最初的动机其实是可观测性 (混编服务出事根本不知道在哪); Envoy 是数据面, 2017 年 Google 和 IBM 端出 Istio 当控制面, 用声明式 CRD 统一下发流量/安全/观测配置, 本质就是跑在 k8s 上的一组控制器; 与此同时 Prometheus 和 Jaeger 把指标和分布式追踪做成刚需, eBPF/Cilium 在内核里做网络、给 sidecarless 埋下伏笔; 到 2020 年, k8s 成了事实上的"云操作系统", 容器 → 编排 → 协调 → 微服务 → 网格 → 可观测这套栈基本定型, 云原生从前沿变成主流;

副线一: 可靠性二十年, 从 GameDay 到双十一

把上面那条"故障是常态"的暗线单独拎出来按时间走一遍, 它从一开始就埋在 GFS 里、一路长成今天最硬的研究方向;

主动搞崩 (Chaos Engineering): 源头比很多人以为的早, Amazon 的 Jesse Robbins 在 2006 年前后就搞 GameDay (安排一场灾难演习、故意在生产里制造故障逼团队练应急); 但把它做成文化的是 Netflix, 2008 年那场数据库事故 + 整体上 AWS 之后, 它要确认系统真扛得住实例随机暴毙, 2011 年造了 Chaos Monkey (工作时间随机弄死生产服务器, 逼工程师把每个服务写得能容错); 它的哲学很轴: 反正早晚要挂, 不如让它在大白天工程师盯着时挂、而不是凌晨三点; 接着升级成 Simian Army (猴子军团): Chaos Gorilla 干掉一整个可用区、Chaos Kong 端掉一整个区域, blast radius 一级级加; 到 2015 年这事被提炼成一门学科 Chaos Engineering (《Principles of Chaos Engineering》: 定义稳态假设、注入真实故障、生产里跑实验但控住爆炸半径), 再往后是工具化 (Gremlin 2016 把"故障即服务"做成产品, 以及 k8s 原生的 Chaos Mesh、AWS Fault Injection Simulator);

扛住洪峰 (过载控制): 同一时期太平洋另一头, Alibaba 在打更极端的仗——双十一; 11 月 11 日零点流量几秒内冲到几十倍、订单峰值每秒几十万笔, 这是地球上最凶残的 overload 场景; 它顺手开源了一整条中间件 (RPC 框架 Dubbo、消息队列 RocketMQ、服务发现 Nacos、分布式事务 Seata、流控库 Sentinel), 扛洪峰那套招式几乎每一招都是 congestion control 搬到业务层: 削峰填谷 (订单先灌进 RocketMQ 队列、后端按可持续速率慢慢消费, 就是拿 buffer 吸收突发)、限流 (Sentinel 在边缘摁掉超额流量、本质是 token bucket 准入)、降级 (极端负载下关掉非核心功能、死保支付核心链路)、熔断 (依赖一挂立刻切断防雪崩)、异地多活/单元化 (把用户切成自包含单元分散到多机房)、全链路压测 (双十一前拿生产级流量回放、提前揪瓶颈);

这两件事其实是一枚硬币的两面: chaos engineering 是在故障找上门前主动把它逼出来, 双十一是在已知的极限洪峰下死活不让系统崩; 它们共同通向今天的可靠性研究 (metastable failure、过载控制): 一次瞬时触发器 + 一个自我维持的正反馈环 (重试风暴、GC、选举抖动) 会把系统困在崩溃坏稳态, 而削峰填谷、限流降级、混沌实验, 全是给这个正反馈环装刹车; 这也是这二十年留下的、最硬也最值得啃的题;

副线二: 把镜头拉到前台, Web 1.0 → 2.0 → 3.0

前面整篇讲后台基建, 但面向用户那张网二十年里也走过自己的范式跃迁, 且和后台互为因果 (web 2.0 那波 UGC 洪流, 就是前面云、NoSQL、nginx、redis 被逼出来的总根源); 一个口诀压轴: Web 1.0 只能读, Web 2.0 能读能写, Web 3.0 读写还能拥有;

Web 1.0 (约 1991-2004): 只读的网; 网页静态, 内容由少数网站方单向发布, 用户只能看不能贡献, 像座只能借阅的图书馆; 代表是手写 HTML、门户和网址目录 (Yahoo、早期新浪搜狐)、浏览器大战 (Netscape vs IE);

Web 2.0 (约 2004-2010s): 能读能写的网; 用户从看客变成创作者, 内容由大家生产 (UGC), 平台只搭框架; Tim O’Reilly 在 2004 年提出这个词、口号是"网络即平台"; 引爆它的关键技术是 AJAX (网页能异步局部刷新, Gmail/Google Maps 让网页第一次像桌面软件), 之后是富前端 JS、SPA 框架、开放 REST API、以及 2007 年 iPhone 带起的移动互联网; 代表是博客、维基、Facebook/微博、YouTube; 但它埋了个隐患: 用户创造的内容和数据全攥在平台手里, 这正是 Web 3.0 要反的;

Web 3.0 (2020s-): 定义还没统一; 同一个词被三拨人用在完全不同的意思上:

说法 核心 代表技术
语义网 Semantic Web 让机器也读懂网页含义 RDF、SPARQL、知识图谱、schema.org
去中心化 Web3 (最流行) 去中心化 + 用户拥有数据/资产 区块链、智能合约、加密货币、NFT、DAO、DeFi
AI 网 (近年新加) AI/agent 驱动的智能网络 LLM、智能 agent、个性化

最主流是中间那个区块链 Web3, 口号补全口诀 read-write-own (用户能真正"拥有"身份/资产/数据、不再被平台垄断), 但争议极大、至今远没成为主流; 而 Berners-Lee 最初设想的语义网愿景大半没实现, 却留下了知识图谱和结构化数据这些遗产; 要记住的就一句: Web 1.0 和 2.0 是公认的历史阶段, Web 3.0 还是个没尘埃落定的概念;

收尾: 撑爆 → 抽象 → 再撑爆

把这二十年抽象一下, 其实就是一个"撑爆 → 抽象 → 再撑爆"的循环:

被撑爆的东西 逼出的抽象 代表作
物理机租不出整台 虚拟化 + 数据中心 VMware、Xen、AWS
单机存不下 分布式文件/存储 GFS、Dynamo、Bigtable
单机算不动 分布式计算框架 MapReduce、Spark
前端连接/读流量爆 事件驱动前门 + 缓存 nginx、redis
平均延迟在骗人 p99/尾延迟 + SLO 纪律 Dynamo、The Tail at Scale、SRE
关系库扛不住量 NoSQL / 分片 / NewSQL Cassandra、Spanner
协调/选主乱套 协调服务 Chubby、ZooKeeper、etcd
部署环境不一致 容器 Docker
容器太多管不过来 编排 Kubernetes
微服务通信乱 服务网格 Envoy、Istio
流量洪峰要命 过载控制 Sentinel、削峰填谷
不知道扛不扛得住 主动注入故障验证 Chaos Monkey、Gremlin
系统大了看不见 可观测性 Prometheus、Jaeger

而比这更深的一条暗线是: 越往后, 工程界越把"故障是常态"焊进骨子里; 从 GFS 假设磁盘必坏, 到 Dynamo 宁可最终一致也要永远可用, 到 Netflix 用 Chaos Monkey 自己动手搞破坏, 到 k8s 默认 Pod 随时会死然后自愈, 再到 Alibaba 把双十一当成一年一度的极限演习; 这条"design for failure"的线, 一路通到今天的可靠性研究 (metastable failure、过载控制), 也就是这堆系统在压力下到底怎么才能不雪崩; 那才是这二十年留下的、最硬也最值得啃的题;