鸿蒙系统设计：宏内核vs微内核的基础逻辑

当鸿蒙OS宣布开源的时候，各种空洞的炒作，几乎把国产操作系统的技术本质掩盖了，虽然笔者没亲眼见过鸿蒙的代码，也没用方舟成功编译什么程序，不过当华为官宣鸿蒙将使用微内核的时候其实这款OS的风格就已经确定了，因为这就是内核的价值和意义。

记得十几年前笔者刚刚毕业，初次进入嵌入式开发的圈子，那时总感觉操作系统距离我很远，甚至有些高不可攀。当时看到CSDN论坛上各种有关WINCE、MINIGUI等嵌入式OS的发贴时，那些生硬的代码真是给我当时还年轻的心灵留下了巨大的阴影，不过这十年来虽然工作和嵌入式渐行渐远，但是不断总结经验回头来看，感觉操作内核的设计并不是一个纯数学或者技术的建模过程，甚至还反应了我们日常生活中的很多道理。

在科技界有一句名言“如果你无法简洁的表达你的想法，那只说明你还不够了解它”，所以经过了这些年的沉淀，笔者尝试使用最通俗的语言来向大家解释，什么是内核、什么又是微内核，阅读本文不需要读者具备什么操作系统的知识。

宏内核vs微内核的基础逻辑

上世纪90年代，微内核操作Minix的作者Tanenbaum与微内核操作系统Linux的作者Linus，曾经有一段非常著名的论战，(具体链接: https://www.oreilly.com/openbook/opensources/book/appa.html),这里笔者无意全文翻译，只是想说即便是Linus这样的大神级人物也难免会陷入谁优谁劣的口水仗之中，而普通人士可能更难免俗，所以我们先搁置优劣的争议，先直观来感受宏内核与微内核的架构图是什么样子的。

图1. 宏内核架构图

图1. 微内核架构图

简单的讲宏内核就是操作系统是个大管家，几乎包办一切，用户应用程序的需求直接向内核提出就行；微内核更向一个代理人，几乎所有的驱动、文件系统全部运行在与用户应用程序平级的用户模式下。

内核类型的简单类比

为了让读者理解起来更方便，接下来让我们做一个比较简单的类比，如果把操作系统看成一家公司，而宏内核的特点是用户请求直达内核，内核统一安排执行，这代表此公司使用扁平化的管理架构，而微内核的操作系统中则需要设立很多如驱动，文件系统等部门，这显示公司使用制度化、等级化的管理架构。

简而之宏内核代表的是层次简单的扁平化管理风格，微内核则代表多部门的制度化管理风格。

基础概念释义

上下文及上下文切换：这个名词经常出现在各类操作系统的书籍当中，还是以公司为例，上下文就代表了处理一个项目所需要的相关材料、文件，而上下文切换则代表这些材料文件在不同部门（进程）或者领导（CPU）之间的流转。

状态保持（快照）及恢复：假设这样一种场景，我正在领导的办公室中汇报工作，此时外面另一个人有更重要的事情向领导汇报，由于涉及权限问题需要我先退出他的办公室，那么我在退出前需要做一次状态快照，以便领导处理完紧急事务后可以继续处理我的工作。这就是计算机中状态保持与恢复的过程。

基本推论

运行效率宏内核更优：相信大家都有过跑部门跑公章的经历，很多时间、精力都浪费在了部门（进程）之间的上下文切换(上文已经释义)中了，微内核在效率方面肯定是处于劣势的，所以目前的主流操作系统如Linux和Windows本质上使用的都是宏内核，当然有读者可能会提出Windows使用的是混合内核，不过这种混合内核也是以效率优先的扁平化架构，本质上还是宏内核。

宏内核vs微内核 谁更安全

有关安全性的比较，其实仅凭直觉就能得到正确结论。正如各位日常所见，正规军队采用的都是“下级服从上级、命令绝对执行”的管理方式，而只有游击队才搞会扁平化管理的。其中逻辑也不难理解，扁平化虽然能有比较高的效率，但是难免会在身份鉴别、数据传递的过程中出现纰漏，从而给入侵者可称之机。

而目前已有部分宏内核如sel4（Github地址：https://github.com/seL4/seL4）已经被形式化证明无误（论文地址：http://ts.data61.csiro.au/publications/nicta_full_text/955.pdf），

对于sel4的形式化证明笔者在这里多聊几句，从本质上来说sel4的内核代码只有1万行左右，而linux的内核代码已经突破了2000万行，所以微内核的sel4由于其代码数量较小，所以研究人员干脆将其内核抽象成一个有限状态机，进而证明在状态迁移与跃迁的过程中都不会发生会被恶意利用的漏洞，从而保证整个体系的安全。当然这个安全也有前提：

一、不有有内鬼：即生成内核的编译器、链接器与操作运行的硬件环境如DMA等设备不能被提前恶意植入后门。

二、不能有密码泄露：形式化验证只能保证制度体系本身不出问题，如果用户将自身密码泄露那系统是无法防范的。

不过我们也知道宏内核的操作系统尤其是Windows，经常会暴出安全漏洞，用户在没有泄露密码且没使用问题硬件的情况下，还是会遭到被黑客入侵。所以在安全性对比上微内核可谓优势明显。

宏内核vs微内核 谁实时性强

这个问题的答案可能与读者的第一反应不同，效率更优的宏内核在实时性方面的表现其实不如微内核。那些对于实时性要求极高的军用操作系统（如vxWorks等）使用的都是微内核架构。

请想象这样一个场景，假如我是公司的销售部负责人，正在向总经理汇报明年的销售计划，这时总经理状态一般办公室屏蔽来访，手机屏蔽来电，专门处理我的汇报，恰在此时读者做为战略部负责人带着阿里即将收购公司的消息，来到总经理办公室门口，请求汇报。假设此时有关阿里收购汇报的优先级是高于其它所有工作的优先级，所以总经理会把我汇报的内容做一下状态保持（快照），尽快安排战略部负责人进来汇报。

由于宏内核的扁平化架构，几乎所有请求都是直达总经理的，所以总经理对于来访及来电的屏蔽时间就会变得不可控，而反观微内核此时多部门的制度化架构优势开始显现，因为总经理一般只要核对一下其它部门的处理过程是否合规，然后签名即可，因此微内核的最长屏蔽时间是可预期的。

So当我们在向下思考一层就会发现，制度化、流程化的微信核更能保证决策层在最短时间内就给最重要的任务予以响应。

宏内核vs微内核 谁更适合多核处理器

其实目前微内核的回归正好说明了微内核与多处理器的硬件平台配合会更好。请想象这样的场景,假如我是一家餐厅的外卖小哥，我向内核发送了回单位取餐的请求，这是内核会把这个请求拆解为两个，一是我到达单位，状态改为空闲的通知，二是帮我准备指定的菜品，如果这家餐厅规模很小只有一个总经理当然没有任何问题，不过如果餐厅有两个决策人（双核），那么我到达的通知可能先发给了总经理1，而为我准备菜品时总经理1（核心1）有其它任务了，所以需要总经理2（核心2）来安排协调了，这时就需要在总经理1和总经理2进行上下文切换才可以满足我的需求了。而微内核在内核下面设计有部门（服务进程）的架构，就几乎不存在宏内核在核心间调研上下文切换的问题。所以在总体来说，宏内核会在CPU核心间不断进行上下文切换，而微内核则不断在部门（进程）间进行上下文切换。

当然了宏内核针对多处理器时代也不是完全束手无策，比如Linux就提出了用户协议栈的概念，其本质逻辑就是成立一个直属某一总经理的特别行动小组，这一小组的所有任务全部在此总经理的领导下进行，从而避免跨总经理间的上下文切换以提高效率，其实这种方案也有一定局限性，比如出现单个总经理根本管不过来特别组的情况，该如何优化其实还是有待探索。

编辑：hfy