2022年 微前端技术调研- 图文并茂

一.动机

在 我们 的前端开发工作中，我们往往就会遇到如下困境：

• 工程越来越大，打包越来越慢

• 团队人员多，产品功能复杂，代码冲突频繁、影响面大

• 内心想做 SaaS 产品，但要求总是要做定制化

• 不同的团队可能有不同的方法去解决这些问题。在前端开发日新月异、前端工程化蓬勃发展的今天，就衍生了另一种尝试——微前端。

二.背景

微前端是一种类似于微服务的架构，它将微服务的理念应用于浏览器端，即将 Web 应用由单一的单体应用转变为多个小型前端应用聚合为一的应用。各个前端应用可以独立运行、独立开发、独立部署。

微前端的概念由ThoughtWorks于2016年提出，此后很快被业界所接受，并在各互联网大厂中得到推广和应用。

微服务与微前端有很多相似之处，都是希望将某个单一的单体应用，转化为多个可以独立运行、独立开发、独立部署、独立维护的服务或者应用的聚合，从而满足业务快速变化及分布式多团队并行开发的需求。微服务与微前端不仅仅是技术架构的变化，还包含了组织方式、沟通方式的变化。微服务与微前端原理和软件工程，面向对象设计中的原理同样相通，都是遵循单一职责(Single Responsibility)、关注分离(Separation of Concerns)、模块化(Modularity)与分而治之(Divide & Conquer)等基本的原则。

简单地说，就是将一个巨无霸（Monolith）的前端工程拆分成一个一个的小工程。别小看这些小工程，它们也是“麻雀虽小，五脏俱全”，完全具备独立的开发、运行能力。整个系统就将由这些小工程协同合作，实现所有页面的展示与交互。

可以跟微服务这么对比着去理解：

欣赏下（阿里云）微前端的基本工作原理

三. 微前端的优缺点

优点

• 敏捷性 - 独立开发和更快的部署周期：

• 开发团队可以选择自己的技术并及时更新技术栈。

• 一旦完成其中一项就可以部署，而不必等待所有事情完毕。

• 降低错误和回归问题的风险，相互之间的依赖性急剧下降。

• 更简单快捷的测试，每一个小的变化不必再触碰整个应用程序。

• 更快交付客户价值，有助于持续集成、持续部署以及持续交付。

• 维护和 bugfix 非常简单，每个团队都熟悉所维护特定的区域。

缺点

开发与部署环境分离

• 本地需要一个更为复杂的开发环境。

• 每个 App 模块有一个孤立的部署周期。

• 最终应用程序需要在同一个孤立的环境中运行。

• 复杂的集成

• 需要考虑隔离 JS，避免 CSS 冲突，并考虑按需加载资源

• 处理数据获取并考虑用户的初始化加载状态

• 如何有效测试，微前端模块之间的 Contract Testing？