architecture-paradigm-microkernel

微内核（插件）架构范式

适用场景

• 构建具有插件架构的可扩展系统
• 需要针对特定客户进行定制的产品

不适用场景

• 无需插件扩展能力的单体应用
• 所有功能在设计上都是核心功能且紧密耦合的系统

何时采用此范式

• 构建平台、集成开发环境（IDE）、数据摄取管道或第三方需要扩展核心功能的市场时。
• 核心系统需要极高的稳定性，而扩展和功能必须快速演进和变化时。
• 隔离可选依赖项并对插件提供的不可信代码进行沙箱处理至关重要时。

采用步骤

1. 定义核心服务：明确划分微内核的最低限度职责，例如调度、组件生命周期管理、核心领域基本元素和消息传递。
2. 指定插件契约：设计并记录所有插件的正式契约，包括注册流程、能力描述符、生命周期钩子（例如，启动、停止）和权限模型。
3. 构建扩展加载器和沙箱：实现加载扩展、执行版本兼容性检查、协商能力以及隔离插件的机制，以防止故障扩散。
4. 提供软件开发工具包（SDK）：为便于开发插件，提供包含项目模板、测试工具和兼容性检查工具的 SDK。
5. 管理发布流程：维护核心版本与插件版本之间清晰的兼容性矩阵。实施自动化回归测试套件，使用各种插件验证核心功能。

关键交付物

• 一份架构决策记录（ADR），描述核心与插件之间的职责划分，以及插件开发和认证的治理模型。
• 正式的安全和权限模型文档，详细说明插件可使用的能力。
• 一条自动化插件验证流水线，用于执行代码检查、运行测试，并在沙箱环境中执行插件。

风险与缓解措施

• 插件数量失控：
  • 缓解措施：如果没有筛选流程，支持大量插件的维护成本可能变得难以承受。对所有第三方插件实施正式认证流程或类似市场的审核机制。
• 核心与插件之间的版本偏差：
  • 缓解措施：严格对核心和插件使用语义化版本控制（SemVer）。必要时提供抽象层或“垫片”，以保持与旧版插件的向后兼容性。
• 核心系统膨胀：
  • 缓解措施：人们往往会施压，要求将功能逻辑添加到稳定的核心中。应坚决抵制这种诱惑。核心应保持精简，并尽可能将新功能实现为插件。

具体组件

此范式的实现通常包含的工具和抽象的术语。它们不是依赖项，也不是 tools: 前置元数据。

• plugin-loader：在运行时发现、验证并激活插件
• sandbox-executor：在隔离环境中运行每个插件，并限制其可用能力
• sdk-generator：根据内核稳定的接口生成特定语言的 SDK

退出标准

• 一份 ADR 记录了微内核的最小职责、插件契约（注册、能力描述符、生命周期钩子）和权限模型。
• 在开始开发任何第三方插件之前，必须提供正式的插件 SDK 或规范（模板、测试工具、兼容性检查器）。
• 自动化插件验证流水线（lint、测试、沙盒执行）已投入运行，并作为插件认证的门槛。
• 已发布核心版本与受支持的插件 API 版本之间的兼容性矩阵，并在核心插件契约发生变更时及时更新。