★ FEATURED ARTICLE 1. 从“Apollo-11”这个名字说起它到底指什么第一次看到“Apollo-11”这个标题很多人脑子里蹦出来的第一反应是阿波罗登月计划。这个联想没错但如果只停留在“登月”两个字上就完全错过了它在技术圈里真正的分量。在软件工程和计算机历史领域Apollo-11 特指那套把人类送上月球的制导计算机AGC源代码以及后来被公开、被反复研究的整套软件工程遗产。它不是一个产品不是一个框架而是一段被完整保存下来的、运行在极端约束条件下的实时嵌入式系统代码。我最初接触它是因为一个很实际的问题现代开发环境里内存和算力几乎无限我们写代码时很少真正考虑“每一个字节都要省着用”。但 Apollo-11 的代码是在什么样的条件下写出来的主频大约 2MHz内存以 KB 为单位计算存储用的是手工编织的磁芯存储器。在这种条件下它要完成导航、制导、控制、人机交互、故障检测与恢复而且必须做到“几乎不能出错”。这套代码后来被公开在代码托管平台上成为无数工程师研究实时系统、容错设计、资源受限编程的经典样本。所以这篇博文要聊的不是登月历史本身而是Apollo-11 这套代码作为工程样本能给今天的开发者带来什么。它适合谁看适合对嵌入式、实时系统、底层编程感兴趣的开发者适合想理解“资源极度受限时怎么做架构取舍”的技术人也适合单纯对计算机历史好奇、想看看“人类写过的最重要代码之一长什么样”的读者。你不需要有航天背景只需要对“代码如何在极限条件下工作”这件事有兴趣。接下来的内容我会从它的整体架构讲起拆解它的核心模块分析它在资源约束下做的关键设计决策然后落到今天我们能从中学到什么、怎么在自己的项目里借鉴这些思路。全程不堆术语尽量用生活化的类比把复杂机制讲清楚。2. 先搞清楚这套代码的运行环境有多“寒酸”2.1 硬件规格用今天的眼光看几乎是“不可能完成的任务”要理解 Apollo-11 代码的设计逻辑必须先理解它跑在什么硬件上。AGCApollo Guidance Computer的核心参数大致是这样的字长 15 位其中 14 位数据加 1 位奇偶校验主频约 2.048 MHz内存分为两部分——磁芯存储器和只读存储器。磁芯存储器用来存可读写数据容量大约 2K 个 15 位字只读存储器用来存程序容量大约 36K 个 15 位字。换算成今天的概念程序空间大概只有 72KB 左右可读写内存大概 4KB。这个数字是什么概念今天一张手机截图可能就超过 1MB是它程序空间的十几倍。而它要完成的任务包括持续计算飞船位置和速度、控制发动机推力、管理惯性测量单元、处理宇航员输入、监控系统状态、在出现异常时重新配置系统。所有这些都要在 72KB 的程序空间里塞进去还要留出余量应对突发情况。我经常用一个类比来解释这种约束今天的开发像是在一个巨大的仓库里干活工具随便摆材料随便放找不到就再买一份。而 Apollo-11 的开发像是在一个行李箱里完成一次环球旅行每一件衣服都要卷到最紧每一个缝隙都要利用起来而且路上不能打开箱子重新整理。这种约束会彻底改变你的设计思路。2.2 磁芯存储器手工编织出来的“内存”Apollo-11 使用的磁芯存储器是计算机历史上一个非常特殊的存在。它的原理是用细小的磁性圆环磁芯来存储比特每个磁芯代表一位通过导线穿过磁芯的方向来决定它是 0 还是 1。这些存储器是工人手工编织的一个 36K 字的只读存储器背后是无数根细导线和磁芯的精密排列。为什么这件事重要因为它意味着程序一旦编织进去就几乎不能修改。今天的开发是“写代码—编译—部署—热更新”而当时是“写代码—测试—编织—如果错了就重新编织”。这种不可逆性倒逼开发流程必须极其严谨代码在编织之前要经过反复验证要有完整的仿真测试要有备份方案。这种“一次做对”的压力和今天很多团队“先上线再修”的文化形成鲜明对比。从工程角度看磁芯存储器的另一个特点是非易失性。断电之后数据不会丢失这对航天任务至关重要。今天的闪存也有类似特性但速度和可靠性完全不在一个量级。理解这一点就能理解为什么 AGC 的软件架构里很多设计是围绕“存储可靠性”展开的而不是围绕“运行速度”展开的。2.3 实时性要求不是“快”而是“准时”很多人以为实时系统的核心是“快”其实不是。实时系统的核心是确定性——在规定的时间内必须给出结果早一点晚一点都可能出问题。Apollo-11 的 AGC 要控制飞船的姿态和轨迹如果计算延迟超过某个阈值发动机的响应就会滞后飞船可能偏离轨道。AGC 的调度机制是围绕这个确定性设计的。它有一个基本的时钟节拍所有任务都按照优先级和固定时间片来调度。高优先级的任务比如姿态控制会打断低优先级的任务比如显示更新确保关键操作永远能及时执行。这种设计思路在今天依然适用任何对时间敏感的系统都不能依赖“平均性能”而要保证“最坏情况下的响应时间”。我在实际项目里踩过一个坑曾经做一个数据采集系统用了一个“平均延迟很低”的通信库结果在负载高峰时偶尔出现几百毫秒的抖动导致采集数据出现时间戳错乱。后来换成固定周期的轮询方案虽然平均延迟略高但抖动控制在微秒级问题就解决了。这就是实时系统思维的价值——确定性比平均性能更重要。3. 代码架构拆解72KB 里到底装了什么3.1 核心模块划分每个字节都有明确归属Apollo-11 的代码在架构上做了非常清晰的模块划分大致可以分为几个核心部分执行控制负责调度和中断处理、导航计算位置和速度、制导计算需要的推力方向、控制驱动发动机和推进器、人机接口处理键盘和显示、自检与故障恢复。每个模块都有明确的职责边界模块之间的接口定义得非常严格。这种划分方式在今天看来很常规但考虑到当时的存储约束能做到这一点非常不容易。因为模块化本身是有成本的——每个模块需要独立的代码空间、独立的接口定义、独立的测试用例。在 72KB 的预算里能把这些都安排明白说明设计者对“什么必须做、什么可以省”有极其清醒的判断。我特别想强调的一点是Apollo-11 的代码里几乎没有“冗余功能”。今天很多项目会预留大量“以后可能用得上”的接口和扩展点但在这套代码里每一个函数、每一个变量都有明确的用途没有一个是“为了扩展性”而存在的。这种极简主义不是审美选择而是生存压力下的必然结果。3.2 中断处理优先级决定生死AGC 的中断系统是整套代码里最精妙的部分之一。它把中断分成多个优先级最高优先级的中断可以打断任何正在执行的任务包括其他中断处理程序。这种“嵌套中断”机制确保了最关键的事件比如发动机异常能立即得到响应。具体来说AGC 的中断处理遵循几个原则第一中断处理程序尽可能短只做最紧急的事情把耗时操作留给主循环第二中断可以嵌套但有深度限制防止无限嵌套导致栈溢出第三关键数据在中断和主循环之间共享时有明确的保护机制避免竞态条件。这些原则在今天的中断驱动编程里依然是金科玉律。我见过不少项目中断处理程序里塞了大量逻辑结果导致高优先级中断被低优先级中断阻塞系统响应变得不可预测。Apollo-11 的做法是中断里只做“标记”主循环里做“处理”。这个模式简单但极其有效值得每个写嵌入式代码的人学习。3.3 故障恢复不是“不出错”而是“出错后能活下来”Apollo-11 最让人敬佩的设计之一是它的故障恢复机制。这套机制的核心思想是系统一定会出错关键是在出错后能恢复到安全状态。具体做法包括定期检查关键变量的奇偶校验、在检测到异常时重启相关模块、保留多个备份路径、在极端情况下切换到手动控制。有一个著名的案例在登月舱下降过程中AGC 因为雷达数据异常触发了多次重启但每次重启后都能快速恢复最终没有影响着陆。这个案例后来被反复研究因为它证明了容错设计不是“锦上添花”而是“生死攸关”。从工程角度看Apollo-11 的故障恢复有几个值得借鉴的点第一错误检测要早不能等到问题累积到不可收拾才发现第二恢复策略要分级轻微错误就地修复严重错误重启模块致命错误切换备份第三恢复过程要可预测不能因为恢复操作本身引入新的不确定性。4. 资源受限下的编程智慧今天依然能抄的作业4.1 用“解释器”换空间一个反直觉的设计Apollo-11 代码里有一个非常有意思的设计它没有把所有功能都写成机器码而是实现了一个解释器用解释器来执行更高级的指令。这个解释器本身占用了一部分存储空间但它让后续的代码可以用更紧凑的方式编写整体上反而节省了空间。这个思路在今天依然有借鉴意义。比如在资源受限的嵌入式设备上与其为每个功能写一套独立的机器码不如实现一个轻量的虚拟机或脚本引擎用更高级的语言来描述业务逻辑。虽然运行效率会略低但代码体积和开发效率会大幅提升。当然这个取舍要看具体场景——如果对实时性要求极高解释器的开销可能不可接受但如果业务逻辑复杂且变化频繁解释器带来的灵活性就很有价值。我个人的经验是当存储空间比 CPU 时间更稀缺时解释器是值得的反之则不值得。Apollo-11 的选择说明在它的场景里存储空间是更硬的约束。4.2 复用与共享同一个函数服务多个场景在 72KB 的预算里代码复用不是“好习惯”而是“必须做的事”。Apollo-11 的代码里有大量函数被多个模块共享比如数学运算、数据转换、状态检查等。这些函数被设计得非常通用通过参数来适配不同场景。这种做法的代价是可读性下降。一个函数被十几个地方调用每个调用点的上下文都不同理解和修改的难度会上升。但在资源受限的环境里这是必须接受的代价。今天的开发者如果遇到类似约束比如在 MCU 上开发也需要做同样的取舍优先保证功能完整再考虑代码优雅。我的建议是如果要做这种复用一定要把函数的契约写清楚——输入是什么、输出是什么、有哪些副作用、在什么条件下会失败。Apollo-11 的代码里每个共享函数都有详细的注释说明这些信息这是它能在极端约束下保持可靠的关键。4.3 手工优化每一行汇编都有存在的理由Apollo-11 的代码主要是用汇编语言写的这意味着每一行代码都直接对应机器指令没有编译器优化的空间。开发者必须手工做很多今天由编译器自动完成的事情寄存器分配、指令调度、循环展开、常量折叠等。这种手工优化在今天看来很“原始”但它有一个重要的好处开发者对代码的执行路径有完全的控制。在实时系统里这种控制力非常宝贵因为你可以精确知道每个操作需要多少个时钟周期从而保证最坏情况下的响应时间。今天我们用高级语言开发编译器帮我们做了大量优化但代价是我们对执行路径的掌控变弱了。在大多数场景下这不是问题但在对时间极度敏感的场景下可能还是需要回到汇编或者使用内联汇编来精确控制。我的经验是不要轻易用汇编除非你已经确认高级语言无法满足需求并且你愿意承担维护成本。5. 从 Apollo-11 到现代开发哪些思路可以直接迁移5.1 确定性优先实时系统的第一原则Apollo-11 给我的最大启发是在实时系统里确定性比性能更重要。这个原则在今天依然适用而且适用范围远不止航天领域。任何需要“在指定时间内完成指定操作”的系统都应该把确定性放在第一位。具体怎么做第一避免动态内存分配因为分配时间不可预测第二避免无界循环所有循环都要有明确的上限第三避免优先级反转确保高优先级任务不会被低优先级任务阻塞第四对最坏情况做测试而不是只测平均情况。我在一个工业控制项目里应用过这些原则把所有的内存都在启动时分配好运行时不调用任何动态分配函数把所有的循环都加上最大迭代次数保护用优先级继承机制解决优先级反转问题。结果系统的响应时间从“平均 10ms偶尔 200ms”变成了“稳定在 15ms 以内”虽然平均性能略降但可靠性大幅提升。5.2 故障恢复设计把“出错”当成常态Apollo-11 的故障恢复机制告诉我们不要假设系统不会出错而要假设系统一定会出错然后设计出错了之后能恢复的方案。这个思路在今天的高可用系统里已经是标配但很多开发者依然在写“假设一切正常”的代码。一个实用的做法是为每个关键操作定义失败路径。比如一个网络请求成功路径是什么、超时路径是什么、返回错误码路径是什么、连接断开路径是什么。把这些路径都写清楚并且在代码里实现对应的处理逻辑。这样当问题真的发生时系统不会直接崩溃而是能进入一个可控的状态。另一个做法是定期做故障注入测试。主动制造一些错误比如断开网络、模拟磁盘满、注入延迟看看系统能不能正确恢复。这种测试在 Apollo-11 时代是靠仿真完成的今天有更多工具可以帮忙但核心思路没变只有真正测试过故障恢复路径才能相信它在关键时刻能工作。5.3 极简主义每个功能都要证明自己的价值Apollo-11 的代码里没有“可能有用”的功能每个功能都是为了解决一个具体问题而存在的。这种极简主义在今天特别值得学习因为现代项目的功能膨胀太严重了。我见过太多项目代码库里塞满了“以后可能用得上”的模块结果维护成本越来越高真正重要的功能反而被淹没。一个实用的方法是在添加任何功能之前先问三个问题。第一这个功能解决什么问题第二如果不做这个功能会有什么后果第三有没有更简单的方式达到同样的目的如果第一个问题答不清楚或者第二个问题的答案是“没什么后果”那这个功能就不应该加。Apollo-11 的开发者没有选择他们必须在 72KB 里做取舍。但今天的我们有选择而选择“不做”往往比选择“做”更需要勇气和判断力。6. 实操建议怎么在自己的项目里借鉴 Apollo-11 的思路6.1 从“资源预算”开始而不是从“功能列表”开始大多数项目的起点是“我们要做哪些功能”然后才考虑资源够不够。Apollo-11 的做法反过来先确定资源预算多少存储、多少 CPU、多少时间然后在这个预算内决定做什么功能。这个顺序的差别很大因为先定功能再砍资源往往会导致架构上的妥协先定资源再选功能会逼着你做更根本的取舍。具体操作上我建议在项目启动时先做一件事给每个资源维度定一个硬上限。比如“程序空间不超过 256KB”“内存占用不超过 64KB”“最坏响应时间不超过 50ms”。然后把这个上限写在项目文档里作为所有设计决策的约束条件。当有人提出新功能时先问“这个功能会占用多少资源”如果超出预算要么砍功能要么砍其他功能来腾空间。6.2 建立“最坏情况”测试习惯Apollo-11 的测试不是测“正常情况下能不能工作”而是测“最坏情况下能不能工作”。这个习惯在今天依然稀缺。大多数团队的测试用例覆盖的是正常路径对边界条件和异常路径的覆盖远远不够。我的做法是为每个模块写三类测试。第一类是正常路径测试验证基本功能第二类是边界测试验证输入在极限值时的行为第三类是故障测试验证依赖项失效时的行为。第三类测试最容易被忽略但往往最有价值因为它能暴露架构上的脆弱点。6.3 把“可恢复性”作为架构的第一属性在设计系统架构时大多数人关注的是“功能怎么实现”“性能怎么优化”但 Apollo-11 提醒我们可恢复性应该是第一属性。一个系统如果不能在出错后恢复那它的功能再强、性能再好也是不可靠的。具体做法包括为每个关键状态设计备份路径、定期做状态快照、实现分级恢复策略、在恢复过程中保持可观测性。这些做法会增加一些开发成本但在关键时刻能救命。我在一个长时间运行的数据处理系统里应用了这些思路结果在一次存储故障中系统自动切换到备份路径只丢失了不到一秒的数据用户几乎无感知。如果没有这些设计那次故障可能导致数小时的数据丢失。7. 我踩过的坑和总结的经验聊了这么多 Apollo-11 的设计思路最后分享几个我自己在实际项目里踩过的坑以及从这套代码里学到的经验。第一个坑是过度追求性能而忽略确定性。早期做实时数据采集时我选了一个吞吐量很高的通信方案但它的延迟抖动很大。结果数据是采到了但时间戳错乱后续分析全乱套。后来换成固定周期的方案吞吐量降了一些但数据质量大幅提升。这让我明白在实时场景里“稳定”比“快”重要得多。第二个坑是假设依赖项永远可用。我曾经写过一个模块假设数据库连接永远正常结果一次网络抖动导致整个流程卡死。后来我学了 Apollo-11 的做法为每个外部依赖都设计了超时和降级路径系统才变得真正可靠。不要相信任何外部依赖要为它们的失效做好准备。第三个坑是功能蔓延。有一个项目一开始只要求做核心功能后来不断加需求代码库越来越臃肿最后连原来的核心功能都变得不稳定。回头看如果一开始就设定资源预算并严格执行很多“锦上添花”的功能根本不会进来。说不的能力比做的能力更重要。Apollo-11 的代码之所以在几十年后依然被研究不是因为它用了什么高深的技术而是因为它在极端约束下做出了正确的工程判断。这些判断背后的思路——确定性优先、故障恢复设计、极简主义、资源预算先行——在今天依然有效而且适用于任何领域的软件开发。你不需要去写航天代码但你可以把这些思路用到自己的项目里让系统更可靠、更可控、更经得起考验。
阅读完成 · 觉得有帮助？
区别)
