操作系统微内核和Dubbo微内核,有何不同?
你好,我是 yes。
在之前的文章已经提到了 RPC 的核心,想必一个 RPC 通信大致的流程和基本原理已经清晰了。
这篇文章借着 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 中的微内核
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 里面有个「坤坤鼓励师」插件,默认你代码写一小时之后蔡徐坤来给你跳鸡你太美,让你休息休息……
来感受一下?
所以做一个框架或者软件,想要让更多人使用,不仅自身提供的功能要全、性能要好、使用要简单,让用户 DIY,做各种定制化也非常的关键!
Dubbo 的成功其实就离不开它的微内核设计,定制化开发在很多场景都要用到,毕竟都得稍加改造一番来满足自己公司的一些特殊需求。
当然也不是什么都要微内核
微内核看起来是很方便,但是设计起来就不方便了。
需要精心的设计,抽象出各种扩展点。
除了本身的功能还需要管理插件的生命周期、插件如何连接、如何通信等。
有些还需要做沙箱隔离,防止插件污染整个系统等等,本来的内部函数调用变成了插件间的通信,反正设计起来是复杂了。
一般微内核适合用在框架的设计上,或者一些规则引擎的设计,只有复杂的会有很多变化的需求场景才需要用到微内核。
像一般简单的项目,本来就一条直道走到底的那种就算了,不要瞎操作,等下秀折了腿。
最后
微内核其实就是一种架构思想,可以是框架层面的,也可以细化到某个模块的设计。
归根结底就是把变化封装成插件,可插拔,拥抱变化。
当然今天也提到了操作系统的微内核,这个和广义上的微内核还是不太一样的。
至于 Dubbo 的微内核就离不开它的 SPI,之后文章会深入写一波,等我哈。
更多文章可看我的文章汇总:https://github.com/yessimida/yes 欢迎 star !
我是 yes,从一点点到亿点点,欢迎在看、转发、留言,我们下篇见。
巨人的肩膀
https://en.wikipedia.org/wiki/Microkernel
https://en.wikipedia.org/wiki/Tanenbaum–Torvalds_debate
《Software Architecture Patterns》