微前端的概念最早由 thoughtworks 在 2016 年提出。微前端作为近些年来前端发展的热词，大中型企业也在部署微前端应用，像百度，腾讯，阿里等第一梯队大厂也完成了微前端的应用部署，正在逐级优化框架内容。
那作为前端开发人员，我们需要对微前端有比较深入的理解，并且能够实践到项目中。那到底是什么（What）是微前端呢？怎么用（How）、为什么用（Why）都是我们需要探讨的问题。下面我们就开始微前端的神秘探索之路吧。

由来

在SPA应用发展成为主流的趋势下，如果一个大型应用采用纯粹的SPA（单页应用），那么势必也会带来性能、开发、迭代、维护、用户体验等各种问题。项目开发过程中，你是否遇到以下几种情况？

1. 项目迭代开发过程中，项目体积越来越大，打包越来越慢、首页加载越来越慢了?

2. 一些插件的升级和公共组件需要修改，但很多地方都复用了，这一修改就牵一发而动全身。

3. 多人合作开发时，公共文件合并代码就冲突？

4. 把一个旧系统接入到平台中来，难道我要把这个项目代码全部拷贝进来、然后再一起运行打包吗？

5. 项目是用vue开发的，需要我开发一个模块，但是我只会react，不会要我去学vue吧？

想必都或多或少经历过这些痛点，微前端的出现就是为了解决这些痛点。那微前端是怎么解决这些问题的呢？
这里先介绍下后端的微服务。如下图一个系统有Web端、Wap端、App端和后台管理系统，那么整个系统的结构大概就像这样：

 这样的架构设计会造成什么问题呢？

• 单体服务端项目过大，不利于快速上手和打包编译；

• 不同系统会有相同的功能点，导致产生大量重复的无意义的接口；

• 数据库设计复杂。

那么微服务如何解决这个问题呢？
微服务旨在解决庞大的一整块后端服务带来的变更与扩展方面的限制问题。也就是就是将系统拆分成不同的服务，通过网关和controller来进行简单的控制和调用，各服务分而治之、互不影响。 

通过服务的拆分后，系统的项目架构变得很清晰，后期的角色分工和并行开发都很明确。

微前端的设计思路和微服务如出一辙，就是两个字：解耦。将每种业务拆分成单个模块进行开发维护，每个模块独立分工。微前端架构旨在解决单体应用在一个相对长的时间跨度下，由于参与的人员、团队的增多、变迁，从一个普通应用演变成一个巨石应用(Frontend Monolith)后，随之而来的应用不可维护的问题。

概念

微前端是一种多个团队通过独立发布功能的方式来共同构建现代化 web 应用的技术手段及方法策略。

Techniques, strategies and recipes for building a modern web app with multiple teams that can ship features independently.

说的通俗些，也就是将前端应用分解成一些更小、更简单的能够独立开发、测试、部署的小块，最终再由一个容器应用，将拆分后的微前端工程组合为一个整体，面向用户提供服务。在用户看来仍然是内聚的单个产品。

优势和缺陷

微前端架构具备以下几个核心价值：

• 技术栈无关
  主框架不限制接入应用的技术栈，微应用具备完全自主权。

• 独立开发、独立部署
  微应用仓库独立，前后端可独立开发，部署完成后主框架自动完成同步更新

• 增量升级 在面对各种复杂场景时，我们通常很难对一个已经存在的系统做全量的技术栈升级或重构，而微前端是一种非常好的实施渐进式重构的手段和策略

• 独立运行时
  每个微应用之间状态隔离，运行时状态不共享

用处

满足以下几点，你可能就不需要微前端

基于以上两个观点，我们可以概括出，存在以下场景时，你可能就不需要微前端：

1. 你/你的团队 具备系统内所有架构组件的话语权
   简单来说就是，系统里的所有组件都是由一个小的团队开发的。

2. 你/你的团队 有足够动力去治理、改造这个系统中的所有组件 直接改造存量系统的收益大于新老系统混杂带来的问题。

3. 系统及组织架构上，各部件之间本身就是强耦合、自洽、不可分离的
   系统本身就是一个最小单元的「架构量子」，拆分的成本高于治理的成本。

4. 极高的产品体验要求，对任何产品交互上的不一致零容忍
   不允许交互上不一致的情况出现，这基本上从产品上否决了渐进式升级的技术策略

满足以下几点，你才确实可能需要微前端

1. 系统本身是需要集成和被集成的 一般有两种情况：

2. 旧的系统不能下，新的需求还在来。
   没有一家商业公司会同意工程师以单纯的技术升级的理由，直接下线一个有着一定用户的存量系统的。而你大概又不能简单通过 iframe 这种「靠谱的」手段完成新功能的接入，因为产品说需要「弹个框弹到中间」

3. 你的系统需要有一套支持动态插拔的机制。
   这个机制可以是一套精心设计的插件体系，但一旦出现接入应用或被接入应用年代够久远、改造成本过高的场景，可能后面还是会过渡到各种微前端的玩法。

4. 系统中的部件具备足够清晰的服务边界
   通过微前端手段划分服务边界，将复杂度隔离在不同的系统单元中，从而避免因熵增速度不一致带来的代码腐化的传染，以及研发节奏差异带来的工程协同上的问题。

总结

本文介绍了微前端的基本概念、由来、优缺点和用处。重点介绍了微前端解决的痛点。需要注意的是，微前端并不是一门新技术，而是一种新的架构方式。

链接: https://fly63.com/article/detial/11047