微内核架构模式（有时也称为插件架构模式）通常被应用于实现基于产品的应用程序。基于产品的应用程序是一种基于某一个现有产品开发，作为典型第三方产品打包并可供下载的应用程序。微内核架构模式允许我们将附加的应用程序功能作为插件添加到核心应用程序中，提供可扩展性以及额外的功能。

模式介绍

微内核架构模式包含两个核心组件：内核系统（core system）和插件模块（plug-in modules）。基本的核心系统能力加上插件模块提供的彼此之间独立的、高度灵活的功能，共同组成了应用程序的整体功能。

下图展示了微内核模式的基本结构。

内核系统通常只包含基本的能够让系统运行起来的功能。很多操作系统都是采用的微内核架构模式。对于业务应用而言，内核系统通常是通用业务逻辑，没有针对特殊情况、特殊规则或复杂条件处理的自定义逻辑。

插件模块是独立的组件，包含专门处理、附加功能以及自定义代码，旨在增强或扩展内核系统来产生附加业务功能。通常来说，插件模块之间应该是彼此相互独立的，我们也可以使用彼此有依赖的插件，但是需要关注插件间的依赖关系，避免引入依赖问题。

内核系统需要知道如何获取并加载插件。通常来说，我们会有一个插件仓库来管理插件。插件模块有很多方式来集成到内核系统中来，比如 OSGI、消息、web 服务，甚至是直接对象实例化。微内核架构模式本身并未限制集成方式，具体的集成方式可以根据应用规模（小型应用还是大型应用）和具体的业务需求（集中部署还是分布式部署等）来确定。

举例说明

Eclipse IDE 可能是最好的微内核架构的例子。我们下载的 Eclipse IDE 最初只包含一个编辑器，当我们添加一些插件以后，Eclipse 就会变成一个高度定制并且功能丰富的 IDE。浏览器也是一个很好的微内核架构的例子。浏览器插件为浏览器扩展了丰富的功能。

基于产品的应用程序中，微内核架构的例子有很多。在大型业务应用程序中，微内核架构是如何使用的呢？我们举一个保险理赔处理的例子。

保险理赔过程是非常复杂的，不同地区有不同的法规，同一个规则在一个地区允许，在另一个地区不允许。这就导致了在标准理赔处理过程中需要增加无尽的条件判断。

下图展示了基于微内核架构模式实现的理赔处理程序。

每个插件模块都包含特定地区的具体规则，插件模块与内核系统分离，我们可以自由的修改、增删模块中的规则而不影响内核系统。

其他说明

微内核架构模式可以作为组成部分与其他架构模式一起使用。比如当微内核架构模式只解决了某一个特定场景内的问题时，我们就可以将其与其他架构模式（如分层架构模式）一起使用。

微内核架构模式为进化设计和增量开发提供了很好的支持。我们可以先构建一个坚实的内核系统，然后随着应用程序的逐步迭代，添加新的特性和功能，而无需对内核系统进行重大更改。

对于基于产品的应用程序来说，微内核架构模式应该始终是我们作为起始架构的首选，特别是对于那些将随着时间的推移而发布附加功能并希望控制哪些用户获得哪些功能的产品。

思考

通常来说，对于采用大部分微内核架构的应用程序来说，内核系统很快就趋于稳定，而彼此之间松耦合的插件模块可以快速实现变更迭代。同时，插件也是非常易于部署的，甚至可以做到热更新。我们可以方便对内核系统进行 mock，从而方便地进行测试。虽然微内核架构模式不是为了性能而设计的，但是大部分基于此模式的应用都有不错的性能，因为可以自由的定制需要的插件。

我们可以通过插件来扩展一些功能，但是考虑到大部分基于微内核架构模式的应用程序都是基于产品的应用程序，总体来说，扩展性较差。同时，内核系统与插件之间的通信协议设计、版本控制以及插件仓库的管理、插件可粒度设计等等都增加了额外的开发和管理成本。

关注微信公众号，获取最新推送~

加微信，深入交流~