微前端 —— 理论篇

Winer

1. 微前端

        基于spa类的单页应用,随着企业工程项目的体积越来越大,开发的功能越来越多,页面也越来越多,项目随之也变得越来越臃肿,维护起来十分困难,往往改一个logo,或者改一个小样式,都要将项目全部重新打包一遍,维护困难,部署也困难。
        因此前端在借鉴后端的微服务架构模式后,衍生了微前端架构,将一个功能繁多的单页应用转换为多个小型单页应用的组合,这些小型应用往往具有独立开发、独立运行、独立部署的特点。它们通常与技术栈无关,不同的应用可以用react开发,也可以用vue开发,但是它们始终能组成一个完整的应用。

2. 可实现方式

        以下是基于我已经实现的方式介绍的(毕竟没亲手操作过,啥也吹不出来啊)

  1. iframe(难度:1)
  2. single-spa(难度:4)

3. iframe

         iframe实现的方式很简单,这里就简单阐述一下。通常是一个portal项目作为各个小型应用项目的入口,此portal项目包含业务菜单,权限控制等,而各个小型应用项目独立开发,打包并部署到各自服务器上面,在portal项目中,通过将需要展示的小型应用的url赋值给iframe的url,将其内嵌在portal项目中即可,十分简单。
         优点:实现简单
         缺点:iframe与主页面共享连接池;由于iframe与主页面的静态资源文件无法共享,所以相同的依赖在各个项目中独自打包,导致用户需要加载很多重复的依赖,例如react.js、vue.js等,这是影响性能的主要原因;还有一个就是用户缩放等操作,iframe内部的样式无法同时适配。

4. single-spa

官网链接

         single-spa在官网中被自称为一个元框架,可以实现在一个页面将多个不同的框架整合,甚至在切换的时候都不需要刷新页面(支持 React、Vue、Angular 1、Angular 2、Ember 等等)
         官网中的例子是所有项目都在同一个仓储中的,这显然违背了我们的初衷,我们需要每一个小应用都有自己独立的仓储,好在官网中也推荐了一个System框架的案例,实现了各个小应用的独立仓储。

        *现在开始从头搭建我们的微前端架构*。我们要实现的应用是一个主菜单,五个小页面,每个菜单对应一个页面。有一个menu应用,里面包含了菜单的跳转;一个react应用,其中包含3个页面;一个vue应用,包含两个页面。
        项目架构:
图片描述

        其中menu是主菜单应用;portal是应用注册、路由分发等服务和共同依赖包(react、react-dom等)的抽离;project1是react应用,包含3个子页面;project2是vue应用,包含2个子页面。

        由于有些项目的搭建过程太过繁琐,我将分为三篇文章分别介绍portal项目的搭建、project1与menu项目的搭建、project2项目的搭建。


        项目源码

        微前端 —— portal项目
        微前端 —— menu&&project1(React)
        微前端 —— project2项目(VUE

阅读 8.4k

一入前端深似海

455 声望
200 粉丝
0 条评论

一入前端深似海

455 声望
200 粉丝
文章目录
宣传栏