转载

[软件架构模式]-微内核架构(Microkernel Architecture)

微内核架构有时也被成为插件架构模式（plug-in architecture pattern），通常用于实现基于产品的应用，如Eclipse和Firefox。然而许多公司也将内部的业务软件做成软件产品，提供版本、发版说明和插件特性。微内核架构模式通过插件向核心应用添加额外的功能，提供了可扩展性和功能的独立和分离。

模式描述

微内核架构包含两部分组件：核心系统（core system）和插件模块（plug-in modules）。应用逻辑被分割为独立的插件模块和核心系统，提供了可扩展性、灵活性、功能隔离和自定义处理逻辑的特性。

[软件架构模式]-微内核架构(Microkernel Architecture) 图1 微内核架构模式（microkernel architecture pattern）

微内核架构的核心系统通常提供系统运行所需的最小功能集。许多操作系统使用的就是微内核架构，这也是它名字的由来。从商业应用程序的角度来看，核心系统一般是通用业务逻辑，没有特殊情况、特殊规则或复杂情形下的自定义代码。

插件模块是独立的模块，包含特定的处理、额外的功能和自定义代码，来向核心系统增强或扩展额外的业务能力。通常插件模块之间也是独立的，也有一些插件是依赖于若干其它插件的。重要的是，尽量减少插件之间的通信以避免依赖的问题。

核心系统需要知道哪些插件是可用的且如何使用。一种实现的方式是使用插件注册表。注册表中包含插件的一些信息，如名称、数据契约（输入数据和输出数据）、远程访问协议（决定插件如何与核心系统连接，XML或WSDL等）。

插件模块和核心系统的连接方式有多种，包括OSGi (open service gateway initiative)、messaging、web service、甚至点对点绑定（对象实例化）。选择哪种连接方式取决于构件的应用类型和是否分布式部署等特殊需求。

插件和核心系统之间的契约也是各种各样的，既可以是标准的也可以是自定义的。通常在使用第三方插件时需要自定义契约。这种情况下，通常创建一个该插件契约到你的标准契约的适配器，这样核心系统就不需要针对每个插件的定制编码了。创建标准契约时（通常为XML），要记得从一开始就设计好版本策略。

案例

微内核架构最好的案例也许就是Eclipse啦。下载基础版本的Ecilpse或许只比一个功能花哨的编辑器强一点，一旦装上一些插件，它立刻就变成高度定制化的很有用的产品。浏览器也是微内核架构产品的典型案例。

这样的基于产品的软件例子数不胜数，但是大型商业应用呢？微内核结构也是适用的。这里再以保险公司的索赔处理为例。（书中的例子都不符合国情，看着挺费劲的。）

索赔处理过程很复杂，每个阶段都有很多不同的规则和条例来说明是否应该得到赔偿。例如汽车挡风玻璃被岩石击碎，有的州是允许赔偿的，有的是不允许的。标准的索赔过程几乎有无限的条件。

通常保险索赔应用都会使用一个大型的复杂的规则引擎来处理。但是规则引擎会像滚雪球一样越来越大，修改一个规则可能会影响其它的规则，或者一个简单的规则修改需要很多分析人员、开发人员和测试人员。使用微内核架构模式可以避免这样的问题。

如图2中所示，核心系统claims processing包含了处理索赔过程的基本业务逻辑。每个插件模块包含一个州的特殊规则。这个例子中，插件模块可以通过自定义代码或分离规则引擎实例来实现。最重要的是，每个州的独特的规则从核心系统中剥离出来，可以被添加或移除，修改时不影响或会稍微影响核心系统与其它插件。

[软件架构模式]-微内核架构(Microkernel Architecture) 图2 微内核架构案例