一 背景

最近在讨论产品架构时，提到了微内核架构设计。之前对这个概念有过了解，但没有深入研究。借此机会对微内核架构做一次相对系统、全面的了解，作为架构知识储备。

二 概念与来源

2.1 概念

提起微内核架构，有些朋友可能还不太熟悉，但如果说它的另一个名字：插件化(Plug-in)架构，估计就会有很多人恍然大悟，或者直呼：“这不是我们每天都在用的吗？”。

的确，我们常用的从 IDE 到框架：Eclipse、IntelliJ IDEA、SPI 等，插件化架构设计的比比皆是。但如果深入一些，能够把插件化架构阐述清楚，并能够借鉴思想，对我们在做的工作进行优化，尤其是在架构设计上并不简单。

2.2 来源

微内核设计其实就是插件体系。我们都知道，操作系统内核诞生得比较早，所以插件化最早被用在内核设计上，于是就有了微内核设计这一称呼。—— 内容来自 阿里技术，文章：什么是微内核架构设计。

根据百科中对内核的描述：内核，是一个操作系统的核心。是基于硬件的第一层软件扩充，提供操作系统的最基本的功能，是操作系统工作的基础，它负责管理系统的进程、内存、设备驱动程序、文件和网络系统，决定着系统的性能和稳定性。内核的分类可分为单内核和双内核以及微内核。

微内核（Micro kernel）是提供操作系统核心功能的内核的精简版本，它设计成在很小的内存空间内增加移植性，提供模块化设计，以使用户安装不同的接口，如 DOS、Workplace OS、Workplace UNIX 等。IBM、Microsoft、开放软件基金会(OSF)和 UNIX 系统实验室(USL)、鸿蒙 OS 等新操作系统都采用了这一研究成果的优点。

与微内核相对应的一个概念是宏内核，宏内核是包含很多功能的底层程序，干的事情很多，且不可插拔；一点微小的修改都可能会影响到整个内核，典型的”牵一发而动全身“。Linux 就是宏内核，也因此被称为 monolithic OS。

微内核只负责最核心的功能，其他功能都是通过用户态独立进程以插件方式加入进来的，微内核负责进程的管理、调度和进程之间通讯，从而完成整个内核需要的功能。当某个功能出现问题时，由于该功能是以独立进程方式存在的，所以不会对其他进程有什么影响从而导致内核不可用，最多就是内核某一功能现在不可用而已。

扯远了，再回到本文内容。因为是作为一种架构设计模式，所以只是沿用操作系统中的概念，方便定制，而且非常小，可以实现功能的热替换或者在线更新等，这就是微内核被提出来的核心需求。

三 微内核架构设计

3.1 溯源

微内核架构设计（Microkernel Architecture Style）这个关键词，百度中可查到的基本都是转载，或阿里技术公众号发布的文章。搜索了一些词之后，最终定位到《Fundamentals of Software Architecture》这本书，Chapter 12. Microkernel Architecture Style这篇文章中摘录了关于微内核架构风格的部分内容，某 SDN 上的文章，有不少都是基于原英文内容的翻译。

3.2 微内核架构风格-拓扑结构

从下图可见，微内核架构的拓扑结构由两部分组件组成：核心系统（core system）和插件模块（plug-in modules）。应用逻辑被分割为独立的插件模块和核心系统，提供了可扩展性、灵活性、功能隔离和自定义处理逻辑的特性。

3.3 设计关键

微内核架构的核心问题：插件管理、插件连接和插件通信。

1. 插件管理

核心系统需要知道当前有哪些插件可用，如何加载这些插件，什么时候加载插件。常见的实现方法是插件注册表机制。

核心系统提供插件注册表（可以是配置文件，也可以是代码，还可以是数据库），插件注册表含有每个插件模块的信息，包括它的名字、位置、加载时机（启动就加载，还是按需加载）等。

2. 插件连接

插件连接指插件如何连接到核心系统。通常来说，核心系统必须制定插件和核心系统的连接规范，然后插件按照规范实现，核心系统按照规范加载即可。

常见的连接机制有 OSGi（Eclipse 使用）、消息模式、依赖注入（Spring 使用），甚至使用分布式的协议都是可以的，比如 RPC 或者 HTTP Web 的方式。

3. 插件通信

插件通信指插件间的通信。虽然设计的时候插件间是完全解耦的，但实际业务运行过程中，必然会出现某个业务流程需要多个插件协作，这就要求两个插件间进行通信。由于插件之间没有直接联系，通信必须通过核心系统，因此核心系统需要提供插件通信机制。这种情况和计算机类似，计算机的 CPU、硬盘、内存、网卡是独立设计的配件，但计算机运行过程中，CPU 和内存、内存和硬盘肯定是有通信的，计算机通过主板上的总线提供了这些组件之间的通信功能。微内核的核心系统也必须提供类似的通信机制，各个插件之间才能进行正常的通信。