简述

微内核架构（Microkernel Architecture）也被称为插件化架构（Plug-in Architecture），是一种面向功能拆分的可扩展性架构，通常用于实现基于产品（product-based：有多个版本，需要下载、安装才能使用；与 web-based 对应）的应用。它的本质是将变化部分封装在插件里，从而在不影响系统稳定的情况下，灵活、快速的扩展系统功能。

基本架构

微内核架构包含两类组件：

• 核心系统（Core System）
  • 功能：负责和业务无关的通用功能（模块加载、模块间通信等）
  • 特点：通常比较稳定，不会因为业务变动而修改
• 插件模块（Plug-in Modules）
  • 功能：负责实现具体业务逻辑
  • 特点：可以根据业务需求变更不断扩展

核心系统设计关键点

1. 插件管理
   • 核心功能：插件注册表
     • 包含插件信息、加载机制等功能
2. 插件连接
   • 核心功能：插件与核心系统的连接管理
     • 常见机制如：OSGi（开放服务网关倡议）、消息模式、依赖注入、分布式协议（HTTP、RPC）等
3. 插件通信
   • 核心功能：插件间通信

OSGi

OSGi（Open Service Gateway Initiative：开放服务网关倡议） 初始目标是构建一个在广域网和局域网或设备上展开业务的基础平台（针对嵌入式）。但由于其具备动态化、热插拔、高可复用性、高效性、高扩展性等特点，其在 PC 端应用开发上具备天然优势。在 Eclipse 采用 OSGi标准后（Equinox 框架），OSGi 就称为了首选的插件化标准。

逻辑架构

1. 模块层（Module）
   • 功能：插件管理
     • 在 OSGi 中定义为 Bundle
2. 生命周期层（Lifecycle）
   • 功能：插件连接
     • 精确的插件安装、更新、启动、停止、卸载等操作
3. 服务层（Service）
   • 功能：插件通信
     • 插件将自己提供的服务注册（非插件注册）到注册中心，插件想用服务可以直接在注册中心搜索可用服务

规则引擎

• 应用场景
  • 计费、保险、促销（满100减50，3件7折等）等
• 概念
  • 是一种嵌入在应用程序中的组件
  • 实现了将业务决策从业务代码中分离出来，并使用预定义规则语言来编写业务决策
  • 接受数据输入， 解释业务规则，根据规则做出业务决策
• 特点
  • 可扩展（可以在不改动业务代码的前提下扩展业务）
  • 易理解（通过自然语言描述，非程序员也可以理解）
  • 高效率（一般提供可视化规则制定、审批、查询、管理等功能）

规则引擎与微内核

规则引擎中的引擎即微内核中的系统核心，规则则为插件。

• 插件管理
  • 规则管理
• 插件连接
  • 规则语言
• 插件通信
  • 数据流、事件流 （规则负责输出、引擎负责传递到下一个规则）

HarmonyOS & Android & Linux

宏内核（Monolithic Kernel） & 微内核（Microkernel）

宏内核

• 核心特点
  • 整个内核程序是一个单一的二进制执行文件
  • 在内核态以监管者模式运行
  • 用户服务、内核服务运行在同一个地址空间中（内核统一管理）
• 优点
  • 执行速度快（系统调用快：都在同一个空间）
• 缺点
  • 一个核心模块崩溃，可能导致整体崩溃
  • 扩展性差（改一个功能，可能需要修改多个模块）
• 常见宏内核系统
  • Linux、BSDs 等

微内核

• 核心特点
  • 核心功能模块化，各种运行在独立的资源环境下
  • 只有需要绝对特权的服务（进程管理、内存管理、进程间通信等），才能在特权模式下运行，其余的都在用户空间运行
  • 用户服务、内核服务运行在不同的地址空间中
• 优点
  • 设计简单：只有需要绝对特权的服务（进程管理、内存管理、进程间通信等），才能在特权模式下运行，其余的都在用户空间运行
  • 减少耦合度：服务各自独立，有利于实现、调试、移植
  • 健壮：避免某核心模块奔溃导致整体崩溃的问题
• 缺点
  • 模块间通信（IPC）压力大（性能相较宏内核差）
• 常见微内核系统
  • 鸿蒙、Fuchsia 等

HarmonyOS

内核：微内核

1. 内核层
   • 内核子系统：HarmonyOS 采用多内核设计，支持针对不同资源受限设备选用适合的 OS 内核。
     • 内核抽象层（KAL，KernelAbstract Layer）通过屏蔽多内核差异，对上层提供基础的内核能力，包括进程/线程管理、内存管理、文件系统、网络管理和外设管理等
   • 驱动子系统：HarmonyOS 驱动框架（HDF）是 HarmonyOS 硬件生态开放的基础，提供统一外设访问能力和驱动开发、管理框架
2. 系统服务层
   • 系统服务层是HarmonyOS的核心能力集合，通过框架层对应用程序提供服务
     • 系统基本能力子系统集：为分布式应用在 HarmonyOS 多设备上的运行、调度、迁移等操作提供了基础能力，由分布式软总线、分布式数据管理、分布式任务调度、方舟多语言运行时、公共基础库、多模输入、图形、安全、AI等子系统组成。其中，方舟运行时提供了 C/C++/JS 多语言运行时和基础的系统类库，也为使用方舟编译器静态化的 Java 程序（即应用程序或框架层中使用 Java 语言开发的部分）提供运行时
     • 基础软件服务子系统集：为 HarmonyOS 提供公共的、通用的软件服务，由事件通知、电话、多媒体、DFX、MSDP&DV 等子系统组成
     • 增强软件服务子系统集：为 HarmonyOS 提供针对不同设备的、差异化的能力增强型软件服务，由智慧屏专有业务、穿戴专有业务、IoT 专有业务等子系统组成
     • 硬件服务子系统集：为 HarmonyOS 提供硬件服务，由位置服务、生物特征识别、穿戴专有硬件服务、IoT 专有硬件服务等子系统组成
3. 框架层
   • 框架层为 HarmonyOS 的应用程序提供了 Java/C/C++/JS 等多语言的用户程序框架和 Ability 框架，以及各种软硬件服务对外开放的多语言框架 API；同时为采用 HarmonyOS 的设备提供了 C/C++/JS 等多语言的框架 API，不同设备支持的 API 与系统的组件化裁剪程度相关
4. 应用层
   • 应用层包括系统应用和第三方非系统应用。HarmonyOS 的应用由一个或多个 FA（Feature Ability）或 PA（Particle Ability）组成。其中，FA 有 UI 界面，提供与用户交互的能力；而 PA 无 UI 界面，提供后台运行任务的能力以及统一的数据访问抽象。基于 FA/PA 开发的应用，能够实现特定的业务功能，支持跨设备调度与分发，为用户提供一致、高效的应用体验

安卓

内核：宏内核（8.0 开始引入模块化内核）

1. 应用框架
   • 应用框架最常被应用开发者使用。作为硬件开发者，您应该非常了解开发者 API，因为很多此类 API 都可以直接映射到底层 HAL 接口，并可提供与实现驱动程序相关的实用信息。
2. Binder IPC
   • Binder 进程间通信 (IPC) 机制允许应用框架跨越进程边界并调用 Android 系统服务代码，这使得高级框架 API 能与 Android 系统服务进行交互。在应用框架级别，开发者无法看到此类通信的过程，但一切似乎都在“按部就班地运行”
3. 系统服务
   • 系统服务是专注于特定功能的模块化组件，例如窗口管理器、搜索服务或通知管理器。应用框架 API 所提供的功能可与系统服务通信，以访问底层硬件。Android 包含两组服务：“系统”（诸如窗口管理器和通知管理器之类的服务）和“媒体”（与播放和录制媒体相关的服务）
4. 硬件抽象层 (HAL)
   • HAL 可定义一个标准接口以供硬件供应商实现，这可让 Android 忽略较低级别的驱动程序实现。借助 HAL，您可以顺利实现相关功能，而不会影响或更改更高级别的系统。HAL 实现会被封装成模块，并会由 Android 系统适时地加载。如需了解详情，请参阅硬件抽象层 (HAL)
5. Linux 内核
   • 开发设备驱动程序与开发典型的 Linux 设备驱动程序类似。Android 使用的 Linux 内核版本包含一些特殊的补充功能，例如低内存终止守护进程（一个内存管理系统，可更主动地保留内存）、唤醒锁定（一种 PowerManager 系统服务）、Binder IPC 驱动程序，以及对移动嵌入式平台来说非常重要的其他功能。这些补充功能主要用于增强系统功能，不会影响驱动程序开发。您可以使用任意版本的内核，只要它支持所需功能（如 Binder 驱动程序）即可

Google 的 Fuchsia（取代安卓？），也是采用了微内核架构（Zircon）。

参考资料
HarmonyOS 系统架构
安装架构