操作系统微内核和Dubbo微内核各自优缺点！

导读	这篇文章借着 Dubbo 来说说微内核这种设计思想，不会扯到 Dubbo 某个具体细节实现上，和 Dubbo 强相关的内容会在之后的文章写到。所以今天的重点在微内核，而这个概念我最早是从操作系统那里得知，不过操作系统的微内核和 Dubbo 相关的微内核又不太一样。

Dubbo 的微内核广义上的微内核，而操作系统只是针对内核实现。

我们先看看操作系统的微内核。

在维基百科上搜索微内核出现的就是：

在计算机科学中，微内核(英语：Microkernel，μ-kernel)，是一种内核的设计架构，由尽可能精简的程序所组成，以实现一个操作系统所需要的最基本功能，包括了底层的寻址空间管理、线程管理、与进程间通信。

这个词条归类在操作系统技术下，所以这里的微内核指的就是操作系统的内核设计，与之对应的是宏内核架构。

Linux 就是宏内核架构。

操作系统我们都知道它是一个中间层，为我们管理底层的硬件资源，为上层服务提供接口。

提供进程管理、内存管理、文件系统、进程通信等功能。

像 Linux 这样的宏内核设计是把这些功能都作为内核来实现，而微内核则仅保留最基础的功能。

比如就留下进程的管理、内存管理等，把文件管理等功能剥离出去，变成用户空间的独立进程来提供服务。

来看下这个维基百科上的这个图应该就很清晰了。

宏内核中的一些功能在微内核架构上都被独立到用户态中，这样内核代码量就少了。

代码少了潜在的 bug 就少，出了问题也更容易排查。

系统也就更加稳定，不易奔溃，因为那些服务从内核中移除，在用户空间运行着，如果出了故障，内核重启这个服务就好了，不会像之前那样整个内核 GG。

拿显卡驱动来说，出问题就蓝屏，这要是微内核设计就可以重启显卡驱动。

听起来好像微内核很好啊?并不是，接下来就说说微内核的缺点。

首先是性能问题。

因为很多功能作为独立进程放到用户空间运行了，所以宏内核时的函数调用就变成了进程间调用，涉及进程间的通信，还会伴随着内核态和用户态的来回切换，我们知道这种上下文切换时比较耗时的。

这性能的问题就有点大了。

然后微内核设计没那么简单，想要灵巧、减少耦合、提高可移植性就需要好好的设计，按照林纳斯的话来说：“如果 GNU 内核(微内核架构)早在去年春天完成了，我压根不会开始我的项目(Lniux)。”

GNU Hurd 采用微内核架构，设计过于精巧，研发速度缓慢，性能长期无法提升。

当年林纳斯还和 Minix 的作者安德鲁，对操作系统的宏内核和微内核的好坏进行了一波网络口水战。

我们来回顾一下那段历史，挺有意思的。

因为 AT&T 把 Unix 商业化了，大学不能免费使用 Unix，身为大学教授的安德鲁为了教学自己搞了个操作系统，即 Minix。

安德鲁

当时的学术风潮是微内核架构，把核心功能模块化，划分为几个独立的进程，运行在不同的地址空间提高了代码的可移植和系统的安全性。

所以 Minix 就是按微内核架构编写的，当然还有上述提到的 GNU Hurd。

而林纳斯那时候读大学，他祖父送了他一台 Intel 80386，林纳斯也看到了安德鲁的教科书，根据书上的内容写出了 Linux。

林纳斯

不过没有按照微内核的设计，而是跟 Unix 一样采用了宏内核架构。

安德鲁教授看到了 Linux ，然后在 comp.os.Minix 上批评道：宏内核的设计是有害的。

Linux 内核耦合度太高，完全是为了 Intel 80386 而设计的，处理器架构进化很快的，操作系统应该都具备可移植性。

安德鲁还提到：都1991年了还用宏内核来设计操作系统，这是一种巨大的退步。

林纳斯在一天之后进行了反击，他说 Minix 设计上有缺陷，从哲学和美学角度来看微内核确实好，但是你看 GUN Hurd 到现在还没开发出来。

然后操作系统本来就依靠硬件的特性，所以内核本身不需要过度具备可移植性，应用程序的可移植性才重要，Linux 比 Minix 好移植多了。

而且 Linux 本来就是为我自己做的，所以契合 80386，如果要移植到别的平台，代码都是开源的(Minix 源码当时得买)，想要的人自己做咯。

安德鲁也做了一波回应：Minix 有局限性是因为我是教授，因为大部分学生都只能在低配的机器上使用，所以系统的硬件需求得足够低，虽然你 Linux 是免费的，但是需要的硬件贵呀。

其实可以看到，两者并没有对宏内核和微内核的技术细节的进行深入探讨，而是抓住对方的：你这 Minix 代码还要收费，你这 Linux 需要的硬件这么贵来进行“攻击”，所以称之为口水战。

反正口水战之后双方都没有改变各自的设计，不过林纳斯有引进微内核的思想来改进代码，也改善了可移植性。

微内核市面上设计成功的有 QNX，黑莓手机就是用这个操作系统，车用市场也几乎都用 QNX 系统。

这手机很多年前我用过，当时觉得有点东西的。

宏内核的话就提个 Linux ，足够了。

两个架构都有成功的产品，所以还是取舍的问题，也没有谁完全压着谁。

再具体的就不深入了，今天的主角其实是广义上的微内核。

Dubbo 的微内核是广义上的，它的思想是：核心系统+插件。

这个微内核说白了就是把不变的功能抽象出来称为核心，把变动的功能作为插件来扩展，符合开闭原则，更容易扩展、维护。

小霸王游戏机大家都应该玩过，它的设计就可以认为是个微内核设计。

 

机体本身作为核心系统，游戏片就是插件。

我们想玩哪个游戏就插哪个游戏片，简单便捷，不影响机体本身。

假设不把游戏片抽象成插件式，那是不是就难搞了?换个游戏就成为难题了。

所以微内核架构的本质就是将变化的部分抽象成插件，使得可以快速简便地满足各种需求又不影响整体的稳定性。

这就是微内核架构的精髓。

这里再扣个细节，较个真(就是我个人的一点想法)。

Mark Richards 在 《Software Architecture Patterns》的微内核章节里面提到

The core system of the microkernel architecture pattern traditionally contains only the minimal functionality required to make the system operational.

从字面意义来看，Mark 认为核心系统指的是可以独立运行且提供基本功能的最小模块。

例如 vscode、idea、chrome 等设计就符合 Mark 认为的核心设计，核心系统提供基础必备的功能，可以独立运行。

像 vscode 核心就是编辑器，没有插件也可以独立运行，然后又有丰富的插件，来满足一些特殊需求，扩展核心系统的功能。

这里可能会让人产生误导，认为核心必须是能让系统运行的最小功能模块。

我认为核心不一定需要独立运行且提供基础功能，能让系统运行的最小组织模块也是核心。

两个说法的差别在于：只有核心的话系统能否正常的运行。

vscode 没有插件照样能运行，能提供基本功能，而小霸王游戏机没有游戏片那运行个寂寞，玩个球。

但是小霸王这种难道就不算微内核了嘛?

就我个人而言，把变与不变区分出来，把变化封装成插件就称为微内核设计。

像 Dubbo 能支持很多协议、各种负载均衡的扩展、集群的扩展等等，它自身的一些功能也是通过扩展点实现的，没有插件也跑不了。

这样的内核就像胶水，把各个插件结合起来最终提供服务，没有插件这个系统就没什么意义。

所以我认为核心系统不一定需要能独立运行，能让系统运行的最小组织模块也是核心。。

因此我觉得 Mark 说的不太准确，容易产生误导。

当然这是文字上面的抠细节，核心概念都是一致的：抽象出核心，剥离变化为插件。

这里的微内核指的是广义的微内核。

作为一个框架或者软件，扩展性非常的重要。

因为一个框架、一个软件的使用者千千万，不同的人有不同的需求。

身为框架的维护者、软件的开发者你有精力和能力满足所有用户的需求?

做梦，不存在的。

来感受一下?

所以做一个框架或者软件，想要让更多人使用，不仅自身提供的功能要全、性能要好、使用要简单，让用户 DIY，做各种定制化也非常的关键!

Dubbo 的成功其实就离不开它的微内核设计，定制化开发在很多场景都要用到，毕竟都得稍加改造一番来满足自己公司的一些特殊需求。

微内核看起来是很方便，但是设计起来就不方便了。

需要精心的设计，抽象出各种扩展点。

除了本身的功能还需要管理插件的生命周期、插件如何连接、如何通信等。

有些还需要做沙箱隔离，防止插件污染整个系统等等，本来的内部函数调用变成了插件间的通信，反正设计起来是复杂了。

一般微内核适合用在框架的设计上，或者一些规则引擎的设计，只有复杂的会有很多变化的需求场景才需要用到微内核。

像一般简单的项目，本来就一条直道走到底的那种就算了，不要瞎操作，等下秀折了腿。

微内核其实就是一种架构思想，可以是框架层面的，也可以细化到某个模块的设计。

归根结底就是把变化封装成插件，可插拔，拥抱变化。

当然今天也提到了操作系统的微内核，这个和广义上的微内核还是不太一样的。

至于 Dubbo 的微内核就离不开它的 SPI，之后文章会深入写一波，等我哈。