微内核架构是什么
微内核（插件化）架构把系统拆成稳定的核心与可变的插件两部分：核心只承载生命周期管理、注册发现、通信与契约定义等通用能力，业务差异以插件形式扩展。它适合规则与形态频繁变化的平台型产品，例如工作流引擎、IDE、网关过滤器链与规则引擎。代价是核心复杂度上升、插件质量参差不齐，因此契约版本策略、准入评审与沙箱隔离是这种架构的长期成本项。
基本信息
| 核心系统 | 生命周期、注册发现、通信、契约定义等稳定能力 |
|---|---|
| 插件 | 独立开发与部署的扩展单元，实现某个扩展点 |
| 契约 | 插件接口、数据格式与版本兼容策略是设计重心 |
| 注册机制 | 启动时扫描目录或按清单文件加载；单个插件失败不能拖垮内核 |
| 权限模型 | 插件声明所需能力（文件、网络、配置），内核按最小授权放行 |
扩展点设计步骤
- 识别稳定内核：把生命周期、注册发现与通信等通用能力收进核心
- 定义扩展点：接口签名、数据格式与版本兼容规则一并明确
- 登记插件清单：名称、版本、依赖版本与所需权限逐项登记
- 隔离运行：限制插件直接访问内核内部状态，必要时放进独立进程
- 加载容错：插件加载失败记录原因并跳过，不影响内核与其余插件启动
- 契约演进：破坏性变更走 v1/v2 并行接口加弃用公告，给迁移窗口
治理要点
| 事项 | 做法 | 缺省的后果 |
|---|---|---|
| 版本检查 | 插件启动时校验依赖的契约版本，不匹配则拒绝加载并给出可读原因 | 运行到某个分支才报错，故障难以定位 |
| 权限最小化 | 按声明放行能力，网络与文件访问默认关闭 | 第三方插件越权读取数据，隔离失效 |
| 准入评审 | 插件上架前做安全与性能评审，记录版本与责任人 | 质量问题流入生产，内核背锅 |
| 兼容窗口 | v1/v2 并行，关键插件在迁移窗口内双跑验证 | 生产环境出现静默行为差异 |
扩展点与注册示意
扩展点与注册示意
# 内核定义扩展点接口，只暴露必要上下文
interface FilterPlugin {
String name(); # 插件标识，用于清单与日志
String requiredContractVersion(); # 依赖的契约版本，加载前校验
Result apply(Request req, Ctx ctx); # 只通过上下文访问内核能力
}
# 内核启动流程
# 1 扫描插件清单 → 2 校验契约版本 → 3 校验权限声明 → 4 加载并注册
# 单个插件加载失败：记录原因后跳过，内核继续启动插件一旦对外开放，接口兼容与沙箱隔离会变成长期成本：上线前就要明确版本策略、弃用流程与第三方责任边界，事后补往往要重写契约。
扩展点宜少而稳：接口数量随插件生态膨胀会迅速失控，新增扩展点前先确认能否复用已有契约。