微内核架构模式（有时被称为插件架构模式）是实现基于产品的应用的自然模式。基于产品的应用程序是指作为典型的第三方产品被打包并提供下载的版本。然而，许多公司也像软件产品一样开发和发布他们的内部业务应用，有完整的版本、发布说明和可插拔功能。这些也是这种模式的自然适合。微内核架构模式允许你将额外的应用功能作为插件添加到核心应用中，提供可扩展性以及功能分离和隔离性。

模式描述

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

传统上，微内核结构模式的核心系统只包含使系统运行所需的最小功能。许多操作系统实现了微内核体系结构模式，因此这种模式的名称也由此而来。从商业应用的角度来看，核心系统通常被定义为一般的商业逻辑，而不是为特殊情况、特殊规则或复杂的条件处理定制代码。

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

插件模块是单独的、独立的组件，包含专门的处理、额外的功能和自定义代码，旨在增强或扩展核心系统以产生额外的业务能力。一般来说，插件模块应该是独立于其他插件模块的，但你当然也可以设计需要其他插件存在的插件。无论哪种方式，重要的是把插件之间的通信保持在一个小范围内，以避免依赖性问题。

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

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

插件模块和核心系统之间的合同可以从标准合同到自定义合同不等。自定义合同通常出现在插件组件由第三方开发的情况下，你对插件使用的合同没有控制权。在这种情况下，通常会在插件联系人和你的标准合同之间创建一个适配器，这样核心系统就不需要为每个插件编写专门的代码。当创建标准合同（通常通过 XML 或 Java Map 实现）时，重要的是要记住从一开始就创建一个版本策略。

模式示例

也许微内核架构的最好例子是 Eclipse IDE。下载基本的 Eclipse 产品为你提供的只是一个花哨的编辑器。然而，一旦你开始添加插件，它就变成了一个高度可定制和有用的产品。互联网浏览器是另一个使用微内核架构的常见产品例子：查看器和其他插件增加了基本浏览器（即核心系统）所没有的额外功能。

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

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

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

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

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

一些思考

微内核架构模式的一个伟大之处在于，它可以被嵌入或作为另一种架构模式的一部分。例如，如果这种模式解决了你在应用程序的一个特定的波动区域的特定问题，你可能会发现，你不能用这种模式来实现整个架构。在这种情况下，你可以将微服务架构模式嵌入到你正在使用的另一种模式中（例如，分层架构）。同样，上一节关于事件驱动的架构中描述的事件处理器组件也可以用微服务架构模式来实现。

微服务架构模式为进化设计和增量开发提供了巨大支持。你可以先制作一个坚实的核心系统，随着应用程序的逐步发展，增加特性和功能，而不必对核心系统进行重大的改变。

对于基于产品的应用，微内核架构模式应该永远是你的第一选择，特别是对于那些你将随着时间的推移发布更多的功能，并希望控制哪些用户获得哪些功能的产品。如果你发现随着时间的推移，这种模式不能满足你所有的要求，你总是可以重构你的应用，使之成为另一种更适合你的具体要求的架构模式。

模式分析

下表包含了对微内核架构模式的常见架构特征的评级和分析。每个特征的评级都是基于该特征的自然趋势，即基于该模式的典型实现的能力，以及该模式的普遍特点。关于该模式与本报告中其他模式的关系的侧面比较，请参考本报告末尾的 附录 A。

整体敏捷性评级：高

整体敏捷性是指对不断变化的环境做出快速反应的能力。变化在很大程度上可以通过松散耦合的插件模块来快速实现。一般来说，大多数微内核架构的核心系统往往会很快变得稳定，因此是相当稳健的，随着时间的推移需要很少的改变。

易于部署的评级：高

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

可测试性等级：高

插件模块可以被隔离测试，并且可以很容易地被核心系统模拟，以演示或原型化一个特定的功能，而对核心系统几乎没有改变。

性能评级：高

虽然微内核模式并不自然地适用于高性能的应用程序，但一般来说，大多数使用微内核架构模式的应用程序都表现良好，因为你可以定制和精简应用程序，只包括那些你需要的功能。JBoss 应用服务器就是一个很好的例子：通过它的插件架构，你可以将应用服务器缩减到你需要的那些功能，删除昂贵的非使用功能，如远程访问、消息传递和缓存，这些功能会消耗内存、CPU 和线程，使应用服务器变慢。

可扩展性评级：低

因为大多数微内核架构的实现都是基于产品的，而且尺寸一般较小，它们被实现为单一的单元，因此没有高度的可扩展性。根据你实现插件模块的方式，你有时可以在插件功能层面上提供可扩展性，但总体而言，这种模式并不以产生高度可扩展的应用而闻名。

易于开发的评级：低

微内核架构需要深思熟虑的设计和合同管理，这使得它的实施相当复杂。契约版本、内部插件注册、插件颗粒度以及插件连接的广泛选择，都有助于实现这种模式的复杂性。