N年前写的微前端笔记——初探微前端(一)

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

1.后端微服务与前端微服务的优势有何相似之处

优势	后端微服务	前端微服务
复杂度可控	体积小、复杂度低，每个微服务可由一个小规模开发团队完全掌握，易于保持高可维护性和开发效率	每一个UI业务模块由独立的前端团队开发，避免代码巨无霸，保持开发时的高速编译，保持较低的复杂度，便于维护，提升开发效率
独立部署	由于微服务具备独立的运行进程，所以每个微服务也可以独立部署	每个模块都可以单独部署，颗粒度可小到单个组件的UI独立部署，不对其他模块有影响
技术选型灵活	微服务架构下，技术选型去中心化的。每个团队可以根据自身服务的需求和行业发展的现状，自由选择最合适的技术栈	在同一项目下，可使用所有前端技术栈，比如同时时候vue和react
容错	当某一组件发生故障时，避免故障导致应用全局性不可用	单个模块发生错误，不影响全局
扩展	单块架构应用也可以横向扩展	每个服务可以独立横向扩展以满足业务伸缩

从上面的对比可以看出，以上5点，前后端微服务的有点几乎相似。

2. 那么我们何时需要前端微服务化？

按照百度张亚涛的说法，这就像一个人不戴眼镜，不是代表他完全不近视，而是说明他的度数还不高，等到足够高，他就不得不戴眼镜了。一样的，当我们前端项目复杂到一定程度，我们也就不得不使用微前端架构了，否则，在日益庞大的功能面前，我们会显得格外吃力，代码会格外臃肿。
当然，在我们实际开发业务时，除了张亚涛所述的情况外，还有其他情况，也会选择微前端服务化。总结如下：

• 技术栈老旧，相关技术栈开发人员少，功能扩展吃力，重构和维护成本高。
• 项目过于庞大，需要解耦。
• 单一技术栈无法满足要求。

3. 常用的微前端框架

• Mooa
• Single-Spa(本文介绍)
• Qiankun
• Icestark
• Ara Framework
• OpenComponents
• NUT
• PuzzleJs

4. 我们对比后选择Single-Spa

一个用于前端微服务化的JavaScript前端解决方案

• 使用该方案，你将获得如下益处：
  • (兼容各种技术栈)在同一个页面中使用多种技术框架(React, Vue, AngularJS, Angular, Ember等任意技术框架),并且不需要刷新页面.
  • (无需重构现有代码)使用新的技术框架编写代码,现有项目中的代码无需重构.
  • (更优的性能)每个独立模块的代码可做到按需加载,不浪费额外资源.
  • 每个独立模块可独立运行.

4.1 单体应用 与 微前端应用对比

• 单体应用架构
  
• 微前端应用架构