聊聊微前端的那些事儿~

这是我参与11月更文挑战的第26天，活动详情查看：2021最后一次更文挑战

现在 微前端 这个概念在前端圈越来越火热，在2021年，如果你还没听过这个词，那就真的out了

本篇文章准备对微前端这个概念做下科普，通过阅读这篇文章，可以让你知道微前端是啥以及有啥作用，废话不多说，开搞！

什么是微前端

其实微前端是借鉴了 微服务 的理念创造出来的，那微服务是啥呢？它是将一个大的应用服务切分为多个子服务，从而解耦各个子服务，提升整体服务的健壮以及可维护性。微前端其实也是差不多的，传统方式开发出的web应用是一个 巨石应用，所有的功能、资源都绑定在一起，而微前端可以将这些巨石应用切分成许多 子应用，从而解耦各个功能模块，它跟微服务是异曲同工的

微前端架构下会分为父应用(基座)和子应用，父应用用来展示 公共部分，如header、footer，以及管理各个子应用，子应用是用来承载不同的业务功能

实现微前端的方案

目前实现微前端的方案还是很多的，列举如下

通过类似 nginx服务器 的转发，对不同的url返回对应的服务页面,这本质上是服务器利用路由转发的功能来实现的
通过 package 集成，具体方式如下
- 将巨石应用划分为 容器应用，子应用
- 将子应用作为容器应用的 依赖项

这种方式的缺点是每次对某一个子应用的更改，都需要重新编译打包所有应用，因此不推荐此类方式

通过 iframe 实现，由于iframe原生支持隔离，因此可以作为方案之一，但它的优点也是它的缺点，因为隔离太严格，导致路由、历史记录、深层链接、样式、应用之间的通信处理上变得较为复杂
使用 js 来构建微前端架构，由于该方式灵活和较为可控，因此这种方式是目前的主流。每个子应用独立构建和部署，运行时由父应用来进行路由管理，应用加载，启动，卸载，以及通信。但凡事没有完美，这种方式同样会有如下缺陷
- js全局变量污染与冲突，由于子应用与父应用跑在一个页面上，那么如果不做好隔离，就很容易产生污染与冲突的问题，解决方案的话通常是使用沙箱机制，具体方式是采用 with() + new Function(code) + Proxy 来实现
- css样式冲突，众所周知，css不存在模块系统，所有的css都是作用于全局的，因此如果很容易产生冲突。对于css隔离，一般使用BEM、cssModule、css in js、shadow dom来解决
使用 webComponents 来构建，但由于目前存在浏览器兼容以及浏览器实现上的一些bug，因此不推荐使用

微前端带来的好处

由于微前端可以将巨石应用切分为多个子应用，因此灵活性大大提高，具体可以带来如下好处

由于子应用之间的解耦，可以大大降低系统复杂度，提升系统稳定性
子应用之间的开发、测试、发布流程完全独立，可以由不同的团队进行负责
由于子应用之间的完全独立，因此可以使用不同的技术栈
代码库也会被切分为许多小的子库，更加便于维护与管理
可以较为平滑地迁入老项目

微前端带来的坏处

任何事情有舍就有得，微前端并不是完美的，它同样存在以下问题

重复依赖项较多
开发环境较难实现与生产环境一致，因为当微应用越来越多，在本地开发时肯定无法把所有微应用和对应的后端都启动起来，那么你就不得不在本地进行环境的简化
由于划分出了很多团队，那么对不同团队之间的协作提出了更高的要求

结语

微前端的应用越来越广泛，未来越是前端技术发展的趋势，因此一定要掌握它，才能在未来的技术浪潮站稳脚跟，因此，加油吧，骚年！