插件化架构设计(1):插件化架构能解决什么问题？为啥选它？

前面是概念内容，在实现的时候，google 搜的资料进行汇总所做的笔记，看具体事件，从 标题 “插件实践方案” 开始看

如何解决代码重用、快速开发

随着MVVM的框架和库的流行，想必组件化开发已经成为了前端开发的主流思想，特别是Vue、React、Angular已经有比较成熟的开发模式、社区和UI组件库

『成熟型功能明确产品』和『面向企业或单位的部分功能不明确产品』都有一些共同的特点。

• 很大部分逻辑功能是相同的，它们可能会用在很多的系统里面

• 这些功能是需要维护的，不可能维护一个功能要去N个系统里面修改

• 修改某一部分功能不会影响到其他功能，可以随时上线，全站回归的成本太高

整体思路的解决思路是渐进式的封装到可视化开发

建立内部UI组件库（封装粒度小）

1. 基于UI组件库搭建业务组件库（封装粒度一般，有部分功能逻辑）

2. 基于UI组件库和业务组件库建立插件库（封装粒度大，包含完整业务逻辑）

3. 基于插件化开发的模板编译生成页面代码

4. 基于平台的可视化配置+模板编译的低代码开发平台

插件与组件的区别

插件本质也是一种软件复用方式，和我们常说的组件区别是复用的维度不同。

• 组件的复用颗粒度更细，它是技术级复用单元，需要经过进一步加工和组合才能成为解决某一类业务问题的完整部分

• 插件是一个更加完整可以解决某一类业务问题的子系统，是业务级别的复用单元。

比如对Android开发而言，插件化和组件化区别

• 组件化：是将一个App分成多个模块，每个模块都是一个组件（module），

  开发过程中可以让这些组件相互依赖或独立编译、调试部分组件，但是这些组件最终会合并成一个完整的Apk去发布到应用市场。

• 插件化：是将整个App拆分成很多模块，每个模块都是一个Apk（组件化的每个模块是一个lib），

  最终打包的时候将宿主Apk和插件Apk分开打包，只需发布宿主Apk到应用市场，插件Apk通过动态按需下发到宿主Apk。

在现有软件开发中，业务越来越复杂，代码规模越来越大，依赖的人力也越来越多。为了降低系统模块内部耦合度，减少开发难度，也为了能够支持多团队的并行开发，插件式开发架构变得愈加流行，Eclipse, Visual Studio, VSCode等，都是插件式开发架构的典型案例。

现代软件提供插件式开发架构，一方面是服务于产品自身内部开发，另外一方面服务于市场化。借助于市场上各领域开发人员，在某一款软件（开源or商业）上进行面向新领域的开发，可以大大提高该产品的市场占有率，并衍生出一系列各领域的代理商及咨询业务。

现实中，硬件开发其实很多也是插件化思想的

像PC制造，各个功能模块就可以理解为插件。

 

插件化，最大的优势就是按照功能区分，系统耦合度低，一块功能的添加或删除，并不影响其他功能的使用。

如果所有的功能都打包在一个工程内，简单可靠，但扩展性极为不佳，扩展功能的成本非常之高，但效率和代码量均较小。

如果将各个功能拆分成为各个组件，组件间相互调用，这样可以使得系统的耦合度降低，但添加了诸多的数据传递代码

系统的每一部分，都只是一个插件，所有部分都是平级的，可能GUI用来加载并引导框架启动，但其也必须是一个插件，才能被其他组件调用。组件和组件间的循环依赖是可以的，因为大家都仅仅保护对应插件的接口工程。

 

为什么是插件化开发

借用内核+应用软件开发的思想，首先有一个插件调度的核心，在这个核心的支持下可以开发支持这个核心的应用程序，我把这些应用程序称为『插件』，插件是一个具有完整逻辑的应用程序，它不依赖任何其他的插件，只需要依赖核心即可在系统中独立运行。

为什么需要插件

我们的软件系统往往是要面向持续性的迭代的，在开发之初很难把所有需要支持的功能都想清楚，有时候还需要借助社区的力量去持续生产新的功能点，或者优化已有的功能。这就需要我们的软件系统具备一定的可扩展性。插件模式就是我们常常选用的方法。

事实上，现存的大量软件系统或工具都是使用插件方式来实现可扩展性的。比如大家最熟悉的小可爱——VSCode，其插件拥有量已经超越了他的前辈 Atom，发布到市场中的数量目前是 24894 个。这些插件帮助我们定制编辑器的外观或行为，增加额外功能，支持更多语法类型，大大提升了开发效率，同时也不断拓展着自身的用户群体。又或者是我们熟知的浏览器 Chrome，其核心竞争力之一也是丰富的插件市场，使其不论是对开发者还是普通使用者都已成为了不可获取的一个工具。另外还有 Webpack、Nginx 等等各种工具，这边就不一一赘述了。

根据目前各个系统的插件设计，总结下来，我们创造插件主要是帮助我们解决以下两种类型的问题：

• 为系统提供全新的能力
  

• 对系统现有能力进行定制

同时，在解决上面这类问题的时候做到：

• 插件代码与系统代码在工程上解耦，可以独立开发，并对开发者隔离框架内部逻辑的复杂度
  

• 可动态化引入与配置

并且进一步地可以实现：

• 通过对多个单一职责的插件进行组合，可以实现多种复杂逻辑，实现逻辑在复杂场景中的复用

这里提到的不管是提供新能力，还是进行能力定制，都既可以针对系统开发者本身，也可以针对三方开发者。

结合上面的特征，我们尝试简单描述一下插件是什么吧。

• 插件一般是可独立完成某个或一系列功能的模块。

• 一个插件是否引入一定不会影响系统原本的正常运行（除非他和另一个插件存在依赖关系）。

• 插件在运行时被引入系统，由系统控制调度。

• 一个系统可以存在复数个插件，这些插件可通过系统预定的方式进行组合。

 

 

 

参考文章：

前端插件化架构的思考 https://cloud.tencent.com/developer/article/1600005

前端插件化架构的探索和实践 https://segmentfault.com/a/1190000024527170

译] React 16.6 懒加载(与预加载)组件 https://juejin.cn/post/6844903753200451592

前端，何不尝试一下『插件化』开发 https://juejin.cn/post/6844904118591422472

插件化？好像也就那么回事 https://juejin.cn/post/7143869920193822733

 

 

 

转载本站文章《插件化架构设计(1):插件化架构能解决什么问题？为啥选它？》,
请注明出处：https://www.zhoulujun.cn/html/webfront/engineer/Architecture/8755.html