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

一张总图先压个轴, 后面分幕细讲:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
2000 ─ 互联网泡沫破, 活下来的 Google/Amazon 被海量数据逼疯
2003 ─ GFS          (Google: 在会坏的廉价磁盘上存 PB 级文件)
2004 ─ MapReduce    (Google: 让普通工程师也能并行处理 PB 数据)
2006 ─ Bigtable     (Google: web 尺度的结构化存储)
2006 ─ Chubby       (Google: 给上面这些做选主/协调)
2006 ─ AWS          (Amazon: 把自家弹性基建租出去, 云诞生)
2006 ─ Hadoop       (Yahoo: 把 GFS+MapReduce 开源给全世界)
2007 ─ Dynamo       (Amazon: 购物车永远不能拒绝写入 → AP/最终一致)
2008 ─ Cassandra / ZooKeeper (Facebook / Yahoo: NoSQL + 开源 Chubby)
2010 ─ Kafka        (LinkedIn: 把所有数据流统一成一条日志)
2010 ─ Spark        (Berkeley: MapReduce 迭代太慢, 搬进内存)
2012 ─ Spanner      (Google: 全球规模还要强一致 + SQL, NewSQL 诞生)
2013 ─ Docker       (dotCloud: 解决"在我机器上能跑")
2014 ─ Kubernetes   (Google: 把 Borg 十五年经验开源, 编排容器)
2014 ─ Raft / Lambda(Stanford / Amazon: 可懂的共识 / Serverless)
2015 ─ CNCF + etcd   (容器时代的协调大脑, 云原生定旗号)
2016 ─ Envoy        (Lyft: 多语言微服务要统一的网络/观测层)
2017 ─ Istio        (Google/IBM: 管一大群 Envoy, k8s 赢得编排之战)
2018+ ─ Prometheus / Jaeger / eBPF (可观测性 + sidecarless 苗头)

第一幕 (2000-2006): Google 被海量数据逼疯

2000 年泡沫一破, 一地鸡毛里活下来的是 Google、Amazon、Yahoo; 而 Google 的处境最惨也最典型: 它发了疯想把整个互联网抓下来建索引, 可兜里没钱买大型机, 买的全是一堆随时会冒烟的廉价 PC; 这就逼出了一个谁都绕不开的问题: 怎么在一群动不动就挂的破机器上, 可靠地存和算 PB 级的数据;

被逼到墙角的 Google 三年里连发三记重拳, 也就是后来人人会背的"三驾马车"; 先是 2003 年的 GFS, 思路简单粗暴: 既然磁盘一定会坏, 那就把大文件切块、每块存三份、一个 master 管元数据, 坏了就从别的副本补; 它顺手立下了后来云原生的祖训, 故障是常态、不是意外; 紧接着 2004 年的 MapReduce 解决另一半烦恼: 公司里大多数工程师根本不会写分布式, 那就把容错、调度、数据搬运全塞进框架藏起来, 工程师只管写 map 和 reduce 两个函数; "把分布式复杂性藏进框架"这个套路, 从此成了行业默认动作; 到 2006 年又有了 Bigtable, 给 Search、Maps、Gmail 撑起 web 尺度的结构化大表;

可这三个家伙凑一块儿就冒出个新麻烦: 它们都得有人拍板"现在谁是 master"、都要存点关键元数据; 于是同样在 2006 年, Google 又掏出 Chubby, 一个粗粒度锁服务, 专门当这群大块头的裁判; 详见 11.chubby; 它就是后来 ZooKeeper 和 12.etcd 这一整支的老祖宗;

故事的另一条线上, Amazon 在闷声干一件改变世界的事; 它的零售基建本来就得扛黑五那种瞬间洪峰, 平时一大半算力闲着; 2006 年它一拍脑袋: 闲着也是闲着, 干脆把这份弹性算力按量租出去; AWS 就这么诞生了 (S3 三月、EC2 八月), 基础设施第一次变成"按需开、用多少付多少", 云时代的发令枪就此打响;

地基: 这片算力到底跑在什么上面

AWS 把弹性算力租出去, 可你有没有想过, 它租的"一台机器"到底是个啥? 这就得扒开云底下的两层地基: 数据中心和虚拟化;

第一层是数据中心; Google、Amazon、Facebook 这些家伙发现, 与其买昂贵的大型机, 不如拿海量廉价机器堆出一台"仓库级计算机" (warehouse-scale computer, Google 的 Barroso 和 Hölzle 专门写过本小册子就叫这名); 一栋楼里塞几万台服务器, 自己设计供电、散热、网络拓扑, 把单位算力的成本压到地板; 这种 hyperscale 数据中心就是云的物理身体;

但光有一堆物理机还租不出去, 因为你总不能把一整台机器卖给一个只要一点点算力的小客户; 这就要第二层地基: 虚拟化; VMware (1998)、Xen (2003)、KVM (2007) 这些 hypervisor 能把一台物理机切成好多台互相隔离的虚拟机 (VM), 每台 VM 都以为自己独占一台机器; 这就是 multi-tenancy (多租户): 一台物理机上跑好几家互不打扰的客户; AWS 卖的 IaaS, 本质就是卖这些 VM 切片; 底层细节详见 12.xen、18.vmware_esx_mem;

VM 虽好但有点重: 每台都得背一整套 guest 操作系统, 开机慢、吃内存; 于是后来有了更轻的容器 (也就是第四幕的 Docker): 它不虚拟整台机器, 只拿 Linux 的 namespace + cgroup 把进程隔离开、共享同一个内核, 启动快、密度高; 这条 VM → 容器的轻量化路线详见 15.vm_lighter_than_container; 一句话: 虚拟化让一台机器变多台 (撑起多租户的云), 容器又让这些切片更轻更密 (撑起后来的微服务洪流);

有了这套又便宜又弹性的地基, 互联网公司开始算一笔账: 是自己买服务器、堆机房、养运维 (CapEx, 重资产压一身), 还是干脆租云、按量付费 (OpEx, 轻装上阵)? 越来越多人选了后者, 一场"上云大迁徙"就此开始; 最有名的样板是 Netflix: 2008 年它自建的数据库炸了一次、DVD 邮寄停了三天, 痛定思痛决定整体搬上 AWS, 顺手把单体拆成微服务、还用 Chaos Monkey 主动搞破坏来练容灾, 前后花了七年 (2008-2016) 才全搬完; 而新一代创业公司 (Airbnb、Uber、Instagram) 干脆生在云上, 从第一天起就没有自己的机房; 至此"买机器"变成了"调个 API 开机器", 创业的基础设施门槛被一脚踩到地板;

第二幕 (2006-2010): 全世界照着论文造, Amazon 又把数据库哲学掰弯

Google 论文写得漂亮, 代码却一行不开源, 急坏了一票眼馋的工程师; 其中一个叫 Doug Cutting 的, 干脆照着 GFS 和 MapReduce 那两篇硬生生造出了开源版, 取名 Hadoop (2006, 在 Yahoo); 它本是 Yahoo 自家搜索的需要, 没想到一开源就成了整个大数据时代的公共地基, 后面十年的项目几乎都长在它身上;

正当大家忙着复刻 Google 时, Amazon 又甩出一篇把数据库哲学彻底掰弯的论文, Dynamo (SOSP 2007); 它的需求极其朴素也极其要命: 购物车的写入永远不能被拒绝, 哪怕两个机房之间断了网, 用户也得能往里扔东西; 为了这个"永远可用", 它咬牙放弃了强一致, 选了"先让你写进去、数据慢慢对齐" (AP + 最终一致); 这是 CAP 那个老掉牙的取舍第一次被做成真系统, NoSQL 的世界观就此立住; 详见 6.cap、7.eventual_consistency;

Dynamo 这篇还顺手带火了一个影响至今的度量理念, 值得单拎出来说: 别盯着平均延迟看, 要盯 p99 (甚至 p99.9); Amazon 的 SLA 不写"平均响应 100ms", 而是写"99.9% 的请求都得在 X 毫秒内", 这在当年挺反直觉; 道理在于平均会骗人: 哪怕只有 1% 的请求慢得要死, 它也拉不动平均值, 可在 Amazon 这个尺度, 1% 就是几百万个被卡到想摔手机的用户; 更要命的是 fan-out: 你打开一个商品页, 后台要扇出到几十上百个服务 (库存、推荐、价格、评价…), 而你要等的是最慢的那一个, 所以单个服务的尾巴 (tail), 到了用户那儿就成了家常便饭; 这就是后来人人挂嘴边的 tail latency (尾延迟) 问题的起点;

这个理念后面又被推进了两大步; 2013 年 Google 的 Dean 和 Barroso 写了篇神文 《The Tail at Scale》, 把 fan-out 那笔账算得明明白白: 假设一个请求要打 100 个后端、每个只有 1% 的概率超过 1 秒, 那么整体就有 63% 的请求会超过 1 秒, 单看每个服务都"99% 很快", 合起来却惨不忍睹; 这篇还给了一堆"容忍尾巴"的招 (对冲请求 hedged request、绑定请求之类); 再到 2016 年, Google 那本 SRE 书把这套东西彻底制度化, 拆成三个词: SLI (你测的那个指标, 比如 p99 延迟)、SLO (你定的目标, 比如"99.9% < 100ms")、SLA (跟客户签的、违约要赔钱的合同), 外加 error budget (允许翻车的预算); 至此"按一个延迟/可用性目标来运营服务"从玄学变成了工程纪律;

为啥要在编年史里给它一个位置? 因为这条 平均 → p99 → 尾延迟 → SLO 的线, 跟好几条线其实是一根筋: congestion control (BBR 本质就是在治尾延迟和 bufferbloat)、metastable failure (fan-out 把小毛病放大成大故障, 跟尾延迟放大同构)、还有 LLM 推理 (p99 的 TTFT/TPOT 就是 serving 的命根子); 工程界从"看平均"转向"盯尾巴", 是这二十年一个安静但根本的世界观转变;

Dynamo 一开路, 各家立刻照着自己的痛点开造: Facebook 用 Dynamo 的去中心化拼上 Bigtable 的数据模型, 搞出 Cassandra (2008) 喂收件箱搜索; Yahoo 照着 Chubby 复刻出 ZooKeeper (2008), 后来 Kafka、HBase、Hadoop 全靠它协调; web 2.0 的应用嫌 SQL 又慢又死板, 于是 2009 年 Redis 和 MongoDB 接连冒头; 这一代的关键词就俩字: 分片和最终一致, 把单机扛不住的量摊到一片机器上; 详见 8.sharding;

撑住洪峰的两道闸: nginx 和 redis

后端数据库的故事讲了一堆, 但别忘了流量是从前端打进来的; web 2.0 一火, 一个网站要同时伺候的用户从几千涨到几百万, 这就逼出两个专门"扛流量"的常驻角色, 一个挡在最前面、一个挡在数据库前面;

最前面那道闸是 nginx (2004, 俄罗斯人 Igor Sysoev 给门户 Rambler 写的); 它解决的是著名的 C10K 问题: 老牌的 Apache 是"一个连接开一个进程/线程", 并发到一万个连接就被内存和上下文切换活活拖垮; nginx 改用事件驱动, 一个进程拿 epoll 盯着上万个连接、谁有事就处理谁, 轻松扛住高并发; 它还一身兼三职: web server、反向代理、负载均衡, 成了几乎所有网站的标准前门; 你会发现它跟第五幕的 Envoy 是表亲, 都是事件驱动的代理, 只不过 nginx 守的是南北向 (用户进出集群), Envoy 管的是东西向 (服务之间);

第二道闸是 redis (2009, 意大利人 Salvatore Sanfilippo 写的); 它是个跑在内存里的 KV 存储, 快到飞起; 最经典的用法就是挡在数据库前面当缓存: 热点数据先读 redis、读不到再回落到数据库, 这样海量读流量大半被 redis 接走, 后面那个金贵的数据库才不至于被打爆; 除了缓存, 它还能当 session 存储、消息队列、排行榜、甚至限流器 (前面双十一那个限流, 底层计数常用 redis); 一句话: nginx 帮你扛住连接数, redis 帮你扛住读流量, 这俩是一个网站从"能跑"进化到"能扛"之间, 最常加的两块板;

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

讲到这儿你大概也发现了, 这些开源项目老往两个地方聚, 一个是加州大学伯克利分校, 一个是 Apache; 这俩经常一起出现, 角色却恰好相反: Berkeley 是发明系统的产房, Apache 是把系统登记成行业标准的户口本;

Berkeley 的玩法几十年没变: 开一个有主题、五六年周期的实验室, 一边产出开源系统, 一边顺手孵化公司; AMPLab (2011-2016) 一口气吐出了 Spark 和 Mesos; 接棒的 RISELab 搞出了 Ray (现在 LLM 训练和 serving 满世界在用); 再接棒的 Sky Lab 又冒出了 vLLM (现在 LLM 推理满世界在用的引擎); 串起这一长串的灵魂人物是 Ion Stoica, Mesos、Spark、Ray、Databricks、Anyscale 背后都有他, 堪称碰啥火啥; 记住 Berkeley 的三连招: 研究 → 开源 → 创业;

Apache 则完全是另一种存在, 它不发明东西, 它提供一个厂商中立的家; 一家公司内部造了个好轮子, 把它捐给 Apache 之后, 连竞争对手都能放心一起用、一起改, 不必担心被某家攥在手里; 所以你看 Hadoop、Cassandra、Kafka、ZooKeeper、Spark、Flink、HBase、Pulsar、Dubbo、RocketMQ 这一长串, 整个大数据/分布式开源栈几乎全在 Apache 名下挂着户口; 一句话: Berkeley 管生, Apache 管养, 很多项目都是先在 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 攒了十五年的经验蒸馏出来, 2014 年开源成 Kubernetes; 它那套"声明期望、系统自己收敛"的 reconcile 范式, 详见 12.etcd; 而 k8s 要个协调大脑, 偏偏 Paxos 太难写 (Chubby 自己都写《Paxos Made Live》哭过), 于是 2014 年 Stanford 那篇可读、可实现的 Raft 应运而生, 喂给了 etcd; 详见 5.paxos; 2015 年 CNCF 成立、把 k8s 当种子项目一供, "云原生"这面大旗正式立起来;

这几年还打了一场著名的编排之战, 值得单开一节细说;

番外: 编排之战, k8s 到底是怎么赢的

Docker 让容器好用了, 紧接着的问题是: 几千个容器摊在一整片机器上, 谁来编排、调度、重启、扩缩? 2014 到 2017 年, 三家为这把交椅打了一场混战;

  • Docker Swarm (Docker 公司自己的): 卖点是简单、跟 Docker 无缝集成, 几条命令就起一个集群; 但也就止于简单, 复杂场景和扩展性撑不住; Docker 公司想靠它通吃整条栈;
  • Mesos + Marathon (出身 Berkeley, Mesosphere 公司商业化): Mesos 其实更老 (Berkeley AMPLab, 2011), 是个"数据中心操作系统", 两层调度、啥都能跑 (Hadoop、Spark、容器都行), Twitter、Airbnb 拿它扛过超大规模; 但它太底层太通用, 容器编排是后来拿 Marathon 拼上去的, 偏重;
  • Kubernetes (Google, 2014): 从 Borg 蒸馏出来, 声明式 + pod/label/controller 模型, 还特别能扩 (CRD、operator);

k8s 笑到最后, 靠的不是某个功能更强, 而是几股劲合在一起: 2015 年它进了 CNCF 拿到中立户口, Red Hat、IBM 这些大厂立刻围过来一起推, 网络效应滚起来; 它那套声明式 + 可扩展平台正好卡在 Swarm (太薄) 和 Mesos (太底层) 中间的甜点上, 能在它上面长出整个生态 (Helm、operator、各种 controller); 到 2017 年风向彻底定了: Docker 公司自己宣布在产品里支持 k8s (等于认输), Mesosphere 也加了 k8s 支持、后来干脆改名 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); 注意它最初的动机其实是可观测性, 一堆 PHP/Python/Go 混编的服务, 最痛的是出事根本不知道发生在哪; Envoy 是数据面, 那谁来管一大群 Envoy? 2017 年 Google 和 IBM 端出 Istio, 用声明式 CRD 统一下发流量/安全/观测配置, 它本质就是跑在 k8s 上的一组控制器; 与此同时 Prometheus 和 Jaeger 把指标和分布式追踪做成了刚需 (微服务多到不靠它们根本没法 debug), eBPF/Cilium 则在内核里做网络, 悄悄给"甩掉每个 Pod 一个代理"的 sidecarless 埋了伏笔;

到 2020 年, k8s 已经成了事实上的"云操作系统", 容器 → 编排 → 协调 → 微服务 → 网格 → 可观测这一整套栈基本定型, 云原生从前沿变成了人人挂在嘴边的主流;

番外: 双十一, 地球上最大的过载战场

西方这条线热闹的时候, 太平洋另一头的 Alibaba 在打一场更极端的仗, 双十一; 11 月 11 日零点, 流量在几秒内从基线冲到几十倍, 订单峰值每秒几十万笔; 这是地球上最凶残的 overload 场景, Alibaba 整套微服务和可靠性栈基本就是在这把火里烧出来的, 也顺手开源了一整条中间件: RPC 框架 Dubbo、消息队列 RocketMQ (Kafka 扛不住他们的事务和顺序需求才另起的)、服务发现 Nacos、分布式事务 Seata, 还有那个直接命中你赛道的 Sentinel, 一个生产级的流控/熔断/降级库;

真正精彩的是他们扛洪峰的那套招式, 你会发现每一招都是 congestion control 思想搬到了业务层:

  • 削峰填谷: 订单先灌进 RocketMQ 队列、后端按可持续速率慢慢消费, 这不就是拿 buffer 吸收突发吗;
  • 限流: Sentinel 在每层把超额流量在边缘就摁掉、防止级联, 本质就是 token bucket 准入控制;
  • 降级: 极端负载下关掉推荐、评论这些非核心功能, 死保浏览 → 购物车 → 支付的核心链路;
  • 熔断: 某个依赖一挂立刻切断、阻止雪崩;
  • 异地多活 / 单元化: 把用户切成一个个自包含单元、分散到不同机房, 既容灾又水平扩容;
  • 全链路压测: 双十一前拿生产级流量对真实系统回放, 提前把瓶颈揪出来 (这套实践就是 Alibaba 带火的);

把这串连起来看就一句话: 双十一是一次蓄意制造的"流量尖峰触发器", 而 Alibaba 全栈的唯一目的, 就是不让系统掉进 metastable 崩溃; 削峰填谷防的是重试风暴, 限流降级断的是正反馈环, 压测找的是放大点; metastable failure 和过载控制这套东西, 在这里是按全球最大规模在打实战, 可靠性/overload 这条线最肥的素材库就在这;

番外: Chaos Engineering, 主动把系统搞崩的艺术

那条"design for failure"的暗线, 光"设计"还不够, 怎么确认它真扛得住? Chaos Engineering 就是这条线的验证臂: 故意往生产系统里注入故障, 拿实验证明它真能扛, 而不是嘴上说能扛;

源头比很多人以为的要早; Amazon 的 Jesse Robbins 在 2006 年前后就搞 GameDay: 安排一场"灾难演习", 故意在生产里制造故障、逼团队练应急; 但真正把它做成文化的是 Netflix; 2008 年那场数据库事故加上整体上 AWS 之后, Netflix 要确认自己的分布式系统真能扛住实例随机暴毙, 于是 2011 年造了 Chaos Monkey: 在工作时间随机弄死生产环境里的服务器, 逼工程师把每个服务都写得能容错; 它的哲学很轴: 反正早晚要挂, 不如让它在大白天、在工程师盯着的时候挂, 而不是凌晨三点;

接着 Netflix 把这套升级成一整个 Simian Army (猴子军团): Latency Monkey 注延迟和错误、Chaos Gorilla 直接干掉一整个可用区 (AZ)、Chaos Kong 更狠, 端掉一整个区域 (Region), blast radius 一级级往上加; 到 2015 年前后这事被正式提炼成一门学科 Chaos Engineering, 还出了《Principles of Chaos Engineering》: 先给系统定义一个"稳态" (steady state) 假设, 再注入真实世界会发生的故障, 在生产里跑实验、但把爆炸半径控到最小; 再往后是工具化和商业化: Gremlin (2016, 把"故障即服务"做成产品), 以及 k8s 原生的 LitmusChaos、Chaos Mesh (PingCAP), 连 AWS 都出了官方的 Fault Injection Simulator;

它跟可靠性这条线是绑死的: chaos engineering 就是在 metastable failure 找上门之前, 主动把它逼出来的手段; 想知道系统会不会在某个触发器下掉进崩溃坏稳态, 最实在的办法, 就是亲手按一下那个触发器看看;

另一条轴: 把镜头拉到前台, 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, user-generated content), 平台只搭框架; Tim O’Reilly 在 2004 年提出这个词, 口号是"网络即平台"; 引爆它的关键技术是 AJAX (网页能异步局部刷新、不用整页重载, Gmail 和 Google Maps 让网页第一次像桌面软件一样顺滑), 之后是富前端 JS 和 SPA 框架、开放 REST API、以及 2007 年 iPhone 带起的移动互联网; 代表产品是博客、维基 (Wikipedia)、Facebook/微博、YouTube; 但它埋了个隐患: 用户创造的内容和数据全攥在平台手里 (Google/Facebook/腾讯/阿里), 这正是 Web 3.0 要反的东西;

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

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

最主流的是中间那个区块链 Web3, 它的口号正好补全口诀 read-write-own: 用户不只能读写、还能真正"拥有" (身份、资产、数据上链, 不再被平台垄断); 但它争议极大, 一派认为是网的未来、一派认为是泡沫和炒作, 至今远没成为主流; 而 Berners-Lee 最初设想的语义网那派, 愿景大半没实现, 却留下了知识图谱 (Google Knowledge Graph) 和结构化数据这些实打实的遗产;

要记住的就一句: Web 1.0 和 2.0 是已经发生、公认的历史阶段; Web 3.0 还是个众说纷纭、没尘埃落定的概念, 别默认别人嘴里的"Web 3"跟自己想的是同一件事;

收尾: 一条贯穿二十年的暗线

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

被撑爆的东西 逼出的抽象 代表作
单机存不下 分布式文件/存储 GFS、Dynamo、Bigtable
单机算不动 分布式计算框架 MapReduce、Spark
物理机租不出整台 虚拟化 + 数据中心 VMware、Xen、AWS
前端连接/读流量爆 事件驱动前门 + 缓存 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、过载控制), 也就是这堆系统在压力下到底怎么才能不雪崩; 那才是这二十年留下的、最硬也最值得啃的题;