微前端初识

概念

• 微前端是指存在于浏览器中的微服务。
• 微前端作为用户界面的一部分，通常由许多组件组成，并使用类似于React、Vue和Angular等框架来渲染组件。每个微前端可以由不同的团队进行管理，并可以自主选择框架。虽然在迁移或测试时可以添加额外的框架，出于实用性考虑，建议只使用一种框架。
• 每个微前端都拥有独立的git仓库、package.json和构建工具配置。因此，每个微前端都拥有独立的构建进程和独立的部署/CI。这通常意味着，每个仓库能快速构建。
• （摘自https://zh-hans.single-spa.js.org/docs/microfrontends-concept）

解决的问题

• 拆分模块，独立开发，提升效率
  • 微前端的意义就是将这些庞大应用进行拆分，并随之解耦，每个部分可以单独进行维护和部署，提升效率。
  • 代码量达到一定量的时候，单次构建时间很长，开发&发布效率极低
  • 代码库中依赖升级会影响整个应用，而代码量又非常大，导致回归成本极高
  • 变成一个非常臃肿的巨石应用，完全失去灵活性，无论是多人协作还是业务接入成本都会大大增加
• 逐步升级历史的旧的系统
  • 这些项目大多以采用老框架类似（Backbone.js，Angular.js 1）的B端管理系统为主，介于日常运营，这些系统需要结合到新框架中来使用还不能抛弃，对此我们也没有理由浪费时间和精力重写旧的逻辑。而微前端可以将这些系统进行整合，在基本不修改来逻辑的同时来同时兼容新老两套系统并行运行。

优点

（摘自single-spa文档）

• 在同一页面上使用多个前端框架 而不用刷新页面 (React, AngularJS, Angular, Ember, 你正在使用的框架)
• 独立部署每一个单页面应用
• 新功能使用新框架，旧的单页应用不用重写可以共存

要考虑的问题

• 当发现使用微前端反而使效率变低，简单的变更复杂那就说明微前端并不适用。
• 整体的微前端不仅仅是只将系统集成进来，而是整个微前端体系的完善，这其中就包括：
  1)：基座应用和微应用的自动部署能力。
  2)：微应用的配置管理能力。
  3)：本地开发调试能力。
  4)：线上监控和统计能力等等。
  只有将整个能力体系搭建完善，才能说是整个微前端体系流程的完善。

可选方案

• 除了传统的iframe、nginx等传统方法之外，重点是关注微前端框架的设计思想。
• 当下微前端主要采用的是组合式应用路由方案，该方案的核心是“主从”思想，即包括一个基座（MainApp）应用和若干个微（MicroApp）应用，基座应用大多数是一个前端SPA项目，主要负责应用注册，路由映射，消息下发等，而微应用是独立前端项目，这些项目不限于采用React，Vue，Angular或者JQuery开发，每个微应用注册到基座应用中，由基座进行管理，但是如果脱离基座也是可以单独访问，基本的流程如下图所示：
  
• 对于基座框架，需要解决以下问题：
  1. 路由切换的分发问题
  2. 主微应用的隔离和环境污染问题
  3. 通讯问题

微前端的可选框架

• single-spa
  • https://zh-hans.single-spa.js.org/docs/getting-started-overview
• 阿里系的飞冰 ICE
  • 这篇文章清楚介绍了微前端框架产生的背景需求和应用场景：https://zhuanlan.zhihu.com/p/88449415
• qiankun
  • qiankun 是对 single-spa 的一层封装，核心做了构建层面的一些约束以及沙箱能力，构建层面的约束（比如 umd）个人觉得会让子应用变复杂，不一定是一个好的方案
  • 微前端 qiankun 项目实践：https://mp.weixin.qq.com/s/KifQ7zO8gMv9uqBOhDG9bA

现状

• 微前端当下主要还是在解决工程问题，比如系统的解耦、多人协作之类的
• 探索沙箱机制，让二方业务更加安全的运行，同时让不可控的三方业务接入逐渐成为可能
• 针对微前端的业务场景逐步完善生态，比如一些鉴权之类的业务需求