引言

Plug-in Architecture

如上图所示，这可能是我们每天可能使用和接触的事情，但是很容易被我们忽视这种架构设计思想的存在，如：浏览器插件、Eclipse IDE插件，VS code IDE等。

它不仅存在于一些基础的产品或应用程序中，例如：Eclipse IDE可以通过添加插件和进行自定义的浏览器，而且在我们的应用程序中也随处可见，例如：业务规则和数据处理逻辑都可以根据需求进行插件化设计，例如：在保险索赔和税收等方面。

其实，插件化架构的设计思想很简单，就是能够将功能插件插入到现有的组件当中，而该组件无法感知这些插件功能的实现细节。

或许，有一些词语你听说过，如：多态性（OOP）、保护模式（设计原则）、策略模式（设计模式）等。

的确，插件化架构设计背后确实隐藏了很多相同的概念。

概述

总的来说，插件体系架构由两个核心的组件构成：核心系统和插件模块。其中最主要也是最关键的是允许向核心应用程序添加其它功能作为插件，从而提供可扩展性、灵活性及应用程序功能和自定义处理逻辑的隔离。

具体的规则和处理与核心系统是分开的，任何时候，我们都可以添加、删除和更改现有的插件，而对核心系统或其它插件毫无影响。

核心系统最为插件架构的顶层设计，它定义了系统的的操作方式和基础业务逻辑。它是系统的抽象层，没有特定的实现及定制要求。

举一个简单的例子，例如：工作流引擎，它定义了应用程序内部的数据流方式。但是工作流中涉及的步骤取决于插件。因此，所有的扩展插件都将遵循通用的流程，以便提供其自定义的实现。

插件是一个独立的组件，它包含独立的处理逻辑、附加功能和自定义代码，目的在于增强或扩展核心系统产生附加的功能。

通常来说，插件模块应该独立于其它插件模块。但是，某些插件需要与其它插件进行通信或假定其它插件的存在。

无论哪种方式，保持通信和插件之间的依赖关系（耦合）到最小是最重要的。

对于核心系统来说需要了解（1）有哪些扩展插件模块（2）如获取加载这些插件。核心系统定义了插件可连接的扩展点，而这些扩展点（钩子）通常表示核心系统的生命周期管理。

因此，每个插件都要将自己注册到内核中，并传递一些信息给外部知道，例如：插件名称、通信协议、输出/输出数据处理器，数据格式以及这些扩展点的钩子，就好像设计模式中的模版方法一样；

通常来说，内核和插件之间应该有一个明确的接口定义；

内核系统如何连接到这些插件完全取决于应用程序构建的类型（小型产品或大型业务应用程序）和用户特定的需求（例如：单机部署和分布式部署）。