本文共 1574 字，大约阅读时间需要 5 分钟。

概念

微前端是一种类似于微服务的架构，它将微服务的理念应用于浏览器端，即将单页面前端应用由单一的单体应用转变为把多个小型前端应用聚合为一的应用。各个前端应用还可以独立开发、独立部署。简单说就是将前端应用分解成一些更小、更简单的能够独立开发、测试、部署的小块，而在用户看来仍然是内聚的单个产品。

微前端的好处

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

2.单一职责。每个前端应用可以只关注于自己所需要完成的功能。

3.技术栈无关。你可以使用 Angular 的同时，又可以使用 React 和 Vue。

微前端的缺点

• 应用的拆分基础依赖于基础设施的构建，一旦大量应用依赖于同一基础设施，那么维护变成了一个挑战。
• 拆分的粒度越小，便意味着架构变得复杂、维护成本变高。
• 技术栈一旦多样化，便意味着技术栈混乱

微前端架构模式

微前端应用间的关系来看，分为两种：基座模式（管理式）、自组织式。分别也对应了两者不同的架构模式：

基座模式。

自组织模式。

当前基座模式用的比较多。

设计理念

• 中心化：应用注册表。这个应用注册表拥有每个应用及对应的入口。在前端领域里，入口的直接表现形式可以是路由，又或者对应的应用映射。
• 标识化应用。 我们需要一个标识符来标识不同的应用，以便于在安装、卸载的时候，能寻找到指定的应用。一个简单的模式，就是通过康威定律来命名应用。
• 应用生命周期管理。
• 高内聚，低耦合。

生命周期

前端微架构与后端微架构的最大不同之处，也在于此——生命周期。微前端应用作为一个客户端应用，每个应用都拥有自己的生命周期：

• Load，决定加载哪个应用，并绑定生命周期bootstrap，获取静态资源
• Mount，安装应用，如创建 DOM 节点
• Unload，删除应用的生命周期Unmount，卸载应用，如删除 DOM 节点、取消事件绑定

这部分的内容事实上，也就是微前端的一个难点所在，如何以合适的方式来加载应用——毕竟每个前端框架都各自不同，其所需要的加载方式也是不同的。当我们决定支持多个框架的时候，便需要在这一部分进入更细致的研究。

拆分应用

按技术拆分

• 路由分发式。通过 HTTP 服务器的反向代理功能，来将请求路由到对应的应用上。
• 前端微服务化。在不同的框架之上设计通讯、加载机制，以在一个页面内加载对应的应用。
• 微应用。通过软件工程的方式，在部署构建环境中，组合多个独立应用成一个单体应用。
• 微件化。开发一个新的构建系统，将部分业务功能构建成一个独立的 chunk 代码，使用时只需要远程加载即可。
• 前端容器化。通过将 iFrame 作为容器，来容纳其它前端应用。
• 应用组件化。借助于 Web Components 技术，来构建跨框架的前端应用。

微件（widget），指的是一段可以直接嵌入在应用上运行的代码，它由开发人员预先编译好，在加载时不需要再做任何修改或者编译。

而微前端下的微件化则指的是，每个业务团队编写自己的业务代码，并将编译好的代码部署（上传或者放置）到指定的服务器上，在运行时，我们只需要加载相应的业务模块即可。对应的，在更新代码的时候，我们只需要更新对应的模块即可

按业务拆分

• 按照业务拆分。
• 按照权限拆分。
• 按照变更的频率拆分。
• 按照组织结构拆分。利用康威定律来进一步拆分前端应用。
• 跟随后端微服务划分。实践证明， DDD 与事件风暴是一种颇为有效的后端拆分模式，对于前端来说，它也颇有有效——直接跟踪后端服务。

每个项目都有自己特殊的背景，切分微前端的方式便不一样。即使项目的类型相似，也存在一些细微的差异。

转载地址：http://oovii.baihongyu.com/