什么是微前端

 

 

 

 

 

 

微前端架构模式和设计理念

微前端架构旨在解决单体应用在一个相对长的时间跨度下，由于参与的人员、团队的增多、变迁，从一个普通应用演变成一个巨石应用后，随之而来的应用不可维护的问题。

当我们的系统中有多个不同的子模块,并且子模块之间有相对独立且完整的功能体系时, 一旦子模块变得越来越多, 那么整个应用将变得非常庞大且臃肿,开发和维护成本大大提高。

如果在这种场景下我们采用SPA模式开发,那么项目后期将变得不可想象,页面首次加载将变得非常慢。 但是我们采用MPA(多页应用)模式,虽然解决了应用臃肿的问题, 但仍然存在很多有待处理问题,比如模块切换需要重新刷新页面, 公共组件无法共享,子模块之间,父子模块之间的通信问题,开发部署繁琐等.这写都是传统开发模式会遇到的问题.

面对以上问题, 如果有一种架构模式, 可以让我们在主应用中共享公共组件和状态(但是要保证子应用运行时内部的状态隔离), 并且不同子模块之间可以单独开发部署, 模块间切换不刷新页面, 并且模块之间,父子应用之间可以通过某种简单的方式实现通信,这样是不是就完美了?这就是微前端要解决的问题.

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

微前端生命周期和如何实现

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

基座模式：通过一个主应用，来管理其它应用。设计难度小，方便实践，但是通用度低。

自组织模式：应用之间是平等的，不存在相互管理的模式。设计难度大，不方便实施，但是通用度高。

不论种方式，都需要提供一个查找应用的机制，在微前端中称为服务的注册表模式。
不论是哪种微前端方式，也都需要有一个应用注册表的服务，它可以是一个固定值的配置文件，如 JSON 文件，又或者是一个可动态更新的配置，又或者是一种动态的服务。它主要做这么一些内容：

   应用发现：让主应用可以寻找到其它应用。
   应用注册：即提供新的微前端应用，向应用注册表注册的功能。
   第三方应用注册：即让第三方应用，可以接入到系统中。
   访问权限等相关配置。

应用在部署的时候，便可以在注册表服务中注册。如果是基于注册表来管理应用，那么使用基座模式来开发比较方便。

设计理念：
    中心化：应用注册表。这个应用注册表拥有每个应用及对应的入口。在前端领域里，入口的直接表现形式可    以是路由，又或者对应的应用映射。

    标识化应用。 我们需要一个标识符来标识不同的应用，以便于在安装、卸载的时候，能寻找到指定的应用。    一个简单的模式，就是通过康威定律来命名应用。

    应用生命周期管理。

    高内聚，低耦合。    

微前端生命周期和如何实现

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

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

从技术实践上，微服务架构可以采用以下几种方式进行实现：

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

    
    

 

 

 

 

 

qiankun 是一个基于 single-spa 的微前端实现库，旨在帮助大家能更简单、无痛的构建一个生产可用微前端架构系统。

2018 年 Single-SPA 诞生了， single-spa 是一个用于前端微服务化的 JavaScript 前端解决方案 ( 本身没有处理样式隔离， js 执行隔离 ) 实现了路由劫持和应用加载。

2019 年 qiankun 基于 Single-SPA, 提供了更加开箱即用的 API （ single-spa + sandbox + import-html-entry ） 做到了，技术栈无关、并且接入简单（像 i frame 一样简单）。

核心设计理念：

1. 简单：主微应用都能做到技术栈无关，操作简单：html entry及沙箱的设计，使微应用接入像iframe一样简单
2. 解耦/技术栈无关：将巨石应用拆解成若干的可以自治的松耦合微应用，确保微应用具    备独立开发独立运行的能力。

特性：
  1. 基于single-spa封装，提供了开箱即用的API
  2. 技术栈无关，任意技术栈的应用均可使用/接入,如：react/vue/angular/JQuery等其他框架
  3. HTML Entry接入方式
  4. 样式隔离，确保应用间样式互不影响
  5. JS沙箱，确保应用间全局变量/事件不冲突
  6. 资源预加载，在浏览器空闲时间预加载未打开的微应用资源，加速微应用打开速度。

Single-spa 是一个将多个单页面应用聚合为一个整体应用的 JavaScript 微前端框架。

乾坤属于上述实现方式中的：前端微服务化

子应用的生命周期：
      bootstrap:bootstrap 只会在微应用初始化的时候调用一次，下次微应用重新进入时会直接调用 mount 钩子，不会再重复触发 bootstrap。通常我们可以在这里做一些全局变量的初始化，比如不会在 unmount 阶段被销毁的应用级别的缓存等。
      mount：应用每次进入都会调用 mount 方法，通常我们在这里触发应用的渲染方法。
      unmount：应用每次 切出/卸载 会调用的方法，通常在这里我们会卸载微应用的应用实例。
      update：可选生命周期钩子，仅使用 loadMicroApp 方式加载微应用时生效。