微内核插件架构从原理到实践

前言最近一段时间一直在参与一些SaaS产品的设计,发现SaaS主产品有90%的功能基本都是通用性,其中10%各个租户都会出现定制化,比如一些页面表单字段的差异化、业务规则差异化以及流程差异化等,这些差异化如果软件架构的可扩展性不够,很容易出现后期维护成本非常高 。其实技术发展到今天,软件架构设计有一个核心的理念一直没有不变,如何面的业务发展的不确定性快速实现,比如Nosql的出现为了弥补传统关系型数据库数据结构的不确定性,规则引擎的出现为了解决业务规则的不确定性 。今天同样面对SaaS产品各个租户的需求不确定性以及差异化,让我很容易到微内核插件架构设计,微内核插件架构设计是一种非常典型的架构设计模式 。
 
微内核架构本质上是为了提高系统的扩展性。所谓扩展性,是指系统在经历不可避免的变更时所具有的灵活性,以及针对提供这样的灵活性所需要付出的成本间的平衡能力 。也就是说,当在往系统中添加新业务时,不需要改变原有的各个组件,只需把新业务封闭在一个新的组件中就能完成整体业务的升级,我们认为这样的系统具有较好的可扩展性 。
 
就架构设计而言,扩展性是软件设计的永恒话题 。而要实现系统扩展性,一种思路是提供可插拔式的机制来应对所发生的变化 。当系统中现有的某个组件不满足要求时,我们可以实现一个新的组件来替换它,而整个过程对于系统的运行而言应该是无感知的,我们也可以根据需要随时完成这种新旧组件的替换 。
微内核插件架构在正式介绍微内核插件架构之前,先介绍一下什么是内核以及内核分类 。
百度百科是这样介绍内核:
内核,是一个操作系统的核心 。是基于硬件的第一层软件扩充,提供操作系统的最基本的功能,是操作系统工作的基础,它负责管理系统的进程、内存、设备驱动程序、文件和网络系统,决定着系统的性能和稳定性 。内核的分类可分为单内核和双内核以及微内核 。
 
微内核(Micro kernel)是提供操作系统核心功能的内核的精简版本,它设计成在很小的内存空间内增加移植性,提供模块化设计,以使用户安装不同的接口,如 DOS、Workplace OS、Workplace UNIX 等 。IBM、Microsoft、开放软件基金会(OSF)和 UNIX 系统实验室(USL)、鸿蒙 OS 等新操作系统都采用了这一研究成果的优点 。
 
与微内核相对应的一个概念是宏内核,宏内核是包含很多功能的底层程序,干的事情很多,且不可插拔;一点微小的修改都可能会影响到整个内核,典型的”牵一发而动全身“ 。linux 就是宏内核,也因此被称为 monolithic OS 。Linux除了时钟中断、进程创建与销毁、进程调度、进程间通信外,其他的文件系统、内存管理、输入输出、设备驱动管理都需要内核完成,其中的文件系统、内存管理、设备驱动等都被作为系统进程放到了用户态空间,属于可扩展插件部分 。
 
微内核只负责最核心的功能,其他功能都是通过用户态独立进程以插件方式加入进来的,微内核负责进程的管理、调度和进程之间通讯,从而完成整个内核需要的功能 。当某个功能出现问题时,由于该功能是以独立进程方式存在的,所以不会对其他进程有什么影响从而导致内核不可用,最多就是内核某一功能现在不可用而已 。
 
微内核架构(Microkernel Architecture),也被称为插件式架构(plug-in architecture),作为一个在几十年前就被创建出来的架构模式,它如今仍然被广泛应用在各个领域中 。从组成结构上讲, 微内核架构包含两部分组件:内核系统和插件。这里的内核系统通常提供系统运行所需的最小功能集,而插件是独立的组件,包含自定义的各种业务代码,用来向内核系统增强或扩展额外的业务能力 。
 
微内核架构由以下两部分组成:核心系统(core system)和插件(plug-in component),将应用系统的业务逻辑拆分成核心系统和插件,能够提供很好的可扩展性和灵活性,极大地方便了后续需求的新增和修改 。

微内核插件架构从原理到实践

文章插图
 
核心模块只拥有能使应用运行的最小功能逻辑 。许多操作系统使用微内核系统架构,这就是该结构的名字由来 。从业务应用的角度,核心系统通常定义了一般商务逻辑,不包含特殊情况、特殊规则、复杂的条件的特定处理逻辑 。
 
插件模块是独立存在的模块,包含特殊的处理逻辑、额外的功能和定制的代码,能拓展核心系统业务功能 。通常,不同的插件模块互相之间独立,但是你可以设计成一个插件依赖于另外一个插件的情况 。最重要的是,你需要让插件之间的互依赖关系降低到最小,为避免繁杂的依赖问题 。


推荐阅读