《软件架构模式》-第三章 微内核系统结构

原文地址  译者：克里斯托刘

微内核架构模式（有时被称为插件架构模式）是实现基于产品应用程序的一种自然模式。基于产品的应用程序是已经打包好并且拥有不同版本，可作为第三方插件下载的。然后，很多公司也在开发、发布自己内部商业应用像有版本号、说明及可加载插件式的应用软件（这也是这种模式的特征）。微内核系统可让用户添加额外的应用如插件，到核心应用，继而提供了可扩展性和功能分离的用法。

模式说明

微内核系统架构模式由两块组成：核心系统和插件系统。应用逻辑分为独立的插件模块和基本核心模块，继而有扩展性、灵活性同时隔离应用程序功能和处理特定事物逻辑。架构模式如图3-1。

核心模块只拥有能使应用运行的最小功能逻辑。许多操作系统使用微内核系统架构，这就是该结构的名字由来。从业务应用的角度，核心系统通常定义了一般商务逻辑，不包含特殊情况、特殊规则、复杂的条件的特定处理逻辑。

插件模块是独立存在的模块，包含特殊的处理逻辑、额外的功能和定制的代码，能拓展核心系统业务功能。通常，不同的插件模块互相之间独立，但是你可以设计成一个插件依赖于另外一个插件的情况。最重要的是，你需要让插件之间的互依赖关系降低到最小，为避免繁杂的依赖问题。

核心系统需要知道哪些插件模块是可加载的并且如何使用它们。一种普遍的方法是通过插件注册表。注册表包含每个插件模块的基本信息，包括名称，数据协议和远程访问协议明细。例如，用于标记高风险税务审计项目的税务软件插件可能有一个这样的注册表：包含服务名称（AuditChecker），数据签名（输入数据和输出数据格式），协议格式（XML）。如果通过SOAP访问，它可能还包含WSDL（Web服务定义语言）。

插件模块连接核心系统方法可以有很多种，包含OSGi（开放服务网关协议）、消息队列、网络服务、甚至是直接的点对点绑定（对象实例化）。选用的连接方式取决于设计的应用程序类型（小产品或大型企业产品）和一些特定需求（如单一部署或分布式部署）。架构模式本身不指定任何一种实施方式，只要求插件模块必须保持相互独立。

核心系统和插件模块的协议可以是标准协议或是定制协议。定制协同通常见于插件模块是由第三方公司开发、而你没有协议的控制权的时候。在这种情况，通常使用创建插件特定协议和标准协议的适配器的办法，这样核心系统不需要为每个插件加入专门的代码。当建立标准协议（通常使用XML或者Java Map）时，重要的一点是刚开始就做好版本控制策略。

模式例子

可能最好的微内核例子是Eclipse IDE。下载的Eclipse软件，它只提供你一个炫酷的编辑器。然而，一旦你开始加载插件，它变得更定制化和有用。Internet浏览器是另外一个常见的例子，本身只是视图预览器加上插件提供额外的功能。

对于基于产品的软件，这样的例子不胜枚举。但是对于大型商务软件来说呢？微内核系统同样也适用。我们以保险理赔软件为例。

保险理赔过程是一个非常复杂的过程。每个国家都有不同规定和要求关于什么是和不允许的情况。例如，一些州允许免费更换挡风玻璃如果你的挡风玻璃被岩石损坏，而其他州不可以。 这为标准索赔过程创造了几乎无限种条件。

毫不奇怪，大多数保险索赔程序利用大和复杂的规则引擎来处理这种复杂性。 然而，这些规则引擎可能会变得愈发复杂，当你改变一个规则同时会影响其他规则，或者做一个简单的规则改变就需要大量的分析、开发和测试时，使用微内核体系结构模式可以解决很多这种类型的问题。

图3-2中你看到的代表索赔处理过程的核心系统文件夹堆，它包含所需的基本业务逻辑，没有任何特定处理。 而每个插件模块都包含对应州的特定处理规则。 在这个例子中，插件模块的实现可以使用特定的源代码或单独的规则引擎实例。不管具体实现使用什么技术，核心思想是每个州特定的保险理赔规则和处理是从核心系统中分离出来的，它可被添加、删除、改变，而不会影响其他州的插件模块或核心系统。

注意事项

关于微内核体系结构模式的一个优点就是它可以嵌入或用作另一种架构模式的一部分。例如，如果这个模式解决了应用程序中的一个特定的问题而同时不能用这个模式来实现整个应用架构， 在这种情况下，你可以嵌入微内核架构模式到另一种模式（例如分层体系结构）。同样的，上一节中描述的事件处理、驱动架构上也可以使用微内核架构模式。

微内核架构模式提供了极大的支持给扩展中的设计和增量开发。 你可以创建一个固定的核心系统，随着应用程序的不断发展，可以相应的添加功能和特征，而不必对核心系统做大量变动。

对于基于产品的应用程序，微内核架构模式应始终作为您的首选架构，特别是对于那些未来你还会不断升级功能的产品同时又希望控制哪些目标用户人群有这些新功能的情况。如果你发现随着时间的推移，模式不满足所有的要求，你可以重构你的应用程序到更适合您的特定要求的另一种架构模式。

模式分析

整体敏捷度

评分：高

分析：整体敏捷度是能够快速响应不断改动的条件的能力。改动可以在很大程度上分割出来，并通过松散耦合的插件快速实施。一般来说，大多数微内核架构的核心系统会很快趋于稳定，由于它强大特性而且随着时间的推移仅仅需要很少的变化

部署容易性

评分：高

分析：根据模式的实现方法，插件模块可以在运行时（例如，热部署）动态地添加到核心系统，最大限度地减少停机部署时间。

可测性

评分：高

分析：插件模块可以进行单独测试，可以很容易被核心系统模仿来进行演示或者原型性，仅仅需要很少或根本没有变化。

性能

评分：高

分析：虽然微内核架构不是天然就是高性能应用程序，但一般来说，大部分使用微内核架构模式的应用程序表现优良，这是因为你可以自定义和简化应用程序到只包括需要的那些功能。 JBoss应用程序服务器就是一个很好的例子：通过它的插件架构，您可以将应用程序服务器减少到只有需要的功能，删除庞杂的不需要的功能，例如远程访问，消息队列和缓存消耗内存，CPU和线程。

可扩展性

评分：低

分析：因为大多数微内核架构的实现是基于产品的，规模都比较小，通常被实现为单个单元，因此不具有高度可扩展性。取决于插件架构的实现方式，有时你也可以在插件功能级别上，提供扩展性，但是总体来说，这种模式并不适于生成高可扩展性的应用

易于开发

评分：低

分析：微内核架构需要深思熟虑的设计和协议控制，这使其变得相当复杂去实现。协议版本控制，内部插件注册方式，插件粒度以及广泛的插件连接方法都会增加实施这种模式的复杂性。