业务模块的微前端架构

作者: 张阳君 分类: 前端技术

上一篇讲了纯UI模块的微前端架构,提到了使用脚手架作为中介,来连接模块开发和模块集成。这篇我们来讲讲,如果前端模块带有业务逻辑,该使用什么样的策略去架构微前端。

脚手架的困境

我一开始做微前端架构的时候,处理带业务的模块就是使用脚手架模式,结果在实际生产环境出现了几个大问题。第一点,这类带业务的前端模块都是可以独立运行的,不需要二次开发,所以用的人不需要关心其内部实现,对外应该表现为黑盒,而脚手架是面向开发者的,是代码透明的,这是战略方向错误。第二点,前端业务模块内部都带有ajax处理,模块底座和项目模板底座的ajax处理库得保证是同一个版本,模块是分布式的且数量众多,维护工作十分艰巨,因此处理业务模块需要另辟蹊径。

插件系统的启发

脚手架方案失败之后,想了很久都没有思路。后来灵光一闪想到了Wordpress的插件系统,他的插件系统非常强大,修改主题,添加业务功能都完全ok。那么如何应用到微前端领域呢?首先制作一个cms的本体,也就是插件系统本身,可以提前集成登录,插件管理之类的系统功能,然后给已有功能添加钩子。之后我们在插件管理页面添加插件包,通过开启额外的端口来管理插件包的解压,项目热启动等工作。这样,所有的插件包都是黑盒模式,并且可以在管理插件的详情页面修改接口域等信息,所有操作无需编码,快速高效。

插件系统的实现原理

和上一篇一样,这里我画了一张实现原理图:

业务模块微前端的实现原理

这里需要解释几个关键点:

  1. ajax处理包单独提取出去了,可以放在cdn或者npm上托管,这样开发和集成环境就能使用同一套的ajax处理代码了
  2. 业务底座本身也是一套插件系统,和本体一模一样,也可以独立开发,独立部署
  3. 额外的监听端口可以理解为插件系统内部的脚手架,做一些系统和文件方面的处理工作

结语

业务模块的微前端化基本可以忽略代码的二次开发,所以插件系统的黑盒模式更加人性化。最后总结一下我个人的看法:纯UI模块微前端使用脚手架实现,业务模块的微前端使用插件系统实现

(全文完)

1 条评论
回复
支持 Markdown 语法
vergil 发表于 5 个月前

非常不错!