微内核架构模式（有时称为插件架构模式）是实现基于生产的应用程序的自然模式。 基于产品的应用程序已打包并提供不同版本，可作为第三方插件下载。 然后，很多公司也在开发和发布自己的内部业务应用程序，比如带有版本号、指令和可加载插件的应用软件（这也是这些模式的一个特点）。 微内核系统允许用户向核心应用程序添加附加应用程序，例如插件，从而提供可扩展性和使用的功能分离。

模式说明

微内核系统架构模型由核心系统和插件系统两部分组成。 将应用逻辑分为独立的插件模块和基础核心模块，从而在隔离应用功能和处理具体事务逻辑的同时提供可扩展性和灵活性。 架构模型如图3-1所示。

核心模块仅具有使应用程序运行的最小功能逻辑。 许多操作系统都使用微内核系统架构，该架构由此得名。 从业务应用的角度来看，核心系统一般定义了通用的业务逻辑，不包含针对特殊情况、特殊规则、复杂条件的具体处理逻辑。

插件模块是包含特殊处理逻辑、附加功能和定制代码的独立模块，可以扩展核心系统业务功能。 通常，不同的插件模块是相互独立的，但是您可以设计一个插件来依赖另一个插件。 最重要的是，您需要最大限度地减少插件之间的相互依赖关系，以避免冗长的依赖问题。

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

插件模块可以通过多种方式连接到核心系统，包括OSGi（开放服务网关协议）、消息队列、网络服务，甚至直接点对点绑定（对象实例化）。 您选择的连接类型取决于您正在设计的应用程序类型（小型产品或小型企业产品）和一些特定要求（例如单一部署或分布式部署）。 架构模式本身并没有规定任何实现方法，只是要求插件模块必须保持相互独立。

核心系统和插件模块之间的合约可以是标准合约，也可以是定制合约。 当插件模块由第三方公司开发并且您没有合同控制权时，通常会出现自定义协作。 在这些情况下，通常在特定于插件的合约和标准合约之间创建适配器，以便核心系统不需要为每个插件添加专门的代码。 在构建标准合约（通常使用 XML 或 Java Map）时，从一开始就制定版本控制策略非常重要。

模式示例

微内核的最佳示例可能是 Eclipse IDE。 下载Eclipse软件，它只为您提供一个令人眼花缭乱的编辑器。 然而，一旦你开始加载插件，它就会变得更加多样化和有用。 互联网浏览器是另一个常见的例子，它们本身只是视图预览器，带有提供附加功能的插件。

对于基于产品的软件，这样的例子不胜枚举。 但是小型企业软件呢？ 这同样适用于微内核系统。 我们以保险理赔软件为例。

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

毫不奇怪，大多数保险索赔程序都借助大型且复杂的规则引擎来处理这些复杂性。 然而，这些规则引擎可能显得更加复杂。 当您更改一条规则并影响其他规则时，或者当进行简单的规则更改需要大量分析、开发和测试时，使用微内核架构模式可以解决许多此类问题。 问题类型。

您在图 3-2 中听到的一堆核心系统文件夹代表了索赔处理过程。 它包含了所需的基本业务逻辑，无需任何具体处理。 每个插件模块都包含对应状态的特定处理规则。 在这种情况下软件系统的架构，插件模块的实现可以使用特定的源代码或单独的规则引擎实例。 无论具体实现采用何种技术，其核心思想都是每个州的具体保险损失评估规则和处理与核心系统分离，可以进行增删改，而不影响其他州的插件模块或处理。核心系统。

防范措施

微内核架构模式的好处之一是它可以嵌入或用作另一个架构模式的一部分。 例如，如果该模式解决了应用程序中的特定问题，而整个应用程序架构无法使用该模式来实现，那么在这些情况下您可以将微内核架构模式嵌入到另一种模式中（例如分层架构）。 同样，微内核架构模式也可以用于上一节介绍的风暴处理和驱动架构。

微内核架构模式为扩展设计和增量开发提供了强大的支持。 您可以创建固定的核心系统，并随着应用程序的发展添加功能和特性，而无需对核心系统进行大量更改。

对于基于产品的应用程序，微内核架构模式应该始终是您选择的架构，特别是对于将来会不断升级功能并希望控制哪些目标用户组拥有这些新功能的产品。 如果随着时间的推移您发现某个模式不能满足您的所有要求，您可以将应用程序构建为另一个更适合您的特定要求的架构模式。

模式分析

整体敏捷性

评价：高

分析：整体敏捷性是指对不断变化的条件做出快速反应的能力。 更改可以在很大程度上进行分区，并通过松散耦合的插件快速实现。一般来说，大多数微内核架构的核心系统会很快稳定下来，因为它功能强大，并且随着时间的推移只需要很少的更改。

易于部署

评价：高

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

可测试性

评价：高

分析：插件模块可以单独测试，并且可以通过核心系统轻松模拟，以进行演示或原型设计，而无需进行任何更改或进行最少的更改。

表现

评价：高

分析：虽然微内核架构本质上并不是高性能应用程序，但一般来说，大多数使用微内核架构模式的应用程序都表现良好，因为您可以自定义和简化应用程序，使其仅包含您需要的功能。 。 JBoss应用服务器就是一个很好的例子：通过它的插件架构，你可以将应用服务器减少到只有必要的功能，并删除复杂和不必要的功能，例如消耗视频内存、CPU和线程的远程访问、消息队列和缓存。

可扩展性

评级：低

分析：由于微内核架构的实现大多基于产品，规模相对较小，通常作为单个单元实现，因此可扩展性不高。根据插件架构的实现方式软件系统的架构，有时可以提供插件功能级别的可扩展性，但一般来说，这种模型不容易产生高度可扩展的应用程序。

易于开发

评级：低

分析：微内核架构需要仔细的设计和契约控制，这使得其实现起来相当复杂。 协议版本控制、内部插件注册方法、插件粒度以及广泛的插件连接方法将降低实现这些模式的复杂性。

点击下面