前端插件化架构的思考

前言

有挺长时间没有更新博客了。一来是公司比较忙，二是本身也在思考一些新的问题。最近一个月，在我脑海回想最多的一个词语是“插件化架构”。做此文，也是想简单分享一下我对这个问题的看法。

来自 Webpack 的启发

去年有参与过 Udacity 前端课程翻译。其中我翻译了构建工具部分。Webpack 做为当前主流构建工具，深入影响着前端开发工做流的变革，正如课程中所说，Webpack 聚合当前前端构建工具全部最热门的构建技术，甚至能够说，它能够做任何构建工具能做的事。那么 Webpack 为何这么全能，是由于 Webpack 自身这么能干，精通十八般武艺？No !事实上 Webpack 比想象的要“无能”，它的全能是由于它能容万物只所能。由于 Webpack 自己是一个高度插件化设计的系统，它所表现的能力都借助于真正身怀绝技的插件的赋能。固然，我这里所说的插件包含了 Webpack 的内置插件以及经过配置传入的plugins。能够说，Webpack 只抽象了一个软件运行时环境，在不关心和改动这个系统已有代码的前提下，却能独立开发新的插件来充实整个系统的能力。这不就是软件设计中所要追求的开闭原则的最佳实践吗？从 Webpack 的插件化架构设计上所表现出系统良好的开放性，可持续的简洁性，我天然想象到，为什么不在业务系统中采用这样的插件化架构。

什么是插件？

插件的英文是plugin，拆分开是plug(插头) + in，现实生活生活中，电源插线板就是这样"plugin"应用的例子。插线板和经过插头插入其中的电器构成一个物理世界的插件化系统。插线板经过插孔为“插件”提供电源，而给系统赋予了插件的能力。插入电视的插头，就拥有看电视的功能，插入冰箱的插头就具备冷藏食物的功能，插入台灯的插头，就具有照明的功能，等等。

一个良好设计的插件化系统和插线板的设计也是同样同样的。系统的核心应该是一个可热插拔的“插线板”，负责给系统接入的插件提供电源（插件API），系统的能力是全部插件能力的聚合。和物理世界的插线板不一样是，软件插线板的插头没有数量的限制，也就是说系统能够接入任意数量的插件，意味着它的功能能够无限增长。

如何设计一个插件化的系统？

若是类比插线板的方式设计一个彻底插件化的系统，系统将包含三个部分：

• pluggableCore: 插件运行时核心
• pluginApi: 为插件运行提供访问运行时接口
• plugin: 实现具体功能的插件

其中 pluggableCore 与 pluginApi 是插件化系统的核心部分，或者内部系统，一旦设计好了，不会轻易改变的；而plugin是外部系统，经过pluginApi访问系统内核和全局状态，实现对应用全生命周期的访问和控制，只须要遵循接口的定义，plugin 能够将自身能力赋予给任何插件化系统，而不是与某一个特定的系统耦合在一块儿。 事实上，plugin 也分为两个部分。咱们依然能够与现实世界的电器，例如上文的电视机对比，它包含用于接入电源的插头和用于播放电视节目物理实现，咱们能够看到，虽然电视机是经过电源线才成为整个系统中的插件一员，但它的物理实现远比电源线复杂的多，甚至能够独立出来一个复杂的系统。一样，插件化系统中，插件的功能实现也多是一个可独立出来复杂系统，而只是经过一个简单的插件注册或应用接口接入另外一个插件的系统。

以 webpack 的插件为例。如下是 webpack 插件的模版：

import VeryComplicatedSystem from "VeryComplicatedSystem";

class AwesomeWebpackPlugin {
    apply(compiler) {
        VeryComplicatedSystem.apply(compiler);
    }
}
复制代码

咱们看到插件的电源线就是包含apply方法的类，只须要5行代码。而插件的功能实现能够是一个独立的复杂系统，它还能够是多个插件的聚合。固然从设计上，插件的功能单一更有利于复用。这里所要表达的是咱们应该把插件看做一个能够脱离插件系统自己存在的功能完整软件系统，让这个系统成为插件而为另外一个插件化系统赋能并不须要重写内部实现，而只是加上一根符合插件标准的电源线而已。这样理解，有助于咱们设计出更容易复用的插件，同时也能够复用已有软件的系统。

插件化架构的优点

正如前文所说，插件化架构一个显而易见的优点就是它是开闭原则在跨系统级别的最佳实践。何为跨系统，若是说设计模式是设计单个系统的最佳实践，那么咱们已经论证，插件化架构能够连接多个子系统，而作到开闭原则。即插件核心和接口不变，系统能够持续接入新插件，来丰富系统的功能。而且，因为新接入的插件是一个独立的子系统，它可独立开发，运行和进行版本管理，不会由于接入的系统复杂而增长接入成本。试想，在一个非插件化的系统中，业务系统就算通过良好设计，随着功能模块的增多，代码量激增，暂且不考虑系统构建和测试，咱们想要给系统加入新的功能，甚至是修复已有功能的BUG，都会愈来愈困难和低效，但插件化架构的系统，增长新功能，不是在一个庞大系统代码库中，而是在一个较小的系统或代码仓库中，所以无论已有系统多复杂，开发新的功能的接入复杂度始终同样。同时，开发编译或修复测试一个插件，也比针对整个系统要简单得多。

插件与组件的区别

插件本质也是一种软件复用方式，和咱们常说的组件区别是复用的维度不一样。组件的复用颗粒度更细，它是技术级复用单元，须要通过进一步加工和组合才能成为解决某一类业务问题的完整部分，而插件是一个更加完整能够解决某一类业务问题的子系统，是业务级别的复用单元。

插件化架构的将来

这里很差说它必定是将来。暂且认为是我设想的将来发展的一种可能。即经过创建一个插件标准，实现业务系统的全面插件化，全部以开发和正在的开发的系统都不是耦合在一个特定的系统，而很难独立出来，在不一样系统复用。全面的插件化，意味着，咱们不用重复造业务轮子，团队和企业能够持续积累本身的插件生态，让软件开能够像汽车等工业制造同样，打造一条标准化装配的流水线。

结语

本文的观点仅是我的思考，还没有通过权威的论证。其中的设想有过初期实践，但还没有造成一个完整的能够推广的技术框架，这部分笔者本人还在探索中，就不贴出来，感兴趣的读者能够关注个人 github。