Amoeba — 把整个机房当一台操作系统
是什么
Amoeba 是 Andrew Tanenbaum 在阿姆斯特丹自由大学带队做的分布式操作系统。它不是给单机 OS 加网络功能，而是从设计第一行就假设：用户面前不是一台机器，是一池机器。
日常类比：你去餐厅吃饭。普通 OS 像每人自带便当——一台电脑只服务一个人，吃完闲着也是闲着。Amoeba 像自助餐——后厨几十个灶台一起开，谁要做菜就分一个灶，做完归还。终端只是看菜单的桌子。
它的三大件：
- 微内核：内核只做最少的事（RPC + 进程 + 内存）。文件、目录、登录全是用户态服务器。
- 处理器池：机房里堆几十上百台 CPU，按需分配给任务。
- 能力（capability）：每个对象（文件、进程、目录）有一张 128 位的”通行证”，跨机器都有效，靠加密防伪造。
为什么重要
你今天用的很多东西，根源都在 Amoeba：
- Kubernetes 把容器调度到一池机器——处理器池的精神孙子
- Fuchsia / seL4 微内核 + 能力寻址——直接继承 Amoeba 的两大支柱
- WebAssembly + WASI 的能力安全模型——能力机制的现代版
- Python——Guido van Rossum（作者之一）最早写 Python 就是为了给 Amoeba 写运维脚本
- Capsicum (FreeBSD) 进程沙箱——能力安全的 Unix 化
不读它，理解不了”分布式 OS 该长什么样”——因为 Linux + 网络 ≠ 分布式 OS。Linux 是把一台机器的内核和外面的网络分开看的；Amoeba 把所有机器看成一个内核。
核心要点
1. 处理器池：CPU 当成自来水
传统模型：每人一台工作站，CPU 80% 时间闲着。Amoeba 把所有 CPU 放进池子——几十上百块板子堆在机房。用户面前是 X 终端（只显示，不计算），要跑编译器、要跑程序，调度器从池里挑空闲 CPU 分给你，跑完归还。
类比：共享单车。你不拥有车，要骑就借一辆，骑完锁回。
2. 能力：128 位的”加密通行证”
每个对象（文件、进程、目录）由它的服务器发一张能力。结构：
| 字段 | 位数 | 作用 |
|---|---|---|
| 服务器端口 | 48 | 谁管这个对象 |
| 对象编号 | 24 | 在那台服务器里第几个对象 |
| 权限位 | 8 | 读/写/删等许可 |
| 加密 check | 48 | 防伪造的指纹 |
关键巧思：客户端拿到能力后想降级权限（比如把”读+写”变成”只读”再发给别人）只能 XOR 权限位再 hash 算新 check。升级做不到——因为 hash 不可逆。
类比：电影票上印一串防伪码。你撕角想”改成 VIP 座位”撕不出来——因为防伪码是按”普通座位”算的，新座位算出来对不上。
3. 微内核：内核只做四件事
内核里只有：RPC 通信 + 进程管理 + 简单内存管理 + 低层 I/O。
不在内核：文件系统、目录服务、登录认证、打印队列、邮件——全是用户态服务器，跟你写的应用一样用 RPC 通信。
类比：政府只管发身份证 + 警察。教育、医疗、邮政都是市场化的服务，公民拿身份证去消费。
4. Bullet 文件服务：文件不可变
文件一旦写完就不可改，只能整体替换。砍掉了缓存一致性问题——既然文件不变，缓存永远对。
类比：刻录光盘。烧完就改不了，但读起来谁都不会读到旧数据。
实践案例
案例 1：登录到 Amoeba 是什么感觉
你坐到 X 终端前，敲账号密码。终端自己什么都不算——它把”我要登录”发给登录服务器（用户态进程，跑在池里某台 CPU 上）。登录通过后，给你发一张”主目录能力”。
你敲 ls，终端把 ls 命令发给目录服务器（另一台 CPU），附上你的目录能力。服务器验证 check 字段，列出文件，每个文件返回一张子能力。
整个过程你不知道也不在乎这些进程跑在哪台机器上。
案例 2：编译大项目
你敲 make。Amoeba 的 make 把 100 个 .c 文件自动分发到池里 20 台空闲 CPU 并行编译。每个 cc 进程的输入输出是能力，谁都能验证身份。
类比：现代 CI 集群（GitHub Actions / Bazel remote execution）做的事，Amoeba 1990 年就做了——只是它的”集群”就是 OS 本身。
案例 3：能力的撤销难题
你给同事发了一张文件的”读”能力。后来不想给他了——怎么撤销？
没办法撤销那一张。唯一办法是服务器改 check 字段——但这样所有旧能力（包括你自己留的）一起作废，必须重发。
这就是能力机制的著名痛点。EROS / KeyKOS 后来用”中间能力（gate）“解决，但 Amoeba 没解。
踩过的坑
-
处理器池没赢——PC 太便宜了：1990 年时一台 PC 还要几千美元，处理器池经济。但 90 年代末 PC 跌到几百美元，每人一台反而更划算。云时代（2010+）又翻回来了，但形式是 K8s 不是 Amoeba。
-
RPC 跨机性能损耗大：分布式透明性听着好，但每次”打开文件”都要 RPC 一次，比单机 syscall 慢数量级。Amoeba 用 FLIP 协议优化（绕过 TCP），但还是干不过本地文件系统。
-
微内核之战的失败方：Linus 1992 年和 Tanenbaum 那场著名邮件论战——Tanenbaum 说”Linux 是过时的宏内核”，Linus 说”实用主义赢”。最终 Linux 赢了 90 年代。微内核要到 21 世纪才靠 seL4 / Fuchsia 翻身。
-
能力撤销几乎做不到：见上面案例 3。这是能力机制的根本性问题，任何用能力的系统都要面对。
适用 vs 不适用场景
适用：
- 多台机器需要”看起来像一台”——研究型集群、超算
- 安全要求强、能接受”用完就重新生成所有 cap”——军事/金融封闭网
- 教学：理解”分布式 OS 原教旨”必读
不适用：
- 商业通用 OS——Linux 早赢了
- 需要灵活权限撤销的场景——能力机制天然弱项
- 单机使用——微内核 RPC 开销不值
历史小故事（可跳过）
- 1981：Tanenbaum 在 VU Amsterdam 启动 Amoeba。
- 1986：能力机制论文发表（ICDCS）。
- 1990：CACM 这篇 status report——这是 Amoeba 最完整的对外公开。
- 1991：Tanenbaum vs Linus 的微内核邮件大战。Tanenbaum 说 Linux “fundamentally flawed”，结果 Linus 赢了。
- 1990s：Guido van Rossum 是作者之一；他在 CWI 给 Amoeba 写脚本时设计了 Python。
- 2000s：项目逐渐停更，Tanenbaum 转去做 MINIX 3。
- 2010s 至今：Amoeba 的思想在 Fuchsia / seL4 / WASI 复活。
学到什么
- 分布式不是加层，是重设计——Linux + 网络 ≠ Amoeba。从第一行就假设多机才能拿到真正的简洁。
- 能力 vs ACL：能力是”持有即权限”，ACL 是”查表才有权限”。各有适用场景。今天 WebAssembly / Capsicum 选了能力。
- 微内核 vs 宏内核 30 年拉锯：性能 vs 模块化的取舍。今天云原生 + 形式化验证给微内核第二春。
- 想法对，时机不对，会输——Amoeba 1990 年想做的事，2015 年 K8s 用容器方式做成了。
延伸阅读
- 论文 PDF：Amoeba 1990
- Tanenbaum vs Torvalds 邮件论战：Linux is obsolete（1992）
- 后续工作：Fuchsia / Zircon 文档（Google 微内核）
- mach-1986 —— 同期另一个微内核流派
- sel4-2009 —— 形式化验证的微内核继承者
关联
- afs-1988 —— AFS 同期分布式文件系统，但建在已有 OS 上，不像 Amoeba 自己就是 OS
- mach-1986 —— Mach 微内核，CMU 的另一答案，最终演化成 macOS XNU
- unix-v6 —— Unix 是 Amoeba 反叛的对象，宏内核的代表
- plan9 —— 同期贝尔实验室的另一种”重设计 Unix”答卷，“一切皆文件”做到极致