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

模式描述

微内核架构模式由两种类型的架构组件组成：核心系统和插件模块。应用程序逻辑分为独立的插件模块和基本核心系统，提供应用程序功能和自定义处理逻辑的可扩展性，灵活性和隔离性。图3-1 说明了基本的微内核架构模式。
微内核架构模式的核心系统传统上仅包含使系统运行所需的最小功能。许多操作系统实现了微内核架构模式，因此是该模式名称的起源。从业务应用程序的角度来看，核心系统通常被定义为一般业务逻辑，不包括特殊情况，特殊规则或复杂条件处理的自定义代码。

图3-1。微内核架构模式

插件模块是独立的独立组件，包含专门的处理，附加功能和自定义代码，旨在增强或扩展核心系统以产生额外的业务功能。通常，插件模块应独立于其他插件模块，但您当然可以设计需要其他插件的插件。无论哪种方式，将插件之间的通信保持在最低限度以避免依赖性问题非常重要。
核心系统需要知道哪些插件模块可用以及如何访问它们。实现此目的的一种常见方法是通过某种插件注册表。此注册表包含有关每个插件模块的信息，包括其名称，数据协定和远程访问协议详细信息（取决于插件如何连接到核心系统）。例如，标记高风险税务审计项目的税务软件插件可能具有包含服务名称（AuditChecker），数据合同（输入数据和输出数据）以及合同格式的注册表项（ XML）。如果通过SOAP访问插件，它也可能包含WSDL（Web服务定义语言）。
插件模块可以通过各种方式连接到核心系统，包括OSGi（开放服务网关计划），消息传递，Web服务，甚至直接点对点绑定（即对象实例化）。您使用的连接类型取决于您正在构建的应用程序类型（小型产品或大型业务应用程序）以及您的特定需求（例如，单个部署或分布式部署）。体系结构模式本身并未指定任何这些实现细节，只是插件模块必须保持彼此独立。
插件模块和核心系统之间的合同范围可以从标准合同到定制合同。自定义合同通常出现在插件组件由第三方开发的情况下，您无法控制插件使用的合同。在这种情况下，通常在插件联系人和标准合同之间创建一个适配器，这样核心系统就不需要为每个插件提供专门的代码。在创建标准合同（通常通过XML或Java Map实现）时，记住从一开始就创建版本控制策略非常重要。

模式示例

也许微内核架构的最好例子是Eclipse IDE。下载基本的Eclipse产品只是一个花哨的编辑器。但是，一旦开始添加插件，它就会变成一个高度可定制且有用的产品。Internet浏览器是使用微内核架构的另一个常见产品示例：查看器和其他插件添加了在基本浏览器（即核心系统）中无法找到的其他功能。
对于基于产品的软件，这些例子是无穷无尽的，但是大型企业应用程序呢？微内核架构也适用于这些情况。为了说明这一点，让我们使用另一个保险公司的例子，但这次涉及保险索赔处理。
索赔处理是一个非常复杂的过程。每个州对保险索赔中允许和不允许的内容都有不同的规则和规定。例如，如果您的挡风玻璃被岩石损坏，某些州允许更换挡风玻璃，而其他州则不允许。这为标准索赔流程创造了几乎无限的条件。
毫不奇怪，大多数保险索赔应用程序利用大型复杂的规则引擎来处理大部分复杂性。然而，这些规则引擎可能会变成一个复杂的泥球，改变一个规则会影响其他规则，或者进行简单的规则更改需要大量的分析师，开发人员和测试人员。使用微内核架构模式可以解决许多这些问题。
您在图3-2中看到的文件夹堆栈代表了索赔处理的核心系统。它包含保险公司处理索赔所需的基本业务逻辑，除非没有任何自定义处理。每个插件模块都包含该状态的特定规则。在此示例中，可以使用自定义源代码或单独的规则引擎实例来实现插件模块。无论实现如何，关键点在于特定于状态的规则和处理与核心声明系统是分开的，并且可以添加，删除和更改，而对核心系统的其余部分或其他插件模块几乎没有影响。

图3-2。微内核架构示例

注意事项

关于微内核架构模式的一个好处是它可以嵌入或用作另一种架构模式的一部分。例如，如果此模式解决了应用程序的特定易失性区域的特定问题，您可能会发现无法使用此模式实现整个体系结构。在这种情况下，您可以将微服务架构模式嵌入到您正在使用的另一种模式中（例如，分层架构）。类似地，前面关于事件驱动架构的部分中描述的事件处理器组件可以使用微服务架构模式来实现。
微服务架构模式为进化设计和增量开发提供了很好的支持。您可以首先生成可靠的核心系统，并随着应用程序的逐步发展，添加功能和功能，而无需对核心系统进行重大更改。
对于基于产品的应用程序，微内核架构模式应该始终是您作为起始架构的首选，特别是对于那些随着时间推移发布其他功能并希望控制哪些用户获得哪些功能的产品。如果您发现该模式不能满足您的所有要求，您始终可以将应用程序重构为更适合您特定要求的另一种体系结构模式。

模式分析

整体敏捷
评级：高
分析：整体敏捷性是指能够快速响应不断变化的环境。通过松散耦合的插件模块，可以在很大程度上隔离并快速实现更改。通常，大多数微内核架构的核心系统趋于快速稳定，因此相当稳健并且随着时间的推移几乎不需要改变。

易于部署
评级：高
分析：根据模式的实现方式，可以在运行时（例如，热部署）将插件模块动态添加到核心系统，从而最大限度地减少部署期间的停机时间。

可测性
评级：高
分析：插件模块可以单独测试，并且可以由核心系统轻松模拟，以演示或原型化特定功能，而对核心系统进行很少或不需要更改。

性能
评级：高
分析：虽然微内核模式自然不适合高性能应用程序，但一般来说，使用微内核架构模式构建的大多数应用程序都能很好地运行，因为您可以自定义和简化应用程序，只包含您需要的功能。JBoss Application Server就是一个很好的例子：通过其插件架构，您可以将应用程序服务器减少到只需要的那些功能，从而消除昂贵的未使用功能，如远程访问，消息传递和消耗内存的缓存，CPU和线程，并降低应用服务器的速度。

可扩展性
评级：低
分析：由于大多数微内核架构实现都是基于产品的，并且通常尺寸较小，因此它们实现为单个单元，因此不具有高度可扩展性。根据您实现插件模块的方式，您有时可以在插件功能级别提供可伸缩性，但总体而言，这种模式对于生成高度可伸缩的应用程序并不为人所知。

易于开发
评级：低
分析：微内核架构需要深思熟虑的设计和合同治理，使其实施起来相当复杂。合同版本控制，内部插件注册表，插件粒度以及可用于插件连接的广泛选择都会导致实现此模式所涉及的复杂性。

参考链接：https://www.oreilly.com/library/view/software-architecture-patterns/9781491971437/ch03.html