聊了聊宏内核和微内核，并吹了一波 Linux-技术圈

内核是操作系统非常重要的组成部分，同时也是操作系统的核心。内核管理着系统资源，内核向上连接着应用程序，向下连接着硬件，它是应用程序和硬件的桥梁。

内核可以进一步的划分，分为宏内核和微内核。

宏内核和微内核最大的区别就是，宏内核的用户服务和内核服务都保存在相同的地址空间中，它们都由内核进行统一管理，而微内核的用户服务和内核服务会保存在不同的地址空间中，下图可以很好的解释这一点。

其实这里的宏内核翻译过来有点牵强，其实应该叫单内核或者单核。在这种单核的设计中，内核是一个大的整体，可以说是一个大进程，在这个大进程中，所有内核服务都运行在一个地址空间中，函数之间的调用链路少，直接通信简单高效。

而微内核的功能会划分为独立的进程，进程之间通过 IPC 进行通信，高度模块化，一个服务的故障不会影响另一个服务。不过由于模块化的影响，函数之间调用链路偏长，进程之间不会直接通信，而是通过内核服务相互通信。

从内核大小上面来讲，微内核的尺寸更小，只包含用户进程相关的服务，而单核的尺寸要比微内核大的多，这点比较好理解，因为宏内核融入了太多服务和驱动。

从执行效率上来说，微内核的执行效率相对较慢，因为涉及到跨模块调用，而宏内核执行效率高，因为函数之间会直接调用。

在微内核模块化之后，它很容易扩展，因为内核空间与用户空间相互隔离，在用户态下（运行在用户空间中的应用程序）应用程序崩溃后一般不会影响到内核中的数据。宏内核的可拓展性较差。

经过上面这些描述之后，我们很容易把宏内核和微内核的特征想象成软件开发中的单体架构和微服务架构。

单体架构最大的特点就是函数调用方便，几乎不存在调用链路，一个项目解决所有问题，项目中包含数据库驱动、各种拦截器、控制器、权限控制，可拓展性非常差。

而微服务的架构之间的调用链路会比较长，模块之间的职责分离并且相互依赖，比如权限控制模块、路由模块、总线通信模块。可拓展性比较强。

这两种不同的内核结构有不同的支持者，就和有些人认为单体架构好，有些人认为微服务架构模式好。

这就像对编程语言的争论一样，你说 Python 、Go、Java 以及其他语言哪个好？管他哪个好，最终都会戏谑的称 PHP 是这个世界上最好的语言。所以，这些争论本没有意义，但是很有趣的是，这种争论常常让人想起前几年在 CPU 领域中 RISC 和 CISC 之间的斗争。

现代成功的 CPU 设计包括这两种技术中的任何一种，就像 Linux 内核是微内核和宏内核的混合产品一样。可能有些人认为 Linux 它不就是个宏内核结构么，但实际上 Linux 不单单只是一个纯碎的集成内核。

为什么 Linux 会使用单内核（此处叫单内核有点应景）结构呢？我猜有下面几个因素。

从 Linus 的角度来看，单内核的开发和选型更容易，因为避免了与消息传递架构、计算模块加载方法等相关的工作。而且 Linux 的诞生原因在于 Linus 对 MINIX（一种类 UNIX 操作系统）只允许在教育上使用很不满，再加上 Linus 本来对操作系统很感兴趣，于是他开始编写 Linux 操作系统，所以我认为当时的 Linus 开发 Linux 起源于兴趣，并未经过详细周到的设计，也并未考虑它的可拓展性。当然这只是鄙人粗浅的猜测。

这就和我们上大学的毕业设计一样，你毕业设计做的系统，你会考虑可拓展性吗？除非你想当产品来做，但是何必呢？

另一个原因是充足的开发时间。Linux 没有研发时间限制，也没有发布时间表。任何限制都只能单独修改和扩展内核。核心的单一设计内部完全模块化，在这种情况下修改或添加不是很困难。问题是没有必要为了追求未经证实的可维护性的小幅增加而重写 Linux 内核。Linus 一再强调以下观点：为了这个好处而损失速度是不值得的。

Linux 是一个借鉴了微内核精髓的宏内核结构，Linux 支持模块化的设计、抢占式内核、对内核线程的支持以及动态加载内核模块的能力。不仅如此，Linux 还避免了其微内核设计的性能损失，允许一切运行在内核模式下，直接调用函数，无需消息传递。