模式描述
微内核架构模式由两种类型的架构组件组成：一个核心系统和插件模块。应用程序逻辑分布在独立的插件模块和基础核心系统之间，提供应用程序特性和定制处理逻辑的可扩展性、灵活性和隔离性。图3-1展示了基本的微内核架构模式。
微内核架构模式的核心系统传统上只包含使系统运行所需的最小功能。许多操作系统实现了微内核架构模式，这也是这个模式名字的由来。从业务应用的角度来看，核心系统通常被定义为没有特殊情况、特殊规则或复杂条件处理的定制代码的通用业务逻辑。
插件模块是独立的、独立的组件，包含专门的处理、额外的特性和定制代码，这些代码旨在增强或扩展核心系统以产生额外的业务能力。通常来说，插件模块应该独立于其他插件模块，但你当然可以设计需要其他插件存在的插件。无论如何，保持插件之间的通信最少是非常重要的，以避免依赖性问题。
核心系统需要知道哪些插件模块是可用的，以及如何访问它们。实现这一点的一种常见方法是通过某种插件注册表。这个注册表包含每个插件模块的信息，包括其名称、数据协议和远程访问协议详情（取决于插件如何连接到核心系统）。例如，一个用于标记高风险税务审计项目的税务软件插件可能有一个注册表条目，包含服务的名称（AuditChecker）、数据协议（输入数据和输出数据）和协议格式（XML）。如果通过SOAP访问插件，它也可能包含一个WSDL（Web服务定义语言）。
插件模块可以通过多种方式连接到核心系统，包括OSGi（开放服务网关倡议）、消息传递、网络服务，甚至直接的点对点绑定（即，对象实例化）。你使用的连接类型取决于你正在构建的应用程序类型（小型产品或大型业务应用程序）和你的特定需求（例如，单一部署或分布式部署）。这种架构模式本身并没有指定任何这些实现细节，只要求插件模块必须彼此独立。
插件模块与核心系统之间的合约可以从标准合约到定制合约。定制合约通常出现在插件组件由第三方开发，而你无法控制插件使用的合约的情况中。在这种情况下，通常会创建一个适配器，将插件合约与你的标准合约进行对接，这样核心系统就不需要为每个插件编写专门的代码。在创建标准合约（通常通过XML或Java Map实现）时，重要的是要记住从一开始就创建一个版本策略。
模式示例
或许微内核架构最好的例子是Eclipse IDE。下载基本的Eclipse产品只能为你提供一个花哨的编辑器。然而，一旦你开始添加插件，它就会变成一个高度可定制和有用的产品。互联网浏览器是使用微内核架构的另一个常见产品示例：浏览器和其他插件添加了基本浏览器（即，核心系统）中找不到的额外功能。
对于基于产品的软件，例子数不胜数，但大型业务应用程序呢？微内核架构也适用于这些情况。为了说明这一点，让我们使用另一个保险公司的例子，但这次涉及的是保险索赔处理。
索赔处理是一个非常复杂的过程。每个州对保险索赔的允许和不允许都有不同的规则和规定。例如，一些州允许如果你的挡风玻璃被石头破坏，免费更换挡风玻璃，而其他州则不允许。这为标准索赔流程创建了近乎无限的条件集。
不出所料，大多数保险索赔应用程序利用大型和复杂的规则引擎来处理这种复杂性。然而，这些规则引擎可以演变成一个复杂的大泥球，改变一个规则会影响其他规则，或者进行简单的规则更改需要大量的分析师、开发人员和测试人员。使用微内核架构模式可以解决这些问题。
你在下图看到的文件夹堆表示的是索赔处理的核心系统。它包含保险公司处理索赔所需的基本业务逻辑，只是没有任何定制处理。每个插件模块包含该州的特定规则。在这个例子中，插件模块可以使用定制的源代码或单独的规则引擎实例来实现。无论实现方式如何，关键点是，特定州的规则和处理与核心索赔系统是分开的，可以被添加、移除和更改，对核心系统或其他插件模块的其余部分影响微乎其微。
结论
以下是微内核架构模式的优点和缺点。
优点：
- 它可以在最小化改变核心系统的同时，对插件模块的改变做出反应。
- 不像分层架构，有插件模块意味着部署更容易，从而最小化停机时间。
- 测试也更容易，因为可以单独测试每个模块。
- 尽管一般来说并不是用于高性能应用的理想模式，但是由于只包含所需的功能来定制应用，它可以表现得很好。
缺点：
- 应用程序倾向于较小的规模，因此并不具有很高的可扩展性。
- 需要在实现之前进行彻底的设计分析。需要分析的项目包括合约版本控制、内部插件注册表、插件粒度，以及插件连接的多样选择。
