一背景
最近在讨论产品架构时，提到了微内核架构设计。之前对这个概念有过了解，但没有深入研究。借此机会对微内核架构做一次相对系统、全面的了解，作为架构知识储备。
2.1概念
提起微内核架构，有些朋友可能还不太熟悉，但如果说它的另一个名字：插件化(Plug-in)架构，估计就会有很多人恍然大悟，或者直呼：“这不是我们每天都在用的吗？”。
的确，我们常用的从IDE到框架：Eclipse、IntelliJ IDEA、SPI等，插件化架构设计的比比皆是。但如果深入一些，能够把插件化架构阐述清楚，并能够借鉴思想，对我们在做的工作进行优化，尤其是在架构设计上并不简单。
微内核设计其实就是插件体系。我们都知道，操作系统内核诞生得比较早，所以插件化最早被用在内核设计上，于是就有了微内核设计这一称呼。—— 内容来自 阿里技术，文章：什么是微内核架构设计。
根据百科中对内核的描述：内核，是一个操作系统的核心。是基于硬件的第一层软件扩充，提供操作系统的最基本的功能，是操作系统工作的基础，它负责管理系统的进程、内存、设备驱动程序、文件和 络系统，决定着系统的性能和稳定性。内核的分类可分为单内核和双内核以及微内核。
微内核（Micro kernel）是提供操作系统核心功能的内核的精简版本，它设计成在很小的内存空间内增加移植性，提供模块化设计，以使用户安装不同的接口，如DOS、Workplace OS、Workplace UNIX等。IBM、Microsoft、开放软件基金会(OSF)和UNIX系统实验室(USL)、鸿蒙OS等新操作系统都采用了这一研究成果的优点。
与微内核相对应的一个概念是宏内核，宏内核是包含很多功能的底层程序，干的事情很多，且不可插拔；一点微小的修改都可能会影响到整个内核，典型的”牵一发而动全身“。Linux就是宏内核，也因此被称为monolithic OS。
微内核只负责最核心的功能，其他功能都是通过用户态独立进程以插件方式加入进来的，微内核负责进程的管理、调度和进程之间通讯，从而完成整个内核需要的功能。当某个功能出现问题时，由于该功能是以独立进程方式存在的，所以不会对其他进程有什么影响从而导致内核不可用，最多就是内核某一功能现在不可用而已。
三微内核架构设计
3.1溯源
3.2微内核架构风格-拓扑结构
从下图可见，微内核架构的拓扑结构由两部分组件组成：核心系统（core system）和插件模块（plug-in modules）。应用逻辑被分割为独立的插件模块和核心系统，提供了可扩展性、灵活性、功能隔离和自定义处理逻辑的特性。
3.3设计关键
微内核架构的核心问题：插件管理、插件连接和插件通信。
1. 插件管理
核心系统需要知道当前有哪些插件可用，如何加载这些插件，什么时候加载插件。常见的实现方法是插件注册表机制。
核心系统提供插件注册表（可以是配置文件，也可以是代码，还可以是数据库），插件注册表含有每个插件模块的信息，包括它的名字、位置、加载时机（启动就加载，还是按需加载）等。
2. 插件连接
插件连接指插件如何连接到核心系统。通常来说，核心系统必须制定插件和核心系统的连接规范，然后插件按照规范实现，核心系统按照规范加载即可。
常见的连接机制有 OSGi（Eclipse 使用）、消息模式、依赖注入（Spring 使用），甚至使用分布式的协议都是可以的，比如 RPC 或者 HTTP Web 的方式。
3. 插件通信
插件通信指插件间的通信。虽然设计的时候插件间是完全解耦的，但实际业务运行过程中，必然会出现某个业务流程需要多个插件协作，这就要求两个插件间进行通信。由于插件之间没有直接联系，通信必须通过核心系统，因此核心系统需要提供插件通信机制。这种情况和计算机类似，计算机的 CPU、硬盘、内存、 卡是独立设计的配件，但计算机运行过程中，CPU 和内存、内存和硬盘肯定是有通信的，计算机通过主板上的总线提供了这些组件之间的通信功能。微内核的核心系统也必须提供类似的通信机制，各个插件之间才能进行正常的通信。
常见的微内核具体实现有两种，一种是 OSGi，另一种是规则引擎，我们一一来进行分析。
四 OSGi架构
4.1 关于OSGi
OSGi（Open Services Gateway initiative），即：开放服务 关协议，是 Java 动态化模块化系统的一系列规范。OSGi 一方面指维护 OSGi 规范的 OSGI 官方联盟，另一方面指的是该组织维护的基于 Java 语言的服务（业务）规范。简单来说，OSGi 可以认为是 Java 平台的模块层。OSGi 服务平台向 Java 提供服务，这些服务使 Java 成为软件集成和软件开发的首选环境。OSGi 技术提供允许应用程序使用精炼、可重用和可协作的组件构建的标准化原语，这些组件能够组装进一个应用和部署中。
4.2 OSGi的两种含义
OSGi 一方面指 OSGi Alliance 组织，另一方面指 OSGi Alliance 制定的一个基于 Java 语言的服务规范——OSGi 服务平台。
4.2.1 OSGiAlliance
4.2.2 OSGi规范
这个规范的核心是一个框架，定义了应用程序的生命周期模式和服务注册。基于这个框架定义了大量的 OSGi 服务：日志、配置管理、偏好，HTTP（运行 servlet）、XML 分析、设备访问、软件包管理、许可管理、星级、用户管理、IO 连接、连线管理、Jini 和 UPnP 等等。从这个角度来说，我们可以理解为 OSGi 技术提供了一种面向服务的架构，它能使这些组件动态地发现对方，以达到低耦合，且耦合度可管理的效果。
特点：
- 可以动态加载、更新和卸载模块而不用停止服务
- 实现系统的模块化、版本化，允许多版本 bundule 同时服务
- Service model 允许模块/插件相互依赖但松耦合，分享服务更简单
4.3 OSGi框架
4.3.1 OSGi的架构
由模型（Module）、生命周期（Lifecycle）、服务层（Service）三层组成，逻辑架构图结构如下：
4.3.2模块（Module）
模块层实现插件管理功能。OSGi 中的插件被称为 Bundle，每个 Bundle 是一个 Java 的 JAR 文件，每个 Bundle 里面都包含一个元数据文件 MANIFEST.MF，这个文件包含了 Bundle 的基本信息。例如，Bundle 的名称、描述、开发商、classpath，以及需要导入的包和输出的包等，OSGi 核心系统会将这些信息加载到系统中用于后续使用。
4.3.3生命周期（Lifecycle）
这一层实现了插件连接功能，提供执行时模块管理，以及模块对底层 OSGi 框架的访问。生命周期层精确地定义了 Bundle 生命周期的操作（安装、更新、启动、停止、卸载），Bundle 必须按照规范实现各个操作。
4.3.4服务层（Service）
服务层实现插件通信功能。OSGi 提供了一个服务注册的功能，用于各个插件将自己能提供的服务注册到 OSGi 核心的服务注册中心，如果某个服务想用其他服务，可以直接在服务注册中心搜索可用服务。
五 规则引擎架构简述
5.1 简析
规则引擎从结构上来看，也属于微内核架构的一种具体实现，其中执行引擎可以看作是微内核，执行引擎解析配置好的业务流，执行其中的条件和规则，通过这种方式来支持业务的灵活多变。
规则引擎在计费、保险、促销等业务领域有广泛的应用，能够很灵活地应对复杂规则场景的需求，主要原因：
- 易扩展：规则引擎使业务逻辑实现与业务系统分离，可以在不改动业务系统的情况下扩展新的业务功能；
- 易理解：规则通过自然语言描述，业务人员易于理解和操作；如果是代码，只有研发人员才能理解和执行开发；
- 高效：规则引擎系统提供可视化的规则定制、审批、查询及管理，方便业务人员快速配置新的业务。
5.2实现流程
- 开发人员将业务功能分解、提炼为多个规则，存储在规则库；
- 业务人员根据业务需要，通过将规则排列组合，配置成业务流程，保存在业务库；
- 规则引擎执行业务流程实现业务功能。
5.3规则引擎架构
图片来自文章：《阿里架构师一文详解微内核架构》
声明：本站部分文章及图片源自用户投稿，如本站任何资料有侵权请您尽早请联系jinwei@zod.com.cn进行处理,非常感谢！