微内核架构设计

微内核设计其实就是插件体系。我们都知道，操作系统内核诞生得比较早，所以插件化最早被用在内核设计上，于是就有了微内核设计这一称呼。

微内核是这样一种内核：它只完成内核不得不完成的功能，包括时钟中断、进程创建与销毁、进程调度、进程间通信，而其他的诸如文件系统、内存管理、设备驱动等都被作为系统进程放到了用户态空间。说白了，微内核是相对于宏内核而言的，像Linux就是典型的宏内核，它除了时钟中断、进程创建与销毁、进程调度、进程间通信外，其他的文件系统、内存管理、输入输出、设备驱动管理都需要内核完成。

也就是说，微内核是相对宏内核而言的，宏内核是一个包含非常多功能的底层程序，也就是我们现在讲的Monolith。它干的事情非常多，而且不是可插拔的，修改一些小的功能，都会涉及到整个程序的重新编译等，比如一个功能出现了一个小bug，可能导致整个内核都出问题。这也是很多人将Linux称为monolithic OS的原因。而微内核只负责最核心的功能，其他功能都是通过用户态独立进程以插件方式加入进来，然后微内核负责进程的管理、调度和进程之间通讯，从而完成整个内核需要的功能。基本一个功能出现问题，但是该功能是以独立进程方式存在的，不会对其他进程有什么影响从而导致内核不可用，最多就是内核某一功能现在不可用而已。

微内核就是一个运行在最高级别的程序片段，它能完成用户态程序不能完成的一些功能。微内核通过进程间通信来协调各个系统进程间的合作，这就需要系统调用，而系统调用需要切换堆栈以及保护进程现场，比较耗费时间；而宏内核则是通过简单的函数调用来完成各个模块之间的合作，所以理论上宏内核效率要比微内核高。这个和微服务的架构设计一样，我们将Monolith应用划分为多个小应用后，系统的设计就变得比较复杂了，之前都是应用内部函数调用，现在要涉及网络通讯、超时等问题，同时响应时间会被拉长。

聊到这里，相信大家对微内核和宏内核已经有了一个大致的了解，看起来各有千秋。但是宏内核有一个最大的问题就是定制和维护陈本。现在的移动设备和IoT设备越来越多，如果要把一个庞大复杂的内核适配到某一设备上，是一件非常复杂的事情，如果很简单的话，那么把Linux内核适配到Android内核，甚至到Tesla等车载系统，基本上人人都可以做了。

因此我们更需要一个微内核的架构设计，方便定制，而且非常小，可以实现功能的热替换或者在线更新等，这就是微内核被提出来的核心需求。但是微内核有一个运行的效率问题，所以在微内核和宏内核之间，又有了Hybrid内核，主要是想拥有微内核的灵活性，同时在关键点上有宏内核的性能。微内核设计在理论上确实有效率问题，但是随着芯片设计、硬件性能提升等，这方面或许已经有了非常大的提升，已经不再是最关键的问题。