https://www.oreilly.com/library/view/software-architecture-patterns/9781491971437/ch03.html

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

模式说明

微内核架构模式包括两种类型的架构组件：核心系统和插件模块。应用程序逻辑在独立的插件模块和基本核心系统之间划分，提供应用程序功能和自定义处理逻辑的可扩展性，灵活性和隔离性。图3-1 说明了基本的微内核架构模式。

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

图3-1 微内核架构模式

插件模块是独立的独立组件，其中包含专门的处理，其他功能以及用于增强或扩展核心系统以产生附加业务功能的自定义代码。通常，插件模块应该独立于其他插件模块，但是您当然可以设计需要存在其他插件的插件。无论哪种方式，都必须将插件之间的通信减至最少，以避免依赖性问题，这一点很重要。

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

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

插件模块和核心系统之间的合同范围很广，从标准合同到定制合同都可以。自定义合同通常在第三方无法开发插件组件的情况下发现，而您无法控制该插件使用的合同。在这种情况下，通常在插件联系人和您的标准合同之间创建一个适配器，以使核心系统不需要每个插件的专用代码。创建标准合同（通常通过XML或Java Map实现）时，切记从一开始就创建版本控制策略，这一点很重要。

模式范例

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

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

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

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

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

图3-2 微内核架构示例

注意事项

关于微内核架构模式的一个很棒的事情是它可以被嵌入或用作另一种架构模式的一部分。例如，如果此模式解决了应用程序特定易失区域的特定问题，则可能会发现您无法使用此模式实现整个体系结构。在这种情况下，您可以将微服务架构模式嵌入到您正在使用的另一个模式中（例如，分层架构）。类似地，可以使用微服务架构模式来实现上一节中有关事件驱动架构的事件处理器组件。

微服务架构模式为演化设计和增量开发提供了强大的支持。您可以首先生成一个可靠的核心系统，然后随着应用程序的逐步发展，无需对核心系统进行重大更改即可添加功能。

对于基于产品的应用程序，微内核体系结构模式应始终是您作为初始体系结构的首选，尤其是对于那些随着时间的推移将发布其他功能并希望控制哪些用户获得哪些功能的产品。如果随着时间的推移发现该模式不能满足您的所有需求，那么您始终可以将您的应用程序重构为更适合您的特定需求的另一个体系结构模式。

模式分析

下表包含对微内核架构模式的通用架构特征的评级和分析。每个特性的等级基于该特性的自然趋势，作为基于模式的典型实现的能力，以及该模式通常已知的功能。

整体敏捷度评分：高

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

易于部署评分：高

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

可测性评分：高

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

性能评分：高

分析：虽然微内核模式无法自然地适合高性能应用程序，但通常来说，大多数使用微内核架构模式构建的应用程序都表现良好，因为您可以自定义和简化应用程序以仅包含所需的那些功能。JBoss应用服务器就是一个很好的例子：借助其插件体系结构，您可以将应用服务器缩减为仅需要的那些功能，删除昂贵的未使用功能，例如远程访问，消息传递和消耗内存的缓存。 ，CPU和线程，并降低应用服务器的速度。

可扩展性评分：低

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

易于发展评分：低

分析：微内核体系结构需要周到的设计和合同治理，因此实施起来相当复杂。合同版本控制，内部插件注册中心，插件粒度以及可用于插件连接的广泛选择都增加了实现此模式所涉及的复杂性。