微内核架构的理解

news2025/1/31 8:03:43

什么是微内核架构

相信大家都听说过微内核架构，也或多或少做过一些类似于微内核架构的设计，为了可以更好的设计出微内核的架构，我们了解下什么是微内核架构。

说到微内核架构，大家首先会想到的是Eclips、IDEA、OSGI、Spring Plugin、SPI等，这些都是我们熟知的微内核架构。有了微内核架构，我们可以更好的定制和控制流程，所以微内核架构的设计思想经常在做配置化中台项目的方案中出现的。

微内核架构实现主要是插件化思想（Plug-in），是一套插件体系，最早的插件化方法是应用在操作系统之上，久而久之就有了微内核设计这一思想。

了解微内核，需要先了解这个“内核”。

在操作系统中，内核围绕于操作系统的核心功能，比如时钟中断、进程创建与销毁、进程调度、进程间通信等内核态的动作。而文件系统、内存管理、设备驱动等都被视为非内核能力，这部分会被放在用户态空间。

微内核是相对于宏内核而言，宏内核包含了很多的底层程序功能，做的事情非常多，而且不是可拔插的，修改任意一个功能点，都需要整个程序联动，而且有可能引入一个bug，导致整个内核不可用，类似于一个功能复杂的单体系统，每次变更和交付成本都非常高，风险也非常大。

而微内核只围绕于核心功能设计，他的功能实现都是相互独立的，其他非核心功能是通过用户态的独立进程以插件的方式加入进来的，微内核引擎负责管理进程、调度进程、进程之间通信。某一个功能出现问题时，由于其是独立的进程，不会对其他进程产生影响，也不会导致内核不可用。

微内核中，多个进程协调通信，需要进行系统调用，系统调用需要切换堆栈及保护进程现场，过程比较耗时。宏内核（也就是用户态）中，是通过函数调用完成各个模块之间合作，所以宏内核较微内核效率更高。

通过操作系统微内核概念，可以类比到业务系统。一个系统，特别是经过微服务拆分之后的系统，都会服务于某个“内核”，多个核心功能通过微服务的方式拆分，服务之间通过通信交换数据。通过微内核解决了快速交付问题，实现了代码隔离，控制风险点的目的。

而考虑到扩展性，我们需要定义出内核的骨架，并开放出plugin，以实现个性化扩展。这样的微内核架构，我们可以便于定制，改动小，进而实现热更新，这也是微内核架构的主要价值。

微内核架构设计

在微内核架构中有两个核心组件：系统内核、插件化组件。

系统内核：主要解决的是内核的核心功能，比如插件的注册与管理、插件生命周期管理、插件之间通信、插件的热加载与替换。

结构如下：

基于微内核的插件化设计，我们可以实现组件隔离，每个插件可以以独立jar包或独立进程运行，这些插件组件进程可以独立部署在分布式网络上，实现水平扩展，某种程度就像我们的微服务治理体系，有独立部署的微服务进程，也有中心治理的注册中心与配置中心。

在操作系统中，微内核与宏内核通信方式上有如下区别：

微内核架构下，组件之间的通信也是基于消息的，比如每个组件对于消息处理有两个能力：收（receive）、发（send）。

那两个进程之间通信，是否需要一个三方中介呢？比如这样：

在操作系统中，消息的通信是基于内核转发的，也就是我们经常听说的消息总线架构，内核负责协调各个进程的通信，比如进程A想要发送消息给进程B，需要知道B对应的内存地址。进程向内核发送消息，内核再将消息发送给对应的接收进程，这就是一个总线通信过程。

在很多微内核架构设计实现上，组件之间都可以通过EventBus实现Plug-in之间的解耦，也就是借鉴了总线的设计。

在微服务架构的通信实现上，在SOA时代，有类似于消息总线的概念。但微服务是进程之间的直接调用，没有了这个所谓的总线。

但是如果引入了一个中心化的服务注册与发现中心，就可能也会有个所谓的内核中转：

在插件化系统中，组件之间不直接通信，而是借助于一个中心化的内核系统进行转发。这种设计思想非常类似于操作系统的内核转发实现，插件之间隔离、透明。某个组件下线或替换，其他组件不需要感知。

这样的架构会存在于一些其他的问题。首先，这个中心化的转发中介变成了单点，其可用性严重影响了整个系统的可用性。当中心化系统变成单点转发，就存在对应的性能问题。

对于远程进程调用的性能优化，我们可以想到这几点：

采用高性能的二进制协议代替http1.x协议，因为http1.1的文本协议性能较差；
采用类似于零拷贝机制，实现快速网络包转发，而不需要做内核态与用户态的转换；
引入好的网络硬件，比如RDMA；好的协议，如UDP、QUIC等；
选择不同的通信方式，比如RPC的、Pub/Sub的、无序ACK的、单工/双工通信的等；

为了处理这么多协议的转发，内核系统需要具备Adapter以实现对于众多协议的解析与转发，比如引入多个filter来支持不同的协议，但是他将变得越来越复杂。

还有一种思路是，内核服务只支持一种协议，各个插件之间也基于这个协议通信，协议的适配与转换由各个组件自己做就可以。

其实很多人会想到，这个中心化的内核组件的消息转发不就是类似于一个MQ系统的Broker吗？而那种独立处理通信协议的组件不就类似于Mesh设计吗？

没错，前一种类似于类似于broker，后一种类似于service mesh或agent思想。功能上是一样的，只是处理逻辑上有些差异。

broker是集中式的，所有组件通过broker进行消息的收发，涉及到注册与发现机制。mesh是基于服务的注册与发现，消息发送需要找到对方的agent，再实现两个agent之间的通信。

broker方案设计核心在于，broker需要管理注册的服务、路由的管理、数据的采集等这些核心功能，类似于微内核的内核本身理念一样。如果要扩展整个微内核架构能力，需要编写独立的service，之后和broker对接，在broker接收消息，处理完毕后发送消息。

那中心的broker负载太高如何扩容呢？因为broker本身具有服务调用的数据采集能力，所以可以从这里采集，作为扩缩容的参考，经过分析后，可以调用k8s的api实现pod的扩缩容了。

我们可以发现，这套围绕于内核的核心设计以及扩展service的思想非常的云原生，比如上层业务系统想要调用存储服务，微内核系统可以对外提供一个消息存储的api，而这套api可以按需扩展是基于redis、还是tair或是其他kv，为服务标准化和可替代性提供了很好的基础，对上云操作非常友好，也就体现了云原生的灵活性。

中心化转发和点对点发送，两个方案各有优缺点，架构就是一个取舍的过程，我们需要结合自己系统的特点和体量决定选择合适的方案。