文/Glenn Fleishman
译者/Sambodhi
编辑/Tina
来源： InfoQ Pro（ID:infoqpro）
导读：
对很多人来说，NASA 非常神秘。NASA 即美国国家航空航天局，是美国联邦政府的一个行政机构，负责制定、实施美国的民用太空计划，以及开展航空科学暨太空科学的研究。NASA 负责美国的太空探索，例如登月的“阿波罗”计划，太空实验室，以及随后的航天飞机。
特别值得一赞的是，NASA 也热烈拥抱了开源：在航天领域中，NASA 在开源方面走在前列，已开源了大量软件、设计工具，涵盖了航天器整个研制和应用过程。众所周知，NASA 每次太空任务都离不开先进的软件程序。可能大多数人不清楚的是，今天的“软件工程”这一概念，正是发轫于 NASA。由此软件架构的重要性可见一斑。
Glenn Fleishman 和我们分享了 NASA 的软件架构的演变等方方面面，可读性非常高。InfoQ 中文站将其翻译出来，只是为了不忘初心：我们的征途是星辰和大海！
当你在离家数百万英里的太空时，如果服务器崩溃了，可没有人能听见你恐慌的呐喊！所以对 NASA 来说，冗余特别重要，既然可以发送五台服务器到平流层外，他们就必定不会只发送一台。
在太空里，宇宙射线、磨损、突发故障各种不确定因素都会对设备造成影响，软件架构必须非常健壮。软件架构领域的创始人、NASA 喷气推进实验室的杰出访问科学家 David Garlan 说，航天器系统尤其需要一个故障保护层，使它们在没有地球方面的直接干预下能够切换到紧急状态。
相对地面的软件，航天软件的设计更难。
在地面，如果一台数据中心的服务器性能过于缓慢，可以不断增加服务器来解决问题，但航天器的计算能力短缺问题却不能靠增加机器的方式解决。航天器的算力在整个任务期间保持不变，系统必须设计成能自动丢弃某些给定的任务。
如果是一台地面上的数据库服务器，无法实时插入数据也不会造成太大的影响。但是，一艘飞奔火星的宇宙飞船，如果其运行周期没有得到完美的控制，可能会与火星完全失之交臂。
持续运行 2700 天，靠的就是自恢复策略。
航天器能用的计算机台数是有严格限制的。增加物理备份，会让航天器的软件变得更具弹性。对于 1972 年至 2011 年的 NASA 航天飞机项目来说，仅有三到四台计算机是不够的，那时共有五台飞行控制计算机，再多增加一台是需要设计人员反复考虑的事情。
此外，NASA 还制定了一项策略，允许软件在最坏的情况下恢复。这一策略在 1961 年至 1972 年的“阿波罗”（Apollo）计划中途首次实施，它是为了出现问题时而明确设计的。如果没有这一策略，一项又一项的任务将不得不放弃。
在 1977 年的发射期间，NASA 太空探测器“旅行者 2 号”（Voyager 2）记录了一些抖动，这些抖动很可能导致服务器“宕机”，科学家也无法预料程序将如何解读这些抖动，但是探测器最终还是正确地进入了恢复模式。
“机遇号”（Opportunity）火星车于 2003 年发射，原计划在火星上运行 90 天，但实际上，到 2018 年中，它仍在运行，总共 5111 天。这台火星车本来设计寿命为 90 天，但却超额服役 15 年，中间曾经根据采集的移动数据重写代码，来绕过一条电缆短路造成的故障。
“好奇号”（Curiosity）于 2011 年发射，最初计划在火星上运行 687 天，但它到今天仍然运行，截止本文写作时，已超过 2700 天。“好奇号”火星车在火星上的第一年和第五年，其两台主计算机曾出现过故障，差点造成任务失败。
有时候，冗余也能增加机会。
“旅行者 2 号”在 1986 年经过天王星，1989 年经过海王星时，要不是“旅行者 2 号”有一套备用的计算机，再加上任务控制中心能够上传新的软件来利用这些备用计算机，否则，“旅行者 2 号”能够拍摄到的天王星和海王星的照片就会少得很多。
能打败墨菲定律的只有备份
允许有几分钟“停服”时间，还是拥有故障转移解决方案，这是需要权衡利弊的。在地球上计算的硬件已经从单一业务大型机发展到功能强大的服务器冗余阵列，这种阵列允许其中一个或多个服务器出现故障，但并不会因此中断业务。出于必要，NASA 也决定让太空中多台计算机运行重复功能。
就算是完美的软件、完美的硬件，仍然也有可能在太空中崩溃：能够打败墨菲定律和宇宙射线的只有备份。在“阿波罗”计划期间，NASA 曾致力于确保每个部件和系统都经过测试，直到确定它是完美的。然而，此举既昂贵又脆弱。
“完美“解决不了问题
有两个著名的例子说明了依赖完美的问题。女工程师 Margaret Hamilton 是麻省理工学院在 20 世纪 60 年代末开发“阿波罗”计划软件的团队负责人，她经常在深夜和周末带着蹒跚学步的女儿 Lauren 到办公室加班。在 1968 年底执行的“阿波罗 8 号”任务将标志着宇航员首次绕月飞行，在此之前，小女孩 Lauren 通过“阿波罗”计算机 DSKY，即一个键盘和显示器的组合，来玩指令舱模拟器。她出人意料地触发了预发射顺序，从而使飞行模拟发生崩溃。
Hamilton 试图说服 NASA 允许她引入错误检查，以防止宇航员在执行任务时犯下同样的错误，尽管这种错误不太可能会发生。但 NASA 驳回了她的请求，坚称宇航员将会完美地完成任务。不得已，Hamilton 在手册上标注了有关这一问题的可能性。
然后，宇航员 Jim Lovell 在“阿波罗 8 号”的飞行中恰巧也选择了相同的顺序，结果，从飞船的内存中擦除了返回地球所需的导航数据。在“阿波罗 13 号”在发生爆炸的时候曾对休斯顿指挥中心回报了一句非常著名的话：“休斯顿，我们有麻烦了”（Houston, we have a problem），万幸的是，“阿波罗 13 号”成功地处置了这一险境，与其说是跳上一艘临时救生艇，不如说是找到备用磁带：Hamilton 和她的团队能够从地球上传输导航数据，因为该系统足够灵活，可以在传输过程中接受这些输入。
Hamilton 将系统设计为具有弹性，可以在出现不堪重负的情况下，系统仍然可以不受干扰地恢复正常运行，并允许它报告错误，同时提供足够的信息以做出判断。在这种情况下，计算机的负载管理软件专注于更高优先级的任务，包括雷达输入，并按预期执行。在任务控制中心经过紧张而迅速的磋商之后，宇航员在月球着陆器的燃料耗尽前几秒钟获得了批准。
1994 年，Hamilton 告诉《航空航天》（Air & Space）杂志：“我们的软件挽救了这次任务，因为它是异步的，因为它会跳过低优先级的任务，如果没有它，这次任务就会失败，或者在月球上坠毁。”
计算机已经变得越来越强大，软件工程，Hamilton 为航天飞行创造的这一术语，经过几年的发展已经趋于成熟。因此，航天飞机的设计没有考虑主系统和备份系统，甚至也没有考虑几个备份系统，而是依靠四台独立的计算机运行相同的导航和制导软件，并接收相同的数据输入。
这四台计算机作为民主的缩影而运作。它们中的三台计算机必须就它们所衡量的内容达成共识，才能采取行动。如果三台计算机同意，而第四台计算机不同意，那么出现这种情况宇航员就会关机或重新启动它。这就使得避免灾难或代价高昂的停顿所需的快速决策成为必要。
如果多台计算机出现故障，或者无法达成共识，那么一台同样可以访问航天飞机控制系统的额外计算机就可以接管。它可以进行预编程的粗略（但安全）的上升、中止和再入。
冗余之上再冗余
1964 年，喷气推进实验室的科学家 Gary Flandro 计算出，到 20 世纪 70 年代末，木星、土星、天王星和海王星将排成直线，允许探测器利用重力助推（gravity assists，亦称重力弹弓效应、绕行星变轨）来访问这几颗行星，围绕行星旋转以获得加速度。这样的排列，每 175 年发生一次。“旅行者号”被派往太空执行探测任务。
“旅行者号”任务的许多方面都有冗余性，它的两个探测器是在不同的地点分别发射的。其中“旅行者 1 号”和“旅行者 2 号”又都配备了两个并行的计算机系统。如果三台 A 计算机（分别用于指令、数据管理和姿态控制）中的一台出现故障或崩溃，探测器可以自动切换或通过指令切换到 B 系统。
“旅行者号”探测器也是 NASA 第一个使用软件检测故障的探测器，可以分析各种事件，并在没有指示的情况下能够做出相应的反应。正如任务发射前项目经理 John Casini 在《旅行者号的故事》（Voyager Tales）一书中的采访中指出的那样：我个人对“伟大航路”（Planetary Grand Tour）的看法是：“运载火箭的转动速度比宇宙飞船在太空中的转动速度要快得多。”然而，在这种速度下，“旅行者 2 号”还是遇到了意外情况，幸运的是它自己判断到了，并将自己重新置于安全模式。
Casini 说，甚至在地面让工作人员弄清楚发生了什么事之前，“宇宙飞船与运载火箭分离后就自行恢复了。”项目人员随后在发射前更新了“旅行者 1 号”的软件，探测器设法正确处置了旋转和抖动。
如今，“旅行者号”已经离开了太阳磁泡的范围，但还没有离开太阳系，而是所谓的太阳圈（heliosphere），现在，正在星际物质中遨游。但是，即使距离如此之远，“旅行者号”仍然可以传回数据，并且仍能让继续管理这些数据的小团队感到惊讶。到了 2010 年，“旅行者 2 号”开始发回一些无意义的信息，而不是科学数据。于是，科学家们将探测器切换到待机模式，这种模式的代码是经过几十年的改进形成的，同时他们也发现了问题所在。他们将程序恢复到了之前的状态，再次使用每秒 160 比特的速率把数据发回地球。
冗余也会引发问题
在太空中，系统并不容易进行升级。对于不可能进行硬件升级的任务来说，“冗余”是个正确的选择，但它也可能会导致其它问题。麻省理工学院航空航天系的 Nancy G.Leveson 教授在一篇题为《软件在航天器事故中的作用》（The Role of Software in Spacecraft Accidents）中写道：
NASA 对一架装有两个版本的控制系统的实验飞机进行了研究，发现在飞行测试期间中出现的所有软件问题，都是由于冗余管理系统中的错误造成的，而不是控制软件本身，控制软件运行正常。我们需要为软件设计保护功能，以反映软件的“故障”模式。
另一个重要的问题是，现代航天器系统比它们的前身要复杂得多。随着更多的算力和更多的任务可以在任务期间处理，驱动当今飞船的代码变得异常复杂：不可避免的是将会出现一些错误。如果缺乏标准的软件架构，会加剧引发故障。但即使是现今计划中最先进的航天器，在一定程度上也依赖于较旧的软件架构概念。“猎户座”飞船的设计目的是在未来的载人航天任务中将宇航员送上月球，它将搭载四台计算机，每台计算机都有两个并行工作的处理器，其结果必须一致。每台计算机的软件都表现得就像它在独立驾驶航天器一样。
这些计算机不是民主主义者（Democracy），而是唯我论者（Solipsist），每台计算机都认为自己是“宇宙中唯一的计算机”。如果一台计算机未能在正确的时间提供正确的指令，系统被设计成在系统故障时重新启动，并接受来自下一台计算机的指令。与航天飞机一样，“猎户座”飞船也将配备一台备用飞行计算机。
距离人类首次登月已经过去 50 多年了，月球是地球唯一的天然卫星，安全返回依然需要付出巨大的努力。
作者介绍
Glenn Fleishman，家住华盛顿州西雅图市，曾撰写了关于 19 世纪的美国、比特币和小卫星（nanosatellites）的文章。他最新的著作《London Kerning》，讲述了到目前为止的伦敦印刷排版的历史探索。
本文最初发表在 Increment，经原作者 Glenn Flsishman 授权，InfoQ 中文站翻译并分享。
原文链接
https://increment.com/software-architecture/in-space-no-one-can-hear-you-kernel-panic/