今天我们来看下微内核架构模式。

微内核架构模式也称为插件式架构模式，是一种天生基于产品应用的架构模式。基于产品应用是将需要发布的程序打包好，并且可能会进行持续迭代升级从而拥有多个版本，提供给用户或三方组织下载使用。但是，很多公司也可以开发并发布他们自己内部的业务应用，例如软件产品，包括版本，发布说明和插件特性。以上的需求场景都可以使用微内核架构模式。微内核架构模式允许你以插件的形式添加额外的应用特性到核心应用中，从而提供了可扩展性和特性隔离。

模式描述

微内核架构模式主要由两个架构组件：核心系统和插件模块。应用逻辑通过独立的插件模块与核心系统分离，提供扩展性，灵活性应用特性隔离和业务处理逻辑定制。

微内核架构模式的核心系统一般只包含能够支撑整个系统运作的最小功能单元。很多操作系统实现了微内核架构模式，这就是微内核架构的由来。从业务应用的层面来看，核心系统通常是定义通用业务逻辑，没有特殊代码定制，特殊规则或者复杂的条件处理。

插件模块是独立的组件，包含特定的处理，额外的特性和定制的代码，以提升或扩展处理业务的能力。一般来说，插件模之间应该相互独立的，但是你可以定制一些插件依赖于当前已经存在的插件。如果你的插件依赖其他插件，那么你的插件模块应该尽可能的减少与其他插件模块通信或调用，这样就会尽可能的避免依赖问题。

核心系统需要知道哪些插件模块是可用的，并且知道如何加载这些可用的插件模块。一个实现插件模块加载的通用实现方式是通过插件注册表。插件注册表包含每个插件模块的信息，可能包括：名称，数据交互，远程协议方式细节（依赖于插件模块与核心系统的的连接方式）。例如，比较高风险税务审计项目的税务软件插件可能有一个包含服务名称的注册表，数据交互（包含数据输入和输出）和交互的数据格式（如XML，JSON等）。如果插件模块与核心系统的交互式通过SOAP，那么核心系统就需要提供一个WSDL（Web Services Definition Language）。

插件模块可以通过各种方式与核心系统连接，包括OSGi(open service gateway initiative)，消息系统，Webservice或者直接点对点的绑定（例如：对象实例）。你使用的连接方式应该依赖于你构建的应用类型（大型或小型应用）和你的具体业务需求（例如：单点部署或者分布式部署）。只有在插件模块保持相互独立的前提下，微内核架构不会指定这些实现细节。

  

模式举例

  

或许微内核架构最好的例子是Eclipse IDE（或者IDEA,JENKINS等）。从Eclipse官网下载一个Eclipse，它只提供了一个基本的编辑器的功能。但是，一旦你开始添加插件，它就变成了一个高度定制且有用的产品。浏览器是使用微内核架构模式的产品示例：视图和插件，插件提供了在浏览器不提供的一些功能。

  

对于基于产品的软件来说，这样的例子很多，但关于大型业务应用到底是什么？微内核架构也可以应用到这些场景中。为了理解这点，我们可以看一个保险公司的例子，处理保险索赔流程。

  

索赔流程是一个复杂的流程。每个地方都有不同的规则和条例：哪些是可以的，哪些是不可以的。例如，如果你的挡风玻璃被岩石打碎，有些地方可以免费更换挡风玻璃，有些地方则不允许免费更换。这些情况就造成了标准索赔流程几乎存在很多的条件集合。

  

大部分保险索赔应用使用大型且负责的规则引擎去处理这些复杂性。但是，规则应用可能会一直增长，当你要去修改一个规则时，却影响了另一个规则，或者当修改一个简单规则时，需要大量的分析师，开发人员和测试人员。使用微内核架构模式可以解决这些问题。

  下图你会看到索赔流程的核心系统。

它包含了保险公司处理索赔的基本业务逻辑，但是不包含定制的流程处理。每个插件模块包含对这个地方的具体索赔处理规则。在这个例子中，插件模块可以使用定制的源代码或者将规则引擎实例分离。不管如何实现，关键点是地方的具体规则和将业务处理与核心索赔系统分离，并且可以在添加，删除，修改规则时不影响核心系统或其他插件模块。

思考

 

微内核架构模式可以嵌入或者作为其他架构模式的一部分。例如这个模式解决了你面临的一些问题，你的整个系统可能无法使用整个微内核架构模式。在这种情况下，你可以嵌入微服务架构到你的另一个架构模式当中（例如分层架构）。类似地，之前谈到的事件驱动中的消息处理器组件可以使用微内核架构模式来实现。

微服务架构模式提供了强大的渐进设计和增量开发。你可以先开发一个核心系统，随着应用程序的不断发展，添加新特性和功能，而不用修改核心系统。

对于基于产品的应用，微内核架构模式应该是首选的架构模式，尤其当这些产品需要持续发布额外的特性并想要控制用户获取到这些特性。如果随着时间流逝，你发现微内核架构模式无法满足你的需求，你可以使用更能满足你需求的架构模式去重构它。

模式分析

灵活性：高

分析：大部分微内核架构模式变化都是基于插件模块的变更，可以快速响应变化。

易于部署：高

分析：依赖于架构如何实现，插件模块在运行时可以动态添加到核心系统（例如：热部署），减少发布的停机时间。

可测试性：高

分析：插件模块可以独立测试，可以很简单的被核心系统模拟。

性能：高

分析：微内核架构模式本来天生不是高性能的应用，通常，大部分基于微内核架构模式的应用性能都很好是因为你可以定制和流线化你需要的应用特性。JBoss服务是一个很好的例子：使用JBoss的插件架构，你可以移除你不需要的功能特性，而这些功能特性的性能又不会很高，例如：远程访问，消息，缓存等。

可扩展性：高

分析：因为大部分微内核架构都是基于产品实现，一般产品规模不会很大，插件模块不会很多，因此并不是高扩展性的。高扩展性依赖于你如何实现插件模块，你可以提供可扩展的插件特性，但总体来讲，微内核架构模式并不是以高度扩展性而闻名的架构。

易于开发：低

分析：微内核架构模式需要深度思考设计和契约治理，使得微内核架构实现复杂。契约版本号，内部插件注册，插件粒度，插件连接方式的多种选择等都会提高实现的复杂性。