「这是我参与11月更文挑战的第5天，活动详情查看：2021最后一次更文挑战」
随着前后端分离技术越来越成熟，后端向着微服务发展，前端项目也越发臃肿起来，不得不做更细粒度的拆分，就这样微前端的思想开始盛行，一些大厂也出台了一些解决方案，本文就让我们一起来了解一下微前端。
1 前端如何发展到微前端？
从最早期的前后端不分离，借助后端进行页面渲染，JSP、ASP、PHP技术盛行。随着项目不断扩大，这种开发形式的弊端也逐渐暴露出来，前端后端越来越复杂，前后耦合严重，不方便分工协作。然后前后端分离的模式诞生，喜欢做用户体验的工程师，专心研究前端，喜欢优化服务器性能，喜欢和数据打交道的工程师研究后端。前后端分离，各自的技术也在不断升级，后端开始向着微服务发展，前端也随着岁月的沉淀，项目变的臃肿，打包编译速度也在不断变慢，而且想要尝试新的技术时，大规模的替换旧代码风险升高，进而前端也面临着拆分，就这样前端发展到微前端时代。
2 什么是微前端?
理解什么是微前端就要先了解什么是微服务，微服务就是后端面向服务架构的一种升级，借助轻量级的通信协议将一个一个的服务组织起来，形成一整套服务，每个服务之间松耦合，可以是不同的语言开发的，每个服务提供不同的职责，最后再组织在一起，对外提供功能。
微前端可以说是吸收了微服务这种思想，将前端的项目也拆分开来，每个项目可以使用不同技术，可以单独部署，最后再借助统一的主应用来加载子应用，将页面集成到一起。
微前端就是将不同的功能按照不同的维度拆分成多个子应用。通过主应用来加载这些子应用。
微前端的核心在于拆, 拆完后再合!
3 微前端有哪些优势?
- 简单、松耦合
- 代码库更小，高内聚，更容易维护，更快的编译速度
- 渐进式的升级，降低前端代码重构风险
- 可独立部署
- 方便不同团队（不同技术栈）开发，最后集成到一起
- 老的应用丢弃不了
- 共享组件
4 微前端的实现方案有哪些？
-
服务端集成，必要的话，可以在服务端也建立一套与前端相对应的结构，使用HTTP服务器的路由重定向多个应用。
-
iframe
最大的特性就是提供了浏览器原生的硬隔离方案，不论是样式隔离、js 隔离这类问题统统都能被完美解决。正是因为其强大的隔离性，使其路由控制、历史栈管理、跨域问题等等变得难以解决，限制了其灵活性。
-
Web Components
将微应用封装成自定义 HTML 元素，以获得样式隔离等好处。
其核心依赖于以下四项技术组件：
- Custom elements（自定义元素）：允许自定义元素及其行为，然后可以在用户界面中按照需要使用。
- Shadow DOM（影子DOM）：将封装的影子DOM树附加到主文档DOM树中，并且可以控制其关联的功能。通过这种方式，可以保持元素的功能私有，不用担心与文档的其他部分发生冲突。
- HTML templates（HTML模板）：
<template>和<slot>元素使您可以编写不在呈现页面中显示的标记模板。然后它们可以作为自定义元素结构的基础被多次重用。 - HTML Imports，可以通过
<link rel="import" href= "/*.html">引入自定义组件。
-
ESM
ESM 存在着 兼容性 这一大弊端, 大部分老版的浏览器 仍然无法直接使用，他可以通过 webpack、 rollup、 esbuild 、 snowpack等编译工具成为兼容性的代码。
-
single-spa
single-spa 是一个用于前端微服务化的JavaScript前端解决方案，实现了路由劫持和应用加载，其本身没有处理样式隔离、js隔离。
-
qiankun
真正意义上的单页微前端框架，基于single-spa封装，增加了 umi 特色，增加沙箱机制。
-
icestark
与 qiankun 同出自阿里， React 技术栈的微前端解决方案
-
piral
基于 TypeScript，React 技术栈的微前端解决方案
-
Mooa
Mooa 是为 Angular 定制的微前端框架，也是基于 single-spa 思想，针对 IE 10 及 IFRAME 优化的微前端解决方案。
Mooa 采用的是主-从式架构，分为主工程和子工程，主工程负责加载子工程，以及一些核心的管理功能。
-
EMP
欢聚时代业务中台自主研发的 单页微前端解决方案
-
...
5 结束语
作为一名后端工程师，对前端一些细节把握确实不够到位，但是微服务，微前端为我们的项目带来了更多的可能性，这种技术演进的方向值得我们深思，说不定主导下个技术时代的，就是浏览的各位。
