操作系统微内核和Dubbo微内核,有何不同?

你好,我是 yes。

在之前的文章已经提到了 RPC 的核心,想必一个 RPC 通信大致的流程和基本原理已经清晰了。

这篇文章借着 Dubbo 来说说微内核这种设计思想,不会扯到 Dubbo 某个具体细节实现上,和 Dubbo 强相关的内容会在之后的文章写到。

所以今天的重点在微内核,而这个概念我最早是从操作系统那里得知,不过操作系统的微内核和 Dubbo 相关的微内核又不太一样。

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

这么说你肯定不清楚,别急,听我慢慢道来。

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

操作系统微内核和Dubbo微内核,有何不同?

操作系统中的微内核

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

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

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

Linux 就是宏内核架构。

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

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

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

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

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

操作系统微内核和Dubbo微内核,有何不同?

宏内核中的一些功能在微内核架构上都被独立到用户态中,这样内核代码量就少了,代码少了潜在的 bug 就少,出了问题也更容易排查。

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

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

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

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

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

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

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

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

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

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

操作系统微内核和Dubbo微内核,有何不同?

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

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

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

操作系统微内核和Dubbo微内核,有何不同?

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

安德鲁教授看到了 Linux ,然后在 comp.os.Minix 上批评道:宏内核的设计有害的,Linux 内核耦合度太高,完全是为了 Intel 80386 而设计的,处理器架构进化很快的,操作系统应该都具备可移植性。

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

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

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

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

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

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

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

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

操作系统微内核和Dubbo微内核,有何不同?

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

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

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

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

Dubbo 中的微内核

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

操作系统微内核和Dubbo微内核,有何不同?

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

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

操作系统微内核和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 说的不太准确,容易产生误导。

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

微内核设计的好处

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

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

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

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

做梦,不存在的。

有些 idea 你想都想不到。

比如我之前看到的 vscode 里面有个「坤坤鼓励师」插件,默认你代码写一小时之后蔡徐坤来给你跳鸡你太美,让你休息休息......

操作系统微内核和Dubbo微内核,有何不同?

来感受一下?

操作系统微内核和Dubbo微内核,有何不同?

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

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

当然也不是什么都要微内核

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

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

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

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

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

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

最后

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

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

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

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

更多文章可看我的文章汇总:https://github.com/yessimida/yes 欢迎 star !

操作系统微内核和Dubbo微内核,有何不同?

我是 yes,从一点点到亿点点,欢迎在看、转发、留言,我们下篇见。

巨人的肩膀

https://en.wikipedia.org/wiki/Microkernel
https://en.wikipedia.org/wiki/Tanenbaum–Torvalds_debate
《Software Architecture Patterns》

文章归发布者所有。发布者:步入,转载请注明出处:https://www.anyitu.com

如该内容侵犯您的权利,请及时联系我们

微信公众号