
课程咨询: 400-996-5531
投诉建议: 400-111-8989
认真做教育 专心促就业
微前端编程开发技术我们在前几期的文章中已经给大家说过很多次了,而本文我们就通过案例分析来简单了解一下,微前端开发架构模式与设计理念分享。
1、架构模式
微前端应用间的关系来看,分为两种:基座模式(管理式)、自组织式。分别也对应了两者不同的架构模式:
基座模式。通过一个主应用,来管理其它应用。设计难度小,方便实践,但是通用度低。自组织模式。应用之间是平等的,不存在相互管理的模式。设计难度大,不方便实施,但是通用度高。就当前而言,基座模式实施起来比较方便,方案上便也是蛮多的。
而不论种方式,都需要提供一个查找应用的机制,在微前端中称为服务的注册表模式。和微服务架构相似,不论是哪种微前端方式,也都需要有一个应用注册表的服务,它可以是一个固定值的配置文件,如JSON文件,又或者是一个可动态更新的配置,又或者是一种动态的服务。它主要做这么一些内容:
应用发现。让主应用可以寻找到其它应用。应用注册。即提供新的微前端应用,向应用注册表注册的功能。三方应用注册。即让三方应用,可以接入到系统中。访问权限等相关配置。
应用在部署的时候,便可以在注册表服务中注册。如果是基于注册表来管理应用,那么使用基座模式来开发比较方便。
2、设计理念
在笔者实践微前端的过程中,发现了以下几点是我们在设计的过程中,需要关注的内容:
中心化:应用注册表。这个应用注册表拥有每个应用及对应的入口。在前端领域里,入口的直接表现形式可以是路由,又或者对应的应用映射。标识化应用。我们需要一个标识符来标识不同的应用,以便于在安装、卸载的时候,能寻找到指定的应用。一个简单的模式,就是通过康威定律来命名应用。应用生命周期管理。高内聚,低耦合。生命周期
前端微架构与后端微架构的大不同之处,也在于此——生命周期。微前端应用作为一个客户端应用,每个应用都拥有自己的生命周期:
Load,决定加载哪个应用,并绑定生命周期bootstrap,获取静态资源Mount,安装应用,如创建DOM节点Unload,删除应用的生命周期Unmount,卸载应用,如删除DOM节点、取消事件绑定这部分的内容事实上,也就是微前端的一个难点所在,如何以合适的方式来加载应用——毕竟每个前端框架都各自不同,其所需要的加载方式也是不同的。当我们决定支持多个框架的时候,便需要在这一部分进入更细致的研究。