微内核架构(Microkernel Architecture)
微内核架构有时也被成为插件架构模式（plug-in architecture pattern），通常用于实现基于产品的应用，如Eclipse和Firefox。然而许多公司也将内部的业务软件做成软件产品，提供版本、发版说明和插件特性。微内核架构模式通过插件向核心应用添加额外的功能，提供了可扩展性和功能的独立和分离。
模式描述
微内核架构包含两部分组件：核心系统（core system）和插件模块（plug-in modules）。应用逻辑被分割为独立的插件模块和核心系统，提供了可扩展性、灵活性、功能隔离和自定义处理逻辑的特性。
图1 微内核架构模式（microkernel architecture pattern）
微内核架构的核心系统通常提供系统运行所需的最小功能集。许多操作系统使用的就是微内核架构，这也是它名字的由来。从商业应用程序的角度来看，核心系统一般是通用业务逻辑，没有特殊情况、特殊规则或复杂情形下的自定义代码。
插件模块是独立的模块，包含特定的处理、额外的功能和自定义代码，来向核心系统增强或扩展额外的业务能力。通常插件模块之间也是独立的，也有一些插件是依赖于若干其它插件的。重要的是，尽量减少插件之间的通信以避免依赖的问题。
核心系统需要知道哪些插件是可用的且如何使用。一种实现的方式是使用插件注册表。注册表中包含插件的一些信息，如名称、数据契约（输入数据和输出数据）、远程访问协议（决定插件如何与核心系统连接，XML或WSDL等）。
插件模块和核心系统的连接方式有多种，包括OSGi (open service gateway initiative)、messaging、web service、甚至点对点绑定（对象实例化）。选择哪种连接方式取决于构件的应用类型和是否分布式部署等特殊需求。
插件和核心系统之间的契约也是各种各样的，既可以是标准的也可以是自定义的。通常在使用第三方插件时需要自定义契约。这种情况下，通常创建一个该插件契约到你的标准契约的适配器，这样核心系统就不需要针对每个插件的定制编码了。创建标准契约时（通常为XML），要记得从一开始就设计好版本策略。
案例
微内核架构最好的案例也许就是Eclipse啦。下载基础版本的Ecilpse或许只比一个功能花哨的编辑器强一点，一旦装上一些插件，它立刻就变成高度定制化的很有用的产品。浏览器也是微内核架构产品的典型案例。
这样的基于产品的软件例子数不胜数，但是大型商业应用呢？微内核结构也是适用的。这里再以保险公司的索赔处理为例。（书中的例子都不符合国情，看着挺费劲的。）
索赔处理过程很复杂，每个阶段都有很多不同的规则和条例来说明是否应该得到赔偿。例如汽车挡风玻璃被岩石击碎，有的州是允许赔偿的，有的是不允许的。标准的索赔过程几乎有无限的条件。
通常保险索赔应用都会使用一个大型的复杂的规则引擎来处理。但是规则引擎会像滚雪球一样越来越大，修改一个规则可能会影响其它的规则，或者一个简单的规则修改需要很多分析人员、开发人员和测试人员。使用微内核架构模式可以避免这样的问题。
如图2中所示，核心系统claims processing包含了处理索赔过程的基本业务逻辑。每个插件模块包含一个州的特殊规则。这个例子中，插件模块可以通过自定义代码或分离规则引擎实例来实现。最重要的是，每个州的独特的规则从核心系统中剥离出来，可以被添加或移除，修改时不影响或会稍微影响核心系统与其它插件。
图2 微内核架构案例
注意事项
微内核架构模式的一个优秀之处在于它可以嵌入或者作为其它架构模式的一部分。例如事件驱动架构中的事件处理组件就可以使用微内核架构实现。
微内核架构为递进设计和增量开发提供了方便。可以先实现一个稳固的核心系统，然后在不对核心系统进行大量修改的情况下逐渐地增加功能和特性。
对于基于产品的应用，微内核架构是一开始的首选。尤其是这样的产品：随着时间逐渐地发布新功能，而且希望保证所有的用户都能获取到新功能。如果以后发现该架构不符合需求了，可以随时重构成其它架构。
模式分析
下表展示了分层架构模式的通用架构特性的评级和分析。
整体灵活性
评级：高
分析：整体灵活性是对环境变化快速响应的能力。由于插件之间的低耦合，改变通常是隔离的，可以快速实现。通常，核心系统是稳定且快速的，具有一定的健壮性，几乎不需要修改。
易于部署
评级：高
分析：取决于实现方式，插件可以在运行时动态添加（热部署），最小化部署的停机时间。
可测试性
评级：高
分析：插件可以独立测试，也很容易被模拟，不需修改核心系统就可以演示或构建新特性的原型。
性能
评级：高
分析：虽然微内核架构本身不会使应用高性能，但通常使用微内核架构构建的应用性能都还不错，因为可以自定义或者裁剪掉不需要的功能。JBoss应用服务器就是这样的。
可伸缩性
评级：低
分析：因为大部分微内核架构的实现都是基于产品的，一般都很小，是一个独立的单元，因此不具有高可伸缩性。取决于插件的实现方式，有时在插件特性层可以提供伸缩性，但总体上来说该架构还是用于构建高可伸缩性应用的。
开发容易度
评级：低
分析：微内核架构需要深思熟虑的设计和契约的规划管理，因此实现起来比较复杂。契约的版本机制、插件的注册机制、插件的粒度、插件连接方式的选择都使得实现起来是复杂的。
参考资料：