微前端学习

1、什么是微前端

微前端是一种架构风格，其中众多独立交付的前端应用组合成一个大型整体。

将前端应用分解成一些更小、更简单的能够独立开发、测试、部署的小块，而在用户看来仍然是内聚的单个产品——这样的一个架构思想称为【微前端】。

2、为什么要提出微前端

任何新技术的产生都是为了解决现有场景和需求下的技术痛点。
微服务所解决的痛点：

• 拆分与解耦

目前，单页面应用（SPA）是非常流行的项目形态之一，随着业务的拓展以及应用功能的丰富。单页面应用变得不再单一而是越来越庞大也越来越难以维护，往往是改一处而动全身，由此带来的打包、发版成本也越来越高。
微前端的意义就是将这些庞大的应用进行拆分，并随之解耦，每个部门可以单独进行维护和部署，提升效率。

• 整合历史系统

在不少业务中，或多或少会存在一些历史项目，也没有足够的精力和胆量去升级重构。
微前端可以对老旧项目进行少量代码修改之后，将老旧项目整合到新的项目应用中。

3、微前端的特点

微前端的优点

• 独立开发部署，加快编译、打包速度
• 减少首屏加载内容，增加首屏加载速度
• 应用自治

只需要遵循统一的接口规范或者框架，以便系统集成到一起，相互之间是不存在依赖关系的。

• 单一职责

每个前端应用可以只关注于自己所需要完成的功能。

• 技术栈无关

每个模块之间使用的技术栈都不相互影响，可以使用不同的技术栈

微前端的缺点

• 开发体验不太友好
• 使用多种的技术栈：依赖复杂，管理成本高
• 相对与SPA体验有折损

4、微前端的方案

架构模式

• 基座模式：通过一个主应用，来管理其它应用。设计难度小，方便实践，但是通用度低。
• 自组织模式：应用之间是平等的，不存在相互管理的模式。设计难度大，不方便实施，但是通用度高。

技术方案

方案	描述	优点	缺点
Nginx路由转发	Nginx配置反向代理来实现不同路径映射到不同应用，例如www.abc.com/app1 对应app1，www.abc.com/app2 对应app2，这种方案本身并不属于前端层面的改造，更多的是运维的配置	简单，快速，易配置	在切换应用时会触发浏览器刷新，影响体验
iframe嵌套	父应用单独是一个页面，每个子应用嵌套一个iframe，父子通信可采用postMessage或者contentWindow方式	实现简单，子应用之间自带沙箱，天然隔离，互不影响	iframe的样式显示、兼容性等都具有局限性；太过简单而显得low
Web Components	每个子应用需要采用纯Web Components技术编写组件，是一套全新的开发模式	每个子应用拥有独立的script和css，也可单独部署	对于历史系统改造成本高，子应用通信较为复杂易踩坑
组合式应用路由分发	每个子应用独立构建和部署，运行时由父应用来进行路由管理，应用加载，启动，卸载，以及通信机制	纯前端改造，体验良好，可无感知切换，子应用相互隔离	需要设计和开发，由于父子应用处于同一页面运行，需要解决子应用的样式冲突，变量对象污染，通信机制等技术点

微前端拆分方式

• 按照业务拆分
• 按照权限拆分
• 按照变更的频率拆分
• 按照组织结构拆分
• 跟随后端微服务划分

5、微前端的难点

• 资源的隔离：由于存在不同应用各自定义CSS和全局变量的情况，应用聚合时需要考虑彼此之间的影响。应用JS沙箱和CSS隔离等相关技术，使各应用之间互不影响。
• 应用的注册：Html Entry 和 Config Entry，是关于如何注册子应用信息。
• 对性能的影响：按需加载、公共依赖加载和预加载，是关于性能的，这些很重要，否则虽然上了微前端，但性能严重下降，或者由于升级引起线上故障，就得不偿失了。
• 应用间通信：父子应用通讯，顾名思义，无需解释。
• 应用嵌套/并行：子应用嵌套 和 子应用并行 是微前端的进阶应用，在某些场景下会用到。

本文地址：https://blog.csdn.net/weixin_44379204/article/details/110953849