欢迎回到软件架构模式博客系列。这是本系列的第 4 章，我们将讨论微内核架构模式

概述：

有时称为插件架构模式
将额外的应用程序功能作为插件添加到核心应用程序，提供可扩展性以及功能分离和隔离。
该模式由两种类型的架构组件组成：核心系统_和_插件模块。
应用逻辑在独立的插件模块和基础核心系统之间划分，提供可扩展性、灵活性和应用特性与自定义处理逻辑的隔离。
从业务应用的角度来看，核心系统通常被定义为通用业务逻辑，没有针对特殊情况、特殊规则或复杂条件处理的自定义代码。
插件模块是独立的、独立的组件，包含专门的处理、附加功能和自定义代码，旨在增强或扩展核心系统以产生附加业务功能。保持插件之间的通信很重要尽量避免依赖性问题。
注册表包含有关每个插件模块的信息，包括名称、数据契约和远程访问协议详细信息（取决于插件如何连接到核心系统）。
插件模块可以通过多种方式连接到核心系统，包括 OSGi（开放服务网关倡议）、消息传递、Web 服务，甚至直接点对点绑定（即对象实例化）。
当插件组件由第三方开发时，您无法控制插件使用的合同。在这种情况下，通常会在插件联系人和您的标准合约之间创建一个适配器，这样核心系统就不需要为每个插件编写专门的代码。

微内核架构

微内核架构模式（有时称为插件架构模式）是实现基于产品的应用程序的自然模式。基于产品的应用程序是作为典型的第三方产品打包并提供多种版本供下载的应用程序。但是，许多公司还开发和发布其内部业务应用程序，如软件产品，包括版本、发行说明和可插入功能。这些也很适合这种模式。微内核架构模式允许您将额外的应用程序功能作为插件添加到核心应用程序，提供可扩展性以及功能分离和隔离。

图案说明

微内核架构模式由两类架构组件组成：核心系统_和_插件模块。应用逻辑在独立的插件模块和基础核心系统之间划分，提供可扩展性、灵活性和应用特性与自定义处理逻辑的隔离。下图说明了基本的微内核架构模式。

微内核架构模式的核心系统传统上只包含使系统运行所需的最少功能。许多操作系统都实现了微内核架构模式，这也是该模式名称的由来。从业务应用的角度来看，核心系统通常被定义为通用业务逻辑，没有针对特殊情况、特殊规则或复杂条件处理的自定义代码。

插件模块是独立的、独立的组件，包含专门的处理、附加功能和自定义代码，旨在增强或扩展核心系统以产生附加业务功能。通常，插件模块应该独立于其他插件模块，但您当然可以设计需要其他插件存在的插件。无论哪种方式，重要的是将插件之间的通信保持在最低限度以避免依赖性问题。

核心系统需要知道哪些插件模块可用以及如何获取它们。一种常见的实现方式是通过某种插件注册表。此注册表包含有关每个插件模块的信息，包括其名称、数据合同和远程访问协议详细信息（取决于插件如何连接到核心系统）。例如，标记高风险税务审计项目的税务软件插件可能有一个注册表项，其中包含服务名称 (AuditChecker)、数据合同（输入数据和输出数据）和合同格式（ XML）。如果通过 SOAP 访问插件，它还可能包含 WSDL（Web 服务定义语言）。

插件模块可以通过多种方式连接到核心系统，包括 OSGi（开放服务网关倡议）、消息传递、Web 服务，甚至直接点对点绑定（即对象实例化）。您使用的连接类型取决于您正在构建的应用程序类型（小型产品或大型业务应用程序）和您的特定需求（例如，单一部署或分布式部署）。架构模式本身并没有指定任何这些实现细节，只是插件模块必须保持相互独立。

插件模块和核心系统之间的合同范围从标准合同到自定义合同。自定义合同通常出现在插件组件由第三方开发的情况下，您无法控制插件使用的合同。在这种情况下，通常会在插件联系人和您的标准合约之间创建一个适配器，这样核心系统就不需要为每个插件专门编写代码。在创建标准契约（通常通过 XML 或 Java Map 实现）时，请务必记住从一开始就创建版本控制策略。

模式示例

也许微内核体系结构的最佳示例是 Eclipse IDE。下载基本的 Eclipse 产品只为您提供了一个精美的编辑器。但是，一旦您开始添加插件，它就会变成一个高度可定制和有用的产品。Internet 浏览器是另一个使用微内核架构的常见产品示例：查看器和其他插件添加了基本浏览器（即核心系统）所没有的附加功能。

基于产品的软件的例子是无穷无尽的，但是大型商业应用程序呢？微内核架构也适用于这些情况。为了说明这一点，让我们使用另一个保险公司的例子，但这次是一个涉及保险理赔处理的例子。

索赔处理是一个非常复杂的过程。对于保险索赔中允许和不允许的内容，每个州都有不同的规则和规定。例如，如果您的挡风玻璃被岩石损坏，一些州允许免费更换挡风玻璃，而其他州则不允许。这为标准索赔流程创造了几乎无限的条件集。

毫不奇怪，大多数保险索赔应用程序都利用大型复杂的规则引擎来处理大部分这种复杂性。然而，这些规则引擎可能会变成一个复杂的大泥球，其中更改一条规则会影响其他规则，或者进行简单的规则更改需要一大批分析师、开发人员和测试人员。使用微内核架构模式可以解决其中的许多问题。

您在图 3–2中看到的文件夹堆栈代表了索赔处理的核心系统。它包含保险公司处理索赔所需的基本业务逻辑，除非没有任何自定义处理。每个插件模块都包含该状态的特定规则。在此示例中，插件模块可以使用自定义源代码或单独的规则引擎实例来实现。无论实施如何，关键点是特定于州的规则和处理与核心索赔系统是分开的，可以添加、删除和更改，而对核心系统的其余部分或其他插件模块影响很小或没有影响.