消失的操作系统

前言

2011年我加入谷歌时，曾引用朋友的一句玩笑：“世界上大约有一台半计算机，谷歌拥有其中一台。“自2011年以来世界已发生巨变，现在全球可能有五六台这样的"计算机”。在下文中，当我说"计算机"时，指的是由大量独立机器连接组成的、能像单台计算机一样运作的超大规模集群。

正文

现代微服务部署的技术生态令人困惑——变化迅速，大量表面相似的项目声称能实现类似功能。即使对我这样深耕技术领域的人而言，不同项目的精确用途也不总是清晰的。

我多次提及"数据中心操作系统"的概念（至少这里和这里），自2015年从谷歌休假以来一直在思考这个问题。最近与一群性能工程师（他们处于开发与运维的交汇点）的交流促使我写下这些思考。这是第一篇相关文章，后续可能还有更多（特别是关于其安全模型的内容）。

警告：本文纯属个人观点，包含大量未经科学验证的主张。我经常犯错。

我的核心观点是：

计算机发展初期，经过数十年才出现真正的"操作系统”。在真正OS出现前，存在许多"原型OS"——需要单独管理拼凑的工具集合。当时全球计算机数量稀少，使用计算机需在大型研究机构工作。这些机器运行着为该计算机专门拼凑的独特OS。
大约从2007年开始，我们正经历第二个类似时期：“单台计算机"模式被"仓库级计算机"取代。最初只有少数财力雄厚的组织能拥有这样的计算机，但云计算使得没有数十亿美元建设完整数据中心的公司也能使用"大量小型独立计算机”。
超大规模企业（谷歌、Facebook，也包括腾讯等）内部正在构建"原型数据中心OS"；亚马逊正在将其部分系统外部化；大量构成数据中心OS的独立组件已作为开源项目存在。

但目前尚不存在一个普通公司可以直接安装的完整数据中心OS。存在一个"消失的OS"——安装在大量计算机集合上的软件，将这些计算机集合转变为"一台计算机"。

数据中心OS的组成

观察现代技术栈会发现一个惊人的趋同现象——不在于人们实际运行的软件，而在于需要实现的"角色"。每个角色通常都有多种不同的实现方案。每个大规模分布式基础设施都包含以下组件：

集群级文件系统：谷歌内部使用GFS/Colossus，外部可能是GlusterFS等。许多公司最终使用S3，因为现有方案不够理想。
水平可扩展键值存储：谷歌内部用BigTable，外部可能是Cassandra、Scylla，甚至ElasticSearch（勉强算）。
分布式一致性键值存储：谷歌内部用Chubby，外部用etcd。大多数应用不直接使用，主要用于集群管理。
发布/订阅消息队列系统：如PubSub、Kafka、AWS的SQS或RabbitMQ。
任务调度/容器编排系统：根据可用资源、待运行任务和约束条件，解决受限的装箱优化问题以确保资源合理利用。如Borg，某种程度上也包括Kubernetes。可能与MapReduce风格的批量工作负载基础设施集成以利用闲置CPU周期。

缺失的工具与挑战

思考"单机OS上有哪些组件应该在数据中心OS中存在"非常有价值：

人们通过Prometheus和各种数据收集代理构建了近似"进程管理器"的工具
分布式追踪（公认的必需品）实质上是数据中心版的strace
“数据中心版的syslog是什么"同样是个有趣问题
大量可观测性工程实质是将单机自省能力移植到"计算机"上
人们谈论的"服务网格"是否只是数据中心版的portmapper？

还有一些功能我们完全不知道如何构建对应方案。比如"计算机"的"调试器"应该是什么样子？显然，在单主机上单步执行不是解决现代分布式系统问题的正确方式——你的服务可能与数十台其他主机交互，这些主机可能同时崩溃（或逐渐停止等），重新启动和单步执行极其困难。

除了需要为"计算机"重建的众多监控、开发和调试工具外，还有许多更基础的问题没有满意答案。安全领域尤其未知：

什么是这台"计算机"的"特权进程”？
权限和信任边界是什么？
用户管理如何工作？
跨服务认证和凭据委派如何实现？
如何避免将James Forshaw在其幻灯片中描述的所有单机权限提升漏洞重新引入我们的新OS和各种服务？
是否有办法确保Linux内核的/mm单个漏洞不会导致整个安全模型崩溃？

结语

简而言之，我认为正在浮现的数据中心OS是计算机科学几十年来最激动人心的发展。有时我希望自己更擅长说服亿万富翁投资几亿美元解决有趣问题——因为如果有我想致力于解决的问题，那就是开发一个FOSS数据中心OS——“在N台机器上安装这个，你就拥有了’一台计算机’"。如果思考"这个特定组件在’计算机’中实现什么功能？这个项目的单机等价物是什么？"，许多技术景观会更容易理解。

本文可能会有后续，因为关于这个话题我还有更多不成熟的想法：

数据中心OS的安全模型
Kubernetes：你想成为调度器还是OS？只能选一个
如何获得bash脚本的强大功能，但针对2万台机器的集群？